命令匯總查看

第一章

• 零散知識(shí)點(diǎn)

1、pod之間通信時(shí)，可為每個(gè)pod創(chuàng)建service，別的pod通過環(huán)境變量<Service_Name>_SERVICE_HOST的值連接其他服務(wù)。--在對應(yīng)的rc.ymal文件種指定環(huán)境變量eg:tomcat連接數(shù)據(jù)庫
kind: ReplicationController
apiVsersion: v1
metadata:
  name: myweb
spec:
  replicas: 1
  selector:
    app: myweb
  template:
    metadata:
      labels:
        app: myweb
    spec:
      containers:
        - name: myweb
          image: kubeguide/tomcat-app:v1
          ports:
          - containerPort: 8080
          env:
          - name: MYSQL_SERVICE_HOST
            value: '10.254.31.69'
          - name: MYSQL_SERVICE_PORT
            value: '3306'
2、CPU 的資源單位為CPU (Core ）的數(shù)量，是一個(gè)絕對值而非相對值，Memory 配額也是一個(gè)絕對值，它的單位是內(nèi)存字節(jié)數(shù)。
一個(gè)CPU 的配額對于絕大多數(shù)容器來說是相當(dāng)大的一個(gè)資源配額了，所以，在Kubernetes里，通常以千分之一的CPU 配額為最小單位，用m 來表示
3、一個(gè)計(jì)算資源進(jìn)行配額限定需要設(shè)定以下兩個(gè)參數(shù)。
    Requests ：該資源的最小申請量，系統(tǒng)必須滿足要求。
    Limits ：該資源最大允許使用的量，不能被突破，當(dāng)容器試圖使用超過這個(gè)量的資源時(shí)，可能會(huì)被Kubernetes Kill 并重啟。

• kuebrnetes 基本概念和術(shù)語
  1、master (4個(gè)關(guān)鍵進(jìn)程)

Kubernetes API Server ( kube叩iserver ） ： 提供了HTTP Rest 接口的關(guān)鍵服務(wù)進(jìn)程，是Kubernetes 里所有資源的增、刪、改、查等操作的唯一入口，也是集群控制的入口進(jìn)程。
Kubernetes Controller Manager ( kube-controller-manager ) : Kubernetes 里所有資源對象的自動(dòng)化控制中心，可以理解為資源對象的“大總管”
Kubernetes Scheduler C !rube-scheduler ）： 負(fù)責(zé)資源調(diào)度（ Pod 調(diào)度〉的進(jìn)程，相當(dāng)于公交公司的“調(diào)度室"
etcd 服務(wù)，因?yàn)镵ubernetes 里的所有資源對象的數(shù)據(jù)全部是保存在etcd 中的。

2、node（3個(gè)關(guān)鍵進(jìn)程）

kubelet：負(fù)責(zé)Pod 對應(yīng)的容器的創(chuàng)建、啟停等任務(wù)，同時(shí)與Master 節(jié)點(diǎn)密切協(xié)作， 實(shí)現(xiàn)集群管理的基本功能。
kube-proxy ： 實(shí)現(xiàn)Kubernetes Service 的通信與負(fù)載均衡機(jī)制的重要組件。
Docker Engine ( docker) : Docker 引擎，負(fù)責(zé)本機(jī)的容器創(chuàng)建和管理工作。

3、pod

每個(gè)Pod 都有一個(gè)特殊的被稱為“根容器”的Pause 容器，Pause 容器對應(yīng)的鏡像屬于Kubemetes平臺(tái)的一部分，除了Pause 容器，每個(gè)Pod 還包含一個(gè)或多個(gè)緊密相關(guān)的用戶業(yè)務(wù)容器。
Kubemetes 為每個(gè)Pod 都分配了唯一的E 地址，稱之為Pod IP ， 一個(gè)Pod 里的多個(gè)容器共享Pod E 地址。Kubernetes 要求底層網(wǎng)絡(luò)支持集群內(nèi)任意兩個(gè)Pod 之間的TCP/IP 直接通信，這通常采用虛擬二層網(wǎng)絡(luò)技術(shù)來實(shí)現(xiàn)，例如Flannel 、Open vSwitch 等。記住一個(gè)Pod 里的容器與另外主機(jī)上的Pod 容器能夠直接通信。

4、Label

1）一個(gè)Label 是一個(gè)key=value 的鍵值對，其中key 與value 由用戶自己指定。Label 可以附加到各種資源對象上,一個(gè)資源對象可以定義任意數(shù)量的Label 。
2）同一個(gè)Label 也可以被添加到任意數(shù)量的資源對象上去， Label 通常在資源對象定義時(shí)確定，也可以在對象創(chuàng)建后動(dòng)態(tài)添加或者刪除。
我們可以通過給指定的資源對象捆綁一個(gè)或多個(gè)不同的Label 來實(shí)現(xiàn)多維度的資源分組管理功能
新出現(xiàn)的管理對象如Deplo嚴(yán)nent 、ReplicaSet 、Daemon Set 和Job 則可以在Se lector 中使用
基于集合的篩選條件定義，例如：P20
selector:
matchLabels :
app: myweb
matchExpressions:
- {key: tier ，operator : In , values: [frontend)}
- {key: environment , operator : Notin , values: [dev)}
可用的條件運(yùn)算符包括： In 、No tin 、Exis ts 和DoesNotExist
3）Label Selector 在Kubemetes 中的重要使用場景有以下幾處。
   kube-controller 進(jìn)程通過資源對象RC 上定義的Label Selector 來篩選要監(jiān)控的Pod 副本的數(shù)量，從而實(shí)現(xiàn)Pod 副本的數(shù)量始終符合預(yù)期設(shè)定的全自動(dòng)控制流程。
   kube-proxy 進(jìn)程通過Service 的Label Selector 來選擇對應(yīng)的Pod ，自動(dòng)建立起每個(gè)
   Service 到對應(yīng)Pod 的請求轉(zhuǎn)發(fā)路由表，從而實(shí)現(xiàn)Service 的智能負(fù)載均衡機(jī)制。
通過對某些Node 定義特定的Label ，并且在Pod 定義文件中使用NodeSelector 這種標(biāo)
簽調(diào)度策略， kube咽heduler 進(jìn)程可以實(shí)現(xiàn)Pod “定向調(diào)度”的特性。

5、Replication Controller

1) 所以RC 的定義包括如下幾個(gè)部分。
  。Pod 期待的副本數(shù)（ replicas ）。
  。用于篩選目標(biāo)Pod 的Label Selector .
  。當(dāng)Pod 的副本數(shù)量小于預(yù)期數(shù)量時(shí)，用于創(chuàng)建新Pod 的Pod 模板（ template ） 。
