kubectl create secret tls ingress-secret-fengjian --key /data/sslkey/cinyi.key --cert /data/sslkey/cinyi.pem [root@k8s1 ingress]# vim ingress.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx-default spec: rules: - host: nginx.cinyi.com http: paths: - backend: serviceName: nginx-default servicePort: 80 [root@k8s1 ingress]# vim ingress_443.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx-default-443 namespace: default spec: tls: - hosts: - nginx.cinyi.com secretName: ingress-secret rules: - host: nginx.cinyi.com http: paths: - backend: serviceName: nginx-default servicePort: 80 kubectl create secret tls ingress-secret-fengjian --key /data/sslkey/cinyi.key --cert /data/sslkey/cinyi.pem --namespace=fengjian [root@k8s1 ingress]# vim ingress-fengjian.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx-fengjian-80 namespace: fengjian spec: rules: - host: feng.cinyi.com http: paths: - backend: serviceName: my-nginx-fengjian servicePort: 80 [root@k8s1 ingress]# vim ingress-fengjian-443.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx-fengjian-443 namespace: fengjian spec: tls: - hosts: - feng.cinyi.com secretName: ingress-secret-fengjian rules: - host: feng.cinyi.com http: paths: - backend: serviceName: my-nginx-fengjian servicePort: 80
Pod的liveness和readiness
Kubelet使用liveness probe（存活探針）來確定何時重啟容器。例如，當應用程序處於運行狀態但無法做進一步操作，liveness探針將捕獲到deadlock，重啟處於該狀態下的容器.
Kubelet使用readiness probe（就緒探針）來確定容器是否已經就緒可以接受流量。只有當Pod中的容器都處於就緒狀態時kubelet才會認定該Pod處於就緒狀態。該信號的作用是控制哪些Pod應該作為service的后端. 如果Pod處於非就緒狀態，那么它們將會被從service的load balancer中移除。
配置活力和准備探測器
此頁面顯示如何為容器配置活動和准備探測。
該kubelet使用活躍度探頭知道什么時候重新啟動的容器。例如，活動探測器可能會遇到一個應用程序正在運行但無法取得進展的僵局。在這種狀態下重新啟動容器可以幫助使應用程序更加可用，盡管有錯誤。
kubelet使用准備探測來知道容器何時准備開始接受流量。當所有容器都准備就緒時，Pod已被准備好了。該信號的一個用途是控制哪些Pod被用作服務的后端。當Pod尚未准備就緒時，它將從服務負載平衡器中刪除。
在你開始之前
您需要有一個Kubernetes集群，並且kubectl命令行工具必須配置為與您的集群進行通信。如果您還沒有一個集群，您可以使用Minikube創建一個集群，也 可以使用這些Kubernetes操場之一：
您的Kubernetes服務器必須是版本或更高版本。要檢查版本，請輸入kubectl version。
定義一個活躍命令
許多長時間運行的應用程序最終會轉換到斷開狀態，除非重新啟動，否則無法恢復。Kubernetes提供活動探測器來檢測和補救這種情況。
在本練習中，您將創建一個基於gcr.io/google_containers/busybox圖像運行容器的Pod 。這是Pod的配置文件：
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec spec: containers: - name: liveness image: gcr.io/google_containers/busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5
當容器啟動時，它將執行此命令：在配置文件中，您可以看到Pod有一個容器。該periodSeconds字段指定kubelet應每5秒執行一次活動探測。該initialDelaySeconds字段告訴kubelet它應該等待5秒鍾，然后執行第一個探測。要執行探測，kubelet將cat /tmp/healthy在Container中執行命令。如果命令成功，則返回0，並且kubelet認為容器是活的和健康的。如果命令返回非零值，那么kubelet會殺死Container並重新啟動它。
/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" 在集裝箱生活的前30秒，有一個/tmp/healthy文件。所以在前30秒，命令cat /tmp/healthy返回成功代碼。30秒后，cat /tmp/healthy返回失敗代碼。
創建莢：
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/exec-liveness.yaml
在30秒內查看莢事件：
kubectl describe pod liveness-exec
輸出表示沒有活性探針失敗：
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox" 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox" 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] 23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e 35秒后，再次查看Pod事件：
kubectl describe pod liveness-exec
在輸出的底部，有一些消息表明活動探測失敗，容器已被殺死並重新創建。
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "gcr.io/google_containers/busybox" 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "gcr.io/google_containers/busybox" 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined] 36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e 2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory 再等30秒，並確認容器已重新啟動：
kubectl get pod liveness-exec
輸出顯示RESTARTS已增加：
NAME READY STATUS RESTARTS AGE
liveness-exec 1/1 Running 1 1m
定義一個活躍的HTTP請求
另一種活躍探測器使用HTTP GET請求。以下是基於gcr.io/google_containers/liveness 圖像運行容器的Pod的配置文件。
apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness image: gcr.io/google_containers/liveness args: - /server livenessProbe: httpGet: path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome initialDelaySeconds: 3 periodSeconds: 3
大於等於200且小於400的任何代碼表示成功。任何其他代碼表示失敗。在配置文件中，您可以看到Pod有一個容器。該periodSeconds字段指定kubelet應每3秒執行一次活動探測。該initialDelaySeconds字段告訴kubelet它應該在執行第一個探測之前等待3秒鍾。要執行探測，kubelet向在容器中運行的服務器發送HTTP GET請求，並偵聽端口8080.如果服務器/healthz路徑的處理程序返回成功代碼，則kubelet會將Container置於活動狀態。如果處理程序返回失敗代碼，則kubelet會殺死Container並重新啟動它。
您可以在server.go中看到服務器的源代碼 。
在容器存在的前10秒中，/healthz處理程序返回200的狀態。之后，處理程序返回500的狀態。
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { duration := time.Now().Sub(started) if duration.Seconds() > 10 { w.WriteHeader(500) w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds()))) } else { w.WriteHeader(200) w.Write([]byte("ok")) } })容器啟動后3秒鍾，kubelet開始執行運行狀況檢查。所以第一對健康檢查將會成功。但10秒鍾后，運行狀況檢查將失敗，並且kubelet將會殺死並重新啟動Container。
要嘗試HTTP活動檢查，請創建一個Pod：
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/http-liveness.yaml
10秒鍾后，查看Pod事件以驗證活動探測失敗，並重新啟動Container：
kubectl describe pod liveness-http
定義TCP活動探測器
第三種活躍探測器使用TCP Socket。使用此配置，kubelet將嘗試在指定端口上的容器上打開一個套接字。如果可以建立連接，容器被認為是健康的，如果它不能被認為是失敗。
tcp-liveness-readiness.yaml  |
|---|
|
如您所見，TCP檢查的配置與HTTP檢查非常相似。此示例使用准備和活動探測。容器啟動后5秒鍾，kubelet將發送第一個准備探測器。這將嘗試連接到goproxy端口8080上的容器。如果探針成功，則將將標簽准備好。kubelet將每10秒鍾繼續運行此檢查。
除了准備探測器之外，該配置還包括活動探測器。容器啟動15秒后，kubelet將運行第一個活動探測器。就像准備探測器一樣，這將嘗試連接到goproxy端口8080上的 容器。如果活動探測器失敗，容器將重新啟動。
使用命名端口
您可以使用命名的 ContainerPort 進行HTTP或TCP活動檢查：
ports: - name: liveness-port containerPort: 8080 hostPort: 8080 livenessProbe: httpGet: path: /healthz port: liveness-port 定義准備探測器
有時，應用程序暫時無法提供流量。例如，應用程序可能需要在啟動期間加載大數據或配置文件。在這種情況下，您不想殺死應用程序，但您也不想發送請求。Kubernetes提供了准備探測器來檢測和減輕這些情況。具有報告他們尚未准備好的容器的莢沒有通過Kubernetes服務接收流量。
准備探測器的配置類似於活性探針。唯一的區別是您使用readinessProbe字段而不是livenessProbe字段。
readinessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 HTTP和TCP准備探測器的配置也與活性探針保持一致。
准備和活力探針可以並行地用於同一個容器。使用兩者可以確保流量未到達未准備好的容器，並且容器在失敗時重新啟動。
配置探頭
探測器有許多領域可用於更准確地控制活動和准備度檢查的行為：
initialDelaySeconds：開始活動探測之前容器啟動后的秒數。periodSeconds：執行探針的頻率（以秒為單位）。默認為10秒。最小值為1。timeoutSeconds：探針超時后的秒數。默認為1秒。最小值為1。successThreshold：探針在失敗后被認為是成功的最小連續成功。默認為1.對於活躍性，必須為1。最小值為1。failureThreshold：當Pod啟動並且探測失敗時，Kubernetes將嘗試failureThreshold放棄重新啟動Pod之前的時間。默認為3.最小值為1。
HTTP探測器 具有可以設置的其他字段httpGet：
host：要連接的主機名，默認為莢IP。您可能希望在httpHeaders中設置“主機”。scheme：用於連接到主機的方案（HTTP或HTTPS）。默認為HTTP。path：訪問HTTP服務器的路徑。httpHeaders：在請求中設置的自定義標題。HTTP允許重復頭。port：容器上要訪問的端口的名稱或編號。數字必須在1到65535之間。
靜態令牌文件
APIserver配置文件添加--token-auth-file=SOMEFILE 在命令行上給出選項時從文件讀取承載令牌。目前，令牌無限期地持續下去，並且不重新啟動API服務器就不能更改令牌列表。
令牌文件是一個至少有3列的csv文件：令牌，用戶名，用戶uid，后跟可選的組名。請注意，如果您有多個組，則該列必須用雙引號括起來，例如
token,user,uid,"group1,group2,group3" 3754a2241da913441733649aa6d68571,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
在請求中放置無記名標記
當使用來自http客戶端的承載令牌認證時，API服務器需要Authorization一個值為的標頭Bearer THETOKEN。不記名令牌必須是一個字符序列，只需使用HTTP的編碼和引用功能就可以將其放入HTTP標頭值中。例如：如果不記名令牌 31ada4fd-adec-460c-809a-9e56ceb75269出現在HTTP標頭中，如下所示。
Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb7526
Bootstrap令牌
為了能夠簡化新群集的引導過程，Kubernetes包含一個名為Bootstrap令牌的動態管理的承載令牌類型。這些令牌作為秘密存儲在kube-system命名空間中，在那里可以動態管理和創建它們。控制器管理器包含一個TokenCleaner控制器，用於在引導令牌過期時刪除引導令牌。
代幣是這種形式的[a-z0-9]{6}.[a-z0-9]{16}。第一個組件是一個令牌ID，第二個組件是令牌密鑰。您在HTTP標頭中指定標記，如下所示：
Authorization: Bearer 781292.db7bc3a58fc5f07e 您必須使用--experimental-bootstrap-token-authAPI服務器上的標志啟用引導令牌認證器 。您必須通過--controllers控制器管理器上的標志啟用TokenCleaner控制器。這是用類似的東西來完成的--controllers=*,tokencleaner。 kubeadm會為你做這個，如果你正在使用它來引導群集。
認證者認證為system:bootstrap:<Token ID>。它包含在system:bootstrappers組中。命名和組有意限制用戶阻止過去使用這些令牌進行引導。用戶名和組可以被使用（並被使用kubeadm）來制定適當的授權策略以支持引導群集
使用 kubeconfig 文件配置跨集群認證
Kubernetes 的認證方式對於不同的人來說可能有所不同。
- 運行 kubelet 可能有一種認證方式（即證書）。
- 用戶可能有不同的認證方式（即令牌）。
- 管理員可能具有他們為個人用戶提供的證書列表。
- 我們可能有多個集群，並希望在同一個地方將其全部定義——這樣用戶就能使用自己的證書並重用相同的全局配置。
所以為了能夠讓用戶輕松地在多個集群之間切換，對於多個用戶的情況下，我們將其定義在了一個 kubeconfig 文件中。
此文件包含一系列與昵稱相關聯的身份驗證機制和集群連接信息。它還引入了一個（用戶）認證信息元組和一個被稱為上下文的與昵稱相關聯的集群連接信息的概念。
如果明確指定，則允許使用多個 kubeconfig 文件。在運行時，它們與命令行中指定的覆蓋選項一起加載並合並（參見下面的 規則）。