工作负载组件结构图

Pod的控制组件

• Deployment: 无状态应用部署，比如，微服务，提供多副本等功能
• StatefulSet: 有状态应用部署，比如redis，提供稳定的存储，网络等功能
• DaemonSet：守护型应用部署，比如日志收集组件，在每个机器都运行一份
• Job/CronJob：定时任务部署，比如垃圾清理组件，可以在指定时间运行

ReplicaSet/ReplicationController控制器

控制pod，使pod拥有自愈，多副本，扩缩容的能力

RelicatinController

Replication Controller 会持续监控正在运行的pod列表， 并保证相应 ” 类型” 的 pod的数目与期望相符（多了删除，少了新增）。所谓的类型就是通过标签选择器监控模板中指定标签的pod的数量。

注意：在新版本的k8s中的副本控制器为Replica Set 完全替代了Replication Controller。在kubectl 命令中 Replication Controller 可简写为rc ，Replica Set  为rs。

RC的三部分

• label selector ( 标签选择器）， 用于确定ReplicationController作用域中有哪些pod

• replica count (副本个数）， 指定应运行的pod 数量

• pod template (pod模板）， 用于创建新的pod 副本

Tips:

1、ReplicationController 的副本个数、标签选择器，甚至是 pod模板都可以随时修改，但只有副本数目的变更会影响现有的 pod。

 

2、更改标签选择器和pod模板对现有 pod 没有影响。在创建 pod后，RC也不关心其 pod的实际 “ 内容 ”（容器镜像、 环境变量及其他）。因此更改模板仅影响由此RC 创建的新pod例如在模板中添加标签不会立马给现有Pod 添加，而是新建新的Pod 的时候会添加这个新的标签。

 

3、修改Pod 的标签，pod 就会脱离了RC控制，然后RC 会新建一个pod，给pod 添加新的标签不影响RC对pod 的管理。

 

4、修改了 ReplicationController 的标签选择器，那么原有的pod 脱离RC控制，然后RC会新创建几个新的 pod。

作用

1、人为删除、增加pod后，副本控制器就会根据模板中定义的数量通过创建/删除来维持应有的数量，或者pod 异常丢失停止都会根据模板创建新的pod

 

2、集群节点发生故障时， 它将为故障节 点 上运行的所有 pod (即受ReplicationController 控制的节点上的那些 pod) 创建替代副本。

 

3、根据使用需求它能轻松实现 pod的水平伸缩,手动和自动都可以。

ReplocaSet

ReplicaSet 的行为与ReplicationController 完全相同， 但pod 选择器的表达能力更强。 虽然 ReplicationController 的标签选择器只允许包含某个标签的匹配 pod, 但ReplicaSet 的选择器还允许匹配缺少某个标签的 pod, 或包含特定标签名的 pod

RS的文件配置：

apiVersion: apps/v1
kind: ReplicaSet
metadata:  name: frontend
  labels:    app: guestbook
    tier: frontend
spec:# modify replicas according to your case  replicas: 3  selector:    matchLabels:      tier: frontend
  template:    metadata:      labels:        tier: frontend
    spec:      containers:      - name: php-redis
        image: nginx:1.7.9

RS 自愈能力

kubectl delete rs  rs-name  --cascade=false　　　　#如果不加--cascade=false 那么就会连同pod 也一起删除

RS 多副本和扩缩容能力

方式一
kubectl scale rs    --replicas=8
方式二
kubectl edit rs rs-name 　　　　　　　　 #找到 spec.replicas字段并将其值更改为8,保存该文件并关闭编辑器， ReplicationController会更新并立即将pod的数量增加到8

Deployment

控制Pod，使Pod拥有自愈，多副本，扩缩容和滚动更新能力

使用 Deployment 部署应用

kubectl run nginx --image=nignx:alpine
kubectl create deployment test –image=nginx:alpine

apiVersion: apps/v1
kind: Deployment
metadata:  name: myngx
spec:  replicas: 3  selector:    matchLabels:      app: myngx
  template:    metadata:     labels:        app: myngx
    spec:      containers:      - image: nginx:1.7.9        name: myngx
        ports:        - containerPort: 80        resources:          requests:            cpu: 8m

多副本能力

kubectl scale deployment  deployment-name  --replicas=4

滚动更新

第一种方式：

kubectl set image deployment/NAME container-name=imagename:version
kubectl set image deployment/myngx myngx=nginx:latest

第二种方式

Kubectl edit deployment name

第三种方式

Kubectl apply –f yaml file

check 升级记录

• kubectl rollout history deployment/name

• kubectl rollout history deployment/name --revision=3

• Kubectl get rs -owide

• k get deployments.apps myngx -o yaml # check metadata.generation: 2

• This number is same with RS # rollback is not counted.

版本回退能力

回滚到上一个版本：

kubectl rollout undo deployment/NAME

回滚到先前的任何版本

kubectl rollout undo deployment/nginx-deployment --to-revision=2

DaemonSet

DaemonSet 能够让所有（或者一些特定）的 Node 节点运行同一个 pod。

当节点加入到 kubernetes 集群中，pod 会被（DaemonSet）调度到该节点上运行。

当节点从 kubernetes 集 群中被移除，被（DaemonSet）调度的 pod 会被移除，如果删除 DaemonSet，所有跟这个 DaemonSet 相关的 pods 都会被删除

DaemonSet使用场景

在使用 kubernetes 来运行应用时，很多时候我们需要在一个区域（zone）或者所有 Node 上 运行同一个守护进程（pod）。

例如如下场景：

每个 Node 上运行一个分布式存储的守护进程，例如 glusterd，ceph 每个 Node 上运行日志采集器，例如 fluentd，logstash

apiVersion: apps/v1
kind: DaemonSet
metadata:  name: ds1
  namespace: kube-system
  labels:    k8s-app: fluentd-logging
spec:  selector:    matchLabels:      name: fluentd-elasticsearch
  template:    metadata:      labels:        name: fluentd-elasticsearch
    spec:      tolerations:      - key: node-role.kubernetes.io/master
        effect: NoSchedule
      containers:      - name: fluentd-elasticsearch
        image: nginx:1.7.9        resources:          limits:            memory: 200Mi
          requests:            cpu: 100m
            memory: 200Mi

StatefulSet

StatefulSet 是为了解决有状态服务的问题 有下面的任意要求时，StatefulSet 的价值就体现出来了。

● 稳定的、唯一的网络标识。

● 稳定的、持久化的存储。

● 有序的、优雅的部署和扩展。  

● 有序的、优雅的删除和停止。

StatefulSet组成

用于定义网络标志（DNS domain）的 Headless Service

用于创建 PersistentVolumes 的 volumeClaimTemplates

定义具体应用的 StatefulSet

创建StatefulSet

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: web
spec:  serviceName: "nginx"  replicas: 3  selector:    matchLabels:      app: nginx
  template:    metadata:      labels:        app: nginx
    spec:      containers:      - name: nginx
        image: nginx:1.9        ports:        - containerPort: 80          name: web

TIPS:

Headless Service 和 StatefulSet 必须在相同的 namespace

Job 和 CronJob

在有些场景下，是想要运行一些容器执行某种特定的任务，任务一旦执行完成，容器也就没 有存在的必要了。在这种场景下，创建 pod 就显得不那么合适。于是就是了 Job，Job 指的 就是那些一次性任务。通过 Job 运行一个容器，当其任务执行完以后，就自动退出，集群也 不再重新将其唤醒。

从程序的运行形态上来区分，可以将 Pod 分为两类：长时运行服务（jboss、mysql 等）和一 次性任务（数据计算、测试）。

RC 创建的 Pod 都是长时运行的服务，Job 多用于执行一次性 任务、批处理工作等，执行完成后便会停止（status.phase 变为 Succeeded）。 job 执行完后，不会自动启动一个新的 pod。执行完成后 pod 便会停止，也不会被自动删除

创建Job

apiVersion: batch/v1
kind: Job
metadata:  name: job-demo
spec:  template:    metadata:      name: job-demo
    spec:      restartPolicy: Never
      containers:      - name: counter
        image: busybox
        command:        - "bin/sh"        - "-c"        - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"        imagePullPolicy: IfNotPresent

创建CronJob

apiVersion: batch/v1beta1
kind: CronJob
metadata:  name: cronjob-demo
spec:  schedule: "*/1 * * * *"  jobTemplate:    spec:      template:        spec:          restartPolicy: OnFailure
          containers:          - name: hello
            image: busybox
            args:            - "bin/sh"            - "-c"            - "for i in 9 8 7 6 5 4 3 2 1; do echo $i; done"