I am new to K8s and I am trying to migrate my service (which currently utilizes docker-compose.yml) to k8s. My service
deploys zipkin and elasticsearch
and these can be accessed at 'localhost:9411' and 'localhost:9200' respectively.
The most commonly used solution I found online was 'kompose' and I tried to run,
kompose up
2.
kompose convert
kubectl apply -f *****-deployment.yaml, ****-service.yaml
Once I finish this, I run kubectl get pods and I can see my deployments, but elasticsearch and zipkin are no more responsive on their respective localhost ports.
Ouput of 'kubectl get pods'
Output of 'docker ps'
Output of curl http://localhost:9200
Can someone tell me why this is happening and how to debug?
It is solved now; all I had to do was port forwarding.
kubectl port-forward zipkin-774cc77659-g929n 9411:9411
Thanks,
By default you service is exposed as ClusterIP, in this case your service will be accessible from within your cluster.
You can use port forwarding "With this connection in place you can use your local workstation to debug your application that is running in the pod" as described in the answer above.
Another approach is to use other "service types" like NodePort.
You can find more information here Publishing services (ServiceTypes)
Related
I am having real trouble understanding how I am suppose to debug my current situation. I have followed the setup instructions from https://docs.substra.org/en/stable/contributing/getting-started.html#
There is a backend service which was created as a ClusterIP, and therefore can not be accessed from the host.
I created a load balancer for this purpose. using the command
kubectl expose deployment deployment_name --port=8000 --target-port=8000 \
--name=lb_service --type=LoadBalancer
However, the attempt to access the backend service failed when I use the LoadBalancer Ingress ip and NodePort port with a connection timeout. I like to see the relevant logs to check where the problem occurred. However, apparently kubectl logs service only shows logs for pods, whereas the load balancer, according to the kubectl expose command is attached to the deployment. Therefore, I am not able to see any logs related either to the load balancer service, or the deployment component.
When I looked at the pod which is supposed to be hosting the deployment, the log showed no error.
Can someone point out where do I look for logs that can debug this failed connectivity?
You probably need to look at the ingress logs, se this page from the documentation: https://kubernetes.github.io/ingress-nginx/troubleshooting/.
it is true that you can only get logs from pods. However, that is sufficient to see the relevant error messages.
I am deploy kubernetes UI using this command:
kubectl apply -f kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml
And it response "Unable to connect to the server: dial tcp 185.199.110.133:443: i/o timeout"
I behind proxy, how can i fix it?
All the services that you deployed via the supplied url don't have a kind specified. This means they will be using the default service type which is ClusterIP.
Services of Kind ClusterIP are only accessible from inside your Kubernetes Cluster.
If you want the Dashboard to be accessible from outside your Cluster, you will need a service of type NodePort. A NodePort Service will assign a random high number port on all your nodes on which your application, in this case the k8s dashboard, will be accessible via ${ip-of-any-node}:${assigned-nodeport}.
For more information, please take a look at the official k8s documentation.
If your cluster is behind a proxy, also make sure, that you can reach your clusters node's external ip from wherever you are trying to send the request from.
In order to find out what port number has been assigned to your NodePort service use kubectl describe service ${servicename} or kubectl get service ${servicename} -o yaml
Influxdb 1.8 is deployed on kubernets using helm charts. influx db is deployed as Stateful Set that exposes a service with one running pods. Am able to ssh into running pods using kubectl exec command and its running fine. I can also see databases using influx cli after logging into pods
But i need to access this influx db on my local system to execute queries directly from my system using curl command. Deployed influxdb has no external IP/DNS. It ha internal endpoint that usually starts with 10...*
Can anybody guide me on how can i access influxdb on my local system using curl command?
You can use the kubectl port-forward command. You can use it to either map a Pod or a Service TCP port to a port on your local machine:
> kubectl port-forward service/your-influxdb-service 8086:8086
^ ^
| |
local port remote/service port
While that command is running, kubectl will forward all connections to your local port 8086 to the same port of your InfluxDB service. All traffic will be funneled through kubectl and your API server, so this is not exactly suited for high-throughput scenarios, but should be sufficient for occasional debugging and testing.
I've been learning Kubernetes recently and just came across this small issue. For some sanity checks, here is the functionality of my grpc app running locally:
> docker run -p 8080:8080 -it olamai/simulation:0.0.1
< omitted logs >
> curl localhost:8080/v1/todo/all
{"api":"v1","toDos":[{}]}
So it works! All I want to do now is deploy it in Minikube and expose the port so I can make calls to it. My end goal is to deploy it to a GKE or Azure cluster and make calls to it from there (again, just to learn and get the hang of everything.)
Here is the yaml I'm using to deploy to minikube
And this is what I run to deploy it on minikube
> kubectl create -f deployment.yaml
I then run this to get the url
> minikube service sim-service --url
http://192.168.99.100:30588
But this is what happens when I make a call to it
> curl http://192.168.99.100:30588/v1/todo/all
curl: (7) Failed to connect to 192.168.99.100 port 30588: Connection refused
What am I doing wrong here?
EDIT: I figured it out, and you should be able to see the update in the linked file. I had pull policy set to Never so it was out of date 🤦
I have a new question now... I'm now able to just create the deployment in minikube (no NodePort) and still make calls to the api... shouldn't the deployment need a NodePort service to expose ports?
I checked your yaml file and it works just fine. But only I realized that you put 2 types for your services, LoadBalancer and also NodePort which is not needed.
As if you check from this documentation definition of LoadBalancer, you will see
LoadBalancer: Exposes the service externally using a cloud provider’s
load balancer. NodePort and ClusterIP services, to which the external
load balancer will route, are automatically created.
As an answer for your next question, you probably put type: LoadBalancer to your deployment yaml file, that's why you are able to see NodePort anyway.
If you put type: ClusterIP to your yaml, then service will be exposed only within cluster, and you won't able to reach to your service outside of cluster.
From same documentation:
ClusterIP: Exposes the service on a cluster-internal IP. Choosing this
value makes the service only reachable from within the cluster. This
is the default ServiceType
I'm installing Prometheus on GKE with Helm using the standard chart as in
helm install -n prom stable/prometheus --namespace hal
but I need to be able to pull up the Prometheus UI in the browser. I know that I can do it with port forwarding, as in
kubectl port-forward -n hal svc/prom-prometheus-server 8000:80
but I'm being told "No, just expose it." Of course, there's already a service so just doing
kubectl expose deploy -n hal prom-prometheus-server
isn't going to work. I assume there's some value I can set in values.yaml that will give me an external IP, but I can't figure out what it is.
Or am I misunderstanding when they tell me "Just expose it"?
It is generally a very bad idea to expose Prometheus itself as it has no authentication mechanism, but you can absolutely set up a LoadBalancer service or Ingress aimed at the HTTP port if you want.
More commonly (and supported by the chart) you'll use Grafana for the public view and only connect to Prom itself via port-forward when needed for debugging.
Agree that it's a bad idea to expose prom publicly, but if its a demo it's ok.
Run:
kubectl expose deploy -n hal prom-prometheus-server --type=LoadBalancer
Kubernetes will create a GCP Load Balancer with an external IP.
Hope it helps!