2）刪除RC 并不會(huì)影響通過該RC 己創(chuàng)建好的Pod 。為了刪除所有Pod ，可以設(shè)置replicas 的值為0 ，然后更新該RC 。另外， kubectl 提供了stop 和delete 命令來一次性刪除RC 和RC 控制的全部Pod 。
3）Replica Sets支持基于集合的Label selector ( Set-based selector ），而RC 只支持基于等式的Label Selector(equality-based selector ）
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier , operator: In, values: [frontend)}
4）
。在大多數(shù)情況下，我們通過定義一個(gè)RC 實(shí)現(xiàn)Pod 的創(chuàng)建過程及副本數(shù)量的自動(dòng)控制。
。RC 里包括完整的Pod 定義模板。
。RC 通過Label Selector 機(jī)制實(shí)現(xiàn)對Pod 副本的自動(dòng)控制。
。通過改變RC 里的Pod 副本數(shù)量，可以實(shí)現(xiàn)Pod 的擴(kuò)容或縮容功能。
。通過改變RC 里Pod 模板中的鏡像版本，可以實(shí)現(xiàn)Pod 的滾動(dòng)升級功能。

6、Deployment

DESIRED : Po d 副本數(shù)量的期望值，即Deployment 里定義的Replica
CURRENT ： 當(dāng)前Replica 的值， 實(shí)際上是Deployment 所創(chuàng)建的Replica Set 里的Replica值，這個(gè)值不斷增加，直到達(dá)到DESIRED 為止， 表明整個(gè)部署過程完成。
UP-TO-DATE ： 最新版本的Pod 的副本數(shù)量，用于指示在滾動(dòng)升級的過程中，有多少個(gè)Pod 副本已經(jīng)成功升級。
AVAILABLE ： 當(dāng)前集群中可用的Pod 副本數(shù)量，即集群中當(dāng)前存活的Pod 數(shù)量。

7、－Horizontal Pod Autoscaling-HPA Pod 橫向自動(dòng)擴(kuò)容

apiVersion : autoscaling/vl
kind: HorizontalPodAutoscaler
metadata :
name : php-apache
namespace: default
spec:
maxReplicas : 10
minReplicas : 1
scaleTargetRef:
kind : Deplo 瀘nent
name : php-apache
targetCPUUtilizationPercentage : 90

8、StatefulSet

1)StatefulSet 里的每個(gè)Pod 都有穩(wěn)定、唯一的網(wǎng)絡(luò)標(biāo)識(shí)，可以用來發(fā)現(xiàn)集群內(nèi)的其他成員。假設(shè)StatefulSet 的名字叫kafka, ，那么第l 個(gè)Pod 叫kafka-0 ，第2 個(gè)叫kafk-1 ，以此類推。
2) StatefulSet 控制的Pod 副本的啟停順序是受控的，操作第n 個(gè)Pod 時(shí)，前n-1 個(gè)Pod 己經(jīng)是運(yùn)行且準(zhǔn)備好的狀態(tài)。
StatefulSet 里的Pod 采用穩(wěn)定的持久化存儲(chǔ)卷，通過PV/PVC 來實(shí)現(xiàn)，刪除Pod 時(shí)默認(rèn)不會(huì)刪除與Statefu!Set 相關(guān)的存儲(chǔ)卷（為了保證數(shù)據(jù)的安全〉。
3) StatefulSet 除了要與PV 卷捆綁使用以存儲(chǔ)Pod 的狀態(tài)數(shù)據(jù)，還要Headless Service 配合使用，即在每個(gè)Statefu!Set 的定義中要聲明它屬于哪Headless Service 。Headless Service 與普通Service 的關(guān)鍵區(qū)別在于，
它沒有Cl uster IP ，如果解析Headless Service 的DNS 域名，則返回的是該Service 對應(yīng)的全部Pod 的Endpoint 列表。
Statefu!Set 在Headless Service 的基礎(chǔ)上又為StatefulSet 控制的每個(gè)Pod 實(shí)例創(chuàng)建了一個(gè)DNS 域名，這個(gè)域名的格式為：
$(podname).$(headless service name)
4) 比如一個(gè)3 節(jié)點(diǎn)的Kafka 的Statefu!Set 集群，對應(yīng)的Headless Service 的名字為kafka,
StatefulSet 的名字為kafka ，則StatefulSet 里面的3 個(gè)Pod 的DNS 名稱分別為kafka-0.kafka 、
kafka-1.kafka、kafka-3 .kafka ，這些DNS 名稱可以直接在集群的配置文件中固定下來。

9、Service

1) Kubernetes 里的每個(gè)Service 其實(shí)就是我們經(jīng)常提起的微服務(wù)架構(gòu)中的一個(gè)“微服務(wù)”

