k8s學習筆記之六:Pod控制器(kube-controller-manager)

第一章、什麼是kube-controller-manager？

Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 組成， 是Kubernetes 的大腦， 它經過 apiserver 監控整個集羣的狀態， 並確保集羣處於預期的工做狀態。

kube-controller-manager 由一系列的控制器組成

 1 Replication Controller
 2 Node Controller
 3 CronJob Controller
 4 Daemon Controller
 5 Deployment Controller
 6 Endpoint Controller
 7 Garbage Collector
 8 Namespace Controller
 9 Job Controller
10 Pod AutoScaler
11 RelicaSet
12 Service Controller
13 ServiceAccount Controller
14 StatefulSet Controller
15 Volume Controller
16 Resource quota Controller

cloud-controller-manager 在 Kubernetes 啓用 Cloud Provider 的時候才須要， 用來配合雲服務提供商的控制， 也包括一系列的控制器， 如 

1 Node Controller
2 Route Controller
3 Service Controller

第二章、常見Pod控制器及含義

Replication Controller

Replication Controller 保證了在全部時間內，都有特定數量的Pod副本正在運行，若是太多了，Replication Controller就殺死幾個，若是太少了，Replication Controller會新建幾個，和直接建立的pod不一樣的是，Replication Controller會替換掉那些刪除的或者被終止的pod，無論刪除的緣由是什麼（維護阿，更新啊，Replication Controller都不關心）。基於這個理由，咱們建議即便是隻建立一個pod，咱們也要使用Replication Controller。Replication Controller 就像一個進程管理器，監管着不一樣node上的多個pod,而不是單單監控一個node上的pod,Replication Controller 會委派本地容器來啓動一些節點上服務（Kubelet ,Docker）。
Replication Controller只會對那些RestartPolicy = Always的Pod的生效，（RestartPolicy的默認值就是Always）,Replication Controller 不會去管理那些有不一樣啓動策略pod
Replication Controller永遠不會本身關閉，可是，咱們並不但願Replication Controller成爲一個長久存在的服務。服務可能會有多個Pod組成，這些Pod又被多個Replication Controller控制着，咱們但願Replication Controller 會在服務的生命週期中被刪除和新建（例如在這些pod中發佈一個更新），對於服務和用戶來講，Replication Controller是經過一種無形的方式來維持着服務的狀態

ReplicaSets

ReplicaSet是下一代複本控制器。ReplicaSet和 Replication Controller之間的惟一區別是如今的選擇器支持。Replication Controller只支持基於等式的selector（env=dev或environment!=qa），但ReplicaSet還支持新的，基於集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。
大多數kubectl支持Replication Controller的命令也支持ReplicaSets。rolling-update命令有一個例外 。若是想要滾動更新功能，請考慮使用Deployments。此外， rolling-update命令是必須的，而Deployments是聲明式的，所以咱們建議經過rollout命令使用Deployments。
雖然ReplicaSets能夠獨立使用，可是今天它主要被 Deployments 做爲協調pod建立，刪除和更新的機制。當使用Deployments時，沒必要擔憂管理他們建立的ReplicaSets。Deployments擁有並管理其ReplicaSets。

Deployment

Deployment爲Pod和Replica Set（下一代Replication Controller）提供聲明式更新。
你只須要在Deployment中描述你想要的目標狀態是什麼，Deployment controller就會幫你將Pod和Replica Set的實際狀態改變到你的目標狀態。你能夠定義一個全新的Deployment，也能夠建立一個新的替換舊的Deployment。

一個典型的用例以下：

1.使用Deployment來建立ReplicaSet。ReplicaSet在後臺建立pod。檢查啓動狀態，看它是成功仍是失敗。
2.而後，經過更新Deployment的PodTemplateSpec字段來聲明Pod的新狀態。這會建立一個新的ReplicaSet，Deployment會按照控制的速率將pod從舊的ReplicaSet移動到新的ReplicaSet中。
3.若是當前狀態不穩定，回滾到以前的Deployment revision。每次回滾都會更新Deployment的revision。
4.擴容Deployment以知足更高的負載。
5.暫停Deployment來應用PodTemplateSpec的多個修復，而後恢復上線。
6.根據Deployment 的狀態判斷上線是否hang住了。
7.清除舊的沒必要要的ReplicaSet。

StatefulSet

StatefulSet是爲了解決有狀態服務的問題（對應Deployments和ReplicaSets是爲無狀態服務而設計），其應用場景包括
1.穩定的持久化存儲，即Pod從新調度後仍是能訪問到相同的持久化數據，基於PVC來實現
2.穩定的網絡標誌，即Pod從新調度後其PodName和HostName不變，基於Headless Service（即沒有Cluster IP的Service）來實現
3.有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次依次進行（即從0到N-1，在下一個Pod運行以前全部以前的Pod必須都是Running和Ready狀態），基於init containers來實現
4.有序收縮，有序刪除（即從N-1到0）

從上面的應用場景能夠發現，StatefulSet由如下幾個部分組成：
1.用於定義網絡標誌（DNS domain）的Headless Service
2.用於建立PersistentVolumes的volumeClaimTemplates
3.定義具體應用的StatefulSet

StatefulSet中每一個Pod的DNS格式爲statefulSetName-{0..N-1}.serviceName.namespace.svc.cluster.local，其中
1.serviceName爲Headless Service的名字
2.0..N-1爲Pod所在的序號，從0開始到N-1
3.statefulSetName爲StatefulSet的名字
4.namespace爲服務所在的namespace，Headless Servic和StatefulSet必須在相同的namespace
5..cluster.local爲Cluster Domain，

DaemonSet

DaemonSet保證在每一個Node上都運行一個容器副本，經常使用來部署一些集羣的日誌、監控或者其餘系統管理應用。典型的應用包括：

日誌收集，好比fluentd，logstash等
系統監控，好比Prometheus Node Exporter，collectd，New Relic agent，Ganglia gmond等
系統程序，好比kube-proxy, kube-dns, glusterd, ceph等

 第三章、簡單示例

Deployment

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: myapp-deploy
spec:
  replicas: 5
  selector: 
    matchLabels:
      app: myapp
      release: canary
  template:
    metadata:
      labels:
        app: myapp
        release: canary
    spec:
      containers:
      - name: myapp
        image: ikubernetes/myapp:v2
        ports:
        - name: httpd
          containerPort: 80

Deployment+ DaemonSet

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
      role: logstor
  template:
    metadata:
      labels:
        app: redis
        role: logstor
    spec:
      containers:
      - name: redis
        image: redis:4.0-alpine
        ports:
        - name: redis
          containerPort: 6379
  
---
apiVersion: apps/v1
kind: DaemonSet
metadata: 
  name: filebeat-ds
spec:
  selector: 
    matchLabels:
      app: filebeat
      release: stable
  template:
    metadata:
      labels:
        app: filebeat
        release: stable
    spec:
      containers:
      - name: filebeat
        image: ikubernetes/filebeat:5.6.5-alpine
        env:
        - name: REDIS_HOST
          value: redis.default.svc.cluster.local
        - name: REDIS_LOG_LEVEL
          value: info

StatefulSet

---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: gcr.io/google_containers/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi