黄色在线网站,韩国的毛片,免费av网站,人人妻人人澡人人爽人人D,免费看黄A级毛片成人片,大香蕉精品在线视频,私蜜免费啪啪视频,三级a片在线观看

截止目前 Kubernetes 1.18，Kubernetes 已經(jīng)支持標(biāo)準(zhǔn)容器，Sidecar 容器，Init 容器，Ephemeral 容器 4 種類(lèi)型的 Containers。本文我們?cè)敿?xì)介紹一下這 4 種容器的特性以及使用場(chǎng)景。

1標(biāo)準(zhǔn)容器和 Sidecar 容器

在 Kubernetes 1.18 之前，這兩種容器從 Kubernetes 管理的角度來(lái)看，并沒(méi)有什么區(qū)別。只不過(guò)人為從功能上做了區(qū)分。

使用 Sidecar 容器（模塊化）具有的優(yōu)點(diǎn)

加速應(yīng)用程序開(kāi)發(fā)，因?yàn)槿萜骺梢栽趫F(tuán)隊(duì)甚至更大的社區(qū)之間重復(fù)使用
整理專(zhuān)家知識(shí)，因?yàn)槊總€(gè)人都在一個(gè)容器化的實(shí)現(xiàn)上進(jìn)行協(xié)作，該實(shí)現(xiàn)反映了最佳實(shí)踐，而不是無(wú)數(shù)種功能大致相同的自家生產(chǎn)的不同容器
啟用敏捷團(tuán)隊(duì)，因?yàn)槿萜鬟吔缡亲匀贿吔纾菆F(tuán)隊(duì)職責(zé)的契約
提供關(guān)注點(diǎn)分離，并專(zhuān)注于特定功能，以減少意大利面條的依賴(lài)性和不可測(cè)的組件

對(duì)于 Sidecar 容器一般來(lái)說(shuō)主要體現(xiàn)在以下 4 種角色：

代理

例如現(xiàn)在 Istio 中的 Envoy。

通過(guò)這種 Sidercar 模式，代理可以攔截進(jìn)出主容器的流量從而 Istio 可以提取有關(guān)流量行為的大量信號(hào)作為屬性。Istio 可以使用這些屬性來(lái)執(zhí)行策略決策，并將其發(fā)送到監(jiān)視系統(tǒng)以提供有關(guān)整個(gè)網(wǎng)格行為的信息。

Sidecar 代理模型還允許您將 Istio 功能添加到現(xiàn)有部署中，而無(wú)需重新構(gòu)造或重寫(xiě)代碼。

適配器

適配器容器對(duì)輸出進(jìn)行標(biāo)準(zhǔn)化。考慮監(jiān)視 N 個(gè)不同應(yīng)用程序的任務(wù)。可以使用不同的導(dǎo)出監(jiān)視數(shù)據(jù)的方式來(lái)構(gòu)建每個(gè)應(yīng)用程序。（例如 JMX，StatsD，特定于應(yīng)用程序的統(tǒng)計(jì)信息），但每個(gè)監(jiān)控系統(tǒng)都希望其收集的監(jiān)控?cái)?shù)據(jù)具有一致且統(tǒng)一的數(shù)據(jù)模型。

通過(guò)使用復(fù)合容器的適配器模式，您可以通過(guò)創(chuàng)建 Pod 來(lái)將來(lái)自不同系統(tǒng)的異構(gòu)監(jiān)視數(shù)據(jù)轉(zhuǎn)換為一個(gè)統(tǒng)一的表示形式，該 Pod 將應(yīng)用程序容器與知道如何進(jìn)行轉(zhuǎn)換的適配器分組在一起。同樣，由于這些 Pod 共享名稱(chēng)空間和文件系統(tǒng)，因此這兩個(gè)容器的協(xié)調(diào)非常簡(jiǎn)單明了。

增強(qiáng)主容器功能

Sidecar 容器擴(kuò)展并增強(qiáng)了 “主” 容器，它們可以使用現(xiàn)有的容器并使它們變得更好。

例如，考慮一個(gè)運(yùn)行 Nginx Web 服務(wù)器的容器。添加另一個(gè)將文件系統(tǒng)與 Git 存儲(chǔ)庫(kù)同步的容器，在這些容器之間共享文件系統(tǒng)，并且您已經(jīng)構(gòu)建了 Git Push-to-deploy。但是您已經(jīng)以模塊化的方式完成了此工作，其中 Git 同步器可以由不同的團(tuán)隊(duì)構(gòu)建，并且可以在許多不同的Web服務(wù)器（Apache，Python，Tomcat等）上重復(fù)使用。