2) 然每個(gè)Pod 都會(huì)被分配一個(gè)單獨(dú)的E 地址，而且每個(gè)Pod 都提供了一個(gè)獨(dú)立的Endpoint
( Pod IP+ContainerPort ）以被客戶端訪問，現(xiàn)在多個(gè)Pod 副本組成了一個(gè)集群來提供服務(wù)，那么
客戶端如何來訪問它們呢？ 一般的做法是部署一個(gè)負(fù)載均衡器（軟件或硬件），為這組Pod 開啟
一個(gè)對外的服務(wù)端口如8000 端口， 并且將這些Pod 的Endpoint 列表加入8000 端口的轉(zhuǎn)發(fā)列表
中，客戶端就可以通過負(fù)載均衡器的對外E 地址＋服務(wù)端口來訪問此服務(wù)，而客戶端的請求最
后會(huì)被轉(zhuǎn)發(fā)到哪個(gè)Pod ，則由負(fù)載均衡器的算法所決定。

3）在spec . ports 的定義中， taretPort 屬性用來確定提供該服務(wù)的容器所暴露（ EXPOSE ）的端
口號(hào)，即具體業(yè)務(wù)進(jìn)程在容器內(nèi)的targ etPort 上提供TCP/IP 接入：而port 屬性則定義了Service
的虛端口。沒有指定targetPort ，則默認(rèn)targetPort 與port 相同。

4）service多端口問題
  -- Kubernetes 的服務(wù)發(fā)現(xiàn)機(jī)制
    每個(gè)Kubemetes 中的Service 都有一個(gè)唯一的Cluster IP 及唯一的名字,名字由開發(fā)者自己定義
    是如何通過Service 的名字找到對應(yīng)的Cluster IP。
     每個(gè)Service 生成一些對應(yīng)的Linux 環(huán)境變量CENV ），并在每個(gè)Pod 的容器在啟動(dòng)時(shí)，自動(dòng)注入這些環(huán)境變量
      eg: service 名字叫tomcat-service 產(chǎn)生的環(huán)境變量條目：
      TOMCAT SERVICE SERVICE HOST=l 69 .169. 41. 218
      TOMCAT SERVICE SERVICE PORT SERVICE PORT=8080
      TOMCAT SERVICE SERVICE PORT SHUTDOWN PORT=BOOS
      TOMCAT SERVICE SERVICE PORT=8080
      TOMCAT SERVICE PORT 8005 TCP PORT=BOOS
      TOMCAT SERVICE PORT=tcp: / /169 . 169.41.218:8080
      TOMCAT SERVICE PORT 8080 TCP ADDR=l69.169.41.218
      TOMCAT_SERVICE_PORT_8080_TCP=tcp://169.169 . 41.218:8080
      TOMCAT SERVICE PORT 8080 TCP PROTO=tcp
      TOMCAT SERVICE PORT 8080 TCP PORT=8080
      TOMCAT_SERVICE_PORT_8005一TCP=tcp:/ / 169.169.41 . 2 18:8005
      TOMCAT SERVICE PORT 8005 TCP ADDR=169 . 169.41.218
      TOMCAT SERVICE PORT 8005 TCP PROTO=tcp
    DNS系統(tǒng)：把服務(wù)名作為DNS域名

5）外部系統(tǒng)訪問service的問題
  Node IP: Node 節(jié)點(diǎn)的IP 地址。Node IP 是Kubemetes 集群中每個(gè)節(jié)點(diǎn)的物理網(wǎng)卡的IP 地址，這是一個(gè)真實(shí)存在的物理網(wǎng)絡(luò)。
  所有屬于這個(gè)網(wǎng)絡(luò)的服務(wù)器之間都能通過這個(gè)網(wǎng)絡(luò)直接通信。Kubemetes 集群之外的節(jié)點(diǎn)訪問Kubemetes 集群之內(nèi)的某個(gè)節(jié)點(diǎn)或者TCP/IP 服務(wù)時(shí)，必須要通過Node IP 進(jìn)行通信。
  Pod IP: Pod 的IP 地址。它是Docker Engine 根據(jù)dockerO 網(wǎng)橋的E 地址段進(jìn)行分配的，通常是一個(gè)虛擬的二層網(wǎng)絡(luò)。
  Kubemetes 里一個(gè)Pod 里的容器訪問另外一個(gè)Pod 里的容器，就是通過Pod E 所在的虛擬二層網(wǎng)絡(luò)進(jìn)行通信的，而真實(shí)的TCP/IP 流量則是通過Node E 所在的物理網(wǎng)卡流出的。
  Cluster IP: Service 的IP地址。Cluster IP 僅僅作用于Kubemetes Service 這個(gè)對象，并由Kubemetes 管理和分配IP 地址（來源于Cluster IP地址池）。
    Cluster IP 無法被Ping
    Cluster  IP 只能結(jié)合Service Port 組成一個(gè)具體的通信端口，單獨(dú)的Cluster IP 不具備TCP/ IP 通信的基礎(chǔ)，,
    并且它們屬于Kubemetes 集群這樣一個(gè)封閉的空間， 集群之外的節(jié)點(diǎn)如果要訪問這個(gè)通信端口，則需要做一些額外的工作
    在Kubemetes 集群之內(nèi)， Node IP 網(wǎng)、Pod IP 網(wǎng)與Cluster IP 網(wǎng)之間的通信， 采用的是Kubemetes 自己設(shè)計(jì)的一種編程方式的特殊的路由規(guī)則
    NodePort 的實(shí)現(xiàn)方式是在Kubemetes 集群里的每個(gè)Node 上為需要外部訪問的Service 開啟一個(gè)對應(yīng)的TCP 監(jiān)聽端口，外部系統(tǒng)只要用任意一個(gè)Node 的IP 地址＋具體的NodePort 端口號(hào)即可訪問此服務(wù)。

service與pod,rc關(guān)系.png

10、Volume

1) 我們先在Pod 上聲明一個(gè)Volume ，然后在容器里引用該Volume 并Mount 到容器里的某個(gè)目錄上

2) Volume類型
  - emptyDir：它的初始內(nèi)容為空，并且無須指定宿主機(jī)上對應(yīng)的目錄文件，因?yàn)檫@是Kubernetes 自動(dòng)分配的一個(gè)目錄
  - hostPath: 在Pod 上掛載宿主機(jī)上的文件或目錄
  - gcePersistentDisk:表示使用谷歌公有云提供的永久磁盤（ Persistent Disk, PD ）存放Volume 的數(shù)據(jù)    詳見P39
  - awsElasticBlockStore： 使用亞馬遜公有云提供的EBSVolume 存儲(chǔ)數(shù)據(jù)
  - NFS（網(wǎng)絡(luò)文件系統(tǒng)）：
      volumes :
        - name: nfs
          nfs :
      ＃改為你的NFS 服務(wù)器地址
          server: nfs-server.localhost
          path： ”／”
  - iscsi ：使用iSCSI 存儲(chǔ)設(shè)備上的目錄掛載到Pod 中
  ......

11、Persistent Volume（PV）

1)PV 可以理解成Kubemetes 集群中的某個(gè)網(wǎng)絡(luò)存儲(chǔ)中對應(yīng)的一塊存儲(chǔ).
  PV 只能是網(wǎng)絡(luò)存儲(chǔ)，不屬于任何Node ，但可以在每個(gè)Node 上訪問
  PV 井不是定義在Pod 上的，而是獨(dú)立于Pod 之外定義。
  PV 目前支持的類型包括： gcePersistentDisk 、AWSElasticBlockStore 、AzureFile 、
