本文講的是容器、Docker與Kubernetes——Kubernetes的配置入門【編者的話】這是介紹Kubernetes的第三篇，主要集中講述如何配置Kubernetes集群以及作者在配置過程中遇到的問題。

【3 天燒腦式容器存儲網(wǎng)絡(luò)訓(xùn)練營 | 深圳站】本次培訓(xùn)以容器存儲和網(wǎng)絡(luò)為主題，包括：Docker Plugin、Docker storage driver、Docker Volume Pulgin、Kubernetes Storage機制、容器網(wǎng)絡(luò)實現(xiàn)原理和模型、Docker網(wǎng)絡(luò)實現(xiàn)、網(wǎng)絡(luò)插件、Calico、Contiv Netplugin、開源企業(yè)級鏡像倉庫Harbor原理及實現(xiàn)等。

在本系列文章的第一部分中，我們探討了容器、Docker以及這些技術(shù)如何重新定義行業(yè)中的基礎(chǔ)設(shè)施及其運營方式。第二部分文章則繼續(xù)討論，著眼點放在Kubernetes身上——包括Kubernetes是什么以及擁有哪些能力。在今天的第三部分文章中，我將進一步闡述如何上手Kubernetes，同時提供與結(jié)構(gòu)設(shè)計相關(guān)的一點參考意見。

命令（Command）

Kubernetes的集群管理是通過kubectl命令進行的，如果你使用Google Cloud，則會在SDK中自動安裝kubectl命令行工具。雖然你可以完全使用這個命令行工具來配置、控制Kubernetes集群，但是我還是十分推薦你使用單獨的配置文件來配置集群，因為你可以使用版本控制工具來追蹤每次對集群配置的修改而且保證配置的統(tǒng)一，后面會著重介紹如何去做。

kubectl命令集合包含了非常多的子命令來幫助你控制Kubernetes集群的方方面面，如窺探當前集群的工作狀態(tài)等等。下面是我覺得非常常用的幾個命令，并將其分類說明。

管理類（Management）

kubectl?apply?-f?service-file.yml
apply命令會收集配置文件（service-file.yml）中所有的配置項信息，并自動將配置文件中的配置項跟當前集群的運行配置做對比，然后自動將必要的更新應(yīng)用到當前集群中。
kubectl?rollout
所有通過apply命令觸發(fā)的指令都會生成一個新的Rollout對象。通過使用kubectl rollout status命令可以查看最近的更新狀態(tài)、終止一個rollout或者回滾到上一個資源對象（Deployment，Pod，Service等）的版本。

窺探類（Introspection）

kubectl?describe?[pod,service,...]?[resource]
這條命令可以查看某個資源的詳細信息，當錯誤發(fā)生的時候你必須首選考慮使用describe命令來獲取錯誤描述信息。
kubectl?logs?[resource]
Kubernetes內(nèi)的容器會傾向于把所有的日志定向到STDOUT上，kubectl logs -f命令能讓你獲取一個資源（Pod/Container）最新的日志。
kubectl?get?[pods,deployments,services,...]
這條命令會將Kubernetes默認命名空間中運行的資源信息打印出來，如果要看特定命名空間的資源信息，則必須加上--namespace=[my namespace]參數(shù)，如果查看所有命名空間的資源信息，則使用--all-namespace參數(shù)。
kubectl?exec
這條命令是對docker exec命令的包裝，可以讓你執(zhí)行容器內(nèi)部的命令，如果pod中只有一個容器在運行則此命令可以作用在pod上如：kubectl exec -it [pod] /bin/bash。我們可以使用kubectl exec -it [pod name] --/bin/bash來進入一個運行中的pod，-i用來啟動標準輸入流STDIN，-t將輸入流定向到TTY（偽終端）中，這樣就能模擬終端的bash命令操作了。當然如果一個Pod中啟動了多個容器，你可以使用-C[container-name]參數(shù)來進入特定的容器中。

部署新鏡像

