你好，我是張磊。今天我和你分享的主題是：Kubernetes 一鍵部署利器之 kubeadm。

通過前面幾篇文章的內(nèi)容，我其實(shí)闡述了這樣一個思想：要真正發(fā)揮容器技術(shù)的實(shí)力，你就不能僅僅局限于對 Linux 容器本身的鉆研和使用。

這些知識更適合作為你的技術(shù)儲備，以便在需要的時候可以幫你更快的定位問題，并解決問題。

而更深入的學(xué)習(xí)容器技術(shù)的關(guān)鍵在于，如何使用這些技術(shù)來“容器化”你的應(yīng)用。

比如，我們的應(yīng)用既可能是 Java Web 和 MySQL 這樣的組合，也可能是 Cassandra 這樣的分布式系統(tǒng)。而要使用容器把后者運(yùn)行起來，你單單通過 Docker 把一個 Cassandra 鏡像跑起來是沒用的。

要把 Cassandra 應(yīng)用容器化的關(guān)鍵，在于如何處理好這些Cassandra 容器之間的編排關(guān)系。比如，哪些 Cassandra 容器是主，哪些是從？主從容器如何區(qū)分？它們之間又如何進(jìn)行自動發(fā)現(xiàn)和通信？Cassandra 容器的持久化數(shù)據(jù)又如何保持，等等。

這也是為什么我們要反復(fù)強(qiáng)調(diào) Kubernetes 項(xiàng)目的主要原因：這個項(xiàng)目體現(xiàn)出來的容器化“表達(dá)能力”，具有獨(dú)有的先進(jìn)性和完備性。這就使得它不僅能運(yùn)行 Java Web 與 MySQL 這樣的常規(guī)組合，還能夠處理 Cassandra 容器集群等復(fù)雜編排問題。所以，對這種編排能力的剖析、解讀和最佳實(shí)踐，將是本專欄最重要的一部分內(nèi)容。

不過，萬事開頭難。

作為一個典型的分布式項(xiàng)目，Kubernetes 的部署一直以來都是擋在初學(xué)者前面的一只“攔路虎”。尤其是在 Kubernetes 項(xiàng)目發(fā)布初期，它的部署完全要依靠一堆由社區(qū)維護(hù)的腳本。

其實(shí)，Kubernetes 作為一個 Golang 項(xiàng)目，已經(jīng)免去了很多類似于 Python 項(xiàng)目要安裝語言級別依賴的麻煩。但是，除了將各個組件編譯成二進(jìn)制文件外，用戶還要負(fù)責(zé)為這些二進(jìn)制文件編寫對應(yīng)的配置文件、配置自啟動腳本，以及為 kube-apiserver 配置授權(quán)文件等等諸多運(yùn)維工作。

目前，各大云廠商最常用的部署的方法，是使用 SaltStack、Ansible等運(yùn)維工具自動化地執(zhí)行這些步驟。

但即使這樣，這個部署過程依然非常繁瑣。因?yàn)?，SaltStack 這類專業(yè)運(yùn)維工具本身的學(xué)習(xí)成本，就可能比 Kubernetes 項(xiàng)目還要高。

難道 Kubernetes 項(xiàng)目就沒有簡單的部署方法了嗎？

這個問題，在 Kubernetes 社區(qū)里一直沒有得到足夠重視。直到 2017 年，在志愿者的推動下，社區(qū)才終于發(fā)起了一個獨(dú)立的部署工具，名叫：kubeadm。

這個項(xiàng)目的目的，就是要讓用戶能夠通過這樣兩條指令完成一個 Kubernetes 集群的部署：

? ? ? 1 # 創(chuàng)建一個 Master 節(jié)點(diǎn)

? ? ? 2 $ kubeadm init

? ? ? 3?

? ? ? 4 # 將一個 Node 節(jié)點(diǎn)加入到當(dāng)前集群中

? ? ? 5 $ kubeadm join <Master 節(jié)點(diǎn)的 IP 和端口>

是不是非常方便呢？

不過，你可能也會有所顧慮：Kubernetes 的功能那么多，這樣一鍵部署出來的集群，能用于生產(chǎn)環(huán)境嗎？