AzureDisk 、FC ( Fibre Channel ） 、Flocker、NFS 、iSCSI 、RBD (Rados Block Device ）、
CephFS 、Cinder、GlusterFS 、V sphere Volume 、Quobyte Volumes 、VMware Photon 、Portwonc
Volumes 、ScaleIO Volumes 和HostPath （僅供單機(jī)測試）。
2) 如果某個(gè)Pod 想申請某種類型的PY ，則首先需要定義一個(gè)PersistentVolurneClaim ( PVC )對象,然后，在Pod 的Volume 定義中引用上述PVC 即可.
  volumes:
     - name: mypd
       persistentVolumeClaim:
       claimName : myclaim
3) PV的狀態(tài)
  Available ：空閑狀態(tài)。
  Bound ：己經(jīng)綁定到某個(gè)PVC 上。
  Released ：對應(yīng)的PVC 己經(jīng)刪除，但資源還沒有被集群收回
  Failed: PV 自動(dòng)回收失敗。

12、Namespace

1)Namespace 通過將集群內(nèi)部的資源對象“分配”到不同的Namespace 中，形成邏輯上分組的不同項(xiàng)目、小組或用戶組，便于不同的分組在共享使用整個(gè)集群的資源的同時(shí)還能被分別管理。
2）pod中選擇namespace
apiVersion: vl
kind: Pod
metadata:
  name: busybox
  namespace: development

13、Annotation （注解）

第二章

一、單master多node安裝--yum安裝
二、多master高可用安裝--
安裝詳見后續(xù)文章整理

1、kube_apiserver服務(wù)

1）啟動(dòng)service文件
[Unit]
Description=Kubernetes API Server
Documentation=https://github . com/GoogleCloudPlatform/kubernetes
After=etcd. service
Wants=etcd.service
[Service]
EnvironmentFile=/etc/kubernetes/apiserver
ExecStart=/usr/bin/kube - apiserver $KUBE_API_ARGS
Restart=on failure
Type=notify
LimitNOFILE=65536
[Install)
WantedBy=multi-user . target

2）配置文件參數(shù)
KUBE API ARGS="......"
--etcd- servers ： 指定etcd 服務(wù)的URL
--storage-backend ：指定etcd 的版本，從Kubemetes v l.6 開始，默認(rèn)為etcd3,前版本無此參數(shù)
--insecure-bind-address: apiserver 綁定主機(jī)的非安全E 地址，設(shè)置0 . 0 .0 . 0 表示綁定所有ip地址。
-- insecure -port : apise凹er 綁定主機(jī)的非安全端口號(hào)，默認(rèn)為8080 。
--service-cluster-ip-range: Kubemete s 集群中Service 的虛擬IP 地址段范圍，以CIDR 格式表示
--service-node-pod-range: Kubernetes 集群中Service 可映射的物理機(jī)端口號(hào)范圍，默認(rèn)為30 000 ～ 3 2767
--admission_control: Kubernetes 集群的準(zhǔn)入控制設(shè)置，各控制模塊以插件的形式依次生效。-- --logtostderr ：設(shè)置為fa lse 表示將日志寫入文件， 不寫入stderr 。
--log-dir ：日志目錄。
--v:日志級別

2、controller-manager與kube-scheduler 服務(wù)

1) 啟動(dòng)service文件
[ Uni服務(wù)端私鑰文件t ]
Description=Kubernetes Controller Manager
Documentation=https : //gith ub.com/GoogleCloudPlatform/kubernetes
After=kube-apiserver.service
Requires=kube-apiserver.service
[Service]
EnvironmentFil e=/etc/kubernetes/scheduler
ExecStart=/usr/bin/ kube-scheduler $KUBE SCHEDULER ARGS
Restart=on- failure
LimitNOFILE=65536
[Install ]
WantedBy=multi - user.target

2）配置參數(shù)
--master：指定apiserver 的URL 地址。
--logto stderr ： 設(shè)置為false 表示將日志寫入文件，不寫入stderr
--log-dir ： 日志目錄。
--v：日志級別

3、Kubernetes 集群的安全設(shè)置

1)概要
  在一個(gè)安全的內(nèi)網(wǎng)環(huán)境中， Kubernetes 的各個(gè)組件與Master 之間可以通過apiserver的非安全端口
htttp://apiserver:8080 進(jìn)行訪問。但如果apiserver 需要對外提供服務(wù)，或者集群中的某些容器也需要訪問api server 以獲取
集群中的某些信息，則更安全的做法是啟用HTTPS 安全機(jī)制。
2) CA簽名的雙向數(shù)字證書的生成過程如下：
    (1) 為kube -apiserver 生成一個(gè)數(shù)字證書，井用CA 證書進(jìn)行簽名。
    (2) 為kube-api serve r 進(jìn)程配置證書相關(guān)的啟動(dòng)參數(shù)，包括CA 證書（用于驗(yàn)證客戶端證書的簽名真?zhèn)危?、自己的?jīng)過CA 
        簽名后的證書及私鑰。
    (3) 為每個(gè)訪問Kubernetes API Server 的客戶端（如kube-controller-manager 、kube-scheduler、kubelet 、
        kube-proxy 及調(diào)用API server的客戶端程序kubectl 等）進(jìn)程生成自己的數(shù)字證書，也都用CA 證書進(jìn)行簽名，在相關(guān)程序的啟動(dòng)
      參數(shù)里增加CA 證書、自己的證書等相關(guān)參數(shù)。
3) 對應(yīng)服務(wù)秘鑰生成 
  kube-apiserver 的CA 證書--server.key，server.crt,server.csr
  kube-controller-manager 的客戶端證書、私鑰--cs_client.key,cs_client.crt,cs_client.csr
  kube-scheduler復(fù)用kube-controller-manager 創(chuàng)建的客戶端證書
  kubelet的客戶端證書、私鑰：kubelet_client.key，kubelet client.csr，kubelet client.crt
  kube-proxy復(fù)用kubelet創(chuàng)建的客戶端證書
