# 第五模块 Kubernetes落地实践(下)

# 工作负载

控制器又称工作负载,是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试 进行重启,当根据重启策略无效,则会重新新建pod的资源。

  • ReplicaSet: 用户创建指定数量的pod副本数量,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能
  • Deployment:工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,提供声明式配置
  • DaemonSet:用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如EFK服务
  • Job:只要完成就立即退出,不需要重启或重建
  • Cronjob:周期性任务控制,不需要持续后台运行
  • StatefulSet:管理有状态应用

# Deployment

# Deployment配置

mydig/deployment/deploy-mysql.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mysql
  namespace: ni-ning
spec:
  replicas: 1	#指定Pod副本数
  selector:		#指定Pod的选择器
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:	#给Pod打label
        app: mysql
    spec:
      hostNetwork: true
      volumes: 
      - name: mysql-data
        hostPath: 
          path: /opt/mysql/data
      nodeSelector:   # 使用节点选择器将Pod调度到指定label的节点
        component: mysql
      containers:
      - name: mysql
        image: mysql:5.7
        args:
        - --character-set-server=utf8mb4
        - --collation-server=utf8mb4_unicode_ci
        ports:
        - containerPort: 3306
        env:
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mydig
              key: MYSQL_USER
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mydig
              key: MYSQL_PASSWD
        - name: MYSQL_DATABASE
          value: "mydig"
        resources:
          requests:
            memory: 100Mi
            cpu: 50m
          limits:
            memory: 500Mi
            cpu: 100m
        readinessProbe:
          tcpSocket:
            port: 3306
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          tcpSocket:
            port: 3306
          initialDelaySeconds: 15
          periodSeconds: 20
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql

deploy-mydig.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mydig
  namespace: ni-ning
spec:
  replicas: 1	#指定Pod副本数
  selector:		#指定Pod的选择器
    matchLabels:
      app: mydig
  template:
    metadata:
      labels:	#给Pod打label
        app: mydig
    spec:
      containers:
      - name: mydig
        image: 192.168.75.129:5000/mydig:v1
        imagePullPolicy: IfNotPresent
        env:
        - name: MYSQL_HOST
          valueFrom:
            configMapKeyRef:
              name: mydig
              key: MYSQL_HOST
        - name: MYSQL_PORT
          valueFrom:
            configMapKeyRef:
              name: mydig
              key: MYSQL_PORT
        - name: MYSQL_USER
          valueFrom:
            secretKeyRef:
              name: mydig
              key: MYSQL_USER
        - name: MYSQL_PASSWD
          valueFrom:
            secretKeyRef:
              name: mydig
              key: MYSQL_PASSWD
        ports:
        - containerPort: 80
        resources:
          requests:
            memory: 100Mi
            cpu: 50m
          limits:
            memory: 500Mi
            cpu: 100m
        livenessProbe:
          httpGet:
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 10  # 容器启动后第一次执行探测是需要等待多少秒
          periodSeconds: 15 	# 执行探测的频率
          timeoutSeconds: 2		# 探测超时时间
        readinessProbe: 
          httpGet: 
            path: /
            port: 80
            scheme: HTTP
          initialDelaySeconds: 10 
          timeoutSeconds: 2
          periodSeconds: 15

# 创建Deployment

$ kubectl create -f deploy.yaml

# 查看Deployment

# kubectl api-resources
$ kubectl -n ni-ning get deploy
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
mydig   1/1     1            1           2m22s
mysql    1/1     1            1           2d11h

  * `NAME` 列出了集群中 Deployments 的名称。
  * `READY`显示当前正在运行的副本数/期望的副本数。
  * `UP-TO-DATE`显示已更新以实现期望状态的副本数。
  * `AVAILABLE`显示应用程序可供用户使用的副本数。
  * `AGE` 显示应用程序运行的时间量。

# 查看pod
$ kubectl -n ni-ning get po
NAME                      READY   STATUS    RESTARTS   AGE
mydig-7c96c9f76b-qbbg7   1/1     Running   0          109s
mysql-85f4f65f99-w6jkj    1/1     Running   0          2m28s

# 查看replicaSet
$ kubectl -n ni-ning get rs

