Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "how to use Kubernetes services to expose app". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Overview of Kubernetes Servic

Kubernetes Pods will die. Pods actually has a life cycle. When a worker node dies, the Pods running on that node is also lost. ReplicaSet can dynamically restore the cluster to the desired state by creating a new pod to keep the application running. Another example is to consider an image processing backend with three copies. These replicas are interchangeable; front-end systems should not care about back-end replicas or even Pod loss and re-creation. That is, each Pod in a Kubernetes cluster has a unique IP address, or even a Pod on the same node, so you need a way to automatically coordinate changes between Pod so that your application continues to run.

A service in Kubernetes is an abstract concept that defines a set of logical Pods and policies to access them. Services support loose coupling between independent Pods. Services are defined using YAML (preferred) or JSON, just like all Kubernetes objects. The pod collection to which the service is targeted is usually determined by the tag selector.

Although each Pod has a unique IP address, these IP will not be exposed outside the cluster without services. The service allows applications to receive traffic. By specifying a type in ServiceSpec, services can be exposed in different ways:

ClusterIP (default)-expose the service on the internal IP in the cluster. This type allows services to be accessed only from within the cluster.

NodePort-use NAT to expose services on the same port on each selected node in the cluster. Use: make the service accessible from outside the cluster. Superset of ClusterIP.

LoadBalancer-create an external load balancer (if supported) in the current cloud and assign a fixed external IP to the service. Superset of NodePort.

ExternalName-expose the service with any name (specified by externalName in the specification) by returning a CNAME record with a name. Do not use a proxy. This type requires v1.7 or higher kube-dns

More information about the different types of services can be found in the tutorials using the source IP. Please also see Connecting Applications with Services.

Also, note that some service use cases do not have selector defined in spec. When a service without selector is created, the corresponding endpoint object is not created. This allows users to manually map services to specific endpoints. Another possibility without a selector is that you strictly use type: ExternalName.

Services and tags

The service routes traffic between a set of Pods. A service is an abstraction that allows pod to die and there are multiple copies in Kubernetes without affecting the application. Discovery and routing that depend on Pods, such as front-end and back-end components in an application, are handled by Kubernetes services. The service matches a set of pod using tags and selectors, which are grouping primitives that allow logical operations on objects in the Kubernetes. Tags are key/value pairs attached to objects and can be used in any way:

Specify objects for development, testing, and production

Embedded version tag

Use tags to classify objects

Labels can be attached to objects at creation time or later. They can be modified at any time. You can use the following environment to practice service exposure.

The kubectl get command can view the existing Pods: kubectl get pods

The kubectl get services command can check the existing services: as a result of the kubectl get services command, you can see that there is a service called kubernetes, which is created by default when minikube starts the cluster.

To create a new service and expose it to external traffic, we will use the expose command with the NodePort parameter (minikube does not yet support the LoadBalancer option): kubectl expose deployment/kubernetes-bootcamp-- type= "NodePort"-- port 8080, and then run kubectl get services to view the service. We now have a running service called kubernetes-bootcamp. Here, we see that the service receives a unique cluster ip, an internal port, and an external ip (the node's IP).

To find out which port is open externally (through the NodePort option), we will run the describe service command: kubectl describe services/kubernetes-bootcamp

Create an environment variable named NODE_PORT with the value of the specified node port: export NODE_PORT=$ (kubectl get services/kubernetes-bootcamp-o go-template=' {{(index .spec.ports 0) .nodePort}}'); echo "NODE_PORT=$NODE_PORT"

Now we can test whether the application exposes curl $(minikube ip): $NODE_PORT outside the cluster using the curl, the node's IP, and the externally exposed port

That's all for "how to use Kubernetes Services to expose app". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.