4)  證書啟動(dòng)參數(shù)
      (1) kube-apiserver
         --client-ca-file：CA 根證書文件
         --tls-cert-file:  服務(wù)端證書文件
         --tls-private-key-file: 服務(wù)端私鑰文件
         --insecure-port=0   #關(guān)閉非安全端口8080
         --secure-port=6443 #開始安全端口6443（默認(rèn)端口）
      (2) kube-controller-manager
          --master=https://
          --service-account-key-file
          --root-ca-file
          --kubeconfig     #配置了kube-controller-manager客戶端證書等相關(guān)參數(shù)
                user:
                  client-certificate : /var/run/kubernetes/cs client.crt
                  client-key: /var/run/kubernetes/cs_client.key
                cluster:
                  certificate-authority: /var/run/kubernetes/ca.crt
     （3）kube-scheduler 啟動(dòng)參數(shù)
          --master=https://192.168.18.3:6443
          --kubeconfig=/etc/kubernetes/kubeconfig
      (4) kubelet
          --api-servers=https : //192.168.18.3:6443
          --kubeconfig=/etc/kubelet/kubeconfig
      (5) kube-proxy
          --master=https : //192 . 168.18.3:6443
          --kubeconfig=/etc/kubernetes/kubeconfig     #kubelet與kube-proxy公用一個(gè)kubeconfig
apiVersion : vl
kind : Config
users:
- name: kubelet
  user :
    client-certificate: /etc/kubernetes/ssl_keys/kubelet_client.crt
    client-key: /etc/kubernetes/ssl_keys/kubelet_client.key
clusters :
- name : local
  cluster :
   certificate-authority : /etc/kubernetes/ssl_keys/ca.crt
contexts :
- context:
    cluster : local
    user: kubelet
  name: my-context
current-context : my - context
4） 基于TOKEN 認(rèn)證的配直過程

4、Kubernetes 核心服務(wù)配置詳解 p83
在命令的配置文件中添加，修改，刪除參數(shù)

• 公共配置參數(shù)
  公共配置參數(shù)適用于所有服務(wù)(kube-apiserver、kube-controller-manager、kube-scheduler 、kubelet 、kube-proxy)

5、kubectl用法概述 kubectl [command] [TYPE] [NAME) [flags]
【TYPE】

p105
【COMMAND】

【flags】

【輸出格式】

2、Pod深入掌握

Pod 定義詳解

apiVersion : vl
kind: Pod
metadata :
  name : string
  namespace: string
  labels:
    - name: string
  annotations:
    - name: string
spec:
  containers:
  - name: <container-name>
    image: image-name
    iamgePullPolicy: Always|Nerver|IfNotPersent
    command: shell-command-when-container-up
    args: string
    workingDir: string
    volumeMounts:
    - name: <the container paths name mount to outside >
      mountPath: <container path>
      readOnly: boolean
    ports:
    - name: <container servicer port name>
      containerPort: int  <container is linstening port>
      hostPort: int <corresponding to host port >
      protocol: string
    env:
    - name: string
      value: string
    resources:
      limits:
        cpu: string
        memory: string
      requests:
        cpu: string
        memory: string
    livenessProbe:
      exec:
        command: string
      httpGet:
        path: string
        port: number
        host: string
        shceme: string
        httpHeaders:
        - name: string
          value: string
      tcpSocket:
        port: number
      initialDelaySeconds: 0
      timeoutSeconds: 0
      periodSeconds:0
      successThreshold: 0
      failureThreshold: 0
    securityContext:
      privileged: false
  restartPolicy: Always | Never | OnFailure
  nodeSelector: object
  imagePullsecrets:
  - name: string
  hostNetwork: false
  volumes:
  - name: string
    emptyDir: {}
    hostPath:
      path: string
    secret:
      secretName: string
      items:
      - key: string
        path: string
      configMap:
        name: string
        items:
        - key: string
          path: string

(2) pod的使用

? 在使用Docker 時(shí)，可以使用docker run 命令創(chuàng)建井啟動(dòng)一個(gè)容器。而在Kubemetes 系統(tǒng)中對長時(shí)間運(yùn)行容器的要求是： 其主程序需要一直在前臺(tái)執(zhí)行。如果我們創(chuàng)建的Docker 鏡像的啟
動(dòng)命令是后臺(tái)執(zhí)行程序，例如Linux 腳本：
nohup . /s tart.sh &
則在kubelet 創(chuàng)建包含這個(gè)容器的Pod 之后運(yùn)行完該命令， 即認(rèn)為Pod 執(zhí)行結(jié)束，將立刻銷毀該P(yáng)od 。故在制作鏡像時(shí)，啟動(dòng)命令直接前臺(tái)啟動(dòng)對于那些無法改造為前臺(tái)執(zhí)行的應(yīng)用，可以是喲個(gè)supervisor輔助進(jìn)行前臺(tái)運(yùn)行功能。

• 靜態(tài)Pod

? 靜態(tài)Pod 是由陽b elet 進(jìn)行管理的僅存在于特定Node 上的Pod 。它們不能通過API Server進(jìn)行管理， 無法與ReplicationController、Deployment 或者DaemonSet 進(jìn)行關(guān)聯(lián)， 井且kubele t
也無法對它們進(jìn)行健康檢查。靜態(tài)Pod 總是由kubelet 進(jìn)行創(chuàng)建的，并且總是在kubelet 所在的
Node 上運(yùn)行的。

? 創(chuàng)建靜態(tài)Pod有兩種方式：配置文件方式和HTTP方式。

• Pod容器共享volume

? 在同一個(gè)Pod 中的多個(gè)容器能夠共享Pod 級別的存儲(chǔ)卷Volume 。Volume 可以被定義為各種類型，多個(gè)容器各自進(jìn)行掛載操作，將一個(gè)volume 掛載為容器內(nèi)部需要的目錄

（3）Pod的配置管理 —ConfigMap

• 概述

  • 生成為為容器內(nèi)的環(huán)境變量
  • 設(shè)置容器啟動(dòng)命令的啟動(dòng)參數(shù)（需設(shè)置為環(huán)境變量）
  • 以volume的形式掛載為容器內(nèi)部的文件或目錄

  ConfigMap 以一個(gè)或多個(gè)key: value 的形式保存在Kubemetes 系統(tǒng)中供應(yīng)用使用，既可以用于表示一個(gè)變量的值（例如apploglevel=info ），也可以用于表示一個(gè)完整配置文件的內(nèi)容?？梢酝ㄟ^yaml文件或直接使用kubectl create configmap 命令行的方式來創(chuàng)建ConfigMap。

• 創(chuàng)建ConfigMap資源對象

  yaml方式

apiversion: v1
kind: ConfigMap
metadata:
    name: my-appvars