# 副本保障机制

controller实时检测pod状态,并保障副本数一直处于期望的值。

## 删除pod,观察pod状态变化
$ kubectl -n ni-ning delete pod mydig-7c96c9f76b-qbbg7

# 观察pod
$ kubectl get pods -o wide

## 设置两个副本, 或者通过kubectl -n ni-ning edit deploy mydig的方式,最好通过修改文件,然后apply的方式,这样yaml文件可以保持同步
$ kubectl -n ni-ning scale deploy mydig --replicas=2
deployment.extensions/mydig scaled

# 观察pod
$ kubectl get pods -o wide
NAME                      READY   STATUS    RESTARTS   AGE
mydig-7c96c9f76b-qbbg7   1/1     Running   0          11m
mydig-7c96c9f76b-s6brm   1/1     Running   0          55s
mysql-85f4f65f99-w6jkj    1/1     Running   0          11m

# Pod驱逐策略

K8S 有个特色功能叫 pod eviction,它在某些场景下如节点 NotReady,或者资源不足时,把 pod 驱逐至其它节点,这也是出于业务保护的角度去考虑的。

  1. Kube-controller-manager: 周期性检查所有节点状态,当节点处于 NotReady 状态超过一段时间后,驱逐该节点上所有 pod。

    • pod-eviction-timeout:NotReady 状态节点超过该时间后,执行驱逐,默认 5 min,适用于k8s 1.13版本之前

    • 1.13版本后,集群开启TaintBasedEvictions 与TaintNodesByCondition 功能,即taint-based-evictions (opens new window),即节点若失联或者出现各种异常情况,k8s会自动为node打上污点,同时为pod默认添加如下容忍设置:

        tolerations:
        - effect: NoExecute
          key: node.kubernetes.io/not-ready
          operator: Exists
          tolerationSeconds: 300
        - effect: NoExecute
          key: node.kubernetes.io/unreachable
          operator: Exists
          tolerationSeconds: 300
      

      即各pod可以独立设置驱逐容忍时间。

  2. Kubelet: 周期性检查本节点资源,当资源不足时,按照优先级驱逐部分 pod

    • memory.available:节点可用内存
    • nodefs.available:节点根盘可用存储空间
    • nodefs.inodesFree:节点inodes可用数量
    • imagefs.available:镜像存储盘的可用空间
    • imagefs.inodesFree:镜像存储盘的inodes可用数量

# 服务更新

修改服务,重新打tag模拟服务更新。

更新方式:

  1. 修改yaml文件,使用kubectl -n ni-ning apply -f deploy-mydig.yaml来应用更新

  2. kubectl -n ni-ning edit deploy mydig在线更新

  3. kubectl -n ni-ning set image deploy mydig mydig=192.168.75.129:5000/mydig:v2 --record

修改文件测试:

$ vi mybolg/blog/template/index.html

$ docker build . -t 192.168.75.129:5000/mydig:v2 -f Dockerfile
$ docker push 192.168.75.129:5000/mydig:v2

# 滚动更新

# 更新策略

...
spec:
  replicas: 2	#指定Pod副本数
  selector:		#指定Pod的选择器
    matchLabels:
      app: mydig
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate		#指定更新方式为滚动更新,默认策略,通过get deploy yaml查看
    ...

策略控制:

  • maxSurge:最大激增数, 指更新过程中, 最多可以比replicas预先设定值多出的pod数量, 可以为固定值或百分比,默认为desired Pods数的25%。计算时向上取整(比如3.4,取4),更新过程中最多会有replicas + maxSurge个pod
  • maxUnavailable: 指更新过程中, 最多有几个pod处于无法服务状态 , 可以为固定值或百分比,默认为desired Pods数的25%。计算时向下取整(比如3.6,取3)

在Deployment rollout时,需要保证Available(Ready) Pods数不低于 desired pods number - maxUnavailable; 保证所有的非异常状态Pods数不多于 desired pods number + maxSurge