由于這種模塊化，您只需編寫(xiě)和測(cè)試 Git 同步器一次，即可在眾多應(yīng)用程序中重復(fù)使用它。而且，如果有人編寫(xiě)它，您甚至不需要這樣做。

實(shí)現(xiàn)輔助功能

這種場(chǎng)景一般出現(xiàn)在 DevOps 中。比如將收集日志的組件以 Sidecar 的方式部署，實(shí)現(xiàn)收集日志的用途，或是部署一個(gè) Sidecar 組件從配置中心監(jiān)聽(tīng)配置變化，實(shí)時(shí)更新本地配置。

生命周期

Sidecar 容器的所有問(wèn)題都與容器生命周期相關(guān)性有關(guān)。由于和 Pod 中的常規(guī)容器之間沒(méi)有區(qū)別，因此無(wú)法控制哪個(gè)容器首先啟動(dòng)或最后終止，但是先正確運(yùn)行 Sidecar 容器通常是應(yīng)用程序容器正確運(yùn)行的要求。

從 1.18 版本開(kāi)始，K8S 內(nèi)置的 Sidecar 功能將確保 Sidecar 容器在正常業(yè)務(wù)流程開(kāi)始之前就啟動(dòng)并運(yùn)行，即通過(guò)更改 Pod 的啟動(dòng)生命周期，在 Init 容器完成后啟動(dòng) Sidecar 容器，在 Sidecar 容器就緒后啟動(dòng)業(yè)務(wù)容器，從啟動(dòng)流程上保證順序性。

通過(guò)更改 Pod 規(guī)范中的 container.lifecycle.type 將容器標(biāo)記為 Sidecar 類(lèi)型：Sidecar，默認(rèn)為 Standard，如下：

apiVersion: v1
kind: Pod
metadata:
  name: bookings-v1-b54bc7c9c-v42f6
  labels:
    app: demoapp
spec:
  containers:
  - name: bookings
    image: banzaicloud/allspark:0.1.1
    ...
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.4.3
    lifecycle:
      type: Sidecar
    ...

2Init 容器

在 Kubernetes 中，Init 容器是在同一 Pod 中的其他容器之前開(kāi)始并執(zhí)行的容器。它旨在為 Pod 上托管的主應(yīng)用程序執(zhí)行初始化邏輯。例如，創(chuàng)建必要的用戶(hù)帳戶(hù)，執(zhí)行數(shù)據(jù)庫(kù)遷移，創(chuàng)建數(shù)據(jù)庫(kù)結(jié)構(gòu)等。

Init 容器與普通的容器非常像，除了如下兩點(diǎn)：

它們總是運(yùn)行到完成。
每個(gè)都必須在下一個(gè)啟動(dòng)之前成功完成。

與普通容器的不同之處

Init 容器支持應(yīng)用容器的全部字段和特性，包括資源限制、數(shù)據(jù)卷和安全設(shè)置。然而，Init 容器對(duì)資源請(qǐng)求和限制的處理稍有不同。
同時(shí) Init 容器不支持 Readiness Probe，因?yàn)樗鼈儽仨氃?Pod 就緒之前運(yùn)行完成。
如果為一個(gè) Pod 指定了多個(gè) Init 容器，這些容器會(huì)按順序逐個(gè)運(yùn)行。每個(gè) Init 容器必須運(yùn)行成功，下一個(gè)才能夠運(yùn)行。當(dāng)所有的 Init 容器運(yùn)行完成時(shí)，Kubernetes 才會(huì)為 Pod 初始化應(yīng)用容器并像平常一樣運(yùn)行。

Init 容器作用

因?yàn)?Init 容器具有與應(yīng)用容器分離的單獨(dú)鏡像，其啟動(dòng)相關(guān)代碼具有如下優(yōu)勢(shì)：