為了回答這個問題，在今天這篇文章，我就先和你介紹一下 kubeadm 的工作原理吧。

kubeadm 的工作原理

在上一篇文章《從容器到容器云：談?wù)?Kubernetes 的本質(zhì)》中，我已經(jīng)詳細(xì)介紹了Kubernetes 的架構(gòu)和它的組件。在部署時，它的每一個組件都是一個需要被執(zhí)行的、單獨(dú)的二進(jìn)制文件。所以不難想象，SaltStack 這樣的運(yùn)維工具或者由社區(qū)維護(hù)的腳本的功能，就是要把這些二進(jìn)制文件傳輸?shù)街付ǖ臋C(jī)器當(dāng)中，然后編寫控制腳本來啟停這些組件。

不過，在理解了容器技術(shù)之后，你可能已經(jīng)萌生出了這樣一個想法，為什么不用容器部署Kubernetes 呢？

這樣，我只要給每個 Kubernetes 組件做一個容器鏡像，然后在每臺宿主機(jī)上用 docker run 指令啟動這些組件容器，部署不就完成了嗎？

事實(shí)上，在 Kubernetes 早期的部署腳本里，確實(shí)有一個腳本就是用 Docker 部署Kubernetes項(xiàng)目的，這個腳本相比于 SaltStack 等的部署方式，也的確簡單了不少。

但是，這樣做會帶來一個很麻煩的問題，即：如何容器化 kubelet。

我在上一篇文章中，已經(jīng)提到 kubelet 是Kubernetes 項(xiàng)目用來操作 Docker 等容器運(yùn)行時的核心組件?？墒?，除了跟容器運(yùn)行時打交道外，kubelet 在配置容器網(wǎng)絡(luò)、管理容器數(shù)據(jù)卷時，都需要直接操作宿主機(jī)。

而如果現(xiàn)在 kubelet 本身就運(yùn)行在一個容器里，那么直接操作宿主機(jī)就會變得很麻煩。對于網(wǎng)絡(luò)配置來說還好，kubelet 容器可以通過不開啟 Network Namespace（即 Docker 的host network 模式）的方式，直接共享宿主機(jī)的網(wǎng)絡(luò)棧。可是，要讓 kubelet 隔著容器的Mount Namespace 和文件系統(tǒng)，操作宿主機(jī)的文件系統(tǒng)，就有點(diǎn)兒困難了。

比如，如果用戶想要使用 NFS 做容器的持久化數(shù)據(jù)卷，那么kubelet 就需要在容器進(jìn)行綁定掛載前，在宿主機(jī)的指定目錄上，先掛載 NFS 的遠(yuǎn)程目錄。

可是，這時候問題來了。由于現(xiàn)在 kubelet 是運(yùn)行在容器里的，這就意味著它要做的這個“mount -F nfs”命令，被隔離在了一個單獨(dú)的Mount Namespace 中。即，kubelet 做的掛載操作，不能被“傳播”到宿主機(jī)上。

對于這個問題，有人說，可以使用 setns() 系統(tǒng)調(diào)用，在宿主機(jī)的 Mount Namespace 中執(zhí)行這些掛載操作；也有人說，應(yīng)該讓 Docker 支持一個–mnt=host的參數(shù)。

但是，到目前為止，在容器里運(yùn)行 kubelet，依然沒有很好的解決辦法，我也不推薦你用容器去部署 Kubernetes 項(xiàng)目。

正因?yàn)槿绱?，kubeadm 選擇了一種妥協(xié)方案：

? ? ? 把 kubelet 直接運(yùn)行在宿主機(jī)上，然后使用容器部署其他的Kubernetes 組件。

所以，你使用 kubeadm 的第一步，是在機(jī)器上手動安裝kubeadm、kubelet 和 kubectl 這三個二進(jìn)制文件。當(dāng)然，kubeadm 的作者已經(jīng)為各個發(fā)行版的Linux 準(zhǔn)備好了安裝包，所以你只需要執(zhí)行：

1$ apt-get install kubeadm

就可以了。

接下來，你就可以使用“kubeadm init”部署 Master節(jié)點(diǎn)了。

kubeadm init 的工作流程