以mydig为例,使用默认的策略,更新过程:

  1. maxSurge 25%,2个实例,向上取整,则maxSurge为1,意味着最多可以有2+1=3个Pod,那么此时会新创建1个ReplicaSet,RS-new,把副本数置为1,此时呢,副本控制器就去创建这个新的Pod
  2. 同时,maxUnavailable是25%,副本数2*25%,向下取整,则为0,意味着,滚动更新的过程中,不能有少于2个可用的Pod,因此,旧的Replica(RS-old)会先保持不动,等RS-new管理的Pod状态Ready后,此时已经有3个Ready状态的Pod了,那么由于只要保证有2个可用的Pod即可,因此,RS-old的副本数会有2个变成1个,此时,会删掉一个旧的Pod
  3. 删掉旧的Pod的时候,由于总的Pod数量又变成2个了,因此,距离最大的3个还有1个Pod可以创建,所以,RS-new把管理的副本数由1改成2,此时又会创建1个新的Pod,等RS-new管理了2个Pod都ready后,那么就可以把RS-old的副本数由1置为0了,这样就完成了滚动更新
#查看滚动更新事件
$ kubectl -n ni-ning describe deploy mydig
...
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  11s   deployment-controller  Scaled up replica set mydig-6cf56fc848 to 1
  Normal  ScalingReplicaSet  11s   deployment-controller  Scaled down replica set mydig-6fdcf98f9 to 1
  Normal  ScalingReplicaSet  11s   deployment-controller  Scaled up replica set mydig-6cf56fc848 to 2
  Normal  ScalingReplicaSet  6s    deployment-controller  Scaled down replica set mydig-6fdcf98f9 to 0
$ kubectl get rs
NAME                     DESIRED   CURRENT   READY   AGE
mydig-6cf56fc848   2         2         2       16h
mydig-6fdcf98f9    0         0         0       16h


除了滚动更新以外,还有一种策略是Recreate,直接在当前的pod基础上先删后建:

...
  strategy:
    type: Recreate
...

我们课程中的mysql服务应该使用Recreate来管理:

$ kubectl -n ni-ning edit deploy mysql
...
  selector:
    matchLabels:
      app: mysql
  strategy:
    type: Recreate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: mysql
...

# 服务回滚

通过滚动升级的策略可以平滑的升级Deployment,若升级出现问题,需要最快且最好的方式回退到上一次能够提供正常工作的版本。为此K8S提供了回滚机制。

revision:更新应用时,K8S都会记录当前的版本号,即为revision,当升级出现问题时,可通过回滚到某个特定的revision,默认配置下,K8S只会保留最近的几个revision,可以通过Deployment配置文件中的spec.revisionHistoryLimit属性增加revision数量,默认是10。

查看当前:

$ kubectl -n ni-ning rollout history deploy mydig ##CHANGE-CAUSE为空
$ kubectl delete -f deploy-mydig.yaml    ## 方便演示到具体效果,删掉已有deployment


记录回滚:

$ kubectl apply -f deploy-mydig.yaml --record

$ kubectl -n ni-ning set image deploy mydig mydig=192.168.75.129:5000/mydig:v2 --record=true


查看deployment更新历史:

$ kubectl -n ni-ning rollout history deploy mydig
deployment.extensions/mydig
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deploy-mydig.yaml --record=true
2         kubectl set image deploy mydig mydig=192.168.75.129:5000/demo/mydig:v1 --record=true


回滚到具体的REVISION:

$ kubectl -n ni-ning rollout undo deploy mydig --to-revision=1
deployment.extensions/mydig rolled back

# 访问应用测试

# Service基础

# Kubernetes服务访问之Service

通过以前的学习,我们已经能够通过Deployment来创建一组Pod来提供具有高可用性的服务。虽然每个Pod都会分配一个单独的Pod IP,然而却存在如下两个问题:

  • Pod IP仅仅是集群内可见的虚拟IP,外部无法访问。
  • Pod IP会随着Pod的销毁而消失,当ReplicaSet对Pod进行动态伸缩时,Pod IP可能随时随地都会变化,这样对于我们访问这个服务带来了难度。

# Service 负载均衡之Cluster IP

service是一组pod的服务抽象,相当于一组pod的LB,负责将请求分发给对应的pod。service会为这个LB提供一个IP,一般称为cluster IP 。使用Service对象,通过selector进行标签选择,找到对应的Pod:

mydig/deployment/svc-mydig.yaml

apiVersion: v1
kind: Service
metadata:
  name: mydig
  namespace: ni-ning
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: mydig
  type: ClusterIP


操作演示:

## 别名
$ alias kd='kubectl -n ni-ning'

## 创建服务
$ kd create -f svc-mydig.yaml
$ kd get po --show-labels
NAME                      READY   STATUS    RESTARTS   AGE    LABELS
mydig-5c97d79cdb-jn7km   1/1     Running   0          6m5s   app=mydig
mysql-85f4f65f99-w6jkj    1/1     Running   0          176m   app=mysql

$ kd get svc
NAME     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
mydig   ClusterIP   10.99.174.93   <none>        80/TCP    7m50s

$ kd describe svc mydig
Name:              mydig
Namespace:         demo
Labels:            <none>
Annotations:       <none>
Selector:          app=mydig
Type:              ClusterIP
IP:                10.99.174.93
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.68:80
Session Affinity:  None
Events:            <none>

## 扩容mydig服务
$ kd scale deploy mydig --replicas=2
deployment.extensions/mydig scaled

## 再次查看
$ kd describe svc mydig
Name:              mydig
Namespace:         demo
Labels:            <none>
Annotations:       <none>
Selector:          app=mydig
Type:              ClusterIP
IP:                10.99.174.93
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.0.68:80,10.244.1.158:80
Session Affinity:  None
Events:            <none>


Service与Pod如何关联:

service对象创建的同时,会创建同名的endpoints对象,若服务设置了readinessProbe, 当readinessProbe检测失败时,endpoints列表中会剔除掉对应的pod_ip,这样流量就不会分发到健康检测失败的Pod中

$ kd get endpoints mydig
NAME     ENDPOINTS                            AGE
mydig   10.244.0.68:80,10.244.1.158:80   7m


Service Cluster-IP如何访问:

$ kd get svc mydig
NAME   TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
mydig   ClusterIP   10.99.174.93   <none>        80/TCP    13m
$ curl 10.99.174.93/


为mysql服务创建service:

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: ni-ning
spec:
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app: mysql
  type: ClusterIP


访问mysql:

$ kd get svc mysql
mysql    ClusterIP   10.108.214.84   <none>        3306/TCP   3s
$ curl 10.108.214.84:3306


目前使用hostNetwork部署,通过宿主机ip+port访问,弊端:

  • 服务使用hostNetwork,使得宿主机的端口大量暴漏,存在安全隐患
  • 容易引发端口冲突

服务均属于k8s集群,尽可能使用k8s的网络访问,因此可以对目前mydig访问mysql的方式做改造:

  • 为mysql创建一个固定clusterIp的Service,把clusterIp配置在mydig的环境变量中
  • 利用集群服务发现的能力,组件之间通过service name来访问

# 服务发现

在k8s集群中,组件之间可以通过定义的Service名称实现通信。

演示服务发现:

## 演示思路:在mydig的容器中直接通过service名称访问服务,观察是否可以访问通

# 先查看服务
$ kd get svc
NAME     TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mydig   ClusterIP   10.99.174.93    <none>        80/TCP     59m
mysql    ClusterIP   10.108.214.84   <none>        3306/TCP   35m