Init 容器可以包含一些安裝過(guò)程中應(yīng)用容器中不存在的實(shí)用工具或個(gè)性化代碼。例如，沒(méi)有必要僅為了在安裝過(guò)程中使用類(lèi)似 sed、 awk、 python 或 dig 這樣的工具而去FROM 一個(gè)鏡像來(lái)生成一個(gè)新的鏡像。
Init 容器可以安全地運(yùn)行這些工具，避免這些工具導(dǎo)致應(yīng)用鏡像的安全性降低。
應(yīng)用鏡像的創(chuàng)建者和部署者可以各自獨(dú)立工作，而沒(méi)有必要聯(lián)合構(gòu)建一個(gè)單獨(dú)的應(yīng)用鏡像。
Init 容器能以不同于Pod內(nèi)應(yīng)用容器的文件系統(tǒng)視圖運(yùn)行。因此，Init容器可具有訪(fǎng)問(wèn) Secrets 的權(quán)限，而應(yīng)用容器不能夠訪(fǎng)問(wèn)。
由于 Init 容器必須在應(yīng)用容器啟動(dòng)之前運(yùn)行完成，因此 Init 容器提供了一種機(jī)制來(lái)阻塞或延遲應(yīng)用容器的啟動(dòng)，直到滿(mǎn)足了一組先決條件。一旦前置條件滿(mǎn)足，Pod內(nèi)的所有的應(yīng)用容器會(huì)并行啟動(dòng)。

創(chuàng)建 InitContainer 時(shí)應(yīng)考慮一些注意事項(xiàng)：

它們總是在 Pod 中的其他容器之前執(zhí)行。因此，它們不應(yīng)包含需要很長(zhǎng)時(shí)間才能完成的復(fù)雜邏輯。啟動(dòng)腳本通常很小而簡(jiǎn)潔。如果發(fā)現(xiàn)要向初始化容器添加太多邏輯，則應(yīng)考慮將其中的一部分移至應(yīng)用程序容器本身。
初始化容器按順序啟動(dòng)和執(zhí)行。除非一個(gè)初始化容器被成功執(zhí)行，否則下一個(gè)初始化容器不會(huì)被開(kāi)始執(zhí)行。因此，如果啟動(dòng)任務(wù)很長(zhǎng)，則可以考慮將其分為多個(gè)步驟，每個(gè)步驟都由一個(gè)初始化容器處理，以便您知道哪些步驟失敗。
如果任何初始化容器失敗，則將重新啟動(dòng)整個(gè) Pod（除非您將 restartPolicy 設(shè)置為 Never）。重新啟動(dòng) Pod 意味著再次重新執(zhí)行所有容器，包括任何初始化容器。因此，您可能需要確保啟動(dòng)邏輯允許多次執(zhí)行而不會(huì)導(dǎo)致重復(fù)。例如，如果數(shù)據(jù)庫(kù)遷移已經(jīng)完成，則應(yīng)僅忽略再次執(zhí)行遷移命令。
初始化容器是延遲應(yīng)用程序初始化直到一個(gè)或多個(gè)依賴(lài)項(xiàng)可用的很好的選擇。例如，如果您的應(yīng)用程序依賴(lài)于施加API請(qǐng)求速率限制的 API，則您可能需要等待一段時(shí)間才能接收來(lái)自該 API 的響應(yīng)。在應(yīng)用程序容器中實(shí)現(xiàn)此邏輯可能很復(fù)雜；因?yàn)樗枰c健康和就緒狀態(tài)探測(cè)器結(jié)合使用。一種更簡(jiǎn)單的方法是創(chuàng)建一個(gè)初始化容器，該容器要等到API準(zhǔn)備好后才能成功退出。只有在初始化容器成功完成其工作之后，應(yīng)用程序容器才會(huì)啟動(dòng)。
初始化容器不能像應(yīng)用程序容器那樣使用運(yùn)行狀況和就緒探針。原因是它們要成功啟動(dòng)和退出，就像 Jobs 和 CronJobs 的行為一樣。
同一Pod 上的所有容器共享相同的卷和網(wǎng)絡(luò)。您可以利用此功能在應(yīng)用程序及其初始化容器之間共享數(shù)據(jù)。

正如我們剛剛討論的那樣，Init 容器總是比同一個(gè) Pod 上的其他應(yīng)用程序容器先啟動(dòng)。結(jié)果，調(diào)度程序?qū)?Init 容器的資源和限制賦予了更高的優(yōu)先級(jí)。必須仔細(xì)考慮這種行為，因?yàn)檫@可能會(huì)導(dǎo)致不良后果。例如，如果您有一個(gè)初始化容器和一個(gè)應(yīng)用程序容器，并且將初始化容器的資源和限制設(shè)置為高于應(yīng)用程序容器的資源和限制，那么只有在有一個(gè)可用節(jié)點(diǎn)滿(mǎn)足初始化的情況下，才調(diào)度整個(gè) Pod 容器要求。換句話(huà)說(shuō)，即使有一個(gè)未使用的節(jié)點(diǎn)可以在其中運(yùn)行應(yīng)用程序容器，但如果初始化容器具有該節(jié)點(diǎn)可以處理的更高資源先決條件，則 Pod 也不會(huì)部署到該節(jié)點(diǎn)。因此，在定義初始化容器的請(qǐng)求和限制時(shí)，您應(yīng)盡可能?chē)?yán)格。最佳做法是，除非絕對(duì)必要，否則請(qǐng)勿將這些參數(shù)設(shè)置為高于應(yīng)用程序容器的值。

使用 Init 容器

下面的例子定義了一個(gè)具有 2 個(gè) Init 容器的簡(jiǎn)單 Pod。第一個(gè)等待 myservice 啟動(dòng)，第二個(gè)等待 mydb 啟動(dòng)。一旦這兩個(gè) Init容器都啟動(dòng)完成，Pod 將啟動(dòng) spec 區(qū)域中的應(yīng)用容器。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

這是 Kubernetes 1.6 版本的新語(yǔ)法，盡管老的 annotation 語(yǔ)法仍然可以使用。我們已經(jīng)把 Init 容器的聲明移到 spec 中：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

1.5 版本的語(yǔ)法在 1.6 版本仍然可以使用，但是我們推薦使用 1.6 版本的新語(yǔ)法。在 Kubernetes 1.6 版本中，Init 容器在 API 中新建了一個(gè)字段。雖然期望使用 beta 版本的 annotation，但在未來(lái)發(fā)行版將會(huì)被廢棄掉。

在所有的 Init 容器沒(méi)有成功之前，Pod 將不會(huì)變成 Ready 狀態(tài)。Init 容器的端口將不會(huì)在 Service 中進(jìn)行聚集。正在初始化中的 Pod 處于 Pending 狀態(tài)，但應(yīng)該會(huì)將條件 Initializing 設(shè)置為 true。

如果 Pod 重啟，所有 Init 容器必須重新執(zhí)行。

對(duì) Init 容器 spec 的修改，被限制在容器 image 字段中。更改 Init 容器的 image 字段，等價(jià)于重啟該 Pod。

Ephemeral 容器

臨時(shí)容器與其他容器的不同之處在于，它們?nèi)鄙賹?duì)資源或執(zhí)行的保證，并且永遠(yuǎn)不會(huì)自動(dòng)重啟，因此不適用于構(gòu)建應(yīng)用程序。臨時(shí)容器使用與常規(guī)容器相同的 ContainerSpec 段進(jìn)行描述，但許多字段是不相容且不允許的。

臨時(shí)容器沒(méi)有端口配置，因此像 ports，livenessProbe，readinessProbe 這樣的字段是不允許的。
Pod 資源分配是不可變的，因此 resources 配置是不允許的。
有關(guān)允許字段的完整列表，請(qǐng)參見(jiàn)臨時(shí)容器參考文檔。

臨時(shí)容器是使用 API 中的一種特殊的 ephemeralcontainers 處理器進(jìn)行創(chuàng)建的，而不是直接添加到 pod.spec 段，因此無(wú)法使用 kubectl edit 來(lái)添加一個(gè)臨時(shí)容器。

與常規(guī)容器一樣，將臨時(shí)容器添加到 Pod 后，將不能更改或刪除臨時(shí)容器。

為什么我們需要 Ephemeral 容器？

我們知道容器的優(yōu)點(diǎn)是它們通過(guò)使用不變方法提供所有必需的依賴(lài)項(xiàng)來(lái)運(yùn)行隔離的進(jìn)程。通過(guò)僅將所需的依賴(lài)項(xiàng)添加到鏡像中，容器可以降低攻擊面并提供更快的啟動(dòng)和部署。使用 "distroless" 方法構(gòu)建容器鏡像（基于 Scratch ），通過(guò)僅包含已編譯的應(yīng)用程序二進(jìn)制文件，將容器鏡像提升到了一個(gè)新的水平。與普通的容器鏡像不同，它們不基于任何種類(lèi)的 Linux 發(fā)行版，因此不包含任何其他可通過(guò) kubectl exec 執(zhí)行以進(jìn)行故障排除的二進(jìn)制文件和工具。這就決定了該容器有助于提供安全可靠的運(yùn)行時(shí)環(huán)境，但也很難在問(wèn)題發(fā)生時(shí)進(jìn)行調(diào)試。