當(dāng)你執(zhí)行 kubeadm init 指令后，kubeadm 首先要做的，是一系列的檢查工作，以確定這臺機(jī)器可以用來部署 Kubernetes。這一步檢查，我們稱為“Preflight Checks”，它可以為你省掉很多后續(xù)的麻煩。

其實(shí)，Preflight Checks 包括了很多方面，比如：

* Linux 內(nèi)核的版本必須是否是 3.10 以上？

*?Linux Cgroups 模塊是否可用？

*?機(jī)器的 hostname 是否標(biāo)準(zhǔn)？在 Kubernetes 項(xiàng)目里，機(jī)器的名字以及一切存儲在 Etcd 中的 API 對象，都必*須使用標(biāo)準(zhǔn)的 DNS 命名（RFC 1123）。

*?用戶安裝的 kubeadm 和 kubelet 的版本是否匹配？

*?機(jī)器上是不是已經(jīng)安裝了 Kubernetes 的二進(jìn)制文件？

*?Kubernetes 的工作端口 10250/10251/10252 端口是不是已經(jīng)被占用？

*?ip、mount 等 Linux 指令是否存在？

*?Docker 是否已經(jīng)安裝？

……

在通過了 Preflight Checks 之后，kubeadm 要為你做的，是生成 Kubernetes 對外提供服務(wù)所需的各種證書和對應(yīng)的目錄。

Kubernetes 對外提供服務(wù)時，除非專門開啟“不安全模式”，否則都要通過 HTTPS 才能訪問kube-apiserver。這就需要為 Kubernetes 集群配置好證書文件。

kubeadm 為 Kubernetes 項(xiàng)目生成的證書文件都放在 Master 節(jié)點(diǎn)的 /etc/kubernetes/pki 目錄下。在這個目錄下，最主要的證書文件是 ca.crt 和對應(yīng)的私鑰ca.key。

此外，用戶使用 kubectl 獲取容器日志等 streaming操作時，需要通過 kube-apiserver 向kubelet 發(fā)起請求，這個連接也必須是安全的。kubeadm 為這一步生成的是apiserver-kubelet-client.crt 文件，對應(yīng)的私鑰是 apiserver-kubelet-client.key。

除此之外，Kubernetes 集群中還有 Aggregate APIServer 等特性，也需要用到專門的證書，這里我就不再一一列舉了。需要指出的是，你可以選擇不讓 kubeadm 為你生成這些證書，而是拷貝現(xiàn)有的證書到如下證書的目錄里：

/etc/kubernetes/pki/ca.{crt,key}

這時，kubeadm 就會跳過證書生成的步驟，把它完全交給用戶處理。

證書生成后，kubeadm 接下來會為其他組件生成訪問kube-apiserver 所需的配置文件。這些文件的路徑是：/etc/kubernetes/xxx.conf：

ls /etc/kubernetes/

admin.conf? controller-manager.conf? kubelet.conf? scheduler.conf

這些文件里面記錄的是，當(dāng)前這個 Master 節(jié)點(diǎn)的服務(wù)器地址、監(jiān)聽端口、證書目錄等信息。這樣，對應(yīng)的客戶端（比如 scheduler，kubelet 等），可以直接加載相應(yīng)的文件，使用里面的信息與 kube-apiserver 建立安全連接。

接下來，kubeadm 會為 Master 組件生成 Pod 配置文件。我已經(jīng)在上一篇文章中和你介紹過Kubernetes 有三個 Master 組件 kube-apiserver、kube-controller-manager、kube-scheduler，而它們都會被使用 Pod 的方式部署起來。

你可能會有些疑問：這時，Kubernetes 集群尚不存在，難道kubeadm 會直接執(zhí)行docker run 來啟動這些容器嗎？

當(dāng)然不是。

在 Kubernetes 中，有一種特殊的容器啟動方法叫做“Static Pod”。它允許你把要部署的Pod的 YAML 文件放在一個指定的目錄里。這樣，當(dāng)這臺機(jī)器上的kubelet 啟動時，它會自動檢查這個目錄，加載所有的 Pod YAML 文件，然后在這臺機(jī)器上啟動它們。

