一、Pod控制器及其功用:

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

二、pod控制器有多种类型:

1、ReplicaSet:

实现用户创建指定数量的pod副本,确保pod副本数量符合预期状态,并且支持滚动式自动扩容和缩容功能

 ReplicaSet主要三个组件组成:

(1)用户期望的pod副本数量

(2)标签选择器,判断哪个pod归自己管理

(3)当现存的pod数量不足,会根据pod资源模板进行新建 帮助用户管理无状态的pod资源,精确反应用户定义的目标数量,但是RelicaSet不是直接使用的控制器,而是使用Deployment。

2、Deployment:

工作在ReplicaSet之上,用于管理无状态应用,目前来说最好的控制器。支持滚动更新和回滚功能,还提供声明式配置。 ReplicaSet 与Deployment 这两个资源对象逐步替换之前RC的作用。

3、DaemonSet:

用于确保集群中的每一个节点只运行特定的pod副本,通常用于实现系统级后台任务。比如ELK服务。

特性:服务是无状态的 服务必须是守护进程

4、StatefulSet:

管理有状态应用

5、Job:

部署一次性任务pod

只要完成就立即退出,不需要重启或重建

6、Cronjob:

周期性任务控制,不需要持续后台运行

三、Pod与控制器之间的关系:

controllers:在集群上管理和运行容器的 pod 对象, pod 通过 label-selector 相关联。

Pod 通过控制器实现应用的运维,如伸缩,升级等。

四、Deployment(无状态应用):

Deployment主要功能有下面几个:

  • 支持ReplicaSet的所有功能
  • 支持发布的停止、继续
  • 支持滚动升级和回滚版本

特点:

  • 部署无状态应用,只关心数量,不论角色等,称无状态
  • 管理Pod和ReplicaSet
  • 具有上线部署、副本设定、滚动升级、回滚等功能
  • 提供声明式更新,例如只更新一个新的image

1、Deployment的资源清单文件: 

apiVersion: apps/v1 # 版本号
kind: Deployment # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: deploy
spec: # 详情描述
  replicas: 3 # 副本数量
  revisionHistoryLimit: 3 # 保留历史版本
  paused: false # 暂停部署,默认是false
  progressDeadlineSeconds: 600 # 部署超时时间(s),默认是600
  strategy: # 策略
    type: RollingUpdate # 滚动更新策略
    rollingUpdate: # 滚动更新
      maxSurge: 30% # 最大额外可以存在的副本数,可以为百分比,也可以为整数
      maxUnavailable: 30% # 最大不可用状态的 Pod 的最大值,可以为百分比,也可以为整数
  selector: # 选择器,通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

2.创建deployment:

创建nginx-deployment.yaml,内容如下:

# vim nginx-deployment.yaml
 
apiVersion: apps/v1
kind: Deployment
metadata: 
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata: 
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80
        
Replicaset是副本数,回滚就是通过此来实现
 
创建资源
# kubectl create -f nginx-deployment.yaml
查看创建的pod资源、控制器和副本
# kubectl get pods,deploy,rs
查看历史版本
# kubectl rollout history deployment/nginx-deployment

五、ReplicaSet(RS) :

 ReplicaSet的主要作用是保证一定数量的pod正常运行,它会持续监听这些Pod的运行状态,一旦Pod发生故障,就会重启或重建。同时它还支持对pod数量的扩缩容和镜像版本的升降级。

1.ReplicaSet的资源清单文件 :

apiVersion: apps/v1 # 版本号
kind: ReplicaSet # 类型       
metadata: # 元数据
  name: # rs名称 
  namespace: # 所属命名空间 
  labels: #标签
    controller: rs
spec: # 详情描述
  replicas: 3 # 副本数量
  selector: # 选择器,通过它指定该控制器管理哪些pod
    matchLabels:      # Labels匹配规则
      app: nginx-pod
    matchExpressions: # Expressions匹配规则
      - {key: app, operator: In, values: [nginx-pod]}
  template: # 模板,当副本数量不足时,会根据下面的模板创建pod副本
    metadata:
      labels:
        app: nginx-pod
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.1
        ports:
        - containerPort: 80

在这里面,需要新了解的配置项就是spec下面几个选项: 

