<

Starting to Learn Kubernetes a Step Behind - 04. kubectl -

Story

  1. Starting to Learn Kubernetes a Step Behind - 01. Environment Selection -
  2. Starting to Learn Kubernetes a Step Behind - 02. Docker For Mac -
  3. Starting to Learn Kubernetes a Step Behind - 03. Raspberry Pi -
  4. Starting to Learn Kubernetes a Step Behind - 04. kubectl -
  5. Starting to Learn Kubernetes a Step Behind - 05. workloads Part 1 -
  6. Starting to Learn Kubernetes a Step Behind - 06. workloads Part 2 -
  7. Starting to Learn Kubernetes a Step Behind - 07. workloads Part 3 -
  8. Starting to Learn Kubernetes a Step Behind - 08. discovery&LB Part 1 -
  9. Starting to Learn Kubernetes a Step Behind - 09. discovery&LB Part 2 -
  10. Starting to Learn Kubernetes a Step Behind - 10. config&storage Part 1 -
  11. Starting to Learn Kubernetes a Step Behind - 11. config&storage Part 2 -
  12. Starting to Learn Kubernetes a Step Behind - 12. Resource Limitations -
  13. Starting to Learn Kubernetes a Step Behind - 13. Health Checks and Container Lifecycle -
  14. Starting to Learn Kubernetes a Step Behind - 14. Scheduling -
  15. Starting to Learn Kubernetes a Step Behind - 15. Security -
  16. Starting to Learn Kubernetes a Step Behind - 16. Components -

Last Time

In Starting to Learn Kubernetes Late - 03. Raspberry Pi -, we introduced Kubernetes to the RaspberryPi environment. Now that we've confirmed it's working properly, we want to start learning right away.

References

I will proceed by reading the "Kubernetes Complete Guide". The source code is here.

In previous posts, I was referring to Introduction to Kubernetes, but the Kubernetes Complete Guide was better for comprehensive learning, so I used that.

kubectl

Kubectl is a command line interface for running commands against Kubernetes clusters

https://kubernetes.io/docs/reference/kubectl/overview/

It is a CLI for operating Kubernetes.

I have organized the ones I often use and summarized the ones that should be minimally remembered when starting.

1. apply

pi@raspi001:~ $ cat << EOF > sample-pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: sample-pod
spec:
 containers:
   - name: nginx-container
     image: nginx:1.12
EOF
pi@raspi001:~ $ kubectl apply -f sample-pod.yaml
pod/sample-pod created

In Kubernetes, it seems common to create a manifest file and apply it with apply. This is not only for new creation, but also for updates and deletions. There are other CLIs such as create, replace, and delete, but there is not much need to distinguish them because the same operations can be done with apply. The manifest files registered with apply are saved as history.

Kubernetes: Operation of kubectl apply

2. set, get

pi@raspi001:~ $ kubectl set image pod sample-pod nginx-container=nginx:1.13
pod/sample-pod image updated
pi@raspi001:~ $ kubectl get pod sample-pod
NAME         READY   STATUS    RESTARTS   AGE
sample-pod   1/1     Running   1          13m

In kubectl, you need to tell which resource type (pod,service,etc) and which resource name it is. There is also a label as a filtering function.

# sample-pod-label.yaml
apiVersion: v1
kind: Pod
metadata:
 name: sample-pod
  labels:
   env: prod
   app: sample
spec:
 containers:
   - name: nginx-container
     image: nginx:1.12
pi@raspi001:~ $ kubectl get pod -l env=prod
No resources found.
pi@raspi001:~ $ kubectl apply -f sample-pod-label.yaml
pod/sample-pod configured
pi@raspi001:~ $ kubectl get pod -l env=prod
NAME         READY   STATUS    RESTARTS   AGE
sample-pod   1/1     Running   0          7m23s

If you need more detailed information, use describe.

pi@raspi001:~ $ kubectl describe pod sample-pod
Name:               sample-pod
...

※ There is also a method called edit that allows you to edit directly, but it should only be used for temporary measures. It would be meaningless to have a declarative file.

By the way, you can abbreviate service as svc. ※ (Memo) Short resource name in kubectl command

3. debug

pi@raspi001:~ $ kubectl exec -it sample-pod /bin/sh
# exit
pi@raspi001:~ $ kubectl logs sample-pod
pi@raspi001:~ $ kubectl cp sample-pod.yaml sample-pod:/var/sample-pod.yaml
pi@raspi001:~ $ kubectl port-forward sample-pod 8888:80
Forwarding from 127.0.0.1:8888 -> 80
Forwarding from [::1]:8888 -> 80

All of them are operations against pod, so there is no need to specify the resource type. You will use them when you need them in development.

99. top

Unfortunately, I couldn't get this to work... 😥😥 I don't need it that much right now, so I'll put it off for now. It seems to have something to do with calico or flannel, but I don't understand it well enough to solve it.

Cleaning Up

pi@raspi001:~ $ kubectl delete pod sample-pod
pod "sample-pod" deleted

If you are dealing with multiple pods, apply --prune is better than delete, but this time it's a single pod, so I directly delete it.

Conclusion

At the beginning, I was anxious about how much I had to learn, but when I actually started, it wasn't as much as I thought. (I believe there are still many things I don't know) I gradually got used to the habit of specifying the resource type and resource name as a rule. I also learned the rough technique of displaying everything with kubectl get all when it's troublesome. (laughs)

The next one is here.

If it was helpful, support me with a ☕!

Share

Related tags