data:
    apploglevel: info
    appdatadir: /var/data
   

通過kubectl 命令行方式創(chuàng)建

通過kubectl create configmap 創(chuàng)建
（1）通過一from-file 參數(shù)從文件中進(jìn)行創(chuàng)建，可以指定key 的名稱，也可以在一個(gè)命令行中創(chuàng)建包含多個(gè)key 的ConfigMap ，語法為：
 kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source
 例：kubectl create confiqmap cm-server.xml --from-file=server.xml 
（2）通過－－from-file 參數(shù)從目錄中進(jìn)行創(chuàng)建，該目錄下的每個(gè)配置文件名都被設(shè)置為key.文件的內(nèi)容被設(shè)置為va lue ，語法為：
 kubectl create configmap NAME --from-file=config-files-dir
 例：kubectl create configmap cm-appconf - -from-file=configfiles    #configfiels 是目錄
 （3）(3) --from-literal 從文本中進(jìn)行創(chuàng)建，直接將指定的key=value創(chuàng)建為ConfigMap 的內(nèi)容，
語法為：
  kubectl create configmap NAME --from-l iteral=keyl=valuel --from-literal=key2=value2
  例：kubectl create configmapαn-appenv --from-literal ＝loglevel=info --from-literal=appdatadir=/var/data

• 容器應(yīng)用ConfigMap

  1）通過環(huán)境變量方式使用ConfigMap

# 創(chuàng)建

apiVersion: v1
kind: COnfigMap
metadata:
  name: cm-appvars
  
data:
  apploglevel: info             #key: value
  appdatadir: /var/data
  
調(diào)用：
...
spec:
  containers:
  - name:
    image:
    command
    env:
    - name: APPLOGLEVEL
      valueFrom:
        configMapKeyRef:
            name: cm-appvars   #環(huán)境變量的值取自cm-appvars
            key: apploglevel    #對應(yīng)的cm-appvars中的key

? 2) 通過volumeMount使用ConfigMap

cat cm-appconfigfiles.yaml
# 創(chuàng)建ConfigMap資源對象
apiVersiob: v1
kind: ConfigMap
metadata:
    name: cm-serverxml
data:
  key-serverxml: |
    <?xml version='1.0' encoding='utf-8'?>
    ...
  key-loggingproperties: "handlers=..,"
  
# volumeMounts掛載
spec:
  containers:
  - name:
    image:
    ports:
    volumeMonunts:
    - name: serverxml           #引用volume中的那個(gè)卷
      mountPath: /configfiles   # 掛載高容器內(nèi)的目錄
  volume: 
  - name: serverxml             # 定義volume名
    configMap:
      name: cm-appconfigfiles   # 使用的ConfigMap名稱
      items:
      - key: key-serverxml      # 對應(yīng)ConfigMap中的key
        path: server.xml        # 值掛載的文件名，及值寫入到容器中的什么文件中
      - key: key-logging.properties
        path: logging.properties
  
如果不指定items,則使用volumeMount 方式在容器內(nèi)的目錄生成每個(gè)key名稱對應(yīng)的文件。

• 使用ConfigMap 的限制條件
  • ConfigMap 必須在Pod 之前創(chuàng)建
  • ConfigMap 受Namespace 限制，只有處于相同Namespaces 中的Pod 可以引用它。
  • ConfigMap 中的配額管理還未能實(shí)現(xiàn)。
  • kubelet 只支持可以被API Server 管理的Pod 使用ConfigMap 。kubelet 在本Node 上通
    過--mainfest-url 或--config 自動(dòng)創(chuàng)建的靜態(tài)P od 將無法引用Conf1gMap 。
  • 在Po d 對ConfigMap 進(jìn)行掛載（ volumeMount ）操作時(shí)，容器內(nèi)部只能掛載為“目錄”，
    無法掛載為“文件”

(3) 在容器中獲取Pod信息

Downward API 可以通過以下兩種方式將Pod 信息注入容器內(nèi)部。

在某些集群中，集群中的每個(gè)節(jié)點(diǎn)都需要將自身的標(biāo)識(shí)（ ID ）及進(jìn)程綁定的IP 地址等信息事先寫入配置文件中，進(jìn)程啟動(dòng)時(shí)讀取這些信息，然后發(fā)布到某個(gè)類似服務(wù)注冊中心的地方，以實(shí)現(xiàn)集群節(jié)點(diǎn)的自動(dòng)發(fā)現(xiàn)功能。此時(shí)Downward API 就可以派上用場了，具體做法是先編寫
一個(gè)預(yù)啟動(dòng)腳本或Init Container，通過環(huán)境變量或文件方式獲取Pod 自身的名稱、IP 地址等信息，然后寫入主程序的配置文件中， 最后啟動(dòng)主程序。

• 環(huán)境變量：：用于單個(gè)變量，可以將Pod 信息和Container 信息注入容器內(nèi)部。

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
  - name:
    image:
    command:
    ports:
    env:
      - name: MY_POD_NAME
        valumeFrom:
          fieldRef:
            fieldPath: metadata.name
      - name: MY_POD_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: MY_POD_IP
        valumeFrom:
          fieldRef:
            fieldPath: status.podIp
【Downward API提供的變量】
metadata.name: Pod 的名稱，當(dāng)Pod 通過RC 生成時(shí)，其名稱是RC 隨機(jī)產(chǎn)生的唯一名稱。

status.podIP: Pod 的回地址，之所以叫作status.podIP 而非metadata.IP ， 是因?yàn)镻od 的IP 屬于狀態(tài)數(shù)據(jù)，而非元數(shù)據(jù)。

metadata.namespace: Pod 所在的Namespace

requests.cpu ：容器的CPU 請求值

limits.cpu ： 容器的CPU 限制值

requests.memory ：容器的內(nèi)存請求值。

• Volume掛載將數(shù)組類信息生成為文件，掛載到容器內(nèi)部

...
metadata:
  name:
  labels:
    zone: us-est-coast
    cluster: test-cluster1  
  annotations:
    build: two
    builder: john-doe
    
    ...
    volumeMounts:
      - name: podinfo
        mountPath: /etc
        readOnly: false
  volume:
    - name: podinfo
      downwardAPI:
        items:
          - path: "labels"
          fieldRef:
            fieldPath: metadata.labels
          - path: "annotations"
          fieldRef:
            fieldPath: metadata.annotations