當前還沒有命令能夠讓一個Deployment自動將配置的Pod下的容器更新到最新的版本；但是為Kubernetes集群更新容器版本又是一個非常常見的操作，這時你就必須想清楚更新容器的步驟了，我列出以下幾種方法：

• 將新的容器打上:latest的Tag，然后手動刪除運行中的Pod，然后Deployment會自動用最新的容器重新啟動Pod；
• 更新服務(wù)的配置文件（Deployment yaml），讓容器指向指向最新的container label，比如：redis-cache:9c713a，然后重新apply這個配置文件到Kubernetes的集群中，這種方式需要對配置文件進行版本控制；
• 手動更新Deployment下Pod的鏡像版本：kubectl set image deployment/[service name] *=[new image]。

我需要的方案是即能夠在Kubernetes中留下更改歷史，也不想因為老是去提交配置文件的更改導(dǎo)致陷入版本混亂的泥沼。所以，我個人選擇第三種方案，我是這么操作的：

• 所有Pod template的image都指向容器的:latest?tag；
• 新的容器被Push到注冊中心時除了打上:latest?tag以外還要打上與代碼git倉庫HEAD指針指向的Commit號相同的tag（如:9c713a）；
• 運行kubectl set image deployment/[service name] *=[new image]?時填入git commit hash號標識的鏡像。

根據(jù)以上幾點，我可以獲得一些好處：

用set image?命令來更新Pods的鏡像非常的優(yōu)雅，因為可以使用kubectl rollout status來跟蹤所有Deployment的Pods的更新狀態(tài)；

當Pod因為某些原因被殺掉或者新的Pod上線，都會確保運行擁有最新代碼的鏡像；

我可以在minikube中使用跟Kubernetes集群中相同的docker registry而不用擔心會影響到生產(chǎn)環(huán)境的Pods；我一直到上線前都不會使用:latest?tag的鏡像（注：在測試環(huán)境或者非生產(chǎn)環(huán)境使用git commit hash號來啟動容器，但是在生產(chǎn)時使用:latest，因為作者在push鏡像時同時打了兩個tag）。

搭建本地開發(fā)環(huán)境

Kubernetes開發(fā)人員不僅提供了相當全面的文檔可以參考，而且提供了minikube這個可以讓開發(fā)者在本地環(huán)境運行Kubernetes集群的工具。minikube可以運行在多種不同的虛擬化環(huán)境下，它可以很容易的啟動一個全功能的，包含一個單一節(jié)點的Kubernetes集群。當集群啟動后，minikube提供了多種命令來訪問與窺探集群運行情況，同時kubectl工具也是自動為minikube配置好的。最常用的命令莫過于：
minikube?service?[service?name]?--url
這條命令能夠打印出本地集群中配好的Service的訪問url地址。
minikube?dashboard
這會跳轉(zhuǎn)到一個web-based的集群看板頁面，幫助你通過可視化的方式了解集群運行的狀況。

同時我建議將運行minikube的默認的VM配置加高一點，比如配置：4CPUs與8GB內(nèi)存，使用VMWare Fusion作為VM容器，例如可以使用如下命令：
minikube?config?set?cpus?4 minikube?config?set?memory?8192 minikube?start?--vm-driver?vmwarefusion
如果要讓kubectl退出對minikube的訪問，必須重新配置kubectl讓它連接到新的集群；如下命令：
kubectl?config?get-contexts kubectl?config?use-context?[cluster?context?name?from?above]?
當然，如果要重新連接到本地的minikube，只需要使用這條命令：kubectl?config?use-context?minikube

Service的配置

Service的配置文件支持JSON與YAML，但是我推薦使用YAML，因為它比較容易讀寫，而且支持注釋，這對那些復(fù)雜的結(jié)構(gòu)非常管用。

