一、Pod生命周期
- Pod是k8s中最小的管理单元（逻辑上存在，实际不存在），是一组容器的集合
- 同一个Pod中的容器共享网络和存储（通过pause容器实现），由一个统一的IP向集群内部提供服务
- Pod分为自主式（死亡之后就会消失）和被控制器控制的（死亡之后会被控制器拉起来保持Pod的副本数量）
- Pod的生命周期是短暂的，Pod死亡之后，重新创建的Pod和原来的Pod完全不一样
1、init c
-
init c 即 init container （初始化容器）
-
Pod能够具有多个容器，应用运行在容器里面，但是它也可能有一个或多个先于应用容器启动的Init容器
-
Init容器与普通的容器非常像，除了如下两点
- Init容器总是运行到成功完成为止
- 每个Init容器都必须在下一个Init容器启动之前成功完成
-
如果Pod的Init容器失败， Kubernetes 会不断地重启该Pod，直到Init容器成功为止。然而，如果Pod对应的 restartPolicy为Never,他不会重新启动
2、init c的作用
- 因为Init容器具有与应用程序容器分离的单独镜像，所以它们的启动相关代码具有如下优势
- 它们可以包含并运行实用工具，但是出于安全考虑，是不建议在应用程序容器镜像中包含这些实用工具的
- 它们可以包含使用工具和定制化代码来安装，但是不能出现在应用程序镜像中。例如，创建镜像没必要FROM另一个镜像，只需要在安装过程中使用类似 sed 、 awk 、 python或 dig这样的工具
- 应用程序镜像可以分离出创建和部署的角色，而没有必要联合它们构建一个单独的镜像
- Init容器使用 Linux Namespace ，所以相对应用程序容器来说具有不同的文件系统视图。因此，它们能够具有访问 Secret 的权限，而应用程序容器则不能
- 它们必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法，直到满足了一组先决条件
- 也就是说在主容器启动之前使用init c可以做一些其他事情
- 读取配置文件等等（为保证主容器运行）
- 读取私密文件等等（保证系统的安全，init c一旦成功结束，就会删除，而读取私密文件放在主容器中，可能会出现安全隐患，因为主容器时一直运行）
- 但是不建议用init c去监测其他容器（比如，我们的服务mysql应该先启动，用init c去监测mysql的容器时是正常的，init c成功结束，但是主容器启动时mysql容器可能又挂了，所以这种方法不太准确）
3、特殊说明
- 在Pod启动过程中，Init容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出，init c按顺序执行，上一个执行成功之后才会执行下一个
- 如果由于运行时或失败退出，将导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。然而，如果Pod的restartPolicy设置为Always ，Init容器失败时会使用RestartPolicy策略
- 在所有的Init容器没有成功之前，Pod将不会变成Ready状态。Init容器的端口将不会在Service中进行聚集。正在初始化中的 Pod处于 Pending 状态，但应该会将 Initializing状态设置为 true
- 如果Pod重启，所有Init容器必须重新执行
- 对Init容器spec的修改被限制在容器image字段，修改其他字段都不会生效。更改Init容器的image字段，等价于重启该Pod
- Init容器具有应用容器的所有字段。除了 readinessProbe ，因为Init容器无法定义不同于完成（completion）的就绪（readiness）之外的其他状态。这会在验证过程中强制执行
- 在Pod中的每个app和Init容器的名称必须唯一；与任何其它容器共享同一个名称，会在验证时抛出错误
- start和stop会在main c 启动之后和结束之前做一些事情
4、init c资源清单示例
-
# pod 资源清单 apiVersion: v1 kind: Pod metadata: name: initc-pod labels: app: myapp spec: containers: - name: initc-container image: busybox command: ['sh', '-c', 'echo The app is running! && sleep 3600'] # 以下为init c容器 initContainers: # 第一个init c容器 - name: init-myservice image: busybox # 监测service 看集群中有无名为myservice的service 直至监测到才会成功推出（直接写service名称可能不能解析，ping不同，解决方法如下） command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2;done;'] # 第一个init c容器 - name: init-mydb image: busybox # 监测service 看集群中有无名为mydb的service 直至监测到才会成功推出 command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;'] -
# 查看pod状态 [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE initc-pod 0/1 Init:0/2 0 43s # 查看pod日志 [root@k8smaster pods]# kubectl logs initc-pod -c init-myservice ;; connection timed out; no servers could be reached waiting for myservice ;; connection timed out; no servers could be reached waiting for myservice ;; connection timed out; no servers could be reached ...... -
# service 资源清单 简写svc kind: Service apiVersion: v1 metadata: name: myservice spec: ports: # 使用的协议 TCP和UDP可选 - protocol: TCP # 暴露给k8s内部集群的端口 port: 80 # 也监听就是sevice的pod下容器 并且容器暴露端口为9376 targetPort: 9376 # 用--- 分开表示一个yaml文件 --- kind: Service apiVersion: v1 metadata: name: mydb spec: ports: - protocol: TCP port: 80 targetPort: 9377 -
# 启动名为myservice的service 查看pod状态 [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE initc-pod 0/1 Init:1/2 0 57s # 启动名为mydb的service 查看pod状态 [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE initc-pod 1/1 Running 0 2m34s -
解决pod内不能通过域名进行访问其他servce或者pod（ping 不同 不管是clusterIp，还是名称）
-
问题原因：kubeadm安装的k8s的kube-proxy使用的iptables，需要修改为ipvs
-
1.开启ipvs支持（每个节点执行）
- yum -y install ipvsadm ipset （好像可省略）
- 永久生效：cat > /etc/sysconfig/modules/ipvs.modules <<EOF
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
EOF - 临时生效：modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
-
2.修改权限（每个节点执行，好像可省略）
- chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4
-
3.修改kube-proxy的configMap
-
kubectl edit cm kube-proxy -n kube-system
-
ipvs: excludeCIDRs: null minSyncPeriod: 0s scheduler: "" strictARP: false syncPeriod: 30s kind: KubeProxyConfiguration metricsBindAddress: 127.0.0.1:10249 mode: "ipvs" # 修改此处为ipvs
-
-
4.重启kube-proxy
- kubectl get pod -n kube-system | grep kube-proxy |awk '{system("kubectl delete pod "$1" -n kube-system")}'
-
5.查看kube-proxy启动日志，确认是否为ipvs
-
kubectl logs -n kube-system kube-proxy-ff74q（自己的kube-proxy pod名）
-
# 有Using ipvs Proxier则配置成功 I1215 09:18:42.852942 1 server_others.go:259] Using ipvs Proxier.
-
-
6.进入Pod中使用ping 命令测试，如果不行重启k8s集群后再试
-
5、健康检查（探针）
-
探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler 。有三种类型的处理程序
- ExecAction ：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功
- TCPSocketAction ：对指定端口上的容器的IP地址进行TCP检查。如果端口打开，则诊断被认为是成功的
- HTTPGetAction ：对指定的端口和路径上的容器的 IP地址执行 HTTP Get请求。如果响应的状态码大于等于200且小于400 ，则诊断被认为是成功的，可以防止端口是开的但是服务已经挂掉
-
每次探测都将获得以下三种结果之一
- 成功：容器通过了诊断
- 失败：容器未通过诊断
- 未知：诊断失败，因此不会采取任何行动
-
探针分类
-
readinessProbe ：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service的端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure 。如果容器不提供就绪探针，则默认状态为 Success，也就是在主容器创建时，检测该主容器是否已经准备就绪，可以向外界提供服务了，防止出现，容器启动了，但是容器中的服务还没有启动，这个是否向外界提供服务就会出现异常
-
readinessProbe只影响Realy状态，不会重启pod，重启pod会重新执行readinessProbe
-
资源清单示例
-
apiVersion: v1 kind: Pod metadata: name: readiness-httpget-pod namespace: default spec: containers: - name: readiness-httpget-container image: nginx # 镜像拉取方式，如果本地有就用本地 imagePullPolicy: IfNotPresent # 就绪检查方式采用httpGet，默认的nginx肯定没有index1.html readinessProbe: httpGet: port: 80 path: /index1.html # 开始检测延迟时间1s initialDelaySeconds: 1 # 检测间隔时间3s periodSeconds: 3
-
-
启动readiness-httpget-pod并查看
-
# pod的状态为Running，但是READY没准备好 [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE readiness-httpget-pod 0/1 Running 0 5m51s # 查看pod的描述 就绪检测失败 [root@k8smaster pods]# kubectl describe pod readiness-httpget-pod Warning Unhealthy 4m26s (x100 over 9m23s) kubelet, k8snode2 Readiness probe failed: HTTP probe failed with statuscode: 404
-
-
进入Pod中添加index1.html
-
# 向/usr/share/nginx/html 中添加index1.html 后查看pod状态已经就绪 # kubectl exec -it pod名 -c 容器名（pod中只有一个容器可不指定） -- /bin/sh（执行的命令） [root@k8smaster pods]# kubectl exec -it readiness-httpget-pod -c readiness-httpget-container -- /bin/sh # cd /usr/share/nginx/html # echo "123" >> index1.html # ls 50x.html index.html index1.html # exit [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE readiness-httpget-pod 1/1 Running 0 16m
-
-
-
livenessProbe ：指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，并且容器将受到其重启策略的影响。如果容器不提供存活探针，则默认状态为Success，也就是为了防止僵尸进程存在，进程还在，不能提供服务
-
livenessProbe检测失败会重启pod，重启pod会重新执行readinessProbe
-
资源清单示例一：exec方式
-
apiVersion: v1 kind: Pod metadata: name: liveness-exec-pod namespace: default spec: containers: - name: liveness-exec-container image: busybox imagePullPolicy: IfNotPresent # 容器启动的命令 在/tmp下创建live文件 过30s删除 command: ["/bin/sh","-c","touch /tmp/live ; sleep 30; rm -rf /tmp/live; sleep 3600"] # 存活检查采用 命令的方式 看/tmp下创建live文件存不存在 不存在则检测失败，使用Pod的重启策略 livenessProbe: exec: command: ["test","-e","/tmp/live"] initialDelaySeconds: 1 periodSeconds: 3 -
# 查看pod 在30s的时候进行了重启（也不一定是30s，因为容器启动也会浪费时间） [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE liveness-exec-pod 1/1 Running 0 29s web-5dcb957ccc-r74d6 1/1 Running 0 28m [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE liveness-exec-pod 1/1 Running 1 32s web-5dcb957ccc-r74d6 1/1 Running 0 28m
-
-
资源清单示例二：httpGet方式
-
apiVersion: v1 kind: Pod metadata: name: liveness-httpget-pod namespace: default spec: containers: - name: liveness-httpget-container image: nginx imagePullPolicy: IfNotPresent ports: - name: http # 该Pod监听其下容器的端口 containerPort: 80 # 存活检查采用 httpGet的方式 访问/index.html存不存在 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 # 超时时间 超时代表失败 timeoutSeconds: 10 -
# 查看pod状态 [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE liveness-httpget-pod 1/1 Running 0 5m12s # 进入pod删除index.html [root@k8smaster pods]# kubectl exec -it liveness-httpget-pod -c readiness-httpget-container -- /bin/sh # cd /usr/share/nginx/html # rm index.html # 查看pod状态 [root@k8smaster pods]# kubectl get pod NAME READY STATUS RESTARTS AGE liveness-httpget-pod 1/1 Running 1 9m43s
-
-
资源清单示例三：tcp方式
-
apiVersion: v1 kind: Pod metadata: name: liveness-tcp-pod spec: containers: - name: liveness-tcp-container image: nginx # 存活检查采用 tcp的方式 检查8080端口 livenessProbe: initialDelaySeconds: 5 timeoutSeconds: 1 periodSeconds: 3 tcpSocket: port: 8080 -
# 查看pod状态 一直重启 因为8080端口一直不存在 NAME READY STATUS RESTARTS AGE liveness-tcp-pod 1/1 Running 4 104s
-
-
-
readinessProbe和livenessProbe 同时使用
-
资源清单示例
-
apiVersion: v1 kind: Pod metadata: name: liveness-httpget-pod namespace: default spec: containers: - name: liveness-httpget-container image: nginx imagePullPolicy: IfNotPresent ports: - name: http # 该Pod监听其下容器的端口 containerPort: 80 readinessProbe: httpGet: port: 80 path: /index1.html # 开始检测延迟时间1s initialDelaySeconds: 1 # 检测间隔时间3s periodSeconds: 3 # 存活检查采用 httpGet的方式 访问/index.html存不存在 livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3 # 超时时间 超时代表失败 timeoutSeconds: 10
-
-
-
6、start和stop
-
Pod hook（钩子）是由 Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。可以同时为Pod中的所有容器都配置hookHook
-
Hook 的类型包括两种
- exec ：执行一段命令
- HTTP ：发送 HTTP 请求
-
资源清单示例
-
apiVersion: v1 kind: Pod metadata: name: lifecycle-demo spec: containers: - name: lifecycle-demo-container image: nginx lifecycle: # 容器启动后执行 postStart: exec: command: ["/bin/sh", "-c", "echo Hello from the postStart handler >/usr/share/message"] # 容器关闭前执行 preStop: exec: command: ["/bin/sh", "-c", "echo Hello from the poststop handler >/usr/share/message"] -
# 进入容器查看 [root@k8smaster pods]# kubectl exec -it lifecycle-demo -- /bin/sh # cat /usr/share/message Hello from the postStart handler
-
7、pod状态
- 挂起（ Pending ）： Pod 已被 Kubernetes 系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度 Pod
- 运行中（ Running ）：该 Pod 已经绑定到了一个节点上， Pod 中所有的容器都已被创建。至少有一个容器正在运行，或者正处于启动或重启状态
- 成功（ Succeeded ）： Pod 中的所有容器都被成功终止，并且不会再重启 常见job和cronjob
- 失败（ Failed ）： Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非 0
- 未知（ Unknown ）：因为某些原因无法取得 Pod 的状态，通常是因为与 Pod 所在主机通信失败
二、控制器
- Kubernetes中内建了很多controller（控制器），这些相当于一个状态机，用来控制Pod的具体状态和行为，也就是说pod是最小的调度单元，而控制器用来管理pod,由控制器管理的pod死亡后，会被拉起，而没被管理的pod不会被管（也就是自主式pod）
1、Replication Controller(RC)
-
Replication Controller(RC)是Kubernetes系统中核心概念之一，当我们定义了一个 RC并提交到Kubernetes集群中以后，Master节点上的Controller Manager组件就得到通知，定期检查系统中存活的Pod,并确保目标Pod实例的数量刚好等于RC的预期值，如果有过多或过少的Pod运行，系统就会停掉或创建一些Pod.此外我们也可以通过修改RC副本数量，来实现Pod的动态缩放功能，也就是说RC用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收
-
资源清单示例
-
apiVersion: v1 kind: ReplicationController metadata: name: rcdemo spec: # pod需要保持的副本数 replicas: 3 # RC的标签选择器 selector: # 所管理的Pod上有tier=frontend 这个标签，也就是说RC是通过labels来区分自己要管理的Pod，不支持集合式的selector tier: frontend # template 相当于定义的Pod template: metadata: # pod的标签key=value的形式 如果跟RC所需要的一致，就会被匹配到的RC管理 labels: tier: frontend spec: # pod中的容器 containers: - name: mynginx image: nginx # 容器内部添加环境变量 env: - name: GET_HOSTS_FROM value: dns ports: - containerPort: 80 -
# 创建RC [root@k8smaster deployments]# kubectl apply -f rcdemo.yaml replicationcontroller/rcdemo created # 查看rc DESIRED：设计数量 CURRENT：当前数量 READY：准备的数量 [root@k8smaster deployments]# kubectl get rc NAME DESIRED CURRENT READY AGE rcdemo 3 3 3 11m 并查看Pod Pod名称规则（控制器name+随机字符串） [root@k8smaster deployments]# kubectl get pod NAME READY STATUS RESTARTS AGE rcdemo-4sgkd 1/1 Running 0 37s rcdemo-hkhfw 1/1 Running 0 37s rcdemo-xnr2n 1/1 Running 0 37s # 删除所有pod 在查看pod是否被控制器拉起 [root@k8smaster deployments]# kubectl delete pod --all pod "rcdemo-4sgkd" deleted pod "rcdemo-hkhfw" deleted pod "rcdemo-xnr2n" deleted # --show-labels（显示标签） 被拉起的Pod和原来的完全不一样 说明是重新创建的 [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS rcdemo-bxtzt 1/1 Running 0 62s tier=frontend rcdemo-f2pnn 1/1 Running 0 62s tier=frontend rcdemo-gbxt4 1/1 Running 0 62s tier=frontend # 修改其中一个Pod的label 观察Pod情况 发现多了一个Pod（说明了控制器是通过label来控制Pod的） [root@k8smaster deployments]# kubectl label pod rcdemo-bxtzt tier=frontend123 --overwrite pod/rcdemo-bxtzt labeled [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS rcdemo-8kt4h 1/1 Running 0 14s tier=frontend rcdemo-bxtzt 1/1 Running 0 7m34s tier=frontend123 rcdemo-f2pnn 1/1 Running 0 7m34s tier=frontend rcdemo-gbxt4 1/1 Running 0 7m34s tier=frontend
-
2、ReplicaSet(RS)
-
Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector
-
资源清单示例
-
apiVersion: apps/v1 kind: ReplicaSet metadata: name: rsdemo spec: # pod需要保持的副本数 replicas: 3 # RC的标签选择器 selector: # 所管理的Pod上需要有tier=frontend 这个标签，也就是说RS是通过labels来区分自己要管理的Pod，支持集合式的selector matchLabels等（RC不支持） matchLabels: tier: frontend # template 相当于定义的Pod template: metadata: # pod的标签key=value的形式 如果跟RC所需要的一致，就会被匹配到的RS管理 labels: tier: frontend spec: # pod中的容器 containers: - name: mynginx image: nginx # 容器内部添加环境变量 env: - name: GET_HOSTS_FROM value: dns ports: - containerPort: 80 -
# 使用效果和RC一样
-
3、Deployment
-
Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的ReplicationController来方便的管理应用，Kubenetes v1.2 引入的新概念，引入的目的是为了更好的解决 Pod 的编排问题，Deployment 内部使用了 Replica Set 来实现。Deployment 的定义与 Replica Set 的定义很类似
-
应用场景
- RS和RC只能维持Pod的副本数量，功能薄弱
- 定义 Deployment 来创建 Pod 和 ReplicaSet
- 滚动升级和回滚应用：可以动态的切换版本，底层使用不同的RS来实现的
- 扩容和缩容：增加或减少副本的数量
- 暂停和继续 Deployment
- 滚动升级和回滚
-
-
说明：从V1版升级到V2版 共有三个Pod副本
- 1.创建新的RS1，创建一个（数量可控）新的V2Pod，当新的V2Pod可以正常使用后，删除一个旧的V1Pod，保证k8s集群中该中Pod的数量不会变，直至所有的V1Pod换成V2Pod，并且旧的RS不会被删除（用于回滚）
- 2.回滚的过程和上述相反，启动旧的RS
-
-
资源清单示例
-
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 # 这个版本的Deployment不能省去selector selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 -
# 启动Deployment 查看 Deployment 、rs（rs名称规则：Deployment的name+随机字符串） 和 pod （pod名称规则：rs的name+随机字符串） # --record 方便查看版本 [root@k8smaster deployments]# kubectl apply -f nginx-deployment.yaml --record deployment.apps/nginx-deployment created [root@k8smaster deployments]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 42s [root@k8smaster deployments]# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-5bf87f5f59 3 3 3 47s [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-hxj25 1/1 Running 0 93s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-wgw7w 1/1 Running 0 93s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-zcf82 1/1 Running 0 93s app=nginx,pod-template-hash=5bf87f5f59 # 动态扩容到10个Pod副本 [root@k8smaster deployments]# kubectl scale deployment nginx-deployment --replicas 10 deployment.apps/nginx-deployment scaled [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-58vtn 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-dmrrs 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-f7cl6 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-g5n6j 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-gsvpd 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-hfmjh 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-hxj25 1/1 Running 0 2m30s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-wgw7w 1/1 Running 0 2m30s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-wzjtm 1/1 Running 0 29s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-zcf82 1/1 Running 0 2m30s app=nginx,pod-template-hash=5bf87f5f59 # 动态缩减到3个Pod副本 发现还是原来的那3个 说明会保留存活时间长的 [root@k8smaster deployments]# kubectl scale deployment nginx-deployment --replicas 3 deployment.apps/nginx-deployment scaled [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-hxj25 1/1 Running 0 3m11s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-wgw7w 1/1 Running 0 3m11s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-zcf82 1/1 Running 0 3m11s app=nginx,pod-template-hash=5bf87f5f59 [root@k8smaster deployments]# # 动态扩容和缩减都不会重新创建新的RS [root@k8smaster deployments]# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-5bf87f5f59 3 3 3 5m9s -
# 滚动更新 更新镜像版本 查看 RS 和 pod [root@k8smaster deployments]# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment.apps/nginx-deployment image updated # 已经创建了新的RS [root@k8smaster deployments]# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-5bf87f5f59 3 3 3 9m46s nginx-deployment-678645bf77 1 1 0 3s # 已经启动的新Pod [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-hxj25 1/1 Running 0 9m49s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-wgw7w 1/1 Running 0 9m49s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-zcf82 1/1 Running 0 9m49s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-678645bf77-4k5ls 0/1 ContainerCreating 0 6s app=nginx,pod-template-hash=678645bf77 # 持续观察 RS 和 pod READY的数量始终会保持在我们需要的副本数量 [root@k8smaster deployments]# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-5bf87f5f59 1 1 1 10m nginx-deployment-678645bf77 3 3 2 41s [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-wgw7w 1/1 Running 0 10m app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-678645bf77-4k5ls 1/1 Running 0 48s app=nginx,pod-template-hash=678645bf77 nginx-deployment-678645bf77-szk6f 1/1 Running 0 18s app=nginx,pod-template-hash=678645bf77 nginx-deployment-678645bf77-tm4jl 0/1 ContainerCreating 0 16s app=nginx,pod-template-hash=678645bf77 # 最终结果 旧的RS并没有删除 [root@k8smaster deployments]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-deployment-5bf87f5f59 0 0 0 23m nginx nginx:1.7.9 app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-678645bf77 3 3 3 13m nginx nginx:1.9.1 app=nginx,pod-template-hash=678645bf77 [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-678645bf77-4k5ls 1/1 Running 0 67s app=nginx,pod-template-hash=678645bf77 nginx-deployment-678645bf77-szk6f 1/1 Running 0 37s app=nginx,pod-template-hash=678645bf77 nginx-deployment-678645bf77-tm4jl 1/1 Running 0 35s app=nginx,pod-template-hash=678645bf77 # 使用 kubectl edit deployment/nginx-deployment 可以编辑资源的yaml -
# 回滚到上一个版本 启用上一个版本对应的RS [root@k8smaster deployments]# kubectl rollout undo deployment/nginx-deployment deployment.apps/nginx-deployment rolled back [root@k8smaster deployments]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-deployment-5bf87f5f59 2 2 1 27m nginx nginx:1.7.9 app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-678645bf77 2 2 2 17m nginx nginx:1.9.1 app=nginx,pod-template-hash=678645bf77 [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-97lds 1/1 Running 0 9s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-lb7mm 1/1 Running 0 13s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-zltbv 1/1 Running 0 11s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-678645bf77-4k5ls 0/1 Terminating 0 18m app=nginx,pod-template-hash=678645bf77 nginx-deployment-678645bf77-szk6f 0/1 Terminating 0 17m app=nginx,pod-template-hash=678645bf77 nginx-deployment-678645bf77-tm4jl 0/1 Terminating 0 17m app=nginx,pod-template-hash=678645bf77 [root@k8smaster deployments]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR nginx-deployment-5bf87f5f59 3 3 3 28m nginx nginx:1.7.9 app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-678645bf77 0 0 0 18m nginx nginx:1.9.1 app=nginx,pod-template-hash=678645bf77 [root@k8smaster deployments]# kubectl get pod --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-5bf87f5f59-97lds 1/1 Running 0 26s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-lb7mm 1/1 Running 0 30s app=nginx,pod-template-hash=5bf87f5f59 nginx-deployment-5bf87f5f59-zltbv 1/1 Running 0 28s app=nginx,pod-template-hash=5bf87f5f59 # 查看回滚状态如果 rollout 成功完成， kubectl rollout status 将返回一个0值的 Exit Code [root@k8smaster deployments]# kubectl rollout status deployment/nginx-deployment deployment "nginx-deployment" successfully rolled out [root@k8smaster deployments]# echo $? 0 # 查看版本 前面的REVISION可用于回退于指定版本 [root@k8smaster deployments]# kubectl rollout history deployment/nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 2 kubectl apply --filename=nginx-deployment.yaml --record=true 3 kubectl apply --filename=nginx-deployment.yaml --record=true -
# Deployment 更新策略 # Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用） # Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的Pod数量多一个的 Pod 是 up 的（最多1个 surge ） [root@k8smaster deployments]# kubectl describe deployments Name: nginx-deployment Namespace: default CreationTimestamp: Wed, 16 Dec 2020 10:57:54 +0800 Labels: <none> Annotations: deployment.kubernetes.io/revision: 3 kubernetes.io/change-cause: kubectl apply --filename=nginx-deployment.yaml --record=true Selector: app=nginx Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge # 未来的 Kuberentes 版本中，将从1-1变成25%-25% -
Rollover（多个rollout并行）
- 假如您创建了一个有5个niginx:1.7.9 replica的Deployment，但是当还只有3个nginx:1.7.9 的 replica 创建出来的时候您就开始更新含有5个 nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个 nginx:1.7.9 的 Pod，并开始创建 nginx:1.9.1 的 Pod。它不会等到所有的5个 nginx:1.7.9 的Pod 都创建完成后才开始改变航道
-
回退Deployment
-
# 查看版本历史记录 REVISION可用于回退于指定版本 kubectl rollout history deployment/nginx-deployment [root@k8smaster deployments]# kubectl rollout history deployment/nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 2 kubectl apply --filename=nginx-deployment.yaml --record=true 3 kubectl apply --filename=nginx-deployment.yaml --record=true # 回退到当前的上一个版本 kubectl rollout undo deployment/nginx-deployment # 回退到指定版本 可以使用 --revision参数指定某个历史版本 kubectl rollout undo deployment/nginx-deployment --to-revision=2 # 暂停 deployment 的更新 kubectl rollout pause deployment/nginx-deployment # 通过设置.spec.revisonHistoryLimit来指定deployment最多保留多少revision历史记录。默认会保留所有revision；如果将该项设置为0，Deployment 就不能回退
-
-
4、DaemonSet
-
DaemonSet 确保全部（或者一些）Node上运行一个Pod 的副本。当有Node加入集群时，也会为他们新增一个Pod 。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod，也就是说由DaemoSet控制的Pod会在每个Node上都会运行一个，相当于一个守护模式，当有新的Node加入到集群时，新的Node也会有这种Pod，当有Node退出集群时，这个Node上的Pod就会删除
-
应用场景
- 运行集群存储 daemon，例如在每个 Node 上运行 glusterd 、 ceph
- 在每个 Node 上运行日志收集 daemon，例如 fluentd 、 logstash
- 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、 collectd 、Datadog 代理、New Relic 代理，或 Ganglia gmond
-
资源清单示例
-
apiVersion: apps/v1 kind: DaemonSet metadata: name: deamonset-example labels: app: daemonset spec: selector: matchLabels: name: deamonset-example template: metadata: labels: name: deamonset-example spec: containers: - name: daemonset-example image: nginx -
# 启动deamonset-example [root@k8smaster deployments]# kubectl apply -f deamonset-example.yaml daemonset.apps/deamonset-example created # 查看 DaemonSet [root@k8smaster deployments]# kubectl get daemonset NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE deamonset-example 2 2 2 2 2 <none> 71s # 查看 Pod node1和node2节点上各一个 [root@k8smaster deployments]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES deamonset-example-5l9f6 1/1 Running 0 28s 10.244.2.31 k8snode1 <none> <none> deamonset-example-lwhrl 1/1 Running 0 28s 10.244.1.35 k8snode2 <none> <none>
-
5、StatefulSet
-
StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序
-
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计）例如mysql
-
应用场景
- 定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
- 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行（即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
- 有序收缩，有序删除（即从N-1到0）
-
需要用到的知识有service，pvc存储等，可先跳过，先学习下前置知识
-
在PVC模块详细介绍
6、Job
-
Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束
-
Job Spec
- spec.template格式同Pod
- RestartPolicy仅支持Never或OnFailure（仅执行成功一次所以不能用Always）
- 单个Pod时，默认Pod成功运行后Job即结束
- .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1 （Pod的返回码为0时成功一次）
- .spec.parallelism 标志并行运行的Pod的个数，默认为1
- .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试
-
资源清单示例
-
apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: metadata: name: pi spec: containers: - name: pi # 该镜像用于计算圆周率 CMD是将2000位的圆周率输出 image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never -
# 创建job [root@k8smaster deployments]# kubectl apply -f job-test.yaml job.batch/pi created # 查看job 已经成功结束 [root@k8smaster deployments]# kubectl get job NAME COMPLETIONS DURATION AGE pi 1/1 90s 109s # 查看pod 已经成功结束 [root@k8smaster deployments]# kubectl get pod NAME READY STATUS RESTARTS AGE pi-ljl4g 0/1 Completed 0 101s # 查看pod日志 [root@k8smaster deployments]# kubectl logs pi-ljl4g 3.1415926535897932384626433832795028841971693993751058209...以后位数省略
-
7、CronJob
-
CronJob管理基于时间的 Job
- 在给定时间点只运行一次
- 周期性地在给定时间点运行
- 使用条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob）
- CronJob通过创建Job来进行管理
-
应用场景
- 在给定的时间点调度 Job 运行
- 建周期性运行的 Job，例如：数据库备份、发送邮件
-
CronJob Spec
- .spec.schedule指定任务运行周期，格式同Cron
- .spec.jobTemplate指定需要运行的任务，格式同Job，包含了.spec.completions、.spec.parallelism、.spec.activeDeadlineSeconds
- .spec.startingDeadlineSeconds ：启动 Job 的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限
- .spec.concurrencyPolicy ：并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：
- Allow （默认）：允许并发运行 Job
- Forbid ：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
- Replace ：取消当前正在运行的 Job，用一个新的来替换
- 注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行
- .spec.suspend ：挂起，该字段也是可选的。如果设置为true ，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为 false
- .spec.successfulJobsHistoryLimit和.spec.failedJobsHistoryLimit ：历史限制，是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为3和1 。设置限制的值为0 ，相关类型的Job完成后将不会被保留
- .spec.startingDeadlineSeconds指定任务开始的截止期限
-
资源清单示例
-
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: # 一分钟创建一个Job去执行 （分钟 小时 天 月 周） schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: hello image: busybox args: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: OnFailure -
# 启动cronjob [root@k8smaster deployments]# kubectl apply -f cronjob-test.yaml cronjob.batch/hello created # 查看cronjob [root@k8smaster deployments]# kubectl get cronjob NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 <none> 12s # 等待几分钟查看job和pod 默认只保留3条 [root@k8smaster deployments]# kubectl get job NAME COMPLETIONS DURATION AGE hello-1608103680 1/1 16s 2m49s hello-1608103740 1/1 17s 108s hello-1608103800 1/1 17s 48s [root@k8smaster deployments]# kubectl get pod NAME READY STATUS RESTARTS AGE hello-1608103680-68c5t 0/1 Completed 0 2m54s hello-1608103740-9rwpl 0/1 Completed 0 114s hello-1608103800-fjv7z 0/1 Completed 0 54s -
注意事项：
- 创建Job操作应该是幂等的（防止后面的运行结果影响前面的结果）
- cronjob不能连接到job的成功，只会周期的创建job，但是job是否运行成功可以监测到
-
三、Service
-
Kubernetes Service定义了这样一种抽象：一个Pod的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组Pod能够被Service访问到，通常是通过Label Selector,标签选择不到创建的是空集群
-
Kubernetes Service可以为一组具有相同功能的容器应用提供一个统一的入口地址，并且将请求负载分发到后端的各个容器应用上，提供了服务注册与发现(因为Pod挂掉之后，新创建的Pod的原来的完全不一样，防止Pod失联)，相当于注册中心
-
Service能够提供负载均衡的能力，但是在使用上有以下限制
- 只提供 4 层负载均衡能力，而没有7层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的，仅支持轮询算法
- 四层负载均衡：通过Ip和端口进行转发
- 七层负载均衡：主机和域名进行转发（k8s通过ingress可以实现）
-
service原理：
-
service分类
- ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP
- NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务
- LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort
- ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持
-
VIP和Service代理
- 在 Kubernetes 集群中，每个 Node 运行一个kube-proxy 进程。kube-proxy负责为Service实现了一种VIP（虚拟 IP）的形式，而不是ExternalName的形式。 在Kubernetes v1.0 版本，代理完全在 userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是iptables 代理。 在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理
在 Kubernetes 1.14 版本开始默认使用 ipvs 代理 - 在 Kubernetes v1.0 版本， Service 是 “4层”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了Ingress API（beta 版），用来表示 “7层”（HTTP）服务
- 为什么不使用DNS代理
- 因为DNS有缓存，不能实现负载均衡
- 在 Kubernetes 集群中，每个 Node 运行一个kube-proxy 进程。kube-proxy负责为Service实现了一种VIP（虚拟 IP）的形式，而不是ExternalName的形式。 在Kubernetes v1.0 版本，代理完全在 userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是iptables 代理。 在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理
-
代理模式分类
-
userspace 代理模式
-
iptables 代理模式
-
ipvs 代理模式
-
-
这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：
- rr ：轮询调度
- lc ：最小连接数
- dh ：目标哈希
- sh ：源哈希
- sed ：最短期望延迟
- nq ： 不排队调度
-
-
1、ClusterIp
-
默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP（自身节点也可访问）
-
clusterIP 主要在每个 node 节点使用 iptables或ipvs，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口
-
- apiserver 用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中
- kube-proxy kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中
- iptables 使用NAT等技术将virtualIP的流量转至endpoint中
- 服务支持tcp和UDP，但是默认的是TCP
-
资源清单示例
-
# deployment 的资源清单 apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy namespace: default spec: replicas: 3 selector: # 需要匹配的标签 matchLabels: app: myapp release: stabel template: metadata: # Pod携带的标签 labels: app: myapp release: stabel env: test spec: containers: - name: myapp image: nginx imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 -
# ClusterIP service 的资源清单 apiVersion: v1 kind: Service metadata: name: myapp namespace: default spec: # service 的类型 type: ClusterIP # 通过标签来选择pod，需全部满足 selector: app: myapp release: stabel # 暴露端口 ports: # name 是pod的一个端口 - name: http # 集群内部使用的端口 port: 80 # 转发到其下Pod的容器端口 负载均衡算法是轮询 targetPort: 80 -
# 创建myapp-deploy的deployment 并查看Pod [root@k8smaster services]# kubectl apply -f myapp-deploy.yaml deployment.apps/myapp-deploy created [root@k8smaster services]# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE myapp-deploy 3/3 3 3 14s [root@k8smaster services]# kubectl get pod NAME READY STATUS RESTARTS AGE myapp-deploy-7c4dbc97b9-qk62v 1/1 Running 0 20s myapp-deploy-7c4dbc97b9-qvx4h 1/1 Running 0 20s myapp-deploy-7c4dbc97b9-svsww 1/1 Running 0 20s # 创建service并查看 [root@k8smaster services]# kubectl apply -f clusterip.yaml service/myapp created [root@k8smaster services]# kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 20h <none> myapp ClusterIP 10.110.54.87 <none> 80/TCP 6m28s app=myapp,release=stabel # 使用 CLUSTER-IP 进行访问 [root@k8smaster services]# curl 10.110.54.87:80 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { 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>
-
2、Headless
-
有时不需要或不想要负载均衡，以及单独的 Service IP 。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP) 的值为 “None” 来创建 Headless Service 。这类 Service 并不会分配 Cluster IP， kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由，简单点说CLUSTER-IP为None 部署有状态服务时必须使用
-
资源清单示例
-
apiVersion: v1 kind: Service metadata: name: myapp-headless namespace: default spec: selector: app: myapp clusterIP: "None" ports: - port: 80 targetPort: 80 -
# 创建无头service并查看 [root@k8smaster services]# kubectl apply -f headless.yaml service/myapp-headless created [root@k8smaster services]# kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 21h <none> myapp-headless ClusterIP None <none> 80/TCP 4s app=myapp # 通过endpoints查看其关联的Pod [root@k8smaster services]# kubectl get endpoints NAME ENDPOINTS AGE kubernetes 192.168.47.150:6443 66s myapp-headless 10.244.1.76:80,10.244.2.73:80,10.244.2.74:80 8s
-
-
通过解析域名的方式查看Headless所关联的Pod（也就意味着没有CLUSTER-IP，还能使用域名的方式去访问Headless）
-
# 查看系统Pod 其中 coredns 就是负责域名解析的 [root@k8smaster services]# kubectl get pod -n kube-system -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES coredns-7ff77c879f-494fb 1/1 Running 2 41h 10.244.2.14 k8snode1 <none> <none> coredns-7ff77c879f-tvgrz 1/1 Running 2 42h 10.244.1.20 k8snode2 <none> <none> etcd-k8smaster 1/1 Running 3 6d14h 192.168.47.150 k8smaster <none> <none> kube-apiserver-k8smaster 1/1 Running 3 6d14h 192.168.47.150 k8smaster <none> <none> kube-controller-manager-k8smaster 1/1 Running 15 6d14h 192.168.47.150 k8smaster <none> <none> kube-flannel-ds-amd64-hflj8 1/1 Running 4 6d1h 192.168.47.150 k8smaster <none> <none> kube-flannel-ds-amd64-s9xhk 1/1 Running 3 6d1h 192.168.47.162 k8snode2 <none> <none> kube-flannel-ds-amd64-wp7mp 1/1 Running 4 6d1h 192.168.47.161 k8snode1 <none> <none> kube-proxy-5l8kb 1/1 Running 2 42h 192.168.47.150 k8smaster <none> <none> kube-proxy-6n8vp 1/1 Running 2 42h 192.168.47.161 k8snode1 <none> <none> kube-proxy-lgcxp 1/1 Running 2 42h 192.168.47.162 k8snode2 <none> <none> kube-scheduler-k8smaster 1/1 Running 16 6d14h 192.168.47.150 k8smaster <none> <none> # 使用dig 命令 解析域名 dig -t A service名.命名空间名.svc.cluster.local.（默认集群域名） @coredns的Ip（任意一个即可） # 如果没有dig 命令 安装即可 yum -y install bind-utils # 我们发现 其中所关联的Pod都显示了出来 [root@k8smaster services]# dig -t A myapp-headless.default.svc.cluster.local. @10.244.2.14 ; <<>> DiG 9.11.13-RedHat-9.11.13-3.el8 <<>> -t A myapp-headless.default.svc.cluster.local. @10.244.2.14 ;; global options: +cmd ;; Got answer: ;; WARNING: .local is reserved for Multicast DNS ;; You are currently testing what happens when an mDNS query is leaked to DNS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37833 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 96e732da9566602d (echoed) ;; QUESTION SECTION: ;myapp-headless.default.svc.cluster.local. IN A ;; ANSWER SECTION: myapp-headless.default.svc.cluster.local. 30 IN A 10.244.2.73 myapp-headless.default.svc.cluster.local. 30 IN A 10.244.2.74 myapp-headless.default.svc.cluster.local. 30 IN A 10.244.1.76 ;; Query time: 2 msec ;; SERVER: 10.244.2.14#53(10.244.2.14) ;; WHEN: Thu Dec 17 11:02:40 CST 2020 ;; MSG SIZE rcvd: 249
-
3、NodePort
-
nodePort的原理在于在node上开了一个端口，将向该端口的流量导入到kube-proxy，然后由kube-proxy进一步到给对应的pod
-
将服务暴露给集群外部使用，可指定端口
-
NodePort，Kubernetes master会分配一个区域范围内，（默认是30000-32767），并且，每一个node，都会代理（proxy）这个端口到你的服务中，我们可以在spec.ports[*].nodePort 找到具体的值，如果我们向指定一个端口，我们可以直接写在nodePort上，系统就会给你指派指定端口，但是这个值必须是指定范围内的
-
-
资源清单示例
-
apiVersion: v1 kind: Service metadata: name: myapp-nodeport namespace: default spec: type: NodePort selector: app: myapp release: stabel ports: - name: http port: 80 targetPort: 80 # node暴露的端口 外界使用任意nodeIp:该端口 不指定随机分配 nodePort: 30001 -
# 创建myapp-nodeport并查看service [root@k8smaster services]# kubectl apply -f nodeport.yaml service/myapp-nodeport created [root@k8smaster services]# kubectl get svc -o wide NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 21h <none> myapp-nodeport NodePort 10.111.91.90 <none> 80:30001/TCP 4s app=myapp,release=stabel # 经过测试 在外界使用任意nodeIp:30001 都可访问成功 # iptables -t nat -nvL 查询转发流程 # ipvsadm -Ln 查询转发流程 [root@k8smaster services]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 10.96.0.1:443 rr -> 192.168.47.150:6443 Masq 1 1 0 TCP 10.96.0.10:53 rr -> 10.244.1.20:53 Masq 1 0 0 -> 10.244.2.14:53 Masq 1 0 0
-
4、LoadBalancer
- loadBalancer 和 nodePort 其实是同一种方式。区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用cloud provider 去创建LB来向节点导流（nodePort使用的是nginx等其他）
- 云服务商收费
5、ExternalName
-
这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容( 例如：www.baidu.com )。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务
-
在集群内部访问集群外部的服务
-
-
资源清单示例
-
apiVersion: v1 kind: Service metadata: # 名称externalName-1、externalName1 为什么不合法 不能使用驼峰 只能用-连接单词 并且还要小写 name: external1 namespace: default spec: type: ExternalName # 连接的外界域名 externalName: www.baidu.com -
# 查看ExternalName类型的service [root@k8smaster services]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE external1 ExternalName <none> www.baidu.com <none> 15h
-
-
当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的DNS 服务将返回一个值 my.database.example.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发
6、Multi-Port
-
可能很多服务需要开发不止一个端口,为了满足这样的情况，Kubernetes允许在定义时候指定多个端口，当我们使用多个端口的时候，我们需要指定所有端口的名称，这样endpoints才能清楚
-
资源清单示例
-
apiVersion: v1 kind: Service metadata: name: multiPort spec: type: NodePort selector: app: myapp release: stabel ports: - name: http protocol: TCP port: 80 targetPort: 9376 - name: https protocol: TCP port: 443 targetPort: 9377 -
# 查看service和endpoints [root@k8smaster services]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 16h [root@k8smaster services]# kubectl get endpoints NAME ENDPOINTS AGE multi-port 10.244.1.76:9376,10.244.2.73:9376,10.244.2.74:9376 + 3 more... 48s
-
7、Endpoints
-
当我们创建一个service之后，我们可以使用这个service对Pod进行访问，而service是通过标签的选择来确定访问那些Pod，Kubernete提供了一个简单的Endpoints API，这个Endpoints api的作用就是当一个服务中的pod发生变化时，Endpoints API随之变化，对于哪些不是原生的程序，Kubernetes提供了一个基于虚拟IP的网桥的服务，这个服务会将请求转发到对应的后台pod，也就是service和pod的对应关系，通过Endpoints可以找到，当我们创建一个service之后，k8s就会创建一个同名的Endpoints（没有选择器的情况下 值为None），ExternalName是没有Endpoints的
-
资源清单示例
-
apiVersion: v1 kind: Service metadata: name: myapp1 namespace: default spec: type: ClusterIP # 通过标签来选择pod，需全部满足 当前环境下并没有携带app=myapp1的Pod，也就是该service连接不到任何Pod 所以Endpoints为null selector: app: myapp1 release: stabel # 暴露端口 ports: - name: http # 集群内部使用的端口 port: 80 # 转发到其下Pod的容器端口 targetPort: 80 -
# 查看service [root@k8smaster services]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE multi-port NodePort 10.102.72.19 <none> 80:31277/TCP,443:31584/TCP 11s myapp1 ClusterIP 10.102.0.48 <none> 80/TCP 17m # 查看endpoints 发现myapp1的为<none> 前面的Ip为Pod的ip，端口为targetPort [root@k8smaster services]# kubectl get endpoints -o wide NAME ENDPOINTS AGE multi-port 10.244.1.76:9376,10.244.2.73:9376,10.244.2.74:9376 + 3 more... 63s myapp1 <none> 18m # 查看pod 发现和endpoints中的ip一致 [root@k8smaster services]# kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES myapp-deploy-7c4dbc97b9-7cdzf 1/1 Running 0 16h 10.244.2.74 k8snode1 <none> <none> myapp-deploy-7c4dbc97b9-k44kg 1/1 Running 0 16h 10.244.2.73 k8snode1 <none> <none> myapp-deploy-7c4dbc97b9-lglrv 1/1 Running 0 16h 10.244.1.76 k8snode2 <none> <none>
-
-
这种情况下，我们需要手动创建Endpoints，将service和Pod进行关联
-
资源清单示例
-
apiVersion: v1 kind: Endpoints metadata: # 连接到的servcie名称 如果没有该service，会创建一个新的service 不会对原来的service进行更新 name: myapp1 subsets: # 连接Pod的Ip和port 外部的也可以 - addresses: - ip: 10.244.2.74 ports: - port: 80 -
# 创建endpoints 并查看 [root@k8smaster services]# kubectl apply -f myapp1endpoints.yaml Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply endpoints/myapp1 configured # 发现名为myapp1 的endpoints的ENDPOINTS 不在为<none> 为我们设置的值 [root@k8smaster services]# kubectl get endpoints NAME ENDPOINTS AGE multi-port 10.244.1.76:9376,10.244.2.73:9376,10.244.2.74:9376 + 3 more... 63m myapp1 10.244.2.74:80 80m
-
-
8、service转发
-
我们使用上述NodePort的资源清单创建service 查看其转发规则
-
这就说明了创建NodePort的service，使用任意node:端口都能访问的原因（包含master），在每个node上都开启了该端口
-
# 创建service [root@k8smaster services]# kubectl apply -f nodeport.yaml service/myapp-nodeport created # 查看service [root@k8smaster services]# kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 53s myapp-nodeport NodePort 10.109.117.16 <none> 80:30001/TCP 10s # 查看service ipvs的转发 ipvsadm -Ln # 可以发现使用本机IP和127.0.0.1的30001端口 都会转发到任意Pod的80端口上 # 使用CLUSTER-IP:80 都会转发到任意Pod的80端口上 [root@k8smaster services]# ipvsadm -Ln IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.47.150:30001 rr -> 10.244.1.76:80 Masq 1 0 0 -> 10.244.2.73:80 Masq 1 0 0 -> 10.244.2.74:80 Masq 1 0 0 TCP 10.109.117.16:80 rr -> 10.244.1.76:80 Masq 1 0 0 -> 10.244.2.73:80 Masq 1 0 0 -> 10.244.2.74:80 Masq 1 0 0 TCP 127.0.0.1:30001 rr -> 10.244.1.76:80 Masq 1 0 0 -> 10.244.2.73:80 Masq 1 0 0 -> 10.244.2.74:80 Masq 1 0 0 UDP 10.96.0.10:53 rr -> 10.244.1.20:53 Masq 1 0 0 -> 10.244.2.14:53 Masq 1 0 0 # 还可以使用netstat -ano | grep 30001 查看