16 Video Tutorial for Beginners Summary of Operations #
Hello, I’m Chrono.
After completing the previous 7 lessons of text+audio, today we have another video lesson to review and summarize the knowledge of Kubernetes in the “Beginner’s” section. This video will also focus on practical demonstrations rather than theoretical explanations.
First, we will start minikube in our local environment and log in to the virtual node to see components such as apiserver, etcd and scheduler. Then, we will use the command line tool kubectl to operate Kubernetes and create API objects such as Pod, Job, CronJob, ConfigMap, and Secret.
Let’s move on to the video.
I. minikube environment #
Key points of the video:
We will start with the minikube environment. We won’t demonstrate the installation process, assuming you have already downloaded the minikube and kubectl binary files successfully following the steps in Lecture 9.
Let’s first check the version of minikube:
minikube version
The current latest version is 1.25.2. Now let’s check its status:
minikube status
You can see that none of the Kubernetes components are running, and the cluster is in a stopped state.
Now let’s start the minikube cluster using minikube start:
minikube start --kubernetes-version=v1.23.3
Wait for a moment and pay attention to the emoji in the prompt. A local mini Kubernetes cluster is created. From the prompt, you can see that this Kubernetes cluster’s version is v1.23.3 and it is running on Docker 20.10.12.
Now let’s check the status of minikube again:
minikube status
You can see that the core components of Kubernetes, such as kubelet and apiserver, are running.
The command minikube node list can be used to view the list of nodes in this mini cluster:
minikube node list
By default, minikube only creates one node, and here you can see its IP address is “192.168.49.2”.
We can directly log in to this node using the command minikube ssh. It is a virtual machine running inside another virtual machine, and you can execute any Linux operations in it:
uname -a # Display Ubuntu operating system
docker version # There is also a Docker running on this node, but it actually reuses the Docker on the host machine
docker ps # You can see the Kubernetes processes running in containers in this node, such as pause, scheduler, etc.
exit
After checking the status of the minikube cluster, let’s use kubectl to operate Kubernetes. First, let’s check the version:
kubectl version
The displayed version is 1.23.3. Use kubectl get pod to check the running applications in the current cluster. You will find that it is empty.
Now let’s use the run command to run an Nginx Pod:
kubectl run ngx --image=nginx:alpine
Now if we check the Pod with kubectl get pod, we will see that one Pod is running.
The Nginx Pod belongs to the default namespace, while the core components such as apiserver are in the kube-system namespace. You can use the -n parameter to view the Pods running in kube-system:
kubectl get pod -n kube-system
You can see that there are Pods running in this namespace, such as apiserver, etcd, scheduler, controller manager, coredns, kube-proxy, etc.
II. Operating API objects with kubectl #
Key points of the video:
Next, let’s focus on operating Kubernetes API objects with kubectl.
First, let’s check all the API objects supported by the current Kubernetes version using the kubectl api-resources command:
kubectl api-resources
The output contains many information. You can see that the abbreviation for Pod is po with API version v1, and the abbreviation for CronJob is cj with API version batch/v1. This information is very useful when writing YAML manifest files.
Next, let’s use another commonly used command kubectl explain to display detailed information about the fields of an API object. For example, let’s check the Pod:
kubectl explain pod
kubectl explain pod.metadata
kubectl explain pod.spec
kubectl explain pod.spec.containers
With this handy documentation, we won’t be at a loss when writing YAML files.
To create a YAML template, we need to use two special parameters, --dry-run=client and -o yaml. Let’s define it as an environment variable:
export out="--dry-run=client -o yaml"
Then let’s create a Pod YAML using kubectl run:
kubectl run ngx --image=nginx:alpine $out > pod.yml
Use vi to edit this file and delete unnecessary fields. Now we have a YAML manifest file representing an API object.
III. Pod object #
Key points of the video:
Now let’s take a look at the edited Nginx Pod object. It defines a name ngx-pod and has two labels env and owner. In the spec field, it defines that there is only one container in the Pod with the image nginx:alpine and the external port is 80.
Now we can use the kubectl apply command to create this Pod and use kubectl get pod to check its status:
kubectl apply -f ngx-pod.yml
kubectl get pod
The kubectl logs command will output the running logs of Nginx:
kubectl logs ngx-pod
We can also use kubectl exec to enter the container inside the Pod, remember to use --:
kubectl exec -it ngx-pod -- sh
nginx -v
uname -a
exit
Finally, let’s use kubectl delete to delete this Pod:
kubectl delete -f ngx-pod.yml
IV. Offline Business Objects: Job, CronJob #
Key points of the video:
After understanding the basic operations of Pods, let’s take a look at the Job and CronJob objects for offline businesses.
First, create a Job template file using kubectl create:
kubectl create job echo-job --image=busybox $out
After saving and editing it, we can obtain a Job object. Let’s take a look using vi. This Job is very simple, executing the echo command and outputting “hello world”. Note that its restart policy is set to “OnFailure”, which means the container will be restarted in place if it fails.
Now let’s create the Job object using the kubectl apply command:
kubectl apply -f job.yml
After creating it, we can check the status of the Job and its corresponding Pod using kubectl get job and kubectl get pod, respectively. We can also retrieve the execution result of the Pod using the kubectl logs command:
kubectl get job
kubectl get pod
kubectl logs echo-job-l52l7
Similarly, CronJobs can also generate template files automatically.
kubectl create cj echo-cj --image=busybox --schedule="" $out
vi cronjob.yml
In the CronJob object, pay attention to the use of the jobTemplate field to define another Job. Then, in the schedule field, use cron syntax to define the scheduling rule. In this case, it will run every minute.
The usage of CronJobs is almost the same as Jobs. After creating them using the apply command, we can use get to check the status of the job:
kubectl apply -f cronjob.yml
kubectl get cj
kubectl get pod
Lastly, let’s use the delete command to delete these two API objects:
kubectl delete -f job.yml
kubectl delete -f cronjob.yml
V. Configuration objects: ConfigMap and Secret #
Key points of the video lesson:
Next, let me show you the configuration objects ConfigMap and Secret in Kubernetes.
As usual, let’s use the kubectl create command to create a template file for ConfigMap. However, this time, we need to add an additional parameter --from-literal to generate some data from a literal value.
kubectl create cm info --from-literal=k=v $out
The creation method for Secrets is similar, but note that the command format is slightly different from ConfigMap. Use generic to represent general confidential information.
kubectl create secret generic user --from-literal=name=root $out
Let’s take a look at the edited YAML files:
vi cm.yml
Here, 4 configuration items are defined. Note that ConfigMap requires string values, so it’s best to enclose them in quotes to avoid interpreting them as numbers, which could lead to errors.
vi secret.yml
In the Secret, 3 configuration items are defined. Since they are base64 encoded, we can’t see the original values directly. However, we can decode them using the base64 -d tool in the command line, for example, to view the username:
echo cm9vdA== | base64 -d
Now, let’s create these two objects:
kubectl apply -f cm.yml
kubectl apply -f secret.yml
Then, check the status of these objects:
kubectl get cm
kubectl describe cm info
ConfigMap is displayed in plain text:
kubectl get secret
kubectl describe secret user
On the other hand, Secrets are of the type “Opaque” and cannot be directly viewed.
Next, let’s inject these configuration information into a Pod in the form of a volume. We need to add the “volumes” and “volumeMounts” fields in the Pod:
vi vol-pod.yml
In this YAML file, I have defined two volumes for ConfigMap and Secret: cm-vol and sec-vol. Then, in the volumeMounts field, they are mounted to the tmp directory.
After creating it using the kubectl apply command, we can still use kubectl exec to enter the Pod and see how the configuration information is loaded:
kubectl apply -f vol-pod.yml
kubectl get pod
kubectl exec -it vol-pod -- sh
cd /tmp
ls # Loaded as two directories
cd cm-items/
cat greeting
cd ..
cd sec-items/
cat pwd # Already decoded with base64
VI. Building WordPress in Kubernetes #
Key points of the video lesson:
Finally, let’s build WordPress in Kubernetes. The YAML files for this task are already prepared. We just need to create them one by one with the apply command.
First, let’s start with MariaDB:
kubectl apply -f mariadb-pod.yml
kubectl get pod -o wide
We need to check the IP address of the MariaDB pod, which is 172.17.0.? here. Then, let’s modify the WordPress YAML file, changing the value of the host environment variable to the address of MariaDB, and then create the WordPress pod:
kubectl apply -f wp-pod.yml
kubectl get pod -o wide
Now, both of these pods are running correctly. We need to expose the port of WordPress. We can use the kubectl port-forward command:
kubectl port-forward wp-pod 8080:80 &
Then, we can use Docker to run an Nginx container and proxy this port:
./wp_proxy.sh
docker ps
Now, let’s open Safari browser on Mac and enter the IP address of the virtual machine, <http://192.168.10.208>. We should be able to see the WordPress installation interface.
Homework #
Today’s lesson is a hands-on exercise. Remember to try it out yourself, as the learning effect is completely different from just watching.
Feel free to share your learning experience and any questions you may have in the comments section. See you in the next lesson.