kuburnetes service exposed port and its application

Posted by deepson2 on Sun, 26 Dec 2021 18:26:30 +0100

service exposes ports in the same way as agent

1. How kubernetes exposes ports

clusterIP
This type will provide a virtual IP within the cluster (not in the same network segment as the pod) for communication between pods within the cluster. clusterIP is also the default IP of kubernetes service
Type mainly requires the following components
Cooperative work apiservice: when creating a service, the apiserver receives the request and stores the data in etcd.
Kube proxy: each node of k8s has this process, which is responsible for realizing the service function. This process is responsible for sensing the changes of service and pod, and writing the changed information into local iptables
iptables: use NAT and other technology awards to transfer the traffic of virtuallp to the endpoint

NodePort

In addition to using cluster ip, the nodeport mode also maps the port of the service to a specified internal port of each node. The mapped internal ports of each node are the same. Expose a port for each node. You can access this service through nodeIP+nodeport. At the same time, the service will still have cluster type ip+port. Internal access is through clusterip and external access is through nodeport

loadbalancer

On the basis of nodeport, k8s the loadbalancer can request the underlying cloud platform to create a load balancer, and use each node as the back end for service distribution. This mode requires the support of the underlying cloud platform (such as GCE)

lngress

lngress is an http routing and forwarding mechanism, which is composed of lngress controller and http proxy server. The instance of lngress controller monitors kubernetes api and updates the forwarding rules of http proxy server in real time. http proxy server has GCE load balancer, haproxy, nginx and other open source solutions

Service is an abstract concept, which defines the logical collection of multiple pods of a service and the policy of accessing pod. Generally, service is called micro service For example, a service runs three pods. How does service b access the pod of service a? The ip address of the pod is not persistent. It will change after restart. At this time, service b can access the service bound to service a. the service information is fixed. Just tell b in advance. The service is bound to the pod of service a through the Label Selector. No matter how the pod of service a changes, it is transparent to b

2. Agency method

Each node in the k8s cluster runs a Kube proxy component, which is actually a proxy layer responsible for implementing services There are two Kube proxy modes:

Proxy mode: userspace

The client access service IP (clusterIP) request will first go from the user space to iptables in the kernel, and then return to the user space Kube proxy, which is responsible for the proxy work.
For each service, Kube proxy will set up a random proxy port on the node node. iptables will capture the port (targetPort) traffic on the clusterIP and redirect the proxy port. Any connection accessing the proxy port will be proxy to a pod at the back end of the service. By default, polling is selected for the back-end pod

Proxy mode: iptables

Client access service IP (clusterIP) requests will be redirected directly to the back end by iptables. Specific details: each service will generate a set of iptables rules by Kube proxy. Iptables will capture the port (targetPort) traffic on the clusterIP and redirect a pod at the back end. It is assumed that the selection of pod is random

Kubernetes v1.2 before, the default is userspace, followed by iptables mode. Iptables mode has better performance and reliability, but iptables mode depends on health check. If one pod does not respond without health check, iptables mode will not switch to another pod

3. Service oriented

ClusterIP is the default mode and can only be accessed within the cluster
NodePort listens to the same port number (30000-32767) on each node, and ClusterIP and routing rules will be created automatically.
LoadBalancer uses external load balancing. In fact, it is also a NodePort, but it will automatically add: to the load balancing of the public cloud
ExternalName creates a dns alias to the service name to prevent the service name from changing. It should be used in conjunction with the dns plug-in

example:

Create a pod where the nginx container runs

[root@master test]# cat test.yml 
apiVersion: v1
kind: Pod
metadata:
  name: test
  labels:
    app: test01
spec:
  containers:
  - image: nginx
    name: nginx

[root@master test]#

establish

[root@master test]# kubectl apply -f test.yml 
pod/test created
[root@master test]#

see

[root@master test]# kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
test                     3/3     Running   0          89s
[root@master test]#

Create a service for a pod and access it through ClusterlP/NodePort

[root@master test]# cat service.yml 
---
apiVersion: v1
kind: Pod
metadata:
  name: testnginx
  labels:
    app: testnginx
spec:
  containers:
  - image: nginx
    name: nginx

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: testnginx
  type: NodePort
[root@master test]#

establish

[root@master test]# kubectl apply -f service.yml 
pod/testnginx created
service/nginx created
[root@master test]#

see

[root@master test]# kubectl get deploy,pod,svc
NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/httpd2   3/3     3            3           11m

NAME                         READY   STATUS    RESTARTS   AGE
pod/httpd2-fd86fb676-f9zjf   1/1     Running   0          11m
pod/httpd2-fd86fb676-hzq27   1/1     Running   0          11m
pod/httpd2-fd86fb676-p94c8   1/1     Running   0          11m
pod/sb                       1/1     Running   0          36s
pod/test                     3/3     Running   0          4m13s

NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
service/httpd2       ClusterIP   10.99.116.85     <none>        80/TCP         11m
service/kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        26m
service/nginx        NodePort    10.100.100.175   <none>        80:31326/TCP   36s
[root@master test]#

ClusterIP access

By default, a virtual IP that can only be accessed inside the Cluster is automatically assigned

[root@master test]# curl 10.100.100.175
<!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</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master test]#

NodePort access

The principle of nodePort is to open a port on the node, import the traffic to the port to Kube proxy, and then go further from Kube proxy to the corresponding pod

[root@master test]# curl 192.168.100.169:31326
<!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</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@master test]#

Topics: Linux Operation & Maintenance Docker Kubernetes

Programmer Think