從這一點(diǎn)也可以看出，kubelet 在 Kubernetes 項(xiàng)目中的地位非常高，在設(shè)計上它就是一個完全獨(dú)立的組件，而其他 Master 組件，則更像是輔助性的系統(tǒng)容器。

在 kubeadm 中，Master 組件的 YAML 文件會被生成在 /etc/kubernetes/manifests 路徑下。比如，kube-apiserver.yaml：

apiVersion: v1

kind: Pod

metadata:

? ? ? ?annotations:

? ? ? ? ? ?scheduler.alpha.kubernetes.io/critical-pod:""

? ? ? ?creationTimestamp: null

? ? ? ?labels:

? ? ? ? ? component:kube-apiserver

? ? ? ? ? tier:control-plane

? ? ? name: kube-apiserver

? ? ? namespace: kube-system

spec:

? ? ? containers:

? ? ? - command:

? ? ? ? ?-kube-apiserver

? ? ? ? ?---authorization-mode=Node,RBAC

? ? ? ? ?---runtime-config=api/all=true

? ? ? ? ?---advertise-address=10.168.0.2

? ? ? ? ?...

? ? ? ? ?---tls-cert-file=/etc/kubernetes/pki/apiserver.crt

? ? ? ? ?---tls-private-key-file=/etc/kubernetes/pki/apiserver.key

? ? ? ? ?image:k8s.gcr.io/kube-apiserver-amd64:v1.11.1

? ? ? ? ?imagePullPolicy:IfNotPresent

? ? ? ? ?livenessProbe:

? ? ? ? ?...

? ? ? ? ?name: kube-apiserver

? ? ? ? ?resources:

? ? ? ? ?requests:

? ? ? ? ?cpu: 250m

? ? ? ? ?volumeMounts:

? ? ? ? ?- mountPath:/usr/share/ca-certificates

? ? ? ? ?name:usr-share-ca-certificates

? ? ? ? ?readOnly:true

? ? ? ? ?...

hostNetwork: true

priorityClassName:system-cluster-critical

volumes:

- hostPath:

? ? ?path:/etc/ca-certificates

? ? ?type:DirectoryOrCreate

? name:etc-ca-certificates

...

關(guān)于一個 Pod 的 YAML 文件怎么寫、里面的字段如何解讀，我會在后續(xù)專門的文章中為你詳細(xì)分析。在這里，你只需要關(guān)注這樣幾個信息：

1. 這個 Pod 里只定義了一個容器，它使用的鏡像是：k8s.gcr.io/kube-apiserver-amd64:v1.11.1 。這個鏡像是 Kubernetes 官方維護(hù)的一個組件鏡像。

2. 這個容器的啟動命令（commands）是kube-apiserver --authorization-mode=Node,RBAC …，這樣一句非常長的命令。其實(shí)，它就是容器里 kube-apiserver 這個二進(jìn)制文件再加上指定的配置參數(shù)而已。

3. 如果你要修改一個已有集群的 kube-apiserver 的配置，需要修改這個 YAML 文件。

4. 這些組件的參數(shù)也可以在部署時指定，我很快就會講解到。

在這一步完成后，kubeadm 還會再生成一個 Etcd 的 Pod YAML 文件，用來通過同樣的Static Pod 的方式啟動 Etcd。所以，最后 Master 組件的 Pod YAML 文件如下所示：

1$ ls /etc/kubernetes/manifests/

2 etcd.yaml? kube-apiserver.yaml? ?kube-controller-manager.yaml? ?kube-scheduler.yaml

而一旦這些 YAML 文件出現(xiàn)在被 kubelet 監(jiān)視的 /etc/kubernetes/manifests 目錄下，kubelet 就會自動創(chuàng)建這些 YAML 文件中定義的 Pod，即 Master 組件的容器。

Master 容器啟動后，kubeadm 會通過檢查localhost:6443/healthz 這個 Master 組件的健康檢查 URL，等待 Master 組件完全運(yùn)行起來。

然后，kubeadm 就會為集群生成一個 bootstrap token。在后面，只要持有這個 token，任何一個安裝了 kubelet 和 kubadm 的節(jié)點(diǎn)，都可以通過 kubeadm join 加入到這個集群當(dāng)中。

