In the column Docker for WEB Developers, I introduced the use of containers in the development process. Although the whole column is not finished yet, I think the existing content should give you a general idea of the concept of containers and what they can do.
This article is a reading note, I think the content can further understand the application of container technology.
What is Kubernetes?
Kubernetes (K8S for short) is a portable, extensible open source platform for managing containerized workloads and services that facilitates declarative configuration and automation. Kubernetes has a large and rapidly growing ecosystem. Kubernetes’ services, support and tools are widely available.
Pod is introduced
A POD is a set of juxtaposed containers that are the basic build model for Kubernetes. All containers (Dockers) of a POD run on the same worker node, never across multiple worker nodes.
Pod is the most important core concept in Kubernetes. This paper mainly focuses on the concept, management and use of POD.
Why do YOU need a POD instead of just using a container
Multiple containers are better than a single container containing multiple processes. If a container runs multiple processes, it is very difficult to view the run logs of each process, which is not conducive to troubleshooting.
Understand the pod
A POD is a logical host that behaves much like a physical host or virtual machine in a non-container world.
Since multiple processes cannot be gathered in a single container, pods are required to manage the container as a unit. Under a POD containing a container, closely related processes can run simultaneously while maintaining some isolation.
Partial isolation between containers in the same Pod
All containers in the same POD run under the same network and UTS namespace, so they all share the same hostname and network interface. When it comes to file systems, each container’s file system is completely isolated from the other containers.
How do containers share the same IP and port space
Because containers in a POD run in the same Network namespace, they share the same IP address and port space and can communicate with other containers in the same POD via localhost.
For ports, multiple processes running in containers in the same POD bound to the same port number will cause conflicts, and containers in different pods will never have port conflicts.
Flat inter-POD network
All pods in the Kubernetes cluster are in the same shared network address space and can be accessed through IP addresses.
Manage containers properly with PODS
Because pods are lightweight, you can have as many pods as possible with little extra overhead, organizing your applications into multiple pods, each containing only closely related components or processes.
- Spread multiple tiers of applications across multiple Pods: If you have a two-node Kubernetes cluster, if you use only one POD, you will always use only one working node and not fully utilize the computing resources on the second node. It is reasonable to deploy the front-end and back-end devices on different nodes.
- Multiple PODS based on capacity expansion: A Pod is a basic unit of capacity expansion. If all pods are deployed in one Pod, the capacity expansion will affect all application layers. For example, the front end and back end cannot be expanded or shrunk only on the back end. Adverse to resource utilization.
- When to use multiple containers in A Pod: An application consists of a main process and one or more helper processes
- Determine when to use multiple containers in a Pod: Containers should not contain multiple processes, and pods should not contain multiple containers that do not need to run on the same host
Create a Pod with a YAML or JSON description file
Description files are created using YAML and can be stored in a version control system for easy maintenance
Main parts:
* 'metadata' : contains the name, namespace, label, and other information about the container. * 'spec' : contains the actual description of the pod contents, such as the container, volume, and other data. * 'status' : contains current information about the running POD, such as conditions, description, status, and IPCopy the codeCreate a simple YAML description file for the POD
ApiVersion: v1 kind: Pod metadata: name: kubia-manual // Pod name spec: containers: - image: luksa/kubia name: Kubia ports: - containerPort: 8080 // Application listening port protocol: TCPCopy the codeCreate pod using Kubectl create
kubectl create -f kubia-manual.yaml
Get the full definition of a running Pod
- Return yamL format:
kubectl get po kubia-manual -o yaml - Return json format:
kubectl get po kubia-manual -o json
View the newly created POD in the POD list
kubectl get pods
Viewing Application Logs
Use the docker logs
Containerized applications log to standard output and standard error streams without writing to files, allowing users to view them in a simple, standard way.
The container run redirects these streams to a file, which can be obtained by using the following command:
docker logs <container id>
You can SSH in to the node where the POD is running and view its logs using the docker logs command.
Using kubectl logs
To view the pod logs, simply run the following command on your local machine: kubectl logs kubia-manual
Get logs for multiple containers of PODS
To obtain the pod logs of multiple containers, specify the container name. Run -c < container name > to explicitly specify the container name
kubectl logs kubia-manual -c kubia
Send the request to the POD
Forwards the local network port to the port in the POD
Kubernetes allows configuration ports to be forwarded to this POD, such as local port 8888 to port 8080 of Kubia-Manual Pod. This allows you to connect to a POD through a local port.
kubectl port-forward kubia-manual 8888:8080
Connect to pod through port forwarding
On another terminal, you can send an Http request to pod by running the proxy on localhost:8888:
curl localhost:8888
Organize pods with tags
In practice, as the number of PODS increases, the use of tags can be effectively organized.
Example: Microservices architecture
The number of deployed microservices can easily exceed 20. In the actual operation process, version release and rapid expansion can easily lead to chaos. As shown in figure:
It is clear that there is a need for a way to operate on all or some pods in a single operation, rather than on each pod.
Therefore, you need to organize pods using tags, a simple but powerful Kubernetes feature that organizes pods as well as other resources.
As in the previous example, add two tags to pod:
app: Specifies which applications, components, or microservices the POD belongs torel: Specifies the version of the application running in pod, such as stable and Beta
Specify the label when creating the POD
kubia-manual-with-labels.yaml
ApiVersion: v1 kind: Pod metadata: name: kubia-manual-v2 labels: // Attach labels to Pod creation_method: manual env: prod spec: containers: - image: luksa/kubia name: kubia ports: - containerPort: 8080 protocol: TCPCopy the codeRun the kubectl create -f kubia-manual-with-alllabs. yaml command to create one
No labels are listed by default. To view them, run the following command:
Run kubectl get Po –show labels
If you need to filter some tags, you can specify it with the -l option, for example:
kubectl get po -L creation_method,env
Modify the label of an existing POD
Labels can be added and modified on existing pods. Add labels to kubia-manual using the following command:
kubectl label po kubia-manual creation_method=manual
Change the tag env=prod for pod named kubia-manual-v2 to env= DEBUG, using the –overwrite option to change the existing tag.
kubectl label po kubia-manual-v2 env=debug --overwrite
List the POD subset through the label selector
Before we understand the use of tags, now let’s introduce the tag selector, the actual use of the tag must be combined with the tag selector to play its role.
List the pods using the label selector
-
Kubectl get Po -l creation_method=manual: kubectl get Po -l creation_method=manual
-
Kubectl get po-l env lists the pod containing the env tag: kubectl get po-l env
-
Kubectl get po-l ‘! env’
-
Other options:
creation_method! =manual: Select pod with creation_method tag and value not equal to manualenv in (prod,devel): Select pod with env tag and value prod or develenv notin (prod,devel): Select pod with env tag that is not pord or devel
Use multiple criteria in the label selector
Multiple criteria are used in the tag selector, each separated by a comma, and the selected POD or resource must all match.
kubectl get po -l app=pc,rel=beta
Use labels and selectors to constrain pod scheduling
Because Kubernetes abstracts all the nodes in the cluster into a single large deployment platform, it doesn’t matter which node the POD is actually scheduled to. For each POD, access to the exact number of requested computing resources (CPU, memory, and so on) and other PODS is not affected by the node to which that POD is scheduled.
In practice, we have the need to schedule those PODS to where, without specifying which nodes the pod should be scheduled to, which makes the application strongly coupled to the infrastructure, contrary to Kubernetes’ idea of hiding the actual infrastructure from the applications running on it. So you can use labels and label selectors on nodes to make Kubernetes select nodes that meet certain criteria.
Classify work nodes using labels
If a GPU is added to a cluster for general-purpose GPU computing, you want to add a label to the node to mark this feature by setting the tag GPU =true.
kubectl label node gke-kubia-85f6-node-orrx gpu=true
You can now use the label selector to list nodes:
kubectl get nodes -l gpu=true
Schedule the POD to a specific node
Now that you create a new POD that needs to execute the GPU, to let the scheduler select only nodes that provide the appropriate GPU, add a node selector to the YAML file
apiVersion: v1 kind: Pod metadata: name: kubia-gpu spec: nodeSelector: gpu: "True" // Deploy pod only on nodes that contain the tag gpu=true: -image: luksa/kubia name: kubiaCopy the codeSchedule to a specific node
Again, you can schedule pods to a certain node using the key: kubernetes.io/hostname, which is the actual hostname of the node. It is not recommended that pods be scheduled to each node, but rather to select a specific logical node group through the label selector.
Annotations pod
In addition to labels, PODS and other objects can contain annotations, also key-value pairs, similar in nature to labels. The difference is that annotations cannot be used for grouping like labels.
Annotations can hold more information, and extensive use of annotations can add instructions to each POD or other API object to facilitate user collaboration.
Use namespaces to group resources
Consider namespaces when splitting objects into completely independent and non-overlapping groups. The Kubernetes namespace simply provides a scope for object names.
Namespace requirements
With multiple namespaces, complex systems with a large number of components can be split into smaller groups that can also be used to allocate resources in multi-tenant environments such as production, development, and test environments. The resource name only needs to be unique within the namespace.
Discover additional namespaces and their PODS
List all namespaces in the cluster: kubectl get ns
When using the kubectl get command to list resources, by default only objects in the default namespace are listed.
Kubectl get Po –namespace kube-system
Namespaces can group resources that do not belong to one group into non-overlapping groups and provide a scope for resource names.
Create a namespace
A namespace is a Kubernetes resource like any other resource, so it can also be created from a YAML file.
Create a namespace from a YAML file:
custom-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
name: custom-namespace
Copy the codeRun kubectl create -f custom-namespace.yaml
Use the kubectl create namespace command to create the namespace
Namespace name rules: Comply with the naming conventions specified in the domain name, but do not allow the inclusion of periods, that is, only letters, digits, bar (-)
Kubectl create namespace custom-namespace
Manages objects in other namespaces
Create a resource in the specified namespace:
kubectl create -f kubia-manual.yaml -n custom-namespace
Isolation provided by namespaces
Namespaces separate objects into different groups, only allow operations on objects belonging to a particular namespace, but do not actually provide any isolation of running objects. Whether network isolation is provided between namespaces depends on the network solution used by Kubernetes.
Stop and remove the pod
Delete the POD by name
To delete a POD, terminate all pod containers first
Run the kubectl delete Po kubia-gpu command to delete a single file
Kubectl delete Po pod1 pod2
Remove the POD using the label selector
kubectl delete po -l create_method=manual
Remove the POD by deleting the entire namespace
kubectl delete ns custom-namespace
Delete all pods in the namespace, but keep the namespace
For pods created using kubectl run, delete ReplicationCcontroller if you want to delete all of them
Deletes (almost) all resources in the namespace
kubectl delete all --all
You can run this command to delete all resources in the current namespace and ReplicationCcontroller. Of course, some resources will remain, such as Secret.