Kubernetes-温故知新

Container / 2024-03-06

1.Master节点
2.Node节点
3.Controller
4.Service
5.Namespace
6.架构图
7.Rolling update
8.Health check

一 Master 节点

master是kubernetes cluster（简称为KC）的大脑，运行着daemon服务，包括kube-apiserver、kubescheduler、kube-controller-manager、etcd和Pod网络

  • API Server（kube-apiserver）
  • 提供RESTful API，即kubernetes API
  • 是KC的前端接口，其他组件可以通过它管理cluster的各种资源
  • Scheduler（kube-scheduler）
  • 决定将Pod 放在哪个node上面，调度时会考虑Cluster的top结构，包含负载，高可用，性能，数据亲和性
  • Controller Manager（kube-controller-manager）
  • CM负责管理Cluster的各种资源，保证资源处于预期的状态
  • CM有多种controller组成，包括replication controller（管理Deployment、StatefulSet、DaemonSet），endpoints controller、namespace controller（管理NameSpace资源）
  • etcd
  • 负责保存KC的配置信息和各种资源的状态信息，当数据发生变化时etcd会快速的通知kubernetes相关组件
  • pod网络
  • pod要能够相互通信，KC必须部署Pod网络，flannel是一个可选方案。

二 Node 节点

  • Node 是Pod运行的地方k8s 支持Docker，rkt等容器Runtime。Node上运行的k8s组件有kubelet，kube-proxy和pod网络
  • kubelet
  • 是node的agent，当Scheduler确定在某个node上运行pod后，会将pod的具体信息发送给该节点的kubelet，然后kubelet根据这些信息创建运行容器，并向Master报告运行状态
  • kube-proxy
  • service在逻辑上代表了后端的多个pod，外界通过Service访问Pod，service接收到的请求是如何转发到pod的呢？这就是kube-proxy要完成的工作
  • 每个node 都会运行kube-proxy服务，它负责将访问service的TCP/UPD数据流转发到后端的容器，如果有多个副本，kube-proxy会实现负载均衡
  • Pod 网络
  • pod要能相互通信，KC必须部署Pod网络，flannel 是一个可选方案

三 Controller

k8s通过Controller来管理Pod。

  • Deployment 最常用的Controller，可以管理Pod的多个副本，并确保Pod按照期望的状态运行
  • ReplicaSet 实现了Pod的多副本管理，使用Deployment时会自动创建ReplicaSet，也就是说Deployment是通过ReplicasSet来管理Pod的多个副本的，我们通常不需要直接使用ReplicaSet
  • DaemonSet用于每个Node最多只运行一个Pod副本的场景，常用于运行daemon
  • StatefulSet能够保证Pod的每个副本在整个生命周期中名称是不变，当某个Pod发生故障需要删除并重新启动时，Pod的名称会发生变化，同时StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除
  • Job用于运行结束就删除的应用，而其他Controller种Pod通常是长期持续运行

    四 Service

    Deployment可以部署多个副本，每个Pod都有自己的IP，外界如何访问这些副本呢？
    deployment可以部署多个副本，每个pod 都有自己的IP，外界如何访问这些副本那？
    答案是service
    k8s的 service定义了外界访问一组特定pod的方式。service有自己的IP和端口，service为pod提供了负载均衡。
    k8s运行容器pod与访问容器这两项任务分别由controller和service执行。
    外网如何访问Service
    1.ClusterIP
    a.Service通过Cluster内部的IP对外提供服务，只有Cluster内的节点和Pod可访问，这是默认的Service类型
    2.NodePort
    a.Service 通过Cluster节点的静态端口对外提供服务，Cluster外部可以通过: 访问Service
    3.LoadBalancer
    a.Service利用cloud provider特有的load balancer对外提供服务，cloud provider 负责将load balancer的流量导向Service

五 Namespace

如果有多个用户或者项目组使用同一个k8s cluster，如何将他们创建的Controller、Pod资源分开呢？这就要用到Namespace了。它可以将一个物理的cluster逻辑上划分成多个虚拟cluster，每个cluster就是一个namespace。不同的namespace里的资源是完全隔离的。

六 结构图

k8s架构图

七 Rolling Update

1 更新

假设初始镜像为httpd:2.2.31 更新到http:2.2.32 httpd.yml文件
kubectl apply -f httpd.yml

apiVersion: apps/v1
kind: Deployment
metadata:
    name: httpd
spec:
  replicas: 3
  template:
      metadata:
          labels:
              run: httpd
      spec:
          containers:
          - name: httpd
           image: httpd:2.2.31
           ports:
           - containerPort: 80

2 回滚

kubectl apply 每次更新应用时，kubernetes 都会记录下当前的配置，保存为一个revision，这样就能回滚到特定的revision。
配置文件中的revisionHIstoryLimit 属性用来控制revision的数量。

httpd.v1.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
    name: httpd
spec:
  revisionHistoryLimit: 10
  replicas: 3
  template:
      metadata:
          labels:
              run: httpd
      spec:
          containers:
          - name: httpd
           image: httpd:2.4.17 这里有3个版本 18 19
           ports:
           - containerPort: 80

kubectl apply -f httpd.v1.yml --record
增加参数record的作用是将当前的命令记录到revision中，就知道每个revision对应的是哪个配置文件了。
kubectl rollout history depolyment httpd 会列出历史版本

回到指定的版本

kubectl rollout undo deployment --to-revision=1

八 健康检查

k8s有默认的健康检查机制：每个容器启动时候都会执行一个进程，此进程由Dockerfile的CMD或者ENTRYPOINT指定，进程退出时返回码不是零，认为容器故障，根据restartPolicy 重启容器
只需要在spec属性下添加
restartPolicy: OnFailure 默认为Always
如果有故障，进程不退出怎么整？答案就是Liveness 探测
liveness 探测可以让用户自定义判断容器是否健康的条件，如果探测失败k8s就会重启容器

livenessProbe：
  exec：
    command：
    - cat
    - /tmp/healthy
  initialDealySeconds: 10 容器启动后10s之后开始执行liveness探测
  periodSeconds: 5 每5s执行一次liveness探测，连续失败3次就重启容器。```
Readiness探测告诉k8s什么时候可以将容器加入到Service负载均衡池中，对外提供服务。

readinessProbe：
  exec：
    command:
    - cat
    - /tmp/healthy
  initialDealySeconds: 10 容器启动后15(initialDealySeconds+periodSeconds)之后开始执行Readiness探测
  periodSeconds: 5 每5s执行一次Readiness探测，连续失败3次 把ready状态设置为不可用

区别：

  1. liveness探测和Readiness 探测是两种HealthCheck机制，如果不特意配置，k8s 将对两种探测才去相同的默认希望，通过判断容器启动的进程的返回值是否为0，来判断探测是否成功
  2. 配置方法一样，参数也一样，区别在于探测失败时候，liveness探测是重启容器，Readiness探测则是将容器设置为不可用，不接收Service转发的请求。
    3.liveness探测和Readiness探测是独立执行的，二者之间没有依赖，所以可以单独使用，也可以同时使用；liveness判断容器是否重启以实现自愈，用readiness探测判断容器是否已经准备好对外提供服务。
    使用场景：
    对于多副本应用，当执行Scale up操作时候，新副本会作为backend 被添加到Service的负载均衡，启动需要一个准备阶段，可以用Readiness探测判断容器是否就绪，避免将请求发送到没有ready的backend。

相关文章

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注