這個 token 的值和使用方法會，會在 kubeadm init結(jié)束后被打印出來。

在 token 生成之后，kubeadm 會將 ca.crt 等 Master 節(jié)點(diǎn)的重要信息，通過 ConfigMap 的方式保存在 Etcd 當(dāng)中，供后續(xù)部署 Node 節(jié)點(diǎn)使用。這個 ConfigMap 的名字是cluster-info。

kubeadm init 的最后一步，就是安裝默認(rèn)插件。Kubernetes 默認(rèn) kube-proxy 和 DNS 這兩個插件是必須安裝的。它們分別用來提供整個集群的服務(wù)發(fā)現(xiàn)和 DNS 功能。其實(shí)，這兩個插件也只是兩個容器鏡像而已，所以 kubeadm 只要用Kubernetes 客戶端創(chuàng)建兩個 Pod 就可以了。

kubeadm join 的工作流程

這個流程其實(shí)非常簡單，kubeadm init 生成bootstrap token 之后，你就可以在任意一臺安裝了 kubelet 和 kubeadm 的機(jī)器上執(zhí)行 kubeadm join 了。

可是，為什么執(zhí)行 kubeadm join 需要這樣一個token 呢？

因?yàn)?，任何一臺機(jī)器想要成為 Kubernetes 集群中的一個節(jié)點(diǎn)，就必須在集群的kube-apiserver 上注冊?？墒?，要想跟 apiserver 打交道，這臺機(jī)器就必須要獲取到相應(yīng)的證書文件（CA 文件）?？墒牵瑸榱四軌蛞绘I安裝，我們就不能讓用戶去Master 節(jié)點(diǎn)上手動拷貝這些文件。

所以，kubeadm 至少需要發(fā)起一次“不安全模式”的訪問到kube-apiserver，從而拿到保存在 ConfigMap 中的 cluster-info（它保存了 APIServer 的授權(quán)信息）。而 bootstrap token，扮演的就是這個過程中的安全驗(yàn)證的角色。

只要有了 cluster-info 里的kube-apiserver 的地址、端口、證書，kubelet 就可以以“安全模式”連接到 apiserver 上，這樣一個新的節(jié)點(diǎn)就部署完成了。

接下來，你只要在其他節(jié)點(diǎn)上重復(fù)這個指令就可以了。

配置 kubeadm 的部署參數(shù)

我在前面講解了 kubeadm 部署 Kubernetes 集群最關(guān)鍵的兩個步驟，kubeadm init 和kubeadm join。相信你一定會有這樣的疑問：kubeadm 確實(shí)簡單易用，可是我又該如何定制我的集群組件參數(shù)呢？

比如，我要指定 kube-apiserver 的啟動參數(shù)，該怎么辦？

在這里，我強(qiáng)烈推薦你在使用 kubeadm init 部署Master 節(jié)點(diǎn)時，使用下面這條指令：

$ kubeadm init --configkubeadm.yaml

這時，你就可以給 kubeadm 提供一個 YAML 文件（比如，kubeadm.yaml），它的內(nèi)容如下所示（我僅列舉了主要部分）：

apiVersion:kubeadm.k8s.io/v1alpha2

kind: MasterConfiguration

kubernetesVersion: v1.11.0

api:

? ? advertiseAddress: 192.168.0.102

? ? bindPort: 6443

? ? ...

etcd:

? ? local:

? ? ? ?dataDir:/var/lib/etcd

? ? ? ? image:""

imageRepository: k8s.gcr.io

kubeProxy:

? ? ? config:

? ? ? ? ? ?bindAddress:0.0.0.0

? ? ? ? ? ?...

kubeletConfiguration:

? ? ? ?baseConfig:

? ? ? ? ? ? address:0.0.0.0

? ? ? ? ? ? ...

networking:

? ? ? dnsDomain: cluster.local

? ? ? podSubnet: ""

? ? ? serviceSubnet: 10.96.0.0/12

nodeRegistration:

? ? ? criSocket:/var/run/dockershim.sock

? ? ? ...

