concept command in category kubernetes

This is an excerpt from Manning's book Learn Kubernetes in a Month of Lunches MEAP V07. Login to get full access to this book.

That may have felt like a pretty dull exercise, but it comes with two important takeaways. The first is that Kubectl is a hugely powerful tool - it's your main point of contact with Kubernetes, you'll be spending a lot of time with it, and it’s worth getting a solid understanding of what it can do. Querying the output from commands is a very useful way to see the information you care about, and because you can access all the details of the resource it's great for automation too. The second takeaway is a reminder that Kubernetes does not run containers - the container ID in the pod is a reference to another system which runs containers.

The new pod works in the same way as a pod created with the Kubectl run command - it's allocated to a node and it runs a container. My output in figure 2.13 shows that when I applied the manifest, Kubernetes decided it needed to create a pod to get the current state of the cluster up to my desired state. That’s because the manifest specifies a pod named hello-kiamol-3, and no such pod existed.

Figure 2.13 Applying a manifest sends the YAML file to the Kubernetes API which applies changes

Now that the pod is running, you can manage it in the same way with Kubectl - listing the details of the pod and running a port-forward to send traffic into the pod. The big difference is that the manifest is easy to share, and manifest-based deployment is repeatable. I can run the same Kubectl apply command with the same manifest any number of times and the result will always be the same - a pod named hello-kiamol-3 running my web container.

You can run commands in pods which are managed by a deployment without knowing the pod name, and you can view the logs of all pods which match a label selector.

# make a call to the web app inside the container for the
# pod we created from the deployment YAML file:
kubectl exec deploy/hello-kiamol-4 -- sh -c 'wget -O - http://localhost > /dev/null'
 
# and check that pod’s logs:
kubectl logs --tail=1 -l app=hello-kiamol-4

copy

Figure 2.18 shows the command running inside the pod container, which causes the application to write a log entry and we see that in the pod logs.

This is an excerpt from Manning's book Kubernetes in Action, Second Edition MEAP V05. Login to get full access to this book.

The FROM line defines the container image that you’ll use as the starting point (the base image you’re building on top of). In your case, you use the node container image, tag 12. In the second line, you add the app.js file from your local directory into the root directory of the image, under the same name (app.js). Finally, in the third line, you specify the command that Docker should run when you execute the image. In your case, the command is node app.js.

To run the proxy, execute the command:

Listing 4.3 Using kubectl explain to learn about an object kind
$ kubectl explain nodes
KIND:     Node
VERSION:  v1
 
DESCRIPTION:
     Node is a worker node in Kubernetes. Each node will have a unique
     identifier in the cache (i.e. in etcd).
 
FIELDS:
   apiVersion   <string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest...
 
   kind <string>
     Kind is a string value representing the REST resource this object
     represents. Servers may infer this from the endpoint the client...
 
   metadata     <Object>
     Standard object's metadata. More info: ...
 
   spec <Object>
     Spec defines the behavior of a node...
 
   status       <Object>
     Most recently observed status of the node. Populated by the system.
     Read-only. More info: ...

copy

Figure 6.7 The exec liveness probe runs the command inside the container

This is an excerpt from Manning's book GitOps and Kuberentes MEAP V06 epub. Login to get full access to this book.

The Git version control system provides a mechanism where proposed changes can be committed to a branch or fork and then merged to the main branch through a pull request. It was originally developed to support the e-mail based workflows which were used in a Linux kernel development community. In 2005 Git introduced a ‘request-pull’ command. The command generates a human-readable summary of all the changes which can be mailed to the project maintainer manually. The pull request collects all the changes to all the files in the repository and presents the differences for code review and approval.

Listing 2.1 nginx Pod Manifest (nginx-pod.yaml)

kind: Pod                                #A
apiVersion: v1
metadata:                                #B
  name: nginx
spec:                                    #C
  restartPolicy: Always
  volumes:                               #D
    - name: data
      emptyDir: {}
  initContainers:
  - name: nginx-init                     #E
    image: docker/whalesay
    command: [sh, -c]
    args: [echo "<pre>$(cowsay -b 'Hello Kubernetes')</pre>" > /data/index.html]
    volumeMounts:                        
    - name: data
      mountPath: /data
  containers:
  - name: nginx                          #F
    image: nginx:1.11
    volumeMounts:
    - name: data
      mountPath: /usr/share/nginx/html

copy

Now that your NGINX Pod is running use the kubectl exec command to get a shell on the running container. HINT: The command would be something like kubectl exec -it <POD_NAME> -- /bin/bash. Poke around in the shell. Run ls, df, and ps -ef as well as other Linux commands. What happens if you terminate the nginx process?

This is an excerpt from Manning's book Kubernetes in Action. Login to get full access to this book.

After completing the installation, you can create a Kubernetes cluster with three worker nodes using the command shown in the following listing.

In all the examples so far, you’ve created containers that ran the default command defined in the container image, but Kubernetes allows overriding the command as part of the pod’s container definition when you want to run a different executable instead of the one specified in the image, or want to run it with a different set of command-line arguments. We’ll look at how to do that now.

7.2.2. Overriding the command and arguments in Kubernetes

In Kubernetes, when specifying a container, you can choose to override both ENTRYPOINT and CMD. To do that, you set the properties command and args in the container specification, as shown in the following listing.

Listing 7.3. A pod definition specifying a custom command and arguments

kind: Pod
spec:
  containers:
  - image: some/image
    command: ["/bin/command"]
    args: ["arg1", "arg2", "arg3"]


!@%STYLE%@!
{"css":"{\"css\": \"font-weight: bold;\"}","target":"[[{\"line\":4,\"ch\":4},{\"line\":4,\"ch\":29}],[{\"line\":5,\"ch\":4},{\"line\":5,\"ch\":34}]]"}
!@%STYLE%@!

copy

In most cases, you’ll only set custom arguments and rarely override the command (except in general-purpose images such as busybox, which doesn’t define an ENTRYPOINT at all).