在這種情況下，臨時(shí)容器發(fā)揮作用。它們實(shí)現(xiàn)了調(diào)試容器附加到主進(jìn)程的功能，然后你可以用于調(diào)試任何類(lèi)型的問(wèn)題。調(diào)試容器可以基于任何鏡像，因此可以根據(jù)您的需求進(jìn)行定制。您可以構(gòu)建自己的調(diào)試鏡像，其中包含特殊的調(diào)試二進(jìn)制文件或僅包含 curl，OpenSSL 和 MongoDB客戶(hù)端之類(lèi)的工具。但是，您也可以選擇Linux發(fā)行版（如Ubuntu）或僅運(yùn)行Busybox鏡像，這兩個(gè)鏡像都已經(jīng)包含了許多有用的工具。

如何使用臨時(shí)容器？

臨時(shí)容器是alpha功能，因此默認(rèn)情況下處于禁用狀態(tài)。您將需要激活以下功能門(mén)才能使用它們：

臨時(shí)容器
PodShareProcessNamespace（v1.16中的beta版，因此默認(rèn)情況下已啟用）

本節(jié)中的示例演示了臨時(shí)容器如何出現(xiàn)在 API 中。通常，您可以使用 kubectl 插件進(jìn)行故障排查，從而自動(dòng)化執(zhí)行這些步驟。

臨時(shí)容器是使用 Pod 的 ephemeralcontainers 子資源創(chuàng)建的，可以使用 kubectl --raw 命令進(jìn)行顯示。首先描述臨時(shí)容器被添加為一個(gè) EphemeralContainers 列表：

{
    "apiVersion": "v1",
    "kind": "EphemeralContainers",
    "metadata": {
            "name": "example-pod"
    },
    "ephemeralContainers": [{
        "command": [
            "sh"
        ],
        "image": "busybox",
        "imagePullPolicy": "IfNotPresent",
        "name": "debugger",
        "stdin": true,
        "tty": true,
        "terminationMessagePolicy": "File"
    }]
}

使用如下命令更新已運(yùn)行的臨時(shí)容器 example-pod：

$ kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers  -f ec.json

這將返回臨時(shí)容器的新列表：

{
   "kind":"EphemeralContainers",
   "apiVersion":"v1",
   "metadata":{
      "name":"example-pod",
      "namespace":"default",
      "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
      "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
      "resourceVersion":"15886",
      "creationTimestamp":"2019-08-29T06:41:42Z"
   },
   "ephemeralContainers":[
      {
         "name":"debugger",
         "image":"busybox",
         "command":[
            "sh"
         ],
         "resources":{

         },
         "terminationMessagePolicy":"File",
         "imagePullPolicy":"IfNotPresent",
         "stdin":true,
         "tty":true
      }
   ]
}

可以使用以下命令查看新創(chuàng)建的臨時(shí)容器的狀態(tài)：

$ kubectl describe pod example-pod
...
Ephemeral Containers:
  debugger:
    Container ID:  docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
    State:          Running
      Started:      Thu, 29 Aug 2019 06:42:21 +0000
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:         <none>
...

可以使用以下命令連接到新的臨時(shí)容器：

$ kubectl attach -it example-pod -c debugger

如果啟用了進(jìn)程命名空間共享，則可以查看該 Pod 所有容器中的進(jìn)程。例如，運(yùn)行上述 attach 操作后，在調(diào)試器容器中運(yùn)行 ps 操作：

# 在 "debugger" 臨時(shí)容器內(nèi)中運(yùn)行此 shell 命令
$ ps auxww

運(yùn)行命令后，輸出類(lèi)似于：

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   11 101       0:00 nginx: worker process
   12 101       0:00 nginx: worker process
   13 101       0:00 nginx: worker process
   14 101       0:00 nginx: worker process
   15 101       0:00 nginx: worker process
   16 101       0:00 nginx: worker process
   17 101       0:00 nginx: worker process
   18 101       0:00 nginx: worker process
   19 root      0:00 /pause
   24 root      0:00 sh
   29 root      0:00 ps auxww

總結(jié)

本文簡(jiǎn)單介紹了標(biāo)準(zhǔn)容器，Sidecar 容器，Init 容器，Ephemeral 容器 4 種類(lèi)型的 Containers。隨著 Kubernetes 日益普及，我們需要充分掌握這幾種類(lèi)型容器原理和使用方法，才能更好地服務(wù)業(yè)務(wù)。

此外 Sidecar 容器將會(huì)成為未來(lái)軟件交付的一種新的方式，參照 Dapr 等，不同的團(tuán)隊(duì)提供自己的功能容器，然后選擇性注入 Sidecar 到主業(yè)務(wù)容器，實(shí)現(xiàn)解耦。