對于集群的配置，Service往往是最先配置的，這就是所謂的Service-first配置法。具體的做法是，為每個要創(chuàng)建的服務(wù)分配一個單獨的文件夾，這個文件夾中包含了所有啟動這個服務(wù)的配置文件。為了搜索方面，我建議為每個Kubernetes的Service資源創(chuàng)建一個yaml配置文件，可以這樣命名：[service name]-k8s.yml，這個配置文件中寫入所有這個Service在Kubernetes環(huán)境啟動的配置項。

如下是我配置一個Redis緩存服務(wù)的目錄結(jié)構(gòu)：
services/ redis-cache/Dockerfileredis.confredis-cache-k8s.yml
以下是服務(wù)配置文件redis-cache-k8s.yml：
apiVersion:?v1 kind:?Service metadata: name:?redis-cache labels: role:?cache spec: type:?NodePort ports: -?port:?6379 targetPort:?6379 selector: role:?cache--- apiVersion:?extensions/v1beta1 kind:?Deployment metadata: name:?redis-cache spec: #?https://github.com/kubernetes/kubernetes/issues/23597 revisionHistoryLimit:?3 replicas:?1 template: metadata:labels:role:?cache spec:containers:-?name:?redisimage:?redis:3resources:requests:cpu:?100mmemory:?1Giports:-?containerPort:?6379
然后通過運行apply -f service/redis-cache/redis-cache-k8s.yml?命令就能讓redis-cache服務(wù)在整個Deployment中跑起來。

容器與注冊中心

如何為容器打Tag

我現(xiàn)在為每個容器都打兩個tag分別是：:latest與對應(yīng)代碼git庫中的HEAD指針Commit的hash值如：:9c713a。很多人強烈推薦不要使用:latest?tag，原因在這里（注：內(nèi)容大概講docker registry并不會主動判斷一個鏡像是否是最新的，而是可以人為的隨意為一個老的鏡像打上latest tag的，所以很多人認為latest標簽的鏡像其實并不一定是最新的），但是我覺得這些都是講給那些只用latest標簽的人聽的。我為什么這么做的原因在上面“部署新鏡像”一節(jié)已經(jīng)闡述。

確保Minikube能訪問GKE的Registry

我早期使用minikube遇到的問題是如何讓我的Pod有權(quán)限從我的Google私有鏡像倉庫中拉取docker鏡像。當然，當我在GKE中使用Kubernetes集群拉取鏡像是沒有問題的，因為當使用GKE時，所有的服務(wù)器都自動被賦予了訪問Google私有鏡像倉庫的的權(quán)限，但是作為本地運行的minikube就沒有權(quán)限了。

解決方法是在Pod的spec節(jié)中使用imagePullSecrets值。首先，登錄Google Cloud，然后前往IAM并創(chuàng)建一個新的Service Account?并賦予Storage -> Storage Object Viewer權(quán)限，確保勾選“Furnish a new private key”選項，完事后會給你一個JSON文件，這個文件你需要本地保存，是用于授權(quán)的；所有這些準備就緒后運行這段腳本生成一個新的Secret資源：
#!/usr/bin/env?shSPATH="$(cd?$(dirname?"$0")?&&?pwd?-P)" SECRET_NAME=${1:-docker-registry-secret} CONFIG_PATH=${2:-$SPATH/localkube.json} if?[[?!?-f?$CONFIG_PATH?]];?then echo?"Unable?to?locate?service?account?config?JSON:?$CONFIG_PATH"; exit?1; fikubectl?create?secret?docker-registry?$SECRET_NAME??\ --docker-server?"https://gcr.io"?\ --docker-username?_json_key?\ --docker-email?[service?account?email?address]?\ --docker-password="`cat?$CONFIG_PATH`"?${@:3}?
這段腳本會生成一個名為docker-registry-secret的Secret資源，這個資源稍后要在Service的配置文件中的imagePullSecrets?值中被引用，如下所示：
apiVersion:?extensions/v1beta1 kind:?Deployment metadata: name:?redis-cache spec: ... template: spec:imagePullSecrets:-?name:?docker-registry-secret...containers:-?name:?redisimage:?gcr.io/[google?account?id]/redis-cache:latest ...
配置完成后應(yīng)該就能從Google私有鏡像倉庫中拉取鏡像了。

