Kubernetes Discovery - Quebec

Shraneel1
Tera Contributor

Hi 

I am trying to pilot Kubernetes discovery in our environment. I have been following the following article and documentation for this. These are:

The documentation talks about url connectivity typically https://<kubeapiserver>. In our environment, there is a load balancer fronting to access kube-API as per production architecture for k8s. 

find_real_file.png

 

My question is, for k8s discovery, do we need to point directly to the k8s master nodes (where the kubeapi server actually lives and shares a distributed architecture) or pointing to the kube-api load balancer which will in turn load-balance the connection to one of the master nodes for running REST API calls?

1 ACCEPTED SOLUTION

Shraneel1
Tera Contributor

After much troubleshooting, it turned out to be Kubernetes authentication issue. Running curl commands directly from MID servers to connect to KubeAPI Server suggested that it was authentication issue and we started to address it from there onwards. 

We now have successful k8s discovery.  

View solution in original post

3 REPLIES 3

Rahul Priyadars
Giga Sage
Giga Sage

It Should be K API server host. But since you have a LB scenario for K API also you can try using LB too.

It should work with LB too but i do not have environment to TRY this.

 

Regards

RP

Shraneel1
Tera Contributor

I have set up to point to the load balancer, ran the serverless discovery and seem not able to discover everything.

find_real_file.png

It only runs Pattern Launcher: Kubernetes and gives me input payload as such as a result.

find_real_file.png

 

 

I think the permission on k8s is setup correctly. here is the yaml extract of the setup:

find_real_file.png

When setting up up the Serverless pattern on the discovery schedule, I have setup:

*Pattern = Kubernetes

Run Child Patterns - checked

Parameters:

   url - "https://k8s-test-apiproxy-vip-dc2..." (FQDN of my KubeAPI VIP) - confirmed on MID server that connectivity to the VIP address via TCP 443 is working.

   credentialsAlias - "k8s" where k8s points to a k8s credentials with username and password.

   namespace - * or "service-now" - tried wild card and "service-now" namespace as defined by k8s admin

 

I am not sure where we are going wrong with this setup. 

Shraneel1
Tera Contributor

After much troubleshooting, it turned out to be Kubernetes authentication issue. Running curl commands directly from MID servers to connect to KubeAPI Server suggested that it was authentication issue and we started to address it from there onwards. 

We now have successful k8s discovery.