通過制定這樣一個部署參數(shù)配置文件，你就可以很方便地在這個文件里填寫各種自定義的部署參數(shù)了。比如，我現(xiàn)在要指定 kube-apiserver 的參數(shù)，那么我只要在這個文件里加上這樣一段信息：

...

apiServerExtraArgs:

? ? ?advertise-address: 192.168.0.103

? ? ?anonymous-auth: false

? ? ?enable-admission-plugins:AlwaysPullImages,DefaultStorageClass

? ? ?audit-log-path:/home/johndoe/audit.log

然后，kubeadm 就會使用上面這些信息替換/etc/kubernetes/manifests/kube-apiserver.yaml 里的 command 字段里的參數(shù)了。

而這個 YAML 文件提供的可配置項(xiàng)遠(yuǎn)不止這些。比如，你還可以修改kubelet 和kube-proxy的配置，修改 Kubernetes 使用的基礎(chǔ)鏡像的 URL（默認(rèn)的k8s.gcr.io/xxx鏡像 URL 在國內(nèi)訪問是有困難的），指定自己的證書文件，指定特殊的容器運(yùn)行時等等。這些配置項(xiàng)，就留給你在后續(xù)實(shí)踐中探索了。

總結(jié)

在今天的這次分享中，我重點(diǎn)介紹了 kubeadm 這個部署工具的工作原理和使用方法。緊接著，我會在下一篇文章中，使用它一步步地部署一個完整的 Kubernetes 集群。

從今天的分享中，你可以看到，kubeadm 的設(shè)計非常簡潔。并且，它在實(shí)現(xiàn)每一步部署功能時，都在最大程度地重用 Kubernetes 已有的功能，這也就使得我們在使用 kubeadm 部署Kubernetes 項(xiàng)目時，非常有“原生”的感覺，一點(diǎn)都不會感到突兀。

而 kubeadm 的源代碼，直接就在kubernetes/cmd/kubeadm 目錄下，是 Kubernetes 項(xiàng)目的一部分。其中，app/phases 文件夾下的代碼，對應(yīng)的就是我在這篇文章中詳細(xì)介紹的每一個具體步驟。

看到這里，你可能會猜想，kubeadm 的作者一定是 Google公司的某個“大神”吧。

實(shí)際上，kubeadm 幾乎完全是一位高中生的作品。他叫Lucas K?ldstr?m，芬蘭人，今年只有18歲。kubeadm，是他 17 歲時用業(yè)余時間完成的一個社區(qū)項(xiàng)目。

所以說，開源社區(qū)的魅力也在于此：一個成功的開源項(xiàng)目，總能夠吸引到全世界最厲害的貢獻(xiàn)者參與其中。盡管參與者的總體水平參差不齊，而且頻繁的開源活動又顯得雜亂無章難以管控，但一個有足夠熱度的社區(qū)最終的收斂方向，卻一定是代碼越來越完善、Bug 越來越少、功能越來越強(qiáng)大。

最后，我再來回答一下我在今天這次分享開始提到的問題：kubeadm 能夠用于生產(chǎn)環(huán)境嗎？

到目前為止（2018 年 9 月），這個問題的答案是：不能。

因?yàn)?kubeadm 目前最欠缺的是，一鍵部署一個高可用的Kubernetes 集群，即：Etcd、Master 組件都應(yīng)該是多節(jié)點(diǎn)集群，而不是現(xiàn)在這樣的單點(diǎn)。這，當(dāng)然也正是 kubeadm 接下來發(fā)展的主要方向。

另一方面，Lucas 也正在積極地把 kubeadm phases開放給用戶，即：用戶可以更加自由地定制 kubeadm 的每一個部署步驟。這些舉措，都可以讓這個項(xiàng)目更加完善，我對它的發(fā)展走向也充滿了信心。

當(dāng)然，如果你有部署規(guī)模化生產(chǎn)環(huán)境的需求，我推薦使用kops或者 SaltStack 這樣更復(fù)雜的部署工具。但，在本專欄接下來的講解中，我都會以 kubeadm 為依據(jù)進(jìn)行講述。

* 一方面，作為 Kubernetes 項(xiàng)目的原生部署工具，kubeadm對 Kubernetes 項(xiàng)目特性的使用和集成，確實(shí)要比其他項(xiàng)目“技高一籌”，非常值得我們學(xué)習(xí)和借鑒；

