Pod控制器

Pod控制器

control plane (Master)
API server: gateway,restful风格的api，是我们把所有资源抽象为对象
Resources-objects
API server为所有能存取得资源，规定了一个范式

etcd
 controller: kube-controller-manager
 live Objects
 Recondilation
确保对象中status的状态要和spec的状态一致。status是实际状态，spec是用户期望的状态
Pods -> object
Replicaset -> object(ngx-rs,myapp-rs,....)
Control Loop:周期性运行，其后面一定有个守护进程

其中控制器有多种类型，就需要运行很多不同类型守护进程，管理不方便
kube-controller-manager:就是很把多种不同类型控制器代码，打包成一份，统一运行一个守护进程
kube-controller-manager 手动运行为守护进程，可以使用选项--controllers 选项用于指定要启动的控制器，如果不指定默认启用，就为所有控制器
foo: 启用名字为foo的控制器
-foo: 禁用foo类型的控制器
默认启用的控制器类型中不包含bootstrapsigner和tokencleaner
使用kubeadm部署的k8s,中pod的资源清单所在位置/etc/kubernetes/manifests/,改完资源清单，k8s自动更新pod
Pod controllers 早期版本为 ReplicationController
现在划分为多种类型：因为现在运行在k8s上的进程的运行方式各不相同
守护进程：
无状态：
非系统级 Deployment/Replicaset（deployment的前身）
系统级：Daemoset
有状态（包括服务注册中心）： statefulSet
非守护进程：
Job
CronJob

ReplicaSet

主要控制无状态，守护进程的类型，在给定时间运行一定数量的Pod
ReplicaSet 需要的东西
Pod Template 创建Pod使用
Pod Selector 用来识别当前创建了几个Pod
Replicas 用户期待定义了几个Pod
kubectl explain rs
kubectl get rs (rs是replication 的简写)
kubectl explain rs.spec.selector
kubectl explain rs.spec.template //Pod不应该定义名字，由控制器赋值
kubectl describe rs myapp-rs
删除Pod
1、删除控制器
修改replicas数量
1、资源申请单中修改，重新apply
kubectl scale -h 修改
kubectl scale --replicas=2 deploy ngx-dep
如果需要变更版本
1、通过修改资源申请单中的镜像版本
2、通过kubectl scale 修改
注意：原先存在的Pod不会变更，只有新建Pod才会变更。即我们可以删除原先Pod，其中我们需要手动更新Pod
Deployment 会帮助我们自动完成更新策略
deployment --> Replica sets --> pods
由Deployment控制Replicasets
Deployment 会管理整个rs的历史（即所有版本，用户回滚）
deployment自定义一次加减几个
kubectl explain deployment.spec.strategy.rollingUpdate pod的更新策略

image.png

maxSurge： 即Pod在升级的时候，同时运行的Pod最多是多少
maxUnavailable: 即Pod在升级的时候，同时运行的Pod最少是多少
kubectl set image -h
kubectl set image deploy ngx-dep nginx=nginx:apline //更新ngx-dep控制器的nginx的镜像
其中maxSurge默认是pod数量的25%，maxUnavailable默认为pod数量的25%
kubectl rollout -h
kubectl roullout history deploy ngx-dep //查看回滚记录
kubectl rollout undo deploy/ngx-dep //进行回滚
金丝雀发布
kubectl set image deploy ngx-dep nginx=nginx:1.15:alpine && kubectl rollout pause deploy/ngx-dep
如果没有问题，继续滚动
kubectl rollout resum deploy/ngx-dep

DaemonSets

只需定义Pod模板和标签选择器，每个Node节点运行一个Pod
节点选择器：告诉我们控制器，只调度哪些节点上运行Pod
master 上不能创建Pod，因为master上有污点
kubectl explain ds.spec.updateStrategy //更新版本

[root@k8s-master basic]# cat ds-filebeat.yaml 
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: filebeat-ds
 labels:
   app: filebeat
spec:
 selector:
   matchLabels:
     app: filebeat
 template:
  metadata:
    labels:
      app: filebeat
  spec:
    containers:
      - name: myapp
        image: ikubernetes/myapp:v1
        env:
        - name: REDIS_HOME
          value: db.ikubernetes.io:6379
        - name: LOG_LEVEL
          value: info

kubectl set image ds/filebeat-ds myapp=ikubernets/myapp:v2 //版本更新
kubectl get nodes --show-labels 显示标签

pod运行在指定node上

kubectl explain pods.spec.nodeSelector

cat pod-node.yaml 
apiVersion: v1
kind: Pod
metadata:
 name: pod-daemon
 namespace: default
spec:
 nodeSelector:
   logcollecting: test
 containers:
   - name: myapp
     image: ikubernetes/myapp:v1
     imagePullPolicy: IfNotPresent

kubectl label node k8s-node-01 logcollecting="test"

Job Controller

由于一次性作业，周期性运行（用于创建一个Pod，这个Pod能够完成任务，即可）

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: cronjob-example
  labels:
    app: mycronjob
spec:
  schedule: "*/2 * * * *"
  jobTemplate:
    metadata:
      labels:
        app: mycronjob-jobs
    spec:
      parallelism: 2
      template:
        spec:
          containers:
          - name: myjob
            image: alpine
            command:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster; sleep 10
          restartPolicy: OnFailure

此控制器的Pod重启策略
restartPolicy: OnFailure  如果Pod非正常退出，就进行重启
Nerver：如果Pod非正常退出，就重建
kubectl get job 

Garbage Collection

GC 垃圾回收
Pod终止时，需要回收,每个对象的metadata中都有OwnerRerences指定字段进行回收，一般自动设置也可以手动设置。
删除方式： 级联删除（删除一个资源下所有关联资源）有前台删除和后台删除（默认）

节点状态

kubectl explain node.status
address： HostName,ExternalIP,InternalIP
Condition: 节点处于什么状态，比如磁盘满了，内存耗尽了
capacity: 对应节点的容量，一共有多少cpu，多少内存，容纳了多少个Pod