# 进入mydig容器
$ kd exec -ti mydig-5c97d79cdb-j485f bash
[root@mydig-5c97d79cdb-j485f mydig]# curl mysql:3306
5.7.29 )(mysql_native_password ot packets out of order
[root@mydig-5c97d79cdb-j485f mydig]# curl mydig/
我的博客列表



虽然podip和clusterip都不固定,但是service name是固定的,而且具有完全的跨集群可移植性,因此组件之间调用的同时,完全可以通过service name去通信,这样避免了大量的ip维护成本,使得服务的yaml模板更加简单。因此可以对mysql和mydig的部署进行优化改造:

  1. mysql可以去掉hostNetwork部署,使得服务只暴漏在k8s集群内部网络
  2. configMap中数据库地址可以换成Service名称,这样跨环境的时候,配置内容基本上可以保持不用变化

修改deploy-mysql.yaml

    spec:
      hostNetwork: true	# 去掉此行
      volumes: 
      - name: mysql-data
        hostPath: 
          path: /opt/mysql/data


        ports:
        - containerPort: 3306
          hostPort: 3306 	# 去掉此行
          protocol: TCP

修改configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: mydig
  namespace: ni-ning
data:
  MYSQL_HOST: "mysql"	# 此处替换为mysql
  MYSQL_PORT: "3306"


应用修改:

$ kubectl delete -f deployment-mysql.yaml

## mydig不用动,会自动因健康检测不过而重启


服务发现实现:

CoreDNS是一个Go语言实现的链式插件DNS服务端,是CNCF成员,是一个高性能、易扩展的DNS服务端

$ kubectl -n kube-system get po -o wide|grep dns
coredns-d4475785-2w4hk             1/1     Running   0          4d22h   10.244.0.64       
coredns-d4475785-s49hq             1/1     Running   0          4d22h   10.244.0.65

# 查看mydig的pod解析配置
$ kubectl -n ni-ning exec -ti mydig-5c97d79cdb-j485f bash
[root@mydig-5c97d79cdb-j485f mydig]# cat /etc/resolv.conf
nameserver 10.96.0.10
search ni-ning.svc.cluster.local svc.cluster.local cluster.local
options ndots:5

## 10.96.0.10 从哪来
$ kubectl -n kube-system get svc
NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)         AGE
kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP   51d

## 启动pod的时候,会把kube-dns服务的cluster-ip地址注入到pod的resolve解析配置中,同时添加对应的namespace的search域。 因此跨namespace通过service name访问的话,需要添加对应的namespace名称,
service_name.namespace
$ kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   26h

# NodePort

# Service负载均衡之NodePort

cluster-ip为虚拟地址,只能在k8s集群内部进行访问,集群外部如果访问内部服务,实现方式之一为使用NodePort方式。NodePort会默认在 30000-32767 ,不指定的会随机使用其中一个。

mydig/deployment/svc-mydig-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: mydig-np
  namespace: ni-ning
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: mydig
  type: NodePort


查看并访问服务:

$ kd create -f svc-mydig-nodeport.yaml
service/mydig-np created
$ kd get svc
NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
mydig      ClusterIP   10.99.174.93     <none>        80/TCP         102m
mydig-np   NodePort    10.105.228.101   <none>        80:30647/TCP   4s
mysql       ClusterIP   10.108.214.84    <none>        3306/TCP       77m

#集群内每个节点的NodePort端口都会进行监听
$ curl 192.168.75.129:30647/
我的博客列表
$ curl 192.168.75.129:30647/
我的博客列表
## 浏览器访问


思考:

  1. NodePort的端口监听如何转发到对应的Pod服务?

  2. CLUSTER-IP为虚拟IP,集群内如何通过虚拟IP访问到具体的Pod服务?

# kube-proxy

运行在每个节点上,监听 API Server 中服务对象的变化,再通过创建流量路由规则来实现网络的转发。参照 (opens new window)

有三种模式:

  • User space, 让 Kube-Proxy 在用户空间监听一个端口,所有的 Service 都转发到这个端口,然后 Kube-Proxy 在内部应用层对其进行转发 , 所有报文都走一遍用户态,性能不高,k8s v1.2版本后废弃。
  • Iptables, 当前默认模式,完全由 IPtables 来实现, 通过各个node节点上的iptables规则来实现service的负载均衡,但是随着service数量的增大,iptables模式由于线性查找匹配、全量更新等特点,其性能会显著下降。
  • IPVS, 与iptables同样基于Netfilter,但是采用的hash表,因此当service数量达到一定规模时,hash查表的速度优势就会显现出来,从而提高service的服务性能。 k8s 1.8版本开始引入,1.11版本开始稳定,需要开启宿主机的ipvs模块。

IPtables模式示意图:

$ iptables-save |grep -v mydig-np|grep  "ni-ning/mydig"
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.99.174.93/32 -p tcp -m comment --comment "demo/mydig: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.99.174.93/32 -p tcp -m comment --comment "demo/mydig: cluster IP" -m tcp --dport 80 -j KUBE-SVC-WQNGJ7YFZKCTKPZK