注意volumes 中downwardAPI的特殊語法， 通過items 的設(shè)置，將會(huì)以path 的名稱生成文件。這里將在容器內(nèi)生成/etc/labels 和/etc/annotations 兩個(gè)文件， ／etc/ labels 中將包含
metadata.labels 的全部Labl 列表，／etc/annotations 中將包含metadata.annotations 的全部Label列表。

(4) pod什么周期和重啟策略

• Pending：APIServer 己經(jīng)創(chuàng)建該P(yáng)od ， 但Pod 內(nèi)還有一個(gè)或多個(gè)容器的鏡像沒有創(chuàng)建，包括正在下我鏡像的過程

• Running：Pod 內(nèi)所有容器均己創(chuàng)建，且至少有一個(gè)容器處于運(yùn)行狀態(tài)、正在啟動(dòng)狀態(tài)或正在亟啟狀態(tài)

• Succeeded：Pod 內(nèi)所有容器均成功執(zhí)行退出， 且不會(huì)再重啟

• Failed：Pod 內(nèi)所有容器均已退出，但至少有一個(gè)容器退出為失敗狀態(tài)

• Unknown：由于某種原因無法獲取該P(yáng)od 的狀態(tài)， 可能由于網(wǎng)絡(luò)通信不暢導(dǎo)致

Pod 的重啟策略包括Always 、OnFailure 和Never， 默認(rèn)值為A lways

(5)Pod健康檢查

• LivenessProbe 探針：用于判斷容器是否存活（ running 狀態(tài)），如果LivenessProbe 探針探測到容器不健康，則kubelet 將殺掉該容器，并根據(jù)容器的重啟策略做相應(yīng)的處理。如果一個(gè)容器不包含LivenessProbe 探針，那么kubelet 認(rèn)為該容器的LivenessProbe 探 針返回的值永遠(yuǎn)是“ Success"
  1）ExecAction實(shí)現(xiàn)方式

在容器內(nèi)部執(zhí)行一個(gè)命令，如果該命令的返回碼為0，則表示容器健康。

...
spec:
  containers:
  - name:
    image:
    args:
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
        initialDelaySeconds: 15     # 健康檢查的初始探測時(shí)間s.啟動(dòng)容器后進(jìn)行首次健康檢查的等待時(shí)間
        timeoutSeconds: 1       #健康檢查發(fā)送請求后等待響應(yīng)的超時(shí)時(shí)間s. 當(dāng)超時(shí)發(fā)生時(shí)，kubelet會(huì)認(rèn)為容已經(jīng)法法提供服務(wù)，將會(huì)重啟改容器。

2）TCPSocketAction實(shí)現(xiàn)方式

通過容器的IP地址和端口號(hào)指定TCP檢查，如果能建立TCP連接，則表明容器健康。

...
spec:
  containers:
  - name:
    image:
    ports:
    livenessPorbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 30
      timeoutSeconds: 1

3）HTTPG etAc tion實(shí)現(xiàn)方式

通過容器的IP地址，端口號(hào)，及路徑調(diào)用HTTP get方法，如果響應(yīng)的狀態(tài)碼大于等于200且小于400，則認(rèn)為容器裝填健康。

spec:
  containers:
  - name: 
    image:
    ports:
    livenessProbe:
      httpGet:
        path: /_status/healthz
        port: 80
      initialDelaySeconds: 30
      timeoutSeconds: 1

• ReadinessProbe 探針：用于判斷容器是否啟動(dòng)完成（ ready 狀態(tài)），可以接收請求。如果ReadinessProbe 探針檢測到失敗，則Pod 的狀態(tài)將被修改。Endpoint Con位oiler 將從Service 的Endpoint 中刪除包含該容器所在Pod 的Endpoint 。

(6) Pod 調(diào)度

• Deployment/RC 全自動(dòng)調(diào)度到node節(jié)點(diǎn)

Deployment 或RC 的主要功能之一就是自動(dòng)部署一個(gè)容器應(yīng)用的多份副本， 以及持續(xù)監(jiān)控副本的數(shù)量， 在集群內(nèi)始終維持用戶指定的副本數(shù)量

• NodeSelector：定向調(diào)度

通過Node的標(biāo)簽和Pod的nodeSelector屬性相匹配，來實(shí)現(xiàn)定向調(diào)度。

node打標(biāo)簽：kubectl label nodes <node-name> <label -key>=<label-value >

...

spec.nodeSelector:

如果給多個(gè)node都定義了相同的標(biāo)簽，則scheduler將會(huì)根據(jù)調(diào)度算法 從這組node中挑選一個(gè)可用的node進(jìn)行pod調(diào)度。

• NodeAffinity: node親和性調(diào)度

  • RequiredDuringSchedulinglgnoredDuringExecution ：必須滿足指定的規(guī)則才可以調(diào)度Pod
    到Node 上（功能與nodeSelector 很像，但是使用的是不同的語法），相當(dāng)于硬限制。
  • PreferredDuringSchedulinglgnoredDuringExecution ：強(qiáng)調(diào)優(yōu)先滿足指定規(guī)則，調(diào)度器會(huì)
    嘗試調(diào)度Pod 到Node 上，但并不強(qiáng)求，相當(dāng)于軟限制。多個(gè)優(yōu)先級規(guī)則還可以設(shè)置權(quán)
    重（ weight ）值，以定義執(zhí)行的先后順序。

  IgnoredDuringExecution的意思是：如果一個(gè)Pod 所在的節(jié)點(diǎn)在Pod 運(yùn)行期間標(biāo)簽發(fā)生了變
  更，不再符合該P(yáng)od 的節(jié)點(diǎn)親和性需求，則系統(tǒng)將忽略Node 上Label 的變化，該P(yáng)od 能繼續(xù)在
  該節(jié)點(diǎn)運(yùn)行。

...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingignoredDuringExecution:
        ...
      preferredDuringSchedulingign.redDuringExecution:
        ...

• PodAffinity：pod親和與互斥調(diào)度策略調(diào)度

根據(jù)節(jié)點(diǎn)上正在運(yùn)行的Pod 的標(biāo)簽而不是節(jié)點(diǎn)的標(biāo)簽進(jìn)行判斷和調(diào)度， 要求對節(jié)點(diǎn)和Pod 兩個(gè)條件進(jìn)行匹配。

• Pod互斥性調(diào)度
• Taints 和Tolerations（污點(diǎn)和容忍）