* 另一方面，kubeadm 的部署方法，不會涉及到太多的運(yùn)維工作，也不需要我們額外學(xué)習(xí)復(fù)雜的部署工具。而它部署的 Kubernetes 集群，跟一個完全使用二進(jìn)制文件搭建起來的集群幾乎沒有任何區(qū)別。

因此，使用 kubeadm 去部署一個 Kubernetes 集群，對于你理解 Kubernetes 組件的工作方式和架構(gòu)，最好不過了。

思考題

1. 在 Linux 上為一個類似 kube-apiserver 的 Web Server 制作證書，你知道可以用哪些工具實(shí)現(xiàn)嗎？

2. 回憶一下我在前面文章中分享的 Kubernetes 架構(gòu)，你能夠說出 Kubernetes 各個功能組件之間（包含 Etcd），都有哪些建立連接或者調(diào)用的方式嗎？（比如：HTTP/HTTPS，遠(yuǎn)程調(diào)用等等）

感謝你的收聽，歡迎你給我留言，也歡迎分享給更多的朋友一起閱讀。

文章回復(fù)：

Antergone

有一個ansible playbook可以推薦給大家。https://github.com/gjmzj/kubeasz初學(xué)者可以跟著一步步看原理，后期還可以自己定制化。主要是容易產(chǎn)生興趣。

2018-09-14

MiracleWong

我也補(bǔ)充一個可用于部署生產(chǎn)級別的Kubernetes的開源項(xiàng)目：https://github.com/kubernetes-incubator/kubespray 我們公司正在使用。

2018-09-16

yandd

推薦個k8s實(shí)驗(yàn)平臺https://console.magicsandbox.com，可能需要fan qiang才能訪問

2018-09-15

包治結(jié)巴

https://time.geekbang.org/column/article/39712

2018/11/17

張老師，后面能講講怎么用二進(jìn)制部署kubernetes嗎？畢竟kubeadm不適用于生產(chǎn)環(huán)境，用二進(jìn)制部署還是挺復(fù)雜的，懇請老師不吝講解一下吧。

2018-09-14

作者回復(fù)

我不建議直接使用二進(jìn)制文件部署。而建議你花時間了解一下kubeadm的高可用部署，它現(xiàn)在已經(jīng)初具雛形了。寶貴的時間應(yīng)該用在刀刃上。

2018-09-14

eden

一周更新三章，有點(diǎn)迫不及待了。不過講得確實(shí)不錯，期待后面更精彩的內(nèi)容。想請教一個問題，你怎么看待openstack和k8s的關(guān)系，哪個技術(shù)門檻更高，為什么現(xiàn)在公司更傾向于用k8s來實(shí)現(xiàn)自己的云，而openstack有被k8s取代的趨勢。

2018-09-14

作者回復(fù)

當(dāng)然是openstack門檻更高。90%用戶要的是paas。

2018-09-14

Geek_700d17

第一時間閱讀更新，有種追劇的感覺?。。?/p>

2018-09-14

張應(yīng)羅

其實(shí)國內(nèi)同學(xué)們用kubeadm安裝集群最大的攔路虎在于有幾個鏡像沒法下載，我建議大家先手動把鏡像pull 下來，從阿里的鏡像源上，然后tag成安裝所需的鏡像名稱，這樣你發(fā)現(xiàn)安裝過程會異常順利

2018-09-21

作者回復(fù)

沒錯。kubeadm拉取鏡像的url是可配置的。

2018-09-21

寶仔

etcd可以先部署，然后初始化的時候通過kubeadm.yaml指定已經(jīng)部署好的etcd。高可用可以通過部署三個master節(jié)點(diǎn)來解決！現(xiàn)在有個問題，通過kubeadm部署生成的apiserver證書默認(rèn)有效期是一年，官方是認(rèn)為需要通過kubeadm upgrade 每年升級一次kubernetes，升級的時候也會更新證書，請問老師這個有解決方法嗎？

2018-09-15

作者回復(fù)

