副本機制和其他控制器
kubectl delete rc kubia --cascade=false
kubectl lables pod --overwite
kubectl logs mypod --previous 想看到的是重啟前容器的日誌
存活探針livenessProbe
Kubemetes 可以通過存活探針 (liveness probe) 檢查容器是否還在執行。可以為 pod 中的每個容器單獨指定存活探針。 如果探測失敗，Kubemetes將定期執行探針並重新啟動容器。
有以下三種探測容器的機制：
• HTTP GET探針對容器的 IP 地址（你指定的埠和路徑）執行 HTTP GET 請求。
• TCP套接字探針嘗試與容器指定埠建立TCP連線。如果連線成功建立，則探測成功。否則，容器重新啟動。
• Exec探針在容器內執行任意命令，並檢查命令的退出狀態碼。如果狀態碼是0, 則探測成功。所有其他狀態碼都被認為失敗。
kubia-liveness-probe.yaml
apiVersion: v1
kind: Pod
metadata:
name: kubia-liveness
spec:
containers:
- image: luksa/kubia-unhealthy
name: kubia
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 15
建立pod後describe
Liveness: http-get http://:8080/ delay=0s timeout=1s period=10s #success=1 #failure=3
除了明確指定的存活探針選項，還可以看到其他屬性，例如delay(延遲）、timeout(超時）、period(週期）等。
delay=0s部分顯示在容器啟動後立即開始探測。 timeout僅設定為1秒，因此容器必須在1秒內進行響應， 不然這次探測記作失敗。 每10秒探測一次容器(period=10s), 並在探測連續三次失敗(failure=3)後重啟容器。
initialDelaySeconds: 15 Kubernetes會在第—次探測前等待15秒
保持探針輕量
存活探針不應消耗太多的計算資源， 並且執行不應該花太長時間 。 預設情況下，探測器執行的頻率相對較高， 必須在一秒之內執行完畢。 一個過重探針會大大減慢你的容器執行。
無須在探針中實現重試迴圈
探針的失敗闕值是可配置的， 並且通常在容器被終止之前探針必須失敗多次。 但即使你將失敗闕值設定為1 , Kubemetes為了確認一次探測的失敗，會嘗試若干次 。 因此 在探針中自己實現重試迴圈是浪費精力。
由承載pod的節點上的Kubelet 執行
根據yml檔案建立的RC，通過edit修改標籤（pod，select）後，delete -f yml 可刪除關聯的RC。
apiVersion: v1 kind: ReplicationController metadata: name: kubia spec: replicas: 3 selector: app: kubia template: metadata: labels: app: kubia spec: containers: - name: kubia image: nginx ports: - containerPort: 8080
比較ReplicaSet和ReplicationController
ReplicaSet 的行為與ReplicationController 完全相同， 但pod 選擇器的表達能力更強。 雖然 ReplicationController 的標籤選擇器只允許包含某個標籤的匹配 pod，但ReplicaSet 的選擇器還允許匹配缺少某個標籤的 pod，或包含特定標籤名的 pod，不管其值如何。
另外，舉個例子，單個ReplicationController無法將 pod與標籤 env=production和env=devel同時匹配。它只能匹配帶有env=devel標籤或帶有env=devel標籤的pod。但是一個ReplicaSet可以匹配兩組pod並將它們視為一個大組。
同樣，無論ReplicationController 的值如何，ReplicationController都無法僅基於標籤名的存在來匹配pod，而ReplicaSet 則可以。 例如，ReplicaSet 可匹配所有包含名為 env 的標籤的 pod, 無論ReplicaSet 的實際值是什麼（可以理解為 env= *)。
使用ReplicaSet的更富表達力的標籤選擇器
ReplicaSet 相對於 ReplicationController的主要改進是它更具表達力的標籤選擇器。 之前我們故意在第 一個 ReplicaSet 示例中， 用較簡單的 matchLabels 選擇器來確認 ReplicaSet 與 ReplicationController 沒有區別。 現在，你將用更強大的matchExpressions 屬性來重寫選擇器， 如下面的程式碼清單所示。
注意僅顯示了選擇器。你會在本書的程式碼檔案中找到整個ReplicaSet定義。
可以給選擇器新增額外的表示式。如示例，每個表示式都必須 包含一個key、
一個operator (運算子），並且可能還有一個values的列表（取決於 運算子）。
你會看到四個有效的運算子：
• In : Label的值 必須與其中 一個指定的values 匹配。
• Notln : Label的值與任何指定的values 不匹配。
• Exists : pod 必須包含一個指定名稱的標籤（值不重要）。使用此運算子時，
不應指定 values欄位。
• DoesNotExist : pod不得包含有指定名稱的標籤。values屬性不得指定 。
如果你 指定了多個表示式，則所有這些表示式都必須為true才能使選擇器與
pod匹配。如果同時指定matchLabels和matchExpressions, 則所有標籤都
必須匹配，並且所有表示式必須計算為true以使該pod與選擇器匹配。
使用 DaemonSet 在每個節點上執行一個 pod
ReplicationController 和 ReplicaSet 都用於在 Kubernetes 叢集上執行部署特定數量的 pod。但是，當你希望 pod 在叢集中的每個節點上執行時（並且 每個節點都需要正好一個執行的 pod 例項)，就會出現某些情況，包括 pod 執行系統級別的與基礎結構相關的操作。
例如， 希望在每個節點上執行日誌收集器和資源監控器。 另 一個典型的例子是 Kubernetes 自己的 kube-proxy 程序， 它需要執行在所有節點上才能使服務工作。
DaemonSet 在每個節點上執行一個 pod
DaemonSet 確保建立足夠的 pod , 並在自己的節點上部署每個pod。 儘管ReplicaSet (或ReplicationController)確保叢集中存在期望數量的pod副本， 但 DaemonSet 並沒有期望的副本數的概念。 它不需要， 因為它的工作是確保一個 pod 匹配它的選擇器並在每個節點上執行。如果節點下線， DaemonSet 不會在其他地方重新建立pod。 但是， 當將 一個新節點新增到叢集中時， DaemonSet 會立刻部署一個新的 pod 例項 。 如果有人無意中刪除了 pod 那麼它也會重新一個新的 pod 。與 ReplicaSet 樣，DaemonSet 從配 pod 模板建立 pod。
DaemonSet 只在特定的節點上執行 pod
DaemonSet pod 部署到叢集中的所有節點上，除非指定這些 pod 在部分節點上執行。 這是通過 pod 模板中的 nodeSelector 屬性指定的，這是 DaemonSet 定義的一部分，似於 ReplicaSet ReplicationController 中的 pod 模板。
注意：節點可以被設定為不可排程 ，防止 pod 被部署到節點上。 DaemonSet 甚至會將 pod 部署到這些節點上，因為無法排程的屬性只會被排程器使用，而 DaemonSet 管理 pod 完全繞過排程器。這是預期的，因為DaemonSet 的目的是執行系統服務，即使是在不可排程的節點上，系統服務通常也需要執行。
用一個例子來解釋 DaemonSet
假設有一個名為 ssd-monitor 的守護程序，它需要在包含固態驅動器(SSD的所有節點上執行。 建立 一個DaemonSet ，它在標記為具有 SSD 的所節點上執行這個守護程序。叢集管理員已經向所有此類節點添加了 disk=ssd 的標籤，因此你將使用節點選擇器建立 DaemonSet， 該選擇器只選擇具有該標籤的節點。
cat ssd-monitor-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: ssd-monitor
spec:
selector:
matchLabels:
app: ssd-monitor
template:
metadata:
labels:
app: ssd-monitor
spec:
nodeSelector:
disk: ssd
containers:
- name: main
image: luksa/ssd-monitor
在Job中執行多個pod例項
作業可以配置為建立多個pod例項， 並以並行或序列方式執行它們 。 這是通過在Job配置中設定 completions和parallelism屬性來完成的。
順序執行Job pod
如果你需要 一個Job執行多次，則可以將completions設為你希望作業的pod執行多少次。
apiVersion: batch/v1
kind: Job
metadata:
name: multi-completion-batch-job
spec:
completions: 5
template:
metadata:
labels:
app: batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: luksa/batch-job
Job將一個接一個地執行五個pod。它最初建立一個pod, 當pod的容器執行完成時，它建立第二個pod，以此類推，直到五個pod成功完成。如果其中 一個pod
發生故障，工作會建立一個新的pod，所以Job總共可以建立五個以上的pod。
並行執行Job pod
不必一個接一個地執行單個Jobpod, 也可以讓該Job並行執行多個pod。可以通過parallelism Job配置屬性，指定允許多少個pod並行執行，如下面的程式碼清單所示。
apiVersion: batch/v1
kind: Job
metadata:
name: multi-completion-batch-job
spec:
completions: 5
parallelism: 2
template:
metadata:
labels:
app: batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: luksa/batch-job
只要其中 一個pod完成任務，工作將執行下 一個pod, 直到五個pod都成功完成任務
Job的縮放
你甚至可以在 Job 執行時更改 Job 的 paralllism 屬性。 這與縮放 ReplicaSet或 ReplicationController 類似， 可以使用 kubectl scale 命令完成：
kubectl scale job multi-completion-batch-job --replicsa 3
由於你將 parallelism 從 2 增加到 3, 另一個 pod 立即啟動， 因此現在有三個 pod 在執行
限制Job pod完成任務的時間
關於 Job 我們需要討論最後 一件事。 Job 要等待一個 pod 多久來完成任務？如果 pod 卡住並且根本無法完成（或者無法足夠快完成），該怎麼辦？
通過在pod配置中設定 activeDeadlineSeconds 屬性，可以限制 pod的時間。如果 pod 執行時間超過此時間， 系統將嘗試終止 pod，並將 Job 標記為失敗。
注意 通過指定 Job manifest 中的 spec.backoffLimt欄位，可以配置 Job在被標記為失敗之前可以重試的次數。 如果你沒有明確指定它，則預設為6。
CronJob
startingDeadlineSeconds 指定截止時間
apiVersion: batch/v1beta1
kind: CronJob
metadata:
name: batch-job-every-fifteen-minutes
spec:
schedule: "0,15,30,45 * * * *"
startingDeadlineSeconds: 15
jobTemplate:
spec:
template:
metadata:
labels:
app: periodic-batch-job
spec:
restartPolicy: OnFailure
containers:
- name: main
image: luksa/batch-job