Today, I will continue to introduce the relevant knowledge of Linux operation and maintenance. The main content of this article is the deployment and application of Service objects.
1. The role of Service resources
In the previous Kubernetes detailed explanation (6) - Pod object deployment and application , we introduced the creation and use of Pod objects in detail. After the Pod object is created, inside the Kubernetes cluster, we can access the Pod object by accessing the IP address of the Pod object. However, after the Pod object is deleted, although it will be restored, its IP address will be changed, so the access to the original Pod object will be invalid. As follows:
We hope to find a stable access to the Pod object, that is, no matter how the Pod object is deleted-created, it can be accessed through a fixed IP address. In addition, the IP of the Pod is the internal IP address of the Kubernetes cluster, and we also hope that the Pod object can be accessed outside of Kubernetes. The implementation of these requires our Service object.
Two, Cluster IP type Service resource creation
The Service resource creation of Cluster IP type can execute the command:
kubectl expose deployment 【镜像名】 --name=【Service名】 --port=【Service对外暴露的端口】 --target-pod=【Pod容器的端口】 --protocol=【流量转发协议】
For example, if we want to create a Service for the pod-test object above, we can execute the command:
kubectl expose deployment pod-test --name=svc-test --port=80 --target-port=80 --protocol=TCP
The execution result of this command is as follows:
In the above figure, we executed a command viewed by Service, and the command format is:
kubectl get svc
Run this command to view the basic information of the Service.
We execute this command to view the IP address exposed by the Service. After that, we can access the IP address of the Service. Accessing the IP address of the Service is equivalent to accessing the IP address of the Pod.
The access results are as follows:
In this way, fixed IP access to Pod resources is achieved.
Three, NodePort type Service resource creation
Next, we try to create a Service resource of NodePort type and implement Kubernetes external client access to Pod resources.
The NodePort type Service resource creation is in the same format as the Cluster IP type Service type creation command, but the parameter –type="NodePort" needs to be added to the command.
For example, execute the command:
kubectl expose deployment/pod-test --type="NodePort" --port=80 --name=svcnode-test
The execution result of this command is as follows:
As can be seen from the above figure, the newly created Service type is NodePort, and this type of Service actually has an internal IP address. In the Kubernetes cluster, we can also use the internal IP address of the Service to implement the Pod. access to resources. At the same time, the service also implements the binding of the local port 30344 and port 80 of the Pod, as shown below: In
this way, our access to the device IP address and port 30344 is equivalent to accessing the Pod resources. The access results are as follows:
In addition, due to the characteristics of the Kubernetes cluster, the results of accessing the 30334 nodes of any node in the Kubernetes cluster are the same, as shown below:
4. Service resource deletion
Finally, let's introduce the deletion of the Service resource in the following Kubernetes cluster.
Excuting an order:
kubectl delete svc 【Service名】
The Service resource can be deleted. The execution result of this command is as follows:
Original is not easy, please explain the source of reprint: https://blog.csdn.net/weixin_40228200