$ iptables-save |grep KUBE-SVC-WQNGJ7YFZKCTKPZK
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-GB5GNOM5CZH7ICXZ
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -j KUBE-SEP-7GWC3FN2JI5KLE47

$  iptables-save |grep KUBE-SEP-GB5GNOM5CZH7ICXZ
-A KUBE-SEP-GB5GNOM5CZH7ICXZ -p tcp -m tcp -j DNAT --to-destination 10.244.1.158:80

$ iptables-save |grep KUBE-SEP-7GWC3FN2JI5KLE47
-A KUBE-SEP-7GWC3FN2JI5KLE47 -p tcp -m tcp -j DNAT --to-destination 10.244.1.159:80


面试题: k8s的Service Cluster-IP能不能ping通

iptables转换ipvs模式

# 内核开启ipvs模块,集群各节点都执行
cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
ipvs_modules="ip_vs ip_vs_lc ip_vs_wlc ip_vs_rr ip_vs_wrr ip_vs_lblc ip_vs_lblcr ip_vs_dh ip_vs_sh ip_vs_nq ip_vs_sed ip_vs_ftp nf_conntrack_ipv4"
for kernel_module in \${ipvs_modules}; do
    /sbin/modinfo -F filename \${kernel_module} > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        /sbin/modprobe \${kernel_module}
    fi
done
EOF
chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep ip_vs

# 安装ipvsadm工具
$ yum install ipset ipvsadm -y

# 修改kube-proxy 模式
$ kubectl -n kube-system edit cm kube-proxy
...
    kind: KubeProxyConfiguration
    metricsBindAddress: ""
    mode: "ipvs"
    nodePortAddresses: null
    oomScoreAdj: null
...

# 重建kube-proxy
$ kubectl -n kube-system get po |grep kube-proxy|awk '{print $1}'|xargs kubectl -n kube-system delete po

# 查看日志,确认使用了ipvs模式
$ kubectl -n kube-system logs -f 
I0605 08:47:52.334298       1 node.go:136] Successfully retrieved node IP: 192.168.75.129
I0605 08:47:52.334430       1 server_others.go:142] kube-proxy node IP is an IPv4 address (192.168.75.129), assume IPv4 operation
I0605 08:47:52.766314       1 server_others.go:258] Using ipvs Proxier.
...

# 清理iptables规则
$ iptables -F -t nat
$ iptables -F

# 查看规则生效
$ ipvsadm -ln

# 小结

  1. 核心讲如何通过k8s管理业务应用
  2. 介绍k8s的架构、核心组件和工作流程,使用kubeadm快速安装k8s集群
  3. 定义Pod.yaml,将mydig和mysql打包在同一个Pod中,mydig使用localhost访问mysql
  4. mysql数据持久化,为mydig业务应用添加了健康检查和资源限制
  5. 将mydig与mysql拆分,使用独立的Pod管理
  6. yaml文件中的环境变量存在账号密码明文等敏感信息,使用configMap和Secret来统一配置,优化部署
  7. 只用Pod去直接管理业务应用,对于多副本的需求,很难实现,因此使用Deployment Workload
  8. 有了多副本,多个Pod如何去实现LB入口,因此引入了Service的资源类型,有CLusterIp和NodePort
  9. ClusterIP是四层的IP地址,不固定,不具备跨环境迁移,因此利用coredns实现集群内服务发现,组件之间直接通过Service名称通信,实现配置的去IP化
  10. 对Django应用做改造,django直接使用mysql:3306实现数据库访问
  11. 为了实现在集群外部对集群内服务的访问,因此创建NodePort类型的Service
  12. 介绍了Service的实现原理,通过kube-proxy利用iptables或者ipvs维护服务访问规则,实现虚拟IP转发到具体Pod的需求
  13. 为了实现集群外使用域名访问mydig,因此引入Ingress资源,通过定义访问规则,实现七层代理
  14. 考虑真实的场景,对Ingress的使用做了拓展,介绍多path转发及nginx URL重写的实现
上次更新: 9/8/2022, 8:10:54 PM