
## **run的工作原理**

![image-20220808084810331](http://pic.nexopera.tech/62f05d4b00879.png)



## **Dokcer怎么工作的**

docker是一个client-server结构的系统，docker的守护进程一直在后台运行在主机上（好比装了个mysql，一直在后台运行），通过Socket从客户端访问。Dockerserver（服务进程）接收到dockerclient的指令，就会执行这个命令。

客户端连接到守护进程之后它会启动一些容器，都在服务之内，通过这个守护进程造作容器资源（容器里面就好比有个小的linux虚拟机 可以跑 占用资源进程很少，互相隔离，如果想从外部访问要进行一个连通）

![image-20220808084829580](http://pic.nexopera.tech/62f05d611efc2.png)



## **Docker为什么比VM快**

**Docker 有更少的抽象层**

vm要虚拟出硬件才行，而docker没有这一层，直接在主机安装服务，运行在服务里的 每个隔离的都是容器 由于docker不需要Hypervisor实现硬件资源虚拟化 运行在docker容器上的程序直接使用的都是实际物理机的硬件资源。因此在CPU、内存利用率上docker将会在效率上有明显优势。

**Docker不需要Guest OS**

docker利用的宿主机的内核，vm是需要GuestOS。 docker不用重新加载一个操作系统内核，避免引导，虚拟机需要加载GuestOS，时间是分钟级别。docker是利用宿主机的操作系统，就不需要在虚拟出来了，省略了这个复杂的过程，时间是秒级。Docker底层用的是物理机的资源，虚拟机需要模拟物理机的操作系统，所以Docker加载得更快，而虚拟机更慢。

![image-20220808084851984](http://pic.nexopera.tech/62f05d74932ca.png)


Docker的工作原理

Docker的前世今生

Docker容器技术详解

1.先查看磁盘空间

df -h

![img](http://pic.nexopera.tech/634ca94a4b890.png)

2.找到容器的containerId-json.log文件,并清理(治标不治本，log迟早还会大的)

 查看各个容器的log文件大小

find /var/lib/docker/containers/ -name *-json.log |xargs du -sh

![img](http://pic.nexopera.tech/634ca94cc7cb0.png)

执行清理

$ cat /dev/null > /var/lib/docker/containers/dfe25896671f0def031c5ffeb12dd335f7f54212c6ca5d3aca1c3f50b5e1eec4/dfe25896671f0def031c5ffeb12dd335f7f54212c6ca5d3aca1c3f50b5e1eec4-json.log

![img](http://pic.nexopera.tech/634ca946596b5.png)

 3.脚本化清理

如果docker容器正在运行，那么使用rm -rf方式删除日志后，通过df -h会发现磁盘空间并没有释放。原因是在Linux或者Unix系统中，通过rm -rf或者文件管理器删除文件，将会从文件系统的目录结构上解除链接（unlink）。如果文件是被打开的（有一个进程正在使用），那么进程将仍然可以读取该文件，磁盘空间也一直被占用。正确姿势是cat /dev/null > *-json.log，当然你也可以通过rm -rf删除后重启docker。接下来，提供一个日志清理脚本clean_docker_log.sh，内容如下：

```
#!/bin/sh 

echo "======== start clean docker containers logs ========"  

logs=$(find /var/lib/docker/containers/ -name *-json.log)  

for log in $logs  
        do  
                echo "clean logs : $log"  
                cat /dev/null > $log  
        done  

echo "======== end clean docker containers logs ========"  
```

```
# chmod +x clean_docker_log.sh

# ./clean_docker_log.sh
```

但是，这样清理之后，随着时间的推移，容器日志会像杂草一样，[卷土重来](https://www.baidu.com/s?wd=卷土重来&tn=24004469_oem_dg&rsv_dl=gh_pl_sl_csd)。

4.设置Docker容器日志大小（治本）

　　设置一个容器服务的日志大小上限
　　

　　上述方法，日志文件迟早又会涨回来。要从根本上解决问题，需要限制容器服务的日志大小上限。这个通过配置容器docker-compose的max-size选项来实现

```
nginx: 
image: nginx:1.12.1 
restart: always 
logging: 
driver: “json-file” 
options: 
max-size: “5g” 
重启nginx容器之后，其日志文件的大小就被限制在5GB，再也不用担心了。
```

全局设置
新建/etc/docker/daemon.json，若有就不用新建了。添加log-dirver和log-opts参数，样例如下：

\# vim /etc/docker/daemon.json

```
{
"registry-mirrors": ["http://f613ce8f.m.daocloud.io"],
"log-driver":"json-file",
"log-opts": {"max-size":"500m", "max-file":"3"}
}
```

max-size=500m，意味着一个容器日志大小上限是500M，
max-file=3，意味着一个容器有三个日志，分别是id+.json、id+1.json、id+2.json。

// 重启docker守护进程

\# systemctl daemon-reload

\# systemctl restart docker

**注意：设置的日志大小，只对新建的容器有效。**


docker容器日志清理

故事的开始，让我们先从一件生产故障说起。5月29日，内部某系统出现大规模访问Service故障，发现**Pod容器内无法正常访问ServiceIP:Port**，整个故障持续时间超过12h，相关运维支撑人员没有找到根本原因和解决办法。

经过复盘，我们发现，**大家****对于K8S Service的原理不够清晰，导致对问题的定位不能做得到快速准确，**如果当时能够按照如下的思路去思考问题，排查过程不至于花费如此久的时间。

![image-20220727111126810](http://pic.nexopera.tech/62e0acdf64cf3.png)

下面，我们就来细说一下**Service在Kubernetes中的作用、使用方法及原理**。

Service是一种暴露一组Pod网络的抽象方式，K8S Service提供了针对于一组Pod的负载均衡的暴露。通过这样的方式，可以避免不同的pod之间访问时需要知晓对应pod网络信息的痛苦。例如：前端->后端，由于前端POD IP随时变动，后端亦如此，如何处理前端POD和后端POD的通信，就需要Service这一抽象，来保证简单可靠。



## **Service的使用**

**1、典型服务配置方法**

当配置了selector之后，Service Controller会自动查找匹配这个selector的pod，并且创建出一个同名的endpoint对象，负责具体service之后连接。

```
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

```



**2、配置没有selector的服务**

没有selector的service不会出现Endpoint的信息，需要手工创建Endpoint绑定，Endpoint可以是内部的pod，也可以是外部的服务。

```
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376
```



## **Service的类型**

**1.CluserIP**

```
kubectl expose pod nginx --type=CluserIP --port=80 --name=ng-svc
 
apiVersion: v1
kind: Service
metadata:
  name: ng-svc
  namespace: default
spec:
  selector:
      name: nginx
  clusterIP: 11.254.0.2
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 1234
  sessionAffinity: None
  type: ClusterIP
```

**2.LoadBalance**

```
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127
```

**3.NodePort**

```
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
  app: MyApp
ports:
  - port: 80
    targetPort: 80
    nodePort: 30007
```

**4.ExternalName**

**5.Headless**

```
apiVersion: v1
kind: Service
metadata:
  labels:
    run: curl
  name: my-headless-service
  namespace: default
spec:
  clusterIP: None
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: curl
  type: ClusterIP
```

对定义了选择算符的无头服务，Endpoint 控制器在 API 中创建了 Endpoints 记录， 并且修改 DNS 配置返回 A 记录（IP 地址），通过这个地址直接到达 Service 的后端 Pod 上。

```
# ping my-headless-service
PING my-headless-service (172.200.6.207): 56 data bytes
64 bytes from 172.200.6.207: seq=0 ttl=64 time=0.040 ms
64 bytes from 172.200.6.207: seq=1 ttl=64 time=0.063 ms
```

对没有定义选择算符的无头服务，Endpoint 控制器不会创建 Endpoints 记录。然而 DNS 系统会查找和配置，无论是：

- 对于 ExternalName 类型的服务，查找其 CNAME 记录
- 对所有其他类型的服务，查找与 Service 名称相同的任何 Endpoints 的记录

##  

## **Service的实现方式**

**1.用户态代理访问**

![image-20220727111325747](http://pic.nexopera.tech/62e0ad56520ed.png)

即：当对于每个Service，Kube-Proxy会在本地Node上打开一个随机选择的端口，连接到代理端口的请求，都会被代理转发给Pod。那么通过Iptables规则，捕获到达Service:Port的请求都会被转发到代理端口，代理端口重新转为对Pod的访问

这种方式的缺点是存在内核态转为用户态，再有用户态转发的两次转换，性能较差，一般不再使用

**2.Iptables模式**

![image-20220727111333473](http://pic.nexopera.tech/62e0ad5e12137.png)

**3.Ipvs模式**

![image-20220727111340909](http://pic.nexopera.tech/62e0ad656938a.png)

### **Service Iptables实现原理**

#### **Iptables表和链及处理过程**

![image-20220727111349174](http://pic.nexopera.tech/62e0ad7159f65.png)

Service的Traffic流量将会通过prerouting和output重定向到kube-service链

```
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A POSTROUTING -m comment --comment "kubernetes postrouting rules" -j KUBE-POSTROUTING
-A OUTPUT -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
```

- KUBE-SERVICES->KUBE-SVC-XXXXXXXXXXXXXXXX->KUBE-SEP-XXXXXXXXXXXXXXXX represents a ClusterIP service
- KUBE-NODEPORTS->KUBE-SVC-XXXXXXXXXXXXXXXX->KUBE-SEP-XXXXXXXXXXXXXXXX represents a NodePort service

## **几种不同类型的Service在Kube-Proxy启用Iptables模式下上的表现**

- ClusterIP

```
-A KUBE-SERVICES ! -s 172.200.0.0/16 -d 10.100.160.92/32 -p tcp -m comment --comment "default/ccs-gateway-clusterip:http cluster IP" -m tcp --dport 30080 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.100.160.92/32 -p tcp -m comment --comment "default/ccs-gateway-clusterip:http cluster IP" -m tcp --dport 30080 -j KUBE-SVC-76GERFBRR2RGHNBJ  


-A KUBE-SVC-76GERFBRR2RGHNBJ -m comment --comment "default/ccs-gateway-clusterip:http" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-GBVECAZBIC3ZKMXB
-A KUBE-SVC-76GERFBRR2RGHNBJ -m comment --comment "default/ccs-gateway-clusterip:http" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-PVCYYXEU44D3IMGK
-A KUBE-SVC-76GERFBRR2RGHNBJ -m comment --comment "default/ccs-gateway-clusterip:http" -j KUBE-SEP-JECGZLHE32MEARRX
-A KUBE-SVC-CEZPIJSAUFW5MYPQ -m comment --comment "kubernetes-dashboard/kubernetes-dashboard" -j KUBE-SEP-QO6MV4HR5U56RP7M  


-A KUBE-SEP-GBVECAZBIC3ZKMXB -s 172.200.6.224/32 -m comment --comment "default/ccs-gateway-clusterip:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-GBVECAZBIC3ZKMXB -p tcp -m comment --comment "default/ccs-gateway-clusterip:http" -m tcp -j DNAT --to-destination 172.200.6.224:80
...
```

- NodePort

```
apiVersion: v1
kind: Service
metadata:
labels:
  app: ccs-gateway
spec:
clusterIP: 10.101.156.39
externalTrafficPolicy: Cluster
ports:
- name: http
  nodePort: 30081
  port: 30080
  protocol: TCP
  targetPort: 80
selector:
  app: ccs-gateway
sessionAffinity: None
type: NodePort
```

```
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/ccs-gateway-service:http" -m tcp --dport 30081 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/ccs-gateway-service:http" -m tcp --dport 30081 -j KUBE-SVC-QYHRFFHL5VINYT2K
############################
-A KUBE-SVC-QYHRFFHL5VINYT2K -m comment --comment "default/ccs-gateway-service:http" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-2NPKETIWKKVUXGCL
-A KUBE-SVC-QYHRFFHL5VINYT2K -m comment --comment "default/ccs-gateway-service:http" -j KUBE-SEP-6O5FHQRN5IVNPW4Q
##########################
-A KUBE-SEP-2NPKETIWKKVUXGCL -s 172.200.6.224/32 -m comment --comment "default/ccs-gateway-service:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-2NPKETIWKKVUXGCL -p tcp -m comment --comment "default/ccs-gateway-service:http" -m tcp -j DNAT --to-destination 172.200.6.224:80
#########################
-A KUBE-SEP-6O5FHQRN5IVNPW4Q -s 172.200.6.225/32 -m comment --comment "default/ccs-gateway-service:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-6O5FHQRN5IVNPW4Q -p tcp -m comment --comment "default/ccs-gateway-service:http" -m tcp -j DNAT --to-destination 172.200.6.225:80
```

同时，可以看到Service所申请的端口38081被Kube-proxy所代理和监听

```
# netstat -ntlp | grep 30081
tcp       0      00.0.0.0:30081           0.0.0.0:*               LISTEN     3665705/kube-proxy
```

- LoadBalancer

不带有Endpoint的Service

```
kubectl create svc clusterip fake-endpoint --tcp=80 
-A KUBE-SERVICES -d 10.101.117.0/32 -p tcp -m comment --comment "default/fake-endpoint:80 has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable
```

带有外部endpoint的Service

直接通过iptable规则转发到对应的外部ep地址

```
apiVersion: v1
kind: Service
metadata:
  labels:
    app: external
  name: external
  namespace: default
spec:
  ports:
  - name: http
    protocol: TCP
    port: 80
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: external
  name: external
  namespace: default
subsets:
- addresses:
  - ip: 10.124.142.43
  ports:
  - name: http
    port: 80
protocol: TCP
```

```
-A KUBE-SERVICES ! -s 172.200.0.0/16 -d 10.111.246.87/32 -p tcp -m comment --comment "default/external:http cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.111.246.87/32 -p tcp -m comment --comment "default/external:http cluster IP" -m tcp --dport 80 -j KUBE-SVC-LI2K5327B6J24KJ3 


-A KUBE-SEP-QTGIPNOYXN2CZGD5 -s 10.124.142.43/32 -m comment --comment "default/external:http" -j KUBE-MARK-MASQ
-A KUBE-SEP-QTGIPNOYXN2CZGD5 -p tcp -m comment --comment "default/external:http" -m tcp -j DNAT --to-destination 10.124.142.43:80
```



## **总结**

- ClusterIP类型，KubeProxy监听Service和Endpoint创建规则，采用DNAT将目标地址转换为Pod的ip和端口，当有多个ep时，按照策略进行转发，默认RR模式时，iptables采用：比如有4个实例，四条规则的概率分别为0.25, 0.33, 0.5和 1，按照顺序，一次匹配完成整个流量的分配。
- NodePort类型，将会在上述ClusterIP模式之后，再加上Kube-Proxy的监听（为了确保其他服务不会占用该端口）和KUBE-NODEPORT的iptable规则


K8S Service 实战与原理初探

Nexopera是一个专注于Linux、网络和运维等领域的博客网站。将为读者提供广泛的相关文章，涵盖操作系统、服务器管理、网络配置、安全性等多个主题。如果你是初学者，希望这里有适合你的内容。

run的工作原理

Docker容器技术初识

Docker容器技术简介