Kubernetes 101 : Upgrading deployments and troubleshooting containers



After modifying a deployment's Yaml file and before "applying" it - kubectl apply -, we could check the changes that our new Yaml file will make - f
or example after increasing the number of nginx replicas to three to deal with the increasing workload -.


We could do that using the below command before applying the changes:


By applying the above Yaml file, we know using the "kubectl diff" command that the number of replicas will change.

Remark:

The "kubectl diff" command has also the advantage of showing us the difference between the actual state of a deployment and the last applied Yaml file in case someone increased the replicas, for example using the command line which will not be reflected in the  deployment's Yaml file, for example: 


The above command scales up the "nginx-dep" deployment to "3" replicas.

Forwarding a Container Port:

We can forward a container's port to a port on the local host. We could then connect directly to that container.

We use this method mainly for troubleshooting purposes. 


Then we could access our application - running inside the container -  using a program specific to that application like for example "mongosh" for mongoDB - using the port number of the host -.
If the application uses HTTP, we could access it through our browser.

We could also troubleshoot a container by opening a shell in it using the below command - using a debian image -:


Then we could run commands from the shell - ping, ip addr, ... -.

In case we have more than one container running inside a pod, we would need to specify the container we want to connect to using the "-c" flag as we can see below:


Remark:

For the "kubectl exec" command to work, the pod needs to be in a  running state, we could check that using the below command:


Troubleshooting the DNS:

We start by running an nginx image as follows:


The "--expose" parameter exposes a deployment as service on port "88".

The service_nginx gets an IP address and a fully qualified name that we could check from another debian pod as below:


The above command queries the kube-dns for the service_nginx service.
We get the IP of the service and its fully qualified name.

Remark:

The kube-dns is a service through which we access the coredns pods.

Below is a short explanation of some of the used parameters: 
  • --rm : instructs kubernetes to delete the nginx image when its container stops running.
  • -it : runs the container in an interactive mode and "attaches" the output of the container to our terminal so that we could interact with it.
  • --restart=Never : kubernetes doesn't restart the containers once they exit.
  • --command --: specifies the command to be run.

Remark:

The "--command" parameter overrides the "entrypoint" specified in the Dockerfile image.

Comments

Leave as a comment:

Archive