哈布羅居民大家好！ Kubernetes 是現代雲端生態系統的關鍵要素之一。 該技術為容器虛擬化提供了可靠性、可擴展性和彈性。 John Arundel 和 Justin Domingus 談論 Kubernetes 生態系統，並介紹針對日常問題的行之有效的解決方案。 您將逐步建立自己的雲端原生應用程式並建立支援它的基礎架構，設定開發環境和持續部署管道，這將在您開發下一個應用程式時為您提供協助。
• 從基礎開始使用容器和Kubernetes：學習主題不需要特殊經驗。 • 執行您自己的叢集或選擇來自Amazon、Google 等的託管 Kubernetes 服務。• 使用 Kubernetes 管理容器生命週期和資源消耗。 • 根據成本、效能、彈性、功率和可擴展性最佳化叢集。 • 了解開發、測試和部署應用程式的最佳工具。 • 利用目前的行業實務來確保安全和控制。 • 在整個公司實施DevOps 原則，以便開發團隊能更有彈性、快速、有效率地採取行動。
這本書是為誰而寫的？
本書最適合負責伺服器、應用程式和服務的管理部門的員工，以及參與建立新雲端服務或將現有應用程式遷移到 Kubernetes 和雲端的開發人員。 別擔心，您不需要知道如何使用 Kubernetes 或容器 - 我們會教您一切。
經驗豐富的 Kubernetes 用戶也會發現很多價值，其中深入介紹了 RBAC、持續部署、敏感資料管理和可觀察性等主題。 我們希望本書一定會包含您感興趣的內容，無論您的技能和經驗如何。
本書回答了哪些問題？
在規劃和撰寫這本書的過程中，我們與數百人討論了雲端技術和 Kubernetes，與行業領導者、專家以及完全的新手進行了交談。 以下是他們希望在本出版物中得到解答的精選問題。
- 「我感興趣的是為什麼你應該花時間研究這項技術。 它會幫助我和我的團隊解決什麼問題？”
- 「Kubernetes 看起來很有趣，但進入門檻相當高。 準備一個簡單的範例並不困難，但進一步的管理和調試卻令人畏懼。 我們希望獲得有關人們如何在現實世界中管理 Kubernetes 叢集以及我們可能會遇到哪些問題的可靠建議。”
- “主觀建議會很有幫助。 Kubernetes 生態系統為新團隊提供了太多選擇。 當有多種方法可以做同一件事時，您如何知道哪一種最好？ 如何做出選擇？
也許是所有問題中最重要的：
- “如何在不干擾我公司的情況下使用 Kubernetes？”
摘抄。 配置和秘密對象
將 Kubernetes 應用程式的邏輯與其配置（即與可能隨時間變化的任何值或設定）分開的能力非常有用。 配置值通常包括特定於環境的設定、第三方服務 DNS 位址和身份驗證憑證。
當然，這一切都可以直接放入程式碼中，但這種做法不夠靈活。 例如，更改配置值將需要您再次建置和部署程式碼。 更好的解決方案是將配置與程式碼分開，並從檔案或環境變數中讀取配置。
Kubernetes 提供了幾種不同的方式來管理設定。 首先，您可以透過 pod 包裝器規格中指定的環境變數向應用程式傳遞值（請參閱第 192 頁的「環境變數」）。 其次，設定資料可以使用 ConfigMap 和 Secret 物件直接儲存在 Kubernetes 中。
在本章中，我們將詳細探討這些對象，並研究使用示範應用程式管理配置和敏感資料的一些實用方法。
配置更改時更新 pod shell
假設您的叢集中有一個部署，並且您想要更改其 ConfigMap 中的一些值。 如果您使用 Helm 圖表（請參閱第 102 頁的「Helm：Kubernetes 的套件管理器」），您可以透過一個巧妙的技巧自動偵測設定變更並重新載入 pod shell。 將以下註解新增到您的部署規範中：
checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") .
| sha256sum }}部署範本現在包含配置參數的校驗和：如果參數發生更改，總和將更新。 如果執行 helm Upgrade，Helm 將偵測到部署規格已更改，並將重新啟動所有 pod shell。
Kubernetes 中的敏感數據
我們已經知道，ConfigMap 物件提供了一種靈活的機制來儲存和存取叢集中的配置資料。 然而，大多數應用程式都具有敏感且敏感的訊息，例如密碼或API金鑰。 也可以儲存在ConfigMap中，但這種方案並不理想。
相反，Kubernetes 提供了一種特殊類型的對象，旨在儲存敏感資料：Secret。 接下來，讓我們看一個範例，了解如何在我們的演示應用程式中使用該物件。
首先，請參閱 Secret 物件的 Kubernetes 清單（請參閱 hello-secret-env/k8s/secret.yaml）：
apiVersion: v1
kind: Secret
metadata:
name: demo-secret
stringData:
magicWord: xyzzy
在此範例中，magicWord 私鑰是 xyzzy (en.wikipedia.org/wiki/Xyzzy_(computing))。 xyzzy 這個字在電腦領域通常非常有用。 與ConfigMap類似，你可以在一個Secret物件中儲存多個鍵和值。 這裡，為了簡單起見，我們只使用一個鍵值對。
使用秘密物件作為環境變量
與 ConfigMap 一樣，Secret 物件可以在容器中作為環境變數或磁碟上的檔案提供。 在以下範例中，我們將為 Secret 中的值指派一個環境變數：
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-env
ports:
- containerPort: 8888
env:
- name: GREETING
valueFrom:
secretKeyRef:
name: demo-secret
key: magicWord在演示存儲庫中運行以下命令以應用清單：
kubectl apply -f hello-secret-env/k8s/
deployment.extensions "demo" configured
secret "demo-secret" created與之前一樣，將本機連接埠轉送至部署以在瀏覽器中查看結果：
kubectl port-forward deploy/demo 9999:8888
Forwarding from 127.0.0.1:9999 -> 8888
Forwarding from [::1]:9999 -> 8888打開地址時 :9999/ 您應該看到以下內容：
The magic word is "xyzzy"
將秘密物件寫入文件
在此範例中，我們將 Secret 物件作為文件附加到容器。 程式碼位於演示儲存庫的 hello-secret-file 資料夾中。
要將 Secret 連接為文件，我們將使用以下部署：
spec:
containers:
- name: demo
image: cloudnatived/demo:hello-secret-file
ports:
- containerPort: 8888
volumeMounts:
- name: demo-secret-volume
mountPath: "/secrets/"
readOnly: true
volumes:
- name: demo-secret-volume
secret:
secretName: demo-secret如第 240 頁「從 ConfigMap 物件建立設定檔」小節所述。 XNUMX，我們建立一個磁碟區（在本例中為 demo-secret-volume）並將其安裝到規範的volumeMounts 部分中的容器中。 mountPath 欄位為 /secrets，因此 Kubernetes 會在此資料夾中為 Secret 物件中定義的每個鍵/值對建立一個檔案。
在我們的範例中，我們僅定義了一個名為 magicWord 的鍵值對，因此清單將在容器中建立一個包含敏感資料的唯讀檔案 /secrets/magicWord。
如果您以與前面的範例相同的方式應用此清單，您應該得到相同的結果：
The magic word is "xyzzy"
讀取秘密對象
在上一節中，我們使用 kubectl describe 指令來顯示 ConfigMap 的內容。 Secret 也可以做同樣的事情嗎？
kubectl describe secret/demo-secret
Name: demo-secret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
magicWord: 5 bytes請注意，數據本身不會顯示。 Kubernetes 中的秘密物件是不透明類型的，這表示它們的內容不會顯示在 kubectl 描述輸出、日誌條目或終端機中，因此不可能意外洩漏敏感資訊。
若要查看敏感資料的編碼 YAML 版本，請使用 kubectl get 指令：
kubectl get secret/demo-secret -o yaml
apiVersion: v1
data:
magicWord: eHl6enk=
kind: Secret
metadata:
...
type: Opaquebase64
eHl6enk=是什麼，跟我們原來的值完全不一樣？ 這實際上是一個 Secret 對象，以 base64 編碼表示。 Base64 是將任意二進位資料編碼為字串的方案。
由於敏感資訊可能是二進位的且不會輸出（與 TLS 加密金鑰的情況相同），因此 Secret 物件始終以 base64 格式儲存。
文本 beHl6enk= 是我們的秘密單字 xyzzy 的 Base64 編碼版本。 您可以透過在終端機中執行 base64 —decode 命令來驗證這一點：
echo "eHl6enk=" | base64 --decode
xyzzy因此，雖然 Kubernetes 可以防止您在終端機或日誌檔案中意外輸出敏感數據，但如果您對特定命名空間中的 Secret 物件具有讀取權限，則可以對該資料進行 Base64 編碼並隨後進行解碼。
如果您需要對某些文字進行 Base64 編碼（例如，將其放入 Secret 中），請使用不含參數的 base64 指令：
echo xyzzy | base64
eHl6enkK訪問秘密對象
誰可以讀取和編輯 Secret 物件？ 這是由 RBAC（一種存取控制機制）決定的（我們將在第 258 頁的「基於角色的存取控制簡介」小節中詳細討論）。 如果您執行的叢集沒有 RBAC 或未啟用，則所有 Secret 物件都可供任何使用者和容器使用（我們稍後將解釋您不應該擁有任何沒有 RBAC 的生產叢集）。
被動資料加密
那些有權存取 Kubernetes 儲存所有資訊的 etcd 資料庫的人呢？ 他們可以在沒有透過 API 讀取 Secret 物件的權限的情況下讀取敏感資料嗎？
從1.7版本開始，Kubernetes支援被動資料加密。 這意味著 etcd 內的敏感資訊被加密儲存在磁碟上，即使是直接存取資料庫的人也無法讀取。 要解密它，您需要一個只有 Kubernetes API 伺服器擁有的金鑰。 在正確配置的叢集中，應啟用被動加密。
您可以透過以下方式檢查被動加密在叢集中是否有效：
kubectl describe pod -n kube-system -l component=kube-apiserver |grep encryption
--experimental-encryption-provider-config=...如果您沒有看到experimental-encryption-provider-config 標誌，表示未啟用被動加密。 當使用 Google Kubernetes Engine 或其他 Kubernetes 管理服務時，您的資料會使用不同的機制進行加密，因此該標誌不會出現。 請諮詢您的 Kubernetes 供應商，以了解 etcd 內容是否已加密。
儲存機密數據
有一些 Kubernetes 資源永遠不應該從叢集中刪除，例如高度敏感的 Secret 物件。 您可以使用 Helm 管理器提供的註解來保護資源不被刪除：
kind: Secret
metadata:
annotations:
"helm.sh/resource-policy": keep秘密對像管理策略
在上一節的範例中，敏感資料在儲存到叢集後立即受到保護，免受未經授權的存取。 但在清單檔案中，它們以純文字形式儲存。
切勿將機密資訊放入版本控制的文件中。 在將這些資訊應用到 Kubernetes 叢集之前，如何安全地管理和儲存這些資訊？
您可以選擇任何工具或策略來處理應用程式中的敏感數據，但您仍然需要至少回答以下問題。
- 敏感資料應儲存在哪裡以便易於存取？
- 如何讓您的活動應用程式可以存取敏感資料？
- 當您替換或編輯敏感資料時，您的應用程式會發生什麼情況？
關於作者
約翰·阿倫德爾 是一位在電腦產業擁有 30 年經驗的顧問。 他寫了幾本書，並與來自不同國家的許多公司合作，為他們提供有關雲端原生基礎設施和 Kubernetes 的建議。 在空閒時間，他喜歡衝浪，是一名出色的手槍射擊手，並且業餘彈鋼琴。 住在英國康沃爾郡的童話小屋。
賈斯汀·多明格斯 — 在使用 Kubernetes 和雲端技術的 DevOps 環境中工作的系統管理工程師。 他喜歡在戶外度過時光、喝咖啡、吃螃蟹和坐在電腦前。 住在華盛頓州西雅圖，有一隻很棒的貓，還有一個更棒的妻子和最好的朋友艾德麗安。
» 有關本書的更多詳細信息，請訪問
»
»
對於 Khabrozhiteley 使用優惠券可享 25% 折扣 - Kubernetes
支付紙本書籍的費用後，將透過電子郵件發送電子書。
來源： www.habr.com