Taint污點(diǎn)，讓node拒絕pod的運(yùn)行。Taint 需要和Toleration 配合使用，讓Pod 避開那些不合適的Node。在node上設(shè)置一個(gè)或多個(gè)Taint之后，除非Pod明確什么能容忍這些污點(diǎn)，否則無法在這些Node上運(yùn)行。
Pod 的Toleration 聲明中的key 和effect 需要與Taint 的設(shè)置保持一致，井且滿足以下條件
之一。如果不指定operator ，則默認(rèn)值為Equal

1）operator 的值是Exists （無須指定value ）

2）operator 的值是Equal 井且value 相等。

Kubernetes調(diào)度器處理多個(gè)Taint 和Toleration 的邏輯順序?yàn)椋?首先列出節(jié)點(diǎn)中所有的Ta int ，然后忽略Pod
的Toleration 能夠匹配的部分，剩下的沒有忽略掉的Taint 就是對Pod 的效果了.

1）如果剩余的Taint 中存在effect=NoSchedule ，則調(diào)度器不會(huì)把該P(yáng)od 調(diào)度到這一節(jié)點(diǎn)上

2）如果剩余Taint 中沒有NoSchedule 效果， 但是有PreferNoSch edul e 效果，則調(diào)度器會(huì)嘗
試不把這個(gè)Pod 指派給這個(gè)節(jié)點(diǎn)。

3）如果剩余Taint 的效果有NoExecute 的， 并且這個(gè)Pod 已經(jīng)在該節(jié)點(diǎn)上運(yùn)行，則會(huì)被驅(qū)
逐； 如果沒有在該節(jié)點(diǎn)上運(yùn)行，也不會(huì)再被調(diào)度到該節(jié)點(diǎn)上

獨(dú)占節(jié)點(diǎn)

kubectl taint nodes nodename dedicated=groupName:NoSchedule，然后給這些應(yīng)用的Pod 加入對應(yīng)的Toleration，這樣，帶有合適Toleration 的Pod 就會(huì)被允許同使用其他節(jié)點(diǎn)一樣使用有Taint 的節(jié)點(diǎn)。

具有特殊硬件設(shè)備的節(jié)點(diǎn)

kubectl taint nodes nodename special=true : NoSchedule

kubectl taint nodes nodename special=true:PreferNoSchedule

然后在Pod 中利用對應(yīng)的Toleration 來保障特定的Pod 能夠使用特定的硬件。

定義Pod驅(qū)逐行為，以應(yīng)對節(jié)點(diǎn)故障

(8) Job 批處理調(diào)度

若要使用參閱Kubernetes權(quán)威指南p141

(9) Cronjob定時(shí)任務(wù)

若要使用參閱Kubernetes權(quán)威指南p145

(10) 自定義調(diào)度器

(11)Init Container 初始化容器

用于在啟動(dòng)應(yīng)用容器之前啟動(dòng)一個(gè)或多個(gè)初始化容器，完成應(yīng)用容器的預(yù)置條件，初始化容器運(yùn)行一起就結(jié)束任務(wù)，并且必須在成功執(zhí)行完成后，系統(tǒng)才能繼續(xù)執(zhí)行下一個(gè)容器。

...
spec:
  initContainers:
  - name:
  ...
  containers:

( 1 ) init container 的運(yùn)行方式與應(yīng)用容器不同，它們必須先于應(yīng)用容器執(zhí)行完成， 當(dāng)設(shè)置了
多個(gè)init container 時(shí)，將按順序逐個(gè)運(yùn)行，并且只有前一個(gè)init container 運(yùn)行成功后才能運(yùn)行后
一個(gè)init container 。當(dāng)所有init container 都成功運(yùn)行后， Kubemetes 才會(huì)初始化Pod 的各種信息，
并開始創(chuàng)建和運(yùn)行應(yīng)用容器。

(2 ）在init container 的定義中也可以設(shè)置資源限制、volume 的使用和安全策略， 等等。但資源限制的設(shè)置與應(yīng)用容器略有不同。

(3) init container 不能設(shè)置readinessProbe 探針，因?yàn)楸仨氃谒鼈兂晒\(yùn)行后才能繼續(xù)運(yùn)行Pod 中定義的普通容器。

(12) Pod的升級和回滾

• Deployment的升級：可以在運(yùn)行時(shí)修改Deployment 的Pod 定義(spec.template ）或鏡像名稱，井應(yīng)用到Deployment 對象上，系統(tǒng)即可完成Deployment 的自動(dòng)更新操作。如果在更新過程中發(fā)生了錯(cuò)誤， 則還可以通過回滾（ Rollback ）操作恢復(fù)Pod的版本。在創(chuàng)建Deployment 時(shí)使用--record 參數(shù)(kubectl create -f filename.yaml --record=true)

1）升級

eg：kubectl set image deployment/nginx-deployment nginx=nginx:l . 9.1

kubectl set image deployment/deployment_name container_name=new_image

or

eg：kubectl edit deployment/nginx-deployment

2）升級策略

RollingUpdate滾動(dòng)更新：默認(rèn)更新模式。設(shè)置spec.strateg予type=RollingUpdate。spec.strategy.rollingUpdate.maxUnavailable參數(shù)用于指定在更新過程中不可用狀態(tài)pod數(shù)量的上限。

s pe c.strategy.rollingUpdate .maxSurge參數(shù)用于指定Deployment 更新Pod 過程中Pod 總數(shù)超
過Pod 期望副本數(shù)部分的最大值

Recreate重建：設(shè)置spec. strategy. type= Recreate

3）回滾

查看部署歷史記錄：kubectl rollout history deployment/deployment_name。當(dāng)且僅當(dāng)Deployment的Pod模板被更改時(shí)才會(huì)創(chuàng)建修訂版本。

回滾到指定版本：kubectl rollout undo deployment/nginx-deployment --to-revision=2

4）暫停和恢復(fù)：對于一次復(fù)雜的Deployment 配置修改，為了避免頻繁觸發(fā)Deployment 的更新操作，可以
先暫停Deployment 的更新操作，然后進(jìn)行配置修改，再恢復(fù)Deployment。

暫停：kubectl rollout pause deployment/deployment_name

修改：kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1 or edit編輯

恢復(fù)：kubectl rollout resume deploy deployment_name

• RC的升級

3、Pod深入掌握

至179