replicas:指定副本数量,其实就是当前rs创建出来的pod的数量,默认为1
selector:选择器,它的作用是建立pod控制器和pod之间的关联关系,采用的Label Selector机制。在pod模板上定义label,在控制器上定义选择器,就可以表明当前控制器能管理哪些pod了。
template:模板,就是当前控制器创建pod所使用的模板,里面其实就是前一章学过的pod的定义

特点:

  • 解决Pod独立生命周期,保持Pod启动顺序和唯一性
  • 稳定,唯一的网络标识符,持久存储(例如: etcd 配置文件,节点地址发生变化,将无法使用)
  • 有序,优雅的部署和扩展、删除和终止(例如: mysql 主从关系,先启动主,再启动从)
  • 有序,滚动更新

应用场景: 数据库

2.有状态和无状态的区别:

无状态:​​​​​​​

  1. deployment认为所有的pod都是一样的
  2. 不用考虑顺序的要求
  3. 不用考虑在哪个node节点上运行
  4. 可以随意扩容和缩容

有状态:

  1. 实例之间有差别,每个实例都有自己的独特性,元数据不同,例如etcd, zookeeper
  2. 实例之间不对等的关系,以及依靠外部存储的应用。

3.常规service和无头服务区别:

service:一组Pod访问策略,提供cluster-IP群集之间通讯,还提供负载均衡和服务发现。
Headless service无头服务, 不需要cluster-IP,直接绑定具体的Pod的IP(当Pod的IP地址是动态变化时,所以常用于绑定DNS访问)

①Cluster_ip

②NodePort:使用pod所在节点的IP和端口范围

③headless:直接使用pod 的ip暴露出去

④LoadBalancer:负载均衡(F5)

⑤hostport:直接使用宿主机的IP和端口范围

ps:k8s暴露服务的方式主要就3种:

ingress loadbalancer(SLB/ALB k8s集群外的负载均衡器Ng、haproxy、KONG、traefil等等)service

4.案例:

先创建DNS资源

# vim pod.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: dns-test
spec:
  containers:
  - name: busybox
    image: busybox:1.28.4
    args:
    - /bin/sh
    - -c
    - sleep 36000
  restartPolicy: Never
 
创建dns资源
# kubectl create -f pod.yaml
 
# kubectl get pods

 再用statefulset控制器类型 创建nginx pod资源,并创建无头服务资源

# vim sts.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet  
metadata:
  name: nginx-statefulset  
  namespace: default
spec:
  serviceName: nginx  
  replicas: 3  
  selector:
    matchLabels:  
       app: nginx
  template:  
    metadata:
      labels:
        app: nginx  
    spec:
      containers:
      - name: nginx
        image: nginx:latest  
        ports:
        - containerPort: 80  
 
# kubectl create -f sts.yaml 
有状态化创建的pod,是自动进行打标签进行区分
# kubectl get pods
 
# kubectl get pods,svc
 
验证DNS解析
# kubectl exec -it dns-test.sh
解析pod的唯一域名和自身的IP

六、总结:

1.deployment:

部署无状态应用的管理RS 和 pod 创建pod,主要是维护pod副本数量与期望状态相同

创建和删除pod时,并行执行,升级时是想创建一部分,在删除一部分

2.statfykset:

部署有状态的应用,每个pod的唯一(名称)且不变的,每个pod拥有自己专属的持久化的存储(pvc和pv)

在k8s集群内部可以通过{pod_name}.{service_name}.{namesoace}.svc.cluster.local解析出pod的ip(基于headless service和coreDNS)

创建和删除pod是有顺序的(串行执行的)升级时也是串行执行的,会删除旧的pod,在创建新pod,删除和升级时逆序执行的(从标识符最大的n-1开始,一直到最小的0)

3.Damonset:

理论上再k8s集群所有node节点上创建相同的pod(无论node节点什么时候加入到k8s集群),但是会都到node节点上污点影响

4.部署一次性任务pod:

正常完成后容器立即退出并且不重启容器(restart policy不设置Alway),也不会重建异常完成后重试任务,重建的次数根据back off limit配置指定(默认为6次)

5.cronjob:

周期性的部署任务的pod,正常完成后容器会立即退出并不会重启容器(restartPolicy不设置Always),也不会重建pod

schedule配置周期性的事件表 * * * * *(分时日月周)

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