HA的etcd也是可以用kubeadm部署的，當(dāng)然，external etcd有助于你自己做運(yùn)維。你可以直接改證書生成的步驟，但我當(dāng)然推薦你執(zhí)行upgrade，這個操作是必須的。

2018-09-16

eden

有個開源項(xiàng)目kubespray，支持k8s高可用部署，利用ansible來實(shí)現(xiàn)，這個項(xiàng)目部署的集群可以用于生產(chǎn)吧

2018-09-14

zz@zz

kbueadm init 遇到問題的同學(xué)，可以從報錯日志中獲得需要的 鏡像列表

- No internet connection is available so the kubelet cannot pull or findthe following control plane images:

- k8s.gcr.io/kube-apiserver-amd64:v1.11.4

- k8s.gcr.io/kube-controller-manager-amd64:v1.11.4

- k8s.gcr.io/kube-scheduler-amd64:v1.11.4

- k8s.gcr.io/etcd-amd64:3.2.18

- You can check or miligate this in beforehand with "kubeadm configimages pull" to make sure the images

或者使用如下命令

kubeadm config images list

然后使用下邊的腳本拉鏡像并tag成指定Google的鏡像

images=(

k8s.gcr.io/kube-apiserver-amd64:v1.11.4

k8s.gcr.io/kube-controller-manager-amd64:v1.11.4

k8s.gcr.io/kube-scheduler-amd64:v1.11.4

k8s.gcr.io/kube-proxy-amd64:v1.11.4

k8s.gcr.io/pause:3.1

k8s.gcr.io/etcd-amd64:3.2.18

k8s.gcr.io/coredns:1.1.3

)

for imageName in ${images[@]} ; do

docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName

docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageNamek8s.g

cr.io/$imageName

done

2018-11-03

alex

對墻經(jīng)驗(yàn)豐富的人來了，可以用下面這個鏡像

https://github.com/anjia0532/gcr.io_mirror

作者回復(fù)

你好，樓道門開一下。

一葉

我們的生產(chǎn)環(huán)境是二進(jìn)制安裝的，把安裝步驟寫成腳本就會方便很多，分享一個二進(jìn)制安裝腳本：

https://github.com/SongCF/kubesh

2018-09-23

darling

fabric8 不是Java API 操作K8s嗎？ 大神不知道？？？？

2018-09-14

作者回復(fù)

Java只有大學(xué)交作業(yè)的時候用過……

2018-09-14

廣興

kubeadm不是也支持高可用集群搭建的嗎

2018-09-14

作者回復(fù)

這個特性還沒有完全release ，也就是GA

2018-09-14

pytimer

Kubernetes文檔上現(xiàn)在有關(guān)于使用kubeadm部署高可用集群的說明，是不是說明可以使用kubeadm結(jié)合saltstack、ansible進(jìn)行生產(chǎn)上的部署？

2018-09-14

作者回復(fù)

是的，kubeadm的高可用部署應(yīng)該很快就能發(fā)布了。

2018-09-14

pytimer

制作證書的工具: cfssl openssl easyrsa

2018-09-14

作者回復(fù)

贊。而是這些工具的共同點(diǎn)就是，難用，不夠傻瓜……

2018-09-14

asdf100

admin.conf 這個證書配置文件 是不是etcd 連接api server 時使用？

2018-09-29

北卡

額，指正式版沒有發(fā)布嗎？

2018-09-23

作者回復(fù)

對的，不過大功能已經(jīng)確定了，不必?fù)?dān)心，流程不會有太多變化

2018-09-23

北卡

不能直接回復(fù)作者的回復(fù)嗎?

“kubeadm 高可用部署還沒有GA”

GA是什么意思?

2018-09-23

作者回復(fù)

生產(chǎn)可用

2018-09-24

北卡

kubeadm可以搭建高可用集群，實(shí)際上我們現(xiàn)在的生產(chǎn)環(huán)境就是使用kubeadm搭建的。只是kubeadm搭建高可用集群如果完全按照官方文檔來，它生成的的證書只有一年期限。所以需要自己提前做好證書。

2018-09-23

作者回復(fù)

需要注意高可用部署還沒有GA，有很多問題亟待解決。證書在升級的時候會更新的。