Secrets資源

敏感的數(shù)據(jù)比如：密碼，認證碼與各種key，這些都是要做特殊處理并很容易出錯的數(shù)據(jù)。首先，如果將這些數(shù)據(jù)不加密的保存在代碼管理倉庫中，不管這個倉庫多么機密，并不是一個保險的做法；但同時，你又必須把這些數(shù)據(jù)加密并保存在某個安全的地方，并使用一個跟蹤系統(tǒng)對其做版本記錄與權(quán)限控制。我使用了很多不同的加密、保存方式，發(fā)現(xiàn)StackExchange的BlackBox非常好用。

BlackBox使用PGP/GPG（非對稱加密）加密方式對文件進行加密，確保只有特定的用戶才能訪問加密的文件。對一個用戶授權(quán)訪問某個資源只需這個用戶提供自己的GPG公鑰，而移除一個用戶的授權(quán)只需要在一些配置文件中將其名字去掉即可；然后你要做的事就是告訴BlackBox哪些文件需要加密，而其余的工作交給BlackBox即可，被加密的配置文件可以放心的放入git倉庫了。

將這些加密的信息提供給Kubernetes需要一些額外的本地腳本，因為Kubernetes將配置信息以明文的方式存儲在etcd中。比如：我會對兩類文件進行加密：1、YAML配置文件，內(nèi)部包含很多key-value形式保存的敏感信息（如：數(shù)據(jù)庫密碼等）；2、一些公鑰文件如：SSL Certificate或者其他秘鑰。然后，我使用rake來解密這些文件，然后將解密的文件應(yīng)用到Kubernetes集群中，使用命令：apply -f -(注意：'-'表示STDIN)。

比如，我有個加密的YAML文件，如下：
--- rails: secret_key_base:?"..." service_api_key:?"..." database: username:?"..." password:?"..."
然后導(dǎo)入Kubernetes的Secret：
raw_secrets?=?`blackbox_cat?secrets/my-secrets.yml.gpg`secrets?=?YAML.load(raw_secrets)secrets.each?do?|name,?values| k8s_secret?=?{ "apiVersion"?=>?"v1", "kind"?=>?"Secret", "type"?=>?"Opaque", "metadata"?=>?{?"name"?=>?name?}, "data"?=>?{}, }values.each?do?|key,?value| k8s_secret["data"][key]?=?Base64.strict_encode64(value) endstdout,?status?=?Open3.capture2("kubectl?apply?-f?-",?stdin_data:?k8s_secret.to_yaml) end?
然后在Service的配置文件中來引用這些Secret（使用Secret名稱，我通常使用環(huán)境變量來指定）：
... env: -?name:?RAILS_SECRET_KEY_BASE valueFrom:secretKeyRef:name:?railskey:?secret_key_base -?name:?RAILS_SERVICE_API_KEY valueFrom:secretKeyRef:name:?railskey:?service_api_key -?name:?DATABASE_USERNAME valueFrom:secretKeyRef:name:?databasekey:?username -?name:?DATABASE_PASSWORD valueFrom:secretKeyRef:name:?databasekey:?password
我認為這是我使用、配置Kubernetes過程中遇到的主要問題，希望對您有幫助。

原文鏈接：CONTAINERS, DOCKER, AND KUBERNETES PART 3（翻譯：肖勁）

原文發(fā)布時間為：2017-07-07

本文作者：肖勁

本文來自云棲社區(qū)合作伙伴Dockerone.io，了解相關(guān)信息可以關(guān)注Dockerone.io。

原文標題：容器、Docker與Kubernetes——Kubernetes的配置入門

總結(jié)

以上是生活随笔為你收集整理的容器、Docker与Kubernetes——Kubernetes的配置入门的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。