[Cloud] 6. Kubernetes Service deploy

Another object deployed in Kubernetes is an object called Service. The role of this Service object is like a kind of Gateway. As mentioned earlier, the application actually runs in a container, and the object containing this container is a Pod. This Pod has an IP individually. The problem is that if the IP of the Pod is exposed to an external client, the IP will be changed when a new Pod is created due to a failure.

​

​

In this case, when a service request is made to the pod from the outside, a service failure occurs because the request is made with the old IP. Thus, it is a structure in which an object called Service is created, the IP of the Service Object is exposed to the outside, all service requests are made to the Servie Object, and the Service Object distributes requests to each Pod and delivers them and processes the service.

 

반응형

​

There are various types of this Service Object as shown in the figure below. So let's take a look at what they do one by one.

• Cluster IP: Default Type of Service object. It is a structure in which IP is assigned to the cluster and the pods in the cluster communicate through the Service object. This type operates only inside the cluster.
• Node Port: It is a structure in which the specific port number of all worker nodes is exposed to the outside, and all requests for a specific port coming to the node are forwarded to the Service object, and the Service is delivered to the Pod.
• Loadbalance: CSP providers such as CSP (Amazon, MS, Google, Oracle) provide a Loadbalancer, and it is a structure used by connecting a service to this Loadbalancer. That is, all requests coming in to a specific Loadbalancer are delivered to a specific Service, and the Service object is delivered to a Pod for processing.
• ExternalName: Maps the service to a specific DNS name and returns a specific DNS name.

​

- This is typically used to represent an external data store, such as a database running outside of Kubernetes. Used to create services within Kubernetes.

- When a Pod in one namespace communicates with a service in another namespace, its ExternalName service use (as a local service)

​

• Ingress: Ingress is a feature added to Kubernetes v1.1. Like NodePort and LoadBalancer, it is a resource used when exposing an application's Service to the outside. HTTP and HTTPS traffic from outside It creates an ingress resouce and routes it in the L7 area as a service inside the cluster, and provides load balancing, TLS, and domain-based virtual hosting.

​

The figure above shows the flow when requesting a service inside the cluster using the exec option of the Kubectl command. That is, it is a figure showing the structure that when a specific pod in the cluster makes a request within the cluster, it is processed through the service object. ​

​

Now, let's look at the basic contents of the service.yaml file and proceed with the creation and distribution process.

apiVersion: v1 kind: Service ==> define kind of Object metadata: name: my-nginx labels: run: my-nginx ==> label value of Service Object managed spec: type: NodePort ==> define kind of Service ports: - port: 8080 ==> define port number that received from client targetPort: 80 ==> define port number that Pod processed the request protocol: TCP selector: run: my-nginx

Now, let's create a Service object with ClusterIP Type and deploy a Pod. First, create a clusterIP directory, create a pod.yaml file, enter the following, and then save it. If Type is not defined in the service yaml file, the default value is defined as clusterip.

root@master-VirtualBox:~/test# mkdir clusterIP root@master-VirtualBox:~/test# cd clusterIP/ root@master-VirtualBox:~/test/clusterIP# root@master-VirtualBox:~/test/clusterIP# root@master-VirtualBox:~/test/clusterIP# vi pod.yaml ==>create Pod yaml file apiVersion: v1 kind: Pod ==> define kind of Object metadata: labels: run: my-nginx ==> define label value of Pod name: my-nginx-pod namespace: default spec: containers: - image: nginx imagePullPolicy: Always name: my-nginx-container ports: - containerPort: 80 protocol: TCP ​ root@master-VirtualBox:~/test/clusterIP# vi servie.yaml ==> create service.yaml file apiVersion: v1 kind: Service ==> define kibd of Object metadata: name: my-nginx-svc labels: run: my-nginx ==> define label value of Service spec: ports: - port: 80 protocol: TCP selector: run: my-nginx ​ root@master-VirtualBox:~/test# kubectl apply -f clusterIP/ ==> deplot service and pod pod/my-nginx-pod created service/my-nginx-svc created ​

​

ClusterIP Type and Pod are now created. Then, if you look at the created service with the command below, you can see that an IP that can only be used inside the cluster is assigned..

root@master-VirtualBox:~/test# kubectl get service -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d5h <none> my-nginx-svc ClusterIP 10.96.95.232 <none> 80/TCP 3m38s run=my-nginx ​ root@master-VirtualBox:~/test# kubectl describe service my-nginx-svc Name: my-nginx-svc Namespace: default Labels: run=my-nginx Annotations: <none> Selector: run=my-nginx Type: ClusterIP IP Family Policy: SingleStack IP Families: IPv4 IP: 10.96.95.232 IPs: 10.96.95.232 Port: <unset> 80/TCP TargetPort: 80/TCP Endpoints: 172.16.168.208:80 Session Affinity: None Events: <none>

Now, if you send a service request with curl (command URL) to the Service object, you can see that it works normally.

root@master-VirtualBox:~/test# curl http://10.96.95.232 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> ​ <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org. Commercial support is available at <a href="http://nginx.com/">nginx.com. ​ <p><em>Thank you for using nginx.</em></p> </body> </html> root@master-VirtualBox:~/test# ​

Now, let's create a Service object with NodePort Type and deploy a Pod. After creating the file and directory as shown below, enter the following contents into the yaml file and save it.

root@master-VirtualBox:~/test# mkdir NodePort root@master-VirtualBox:~/test# cd NodePort/ root@master-VirtualBox:~/test/NodePort# vi pod.yaml apiVersion: v1 kind: Service metadata: name: my-nginx-svc labels: run: my-nginx spec: type: NodePort ==> 서비스 객체의 Type을 NodePort로 정의 ports: - port: 8080 targetPort: 80 protocol: TCP selector: run: my-nginx

Now, let's deploy the created Pod and Service objects and check whether they are set up properly.​

root@master-VirtualBox:~/test# kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 5d5h my-nginx-svc NodePort 10.96.95.232 <none> 8080:31793/TCP 19m ​ root@master-VirtualBox:~/test# root@master-VirtualBox:~/test# kubectl describe service my-nginx-svc Name: my-nginx-svc Namespace: default Labels: run=my-nginx Annotations: <none> Selector: run=my-nginx Type: NodePort IP Family Policy: SingleStack IP Families: IPv4 IP: 10.96.95.232 IPs: 10.96.95.232 Port: <unset> 8080/TCP TargetPort: 80/TCP NodePort: <unset> 31793/TCP Endpoints: 172.16.168.208:80 Session Affinity: None External Traffic Policy: Cluster Events: <none>

As you can see above, NodePort is set to 31793. When a request is made to the port from outside or inside the cluster, the request message coming through the port is delivered to the Service object, and the Service object is delivered to the Pod for processing. If you use curl to send an http request message as shown below, you can see that it works normally.

root@master-VirtualBox:~/test# curl localhost:31793 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> ​ <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org. Commercial support is available at <a href="http://nginx.com/">nginx.com. ​ <p><em>Thank you for using nginx.</em></p> </body> </html> root@master-VirtualBox:~/test# ​

As in the above, you can configure and distribute the rest of Tpye in the same way. However, in the case of imgress, we will only look at the part that defines which service is delivered to in ingress.

If you look at the structure of the yaml file below, the ingress request is sent to foo.bar.com, and if the path is /foo, it is forwarded to the Service1 object, and if it is /bar, it is forwarded to the service2 object. ​ apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: simple-fanout-example annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: foo.bar.com http: paths: - path: /foo pathType: Exact backend: service: name: service1 port: number: 4200 - path: /bar pathType: Exact backend: service: name: service2 port: number: 8080 ​ Then, if you look at one more thing, below is the yaml setting that forwards to service 1 if the request host is foo.bar.com, and forwards to service 2 if it is bar.foo.com. ​ apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: name-virtual-host-ingress annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/rewrite-target: / spec: rules: - host: foo.bar.com http: paths: - path: / pathType: Exact backend: service: name: service1 port: number: 80 - host: bar.foo.com http: paths: - path: / pathType: Exact backend: service: name: service2 port: number: 80