從零開始k8s

摘要： 這部文件是面對想要學習Kubernetes叢集的讀者。如果你對入門指南已經可以滿足你對這個列表上所列的需求，我們建議你繼續閱讀這個，因為他是根據前人積累經驗所寫的新手指南。當然如果除了學習入門指南知識外還希望學習IaaS，網路，配置管理或對作業系統有特殊要求，這個指南將會提供給學習者一個指導性...

這部文件是面對想要學習Kubernetes叢集的讀者。如果你對入門指南已經可以滿足你對這個列表上所列的需求，我們建議你繼續閱讀這個，因為他是根據前人積累經驗所寫的新手指南。當然如果除了學習入門指南知識外還希望學習IaaS，網路，配置管理或對作業系統有特殊要求，這個指南將會提供給學習者一個指導性的概述及思路。

設計和準備

1. 你應該已經熟悉Kubernetes了。我們建議根據 其他入門指南架設一個臨時的叢集。這樣可以幫助你先熟悉Kubernetes命令列(kubectl)和一些概念(pods, services, 等等)。

2. 當你瀏覽完其他入門指南的時候，你應該已經安裝好了 kubectl 。如果沒有，你可以根據這個說明安裝。

Cloud Provider

Kubernetes有一個概念叫Cloud Provider，是指一個提供管理TCP負載均衡，節點（例項）和路由器介面的模組。 pkg/cloudprovider/cloud.go 裡具體定義了這個介面。 當然，你也可以不用實現這個Cloud Provider去新建一個自定義的聚群（例如，使用裸機叢集）。取決於不同部件是如何設定的，並不是所有介面都需要實現的。

node（節點）

• 你可以使用虛擬機器或物理機。
• 為了執行本指南給出的例子和測試用例，你最好有4個節點以上。
• 雖說很多入門指南講主節點和普通節點做了區分，但嚴格意義上講，這不是必要的。
• 節點需要執行在x86_64的Linux系統上。當然也可能執行在其他的系統和CPU架構上，但這個指南不會提供相關的幫助。
• 對於一個擁有10個以上節點的叢集來說，Apiserver和etcd可以一起安裝在一臺1核和1GB記憶體的機子上。
• 你可以給其他節點可以分配合理的記憶體和CPU核心。不是所有節點需要同樣的配置。

Kubernetes有一個獨特的網路模型.

Kubernetes給每一個pod分配IP地址。當你新建一個叢集，為了保證Pod獲得IP地址，你需要給Kubernetes分配一個IP地址池。最簡單的做法是每當節點與節點之間的通訊可以以一下兩種方式實現：

（1）配置網路完成Pod的IP地址路由

• 因為一切從頭開始，所以難度會大一些。
• Google Compute Engine (GCE) 和 AWS會指導如何使用這種方式
• 需要程式設計配置路由器和交換機去實現Pod的IP地址路由。
• 可在Kubernetes環境外配置或者通過在Cloud Provider模組的“路由”接口裡實現。
• 通常情況下，提供最優網路效能。

（2）建立一個拓撲網路

• 較容易建立
• 因為資料流量被封裝，所以每個Pod的IP地址是可以路由的。
• 例如：
  Flannel
  Weave
  Open vSwitch (OVS)
• 不需要CLoud Provider模組裡的“路由”部分
• 較為不太理想的效能（具體的效能弱化取決於你的實際情況）

你需要為Pod所需要的IP地址選一個IP地址範圍。

（3）一些可選擇配置方式：

• GCE：每一個專案有一個自己的IP子網“10.0.0.0/8”。專案中的每一個Kubernetes叢集從中獲得一個“/16”的子網。每一個節點從’/16’的子網裡獲IP地址。
• AWS：在一個組織內使用一個VPC。從中分配地址給每一個聚群或者使用給不同的叢集分配不同的VPC。
• 暫不支援支援IPv6

（4）給每一的node的Pod地址分配一個CIDR子網或者一個

• 你總共需要max-pods-per-node * max-number-of-nodes個IP地址。一個“/24” 如果缺少IP地址，一個“/26”（62個節點）或者“/27”（30個節點）也能滿足。
• 例如，使用“10.10.0.0/16” “10.10.0.0/24” “10.10.255.0/24”
• 需要路由設定或連線到拓撲網路

Kubernetes 會給每個service分配一個IP地址。 但是service的地址並不一定是可路由的。當資料離開節點時，kube-proxy需要將Service IP地址翻譯成Pod IP地址。因此，你需要給Service也分配一個地址段。這個網段叫做“SERVICE_CLUSTER_IP_RANGE”。例如，你可以這樣設定“SERVICE_CLUSTER_IP_RANGE=”10.0.0.0/16”，這樣的話就會允許65534個不同的Service同時執行。請注意，你可以調整這個IP地址段。但不允許在Service和Pod執行的時候移除這個網段。

同樣，你需要為主節點選一個靜態IP地址。 －命名這個IP地址為“MASTER_IP”。 －配置防火牆，從而允許訪問apiserver埠80和443。 －使用sysctl設定”net.ipv4.ip_forward = 1“從而開啟IPv4 forwarding。

叢集命名

為你的叢集選個名字。要選一個簡短不會和其他服務重複的名字。

• 用kubectl來訪問不同的叢集。比如當你想在其他的區域測試新的Kubernetes版本。
• Kubernetes叢集可以建立一個Cloud Provider資源（例如，AWS ELB）。所以不同的叢集要能區分他們之間的相關資源，這個名字叫做“CLUSTERNAME”。

軟體安裝包

你需要以下安裝包

• etcd
• 以下容器二選一:
  docker
  rkt
• Kubernetes
  kubelet
  kube-proxy
  kube-apiserver
  kube-controller-manager
  kube-scheduler

下載和解壓縮Kubernetes安裝

Kubernets安裝版本包包含所有Kuberentes的二進位制發行版本和所對應的etcd。你可使直接使用這個二進位制發行版本（推薦）或者按照開發者文件說明編譯這些Kubernetes的二進位制檔案。 本指南只講述瞭如何直接使用二進位制發行版本。 下載最新安裝版本並解壓縮。之後找到你下載“./kubernetes/server/kubernetes-server-linux-amd64.tar.gz”的路徑， 並解壓縮這個壓縮包。然後在其中找到“./kubernetes/server/bin”資料夾。裡面有所所需的可執行的二進位制檔案。

選擇安裝映象

在容器外執行docker，kuberlet和kube-proxy，就像你執行任何後臺系統程式。所以你只需要這些基本的二進位制執行檔案。etcd， kube-apiserver， kube-controller-manager和kubescheduler，我們建議你在容器裡執行etcd， kube-apiserver， kube-controller-manager和kube-scheduler。所以你需要他們的容器映象。 你可以選擇不同的Kubernetes映象：

你可以使用Google Container Registry (GCR)上的映象檔案：

• 例如“gcr.io/google_containers/hyperkube:$TAG”。這裡的“TAG”是指最新的發行版本的標示。這個表示可以從最新發行說明找到。
• 確定$TAG和你使用的kubelet，kube-proxy的標籤是一致的。
• hyperkube是一個整合二進位制執行檔案
• 你可以使用“hyperkube kubelet …”來啟動kubelet ，用“hyperkube apiserver …”執行apiserver， 等等。

生成你自己的映象：

• 使用私有映象伺服器。
• 例如，可以使用“docker load -i kube-apiserver.tar”將“./kubernetes/server/bin/kubeapiserver.tar”檔案轉化成dokcer映象。
• 之後可使用“docker images”來驗證映象是否從制定的映象伺服器載入成功。

對於etcd，你可以：

• 使用上Google Container Registry (GCR)的映象，例如“gcr.io/google_containers/etcd:2.0.12”
• 使用Docker Hub或著Quay.io上的映象，例如“quay.io/coreos/etcd:v2.2.0”
• 使用你作業系統自帶的etcd
• 自己編譯
  你可以使用這個命令列“cd kubernetes/cluster/images/etcd; make”

我們建議你使用Kubernetes發行版本里提供的etcd版本。Kubernetes發行版本里的二進位制執行檔案只是和這個版本的etcd測試過。你可以在“kubernetes/cluster/images/etcd/Makefile”裡“ETCD_VERSION”所對應的值找到所推薦的版本號。 接下來本文件會假設你已經選好映象標示並設定了對應的環境變數。 設定好了最新的標示和正確的映象伺服器：

• “HYPERKUBE_IMAGE==gcr.io/google_containers/hyperkube:$TAG”
• “ETCD_IMAGE=gcr.io/google_containers/etcd:$ETCD_VERSION”

安全模式

這裡有兩種主要的安全選項：

使用HTTP訪問apiserver

• 配合使用防火牆。
• 這種方法比較易用。

使用HTTPS訪問apiserver

• 配合電子證書和使用者登入資訊使用。
• 推薦使用
• 設定電子證書較為複雜。

如果要用HTTPS這個方式，你需要準備電子證書和使用者登入資訊。

準備安全證書

你需要準備多個證書：

• 主節點會是一個HTTPS伺服器，所以需要一個證書。
• 如果Kuberlets需要通過HTTPS提供API服務時，這些kuberlets需要出示證書向主節點證明主從關係。

除非你決定要一個真正CA來生成這些證書的話，你需要一個根證書，並用這個證書來給主節點，kuberlet和kubectl的證書籤名。

• 參見“cluster/gce/util.sh”腳本里的“create-certs”
• 並參見“cluster/saltbase/salt/generate-cert/make-ca-cert.sh”和cluster/saltbase/salt/generate-cert/make-cert.sh“

你需要修改以下部分(我們之後也會用到這些引數的)

”CA_CERT“

• 放置在apiserver所執行的節點上，比如“/srv/kubernetes/ca.crt”。

“MASTER_CERT”

• 用CA_CERT來簽名
• 放置在apiserver所執行的節點上，比如”/srv/kubernetes/server.crt”。

“MASTER_KEY“

• 放置在apiserver所執行的節點上，比如”/srv/kubernetes/server.key“。

“KUBELET_CERT”

• 可選配置

”KUBELET_KEY“

• 可選配置

準備登入資訊

管理員（及任何使用者）需要：

• 對應驗證身份的令牌或密碼。
• 令牌可以是長字串，比如 32個字元
  可參見”TOKEN=$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64 | tr -d”=+/” | dd bs=32 count=1 2>/dev/null)““

你的令牌和密碼需要儲存在apiserver上的一個檔案裡。本指南使用這個檔案”/var/lib/kubeapiserver/known_tokens.csv“。檔案的具體格式在認證文件裡描述了。 至於如何把登入資訊分發給使用者，Kubernetes是將登入資訊放入kubeconfig檔案裡。

管理員可以按如下步驟建立kubeconfig檔案：

• 如果你已經在非客製化的叢集上執行過Kubernetes(例如，按照入門指南架設過Kubernetes)，那麼你已經有“$HOME/.kube/config`”檔案了。
• 你需要在kuberconfig檔案裡新增證書，金鑰和主節點IP：
  1、如果你選擇了“firewall-only”的安全設定，你需要按如下設定apiserver：
  2、“kubectl config set-cluster $CLUSTER_NAME –server=http://$MASTER_IP –insecure-skip-tls-verify=true”
  3、否則，按如下設定你的apiserver的IP，證書，使用者登入資訊：
  4、“kubectl config set-cluster $CLUSTER_NAME –certificate-authority=$CA_CERT –embed-certs=true –server=https://$MASTER_IP”
  5、“kubectl config set-credentials $USER –client-certificate=$CLI_CERT –clientkey=$CLI_KEY –embed-certs=true –token=$TOKEN”
  6、設定你的叢集為預設叢集：
  7、“kubectl config set-context $CONTEXT_NAME –cluster=$CLUSTER_NAME –user=$USER”
  8、“kubectl config use-context $CONTEXT_NAME”

接下來，為kubelets和kube-proxy準備kubeconfig檔案。至於要準備多少不同的檔案，這裡有幾個選項：

1. 使用和管理員同樣的登陸賬號

• 這是最簡單的建設方法。

2. 所有的kubelet使用同一個令牌和kubeconfig檔案，另外一套給所有的kube-proxy使用，在一套給管理員使用。

• 這個設定和GCE的配置類似。

3. 為每一個kubelet，kube-proxy和管理員準備不同的登陸賬號。

• 這個配置在實現中，目前還不支援。

為了生成這個檔案，你可以參照“cluster/gce/configure-vm.sh”中的程式碼直接從“$HOME/.kube/config”拷貝過去或者參考以下模版：

apiVersion: v1
kind: Config users: - name: kubelet
user: token: ${KUBELET_TOKEN} clusters: - name: local cluster: certificate-authority-data: ${CA_CERT_BASE64_ENCODED} contexts: - context: cluster: local user: kubelet
name: service-account-context
current-context: service-account-context

把kubeconfig檔案放置到每一個節點上。本章節之後的事例會假設kubeconfig檔案已經放置在“/var/lib/kube-proxy/kubeconfig”和“/var/lib/kubelet/kubeconfig”裡。

在節點上配置和安裝基礎軟體

這個章節討論的是如歌配置Kubernetes節點。 你應該在每個節點執行三個後臺程序：

• docker or rkt
• kubelet *kube-proxy

Docker容器

對最低Docker版本的要求是隨著kubelet的版本變化的。最新的穩定版本通常是個好選擇。如果版本太低，Kubelet記錄下警報並拒絕執行pod，所以你可以選擇個版本試一下。

如果你之前安裝Docker的節點沒有Kubernetes相關的配置，你可能已經有Docker新建的網橋和iptables的規則。所以你或許希望在為Kubernetes配置Docker前根據以下命令移除之前的配置。

iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0

如何配置Docker取決於你網路是基於routable-vip還是overlay-network。 這裡有一些建議的Docker選項：

• 為每一個節點的CIDR網斷建立你自己的網橋，命名為cbr0併為docker設定 –bridge=cbr0 。
• 配置 –iptables=false ，所以docker不會為host-port設定iptables(這個控制在docker舊版本不夠細緻，以後會在新版本里修復)

所以kube-proxy可以代替docker來設定iptables。

• –ip-masq=false
  如果你將PodIP設定為可路由定址，你會希望將這個選項設定為false。否則，docker會將NodeIP重寫為PodIP的源地址。
  一些環境(例如,GCE)下需要偽裝(masquerade)離開這個雲環境的流量。這個配置是取決於具體的雲環境的。
  如果你在使用overlay網路，請參考其他資料。
• –mtu=
  但使用Flannel的時候，需要這個選項。 因為UDP包封裝造成過大的資料包。
• –insecure-registry $CLUSTER_SUBNET
  為連結沒有SSL安全連結的私有registry。

你或許希望為Docker提高可以開啟檔案的數目：

• DOCKER_NOFILE=1000000 這裡的設定取決於你的節點的作業系統。比如，GCE上基於Debian的發行版本使用 /etc/default/docker 這個配置檔案。

在進行下一步安裝前，可以參考Docker文件裡的例項來確保docker在你的系統上正常工作。

rkt是類似Docker的技術。你只需要二選一安裝Docker或者rkt。最低的版本是v0.5.6。

systemd是在節點上執行rkt必須的。與rkt v0.5.6所對應的最低版本是systemd 215。

rkt metadata service也是必須安裝的，來支援rtk的網路部分。你可以用以下命令來執行rkt的metadata服務 sudo systemd-run rkt metadata-service

接下來你需要來設定kubelet的標記：

--container-runtime=rkt

kubelet

所有的節點都要執行kubelet。

可參考的引數：

• 如果選擇HTTPS的安全配置：
  –api-servers=https://$MASTER_IP
  –kubeconfig=/var/lib/kubelet/kubeconfig
• 否則，使用防火牆的安全配置：
  –api-servers=http://$MASTER_IP
• –config=/etc/kubernetes/manifests
• –cluster-dns= 是用來配置DNS伺服器的地址(參考Starting Addons.)
• –cluster-domain= 是為DNS叢集地址使用的DNS域名字首。
• –docker-root=
• –root-dir=
• –configure-cbr0= (參考之前的介紹)
• –register-node (參考章節節點 .)

kube-proxy

所有的節點都要執行kube-proxy。(並不一定要在主節點上執行kube-proxy，但最好還是與其它節點保持一致) 可參考如何獲得kubelet二進位制執行包來獲得kube-proxy二進位制執行包。

可參考的引數

• 如果選擇HTTPS的安全配置
  –api-servers=https://$MASTER_IP
  –kubeconfig=/var/lib/kube-proxy/kubeconfig
• 否則，使用防火牆的安全配置：
  –api-servers=http://$MASTER_IP

為了pod的網路通訊，需要給每一個節點分配一個自己的CIDR網段。這個叫做 NODE_X_POD_CIDR 。

需要給每一個節點新建一個叫 cbr0 網橋。網橋會在networking documentation裡做詳細介紹。約定俗成，$NODE_X_POD_CIDR 裡的第一個IP地址作為這個網橋的IP地址。這個地址叫做 NODE_X_BRIDGE_ADDR 。比如， NODE_X_POD_CIDR 是 10.0.0.0/16 ，那麼 NODE_X_BRIDGE_ADDR 是 10.0.0.1/16 。注意：這裡用 /16 這個字尾是因為之後也會這麼使用。

• 推薦的自動化步驟:
  1. 在初始化的腳本里，設定kubelet的選項為 –configure-cbr0=true ，並重啟kubelet服務。Kubelet會自動設定cobr0. 它會一直等待，直到節點controller正確設定Node.Spec.PodCIDR。因為你目前還沒有設定好apiserver和節點controller，所以網橋不會馬上完成設定。
• 人工步驟:
  1. 設定kubelet的選項 –configure-cbr0=false ，並重啟kubelet。
  2. 新建網橋比如 brctl addbr cbr0 .
  3. 設定合適的MTU
  比如 ip link set dev cbr0 mtu 1460 (注意: 真實的MTU值是由你的網路環境所決定的)
  4. 把叢集網路加入網橋(docker會連線在這個網橋的另一端)。
  比如 ip addr add $NODE_X_BRIDGE_ADDR dev cbr0
  5. 開啟網橋
  比如 ip link set dev cbr0 up

在你關閉了Docker的IP偽裝的情況下，為了讓pod之間相互通訊，你可能需要為去往叢集網路外的流量做目的IP地址偽裝，例如：

iptables -t nat -A POSTROUTING ! -d ${CLUSTER_SUBNET} -m addrtype ! --dst-type LOCAL -jMASQUERADE

這樣會重寫從PodIP到節點IP的資料流量的原地址。核心connection tracking會確保發向節點的回覆能夠到達pod。

注意: 需不需要IP地址偽裝是視環境而定的。在一些環境下是不需要IP偽裝的。例如GCE這樣的環境從pod發出的資料是不允許發向Interent的，但如果在同一個GCE專案裡是不會有問題的。

• 如果需要，為你的系統安裝包管理器開啟自動升級。
• 為所有的節點設定日誌輪詢(比如，使用logrotate)。
• 建立liveness-monitoring (比如，使用monit)。
• 建立儲存外掛的支援(可選)
  為可選的儲存型別安裝所需的客戶端程式，比如為GlusterFS安裝 glusterfsclient。

使用配置管理工具

之前架設伺服器的步驟都是使用“傳統”的系統管理方式。你可以嘗試使用系統配置工具來自動化架設流程。你可以參考其他入門指南，比如使用Saltstack， Ansible， Juju和CoreOSCloud Config。

引導安裝叢集

通常情況下，基本的節點服務(kubelet， kube-proxy和docker)都是由傳統的系統配置方式完成建立和管理的。其他的Kubernetes的相關部分都是由Kubernetes本身來完成配置和管理的：

• 配置和管理的選項在Pod spec(yaml or json)而不是/etc/init.d檔案或systemd unit裡定義的。
• 他們都是由Kubernetes而不是init來負責執行的。

你需要執行一個或多個etcd例項。

• 推薦方式: 執行一個etcd例項，將日誌儲存在類似RAID，GCE PD的永久儲存空間上。
• 或者: 執行3個或者5個etcd例項。
  日誌可以儲存在 Log can be written to non-durable storage because storage isreplicated.
  執行一個apiserver，這個apiserver連線到其中一個etc例項上。 參見clustertroubleshooting
  獲取更多的有關叢集可用性的資訊。

啟動一個etcd例項:

1.複製 cluster/saltbase/salt/etcd/etcd.manifest 2.做有必要的設定修改 3.將這個檔案放到kubelet mainfest的資料夾中

Apiserver，Controller Manager和Scheduler

在主節點上，apiserver，controller manager，scheduler會執行在各自的pod裡。

啟動以上三個服務的步驟大同小異：

1. 從為pod所提供的template開始。

2. 設定 HYPERKUBE_IMAGE 的值為選擇安裝映象中所設定的值。

3. 可參考以下的template來決定你叢集所需的選項。

4. 在 commands 列表裡設定所需的執行選項（例如，$ARGN）。

5. 將完成的template放在kubelet manifest的資料夾內。

6. 驗證pod是否執行。

Apiserver pod模版

{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "kube-apiserver" }, "spec": { "hostNetwork": true, "containers": [ { "name": "kube-apiserver", "image": "${HYPERKUBE_IMAGE}", "command": [ "/hyperkube", "apiserver", "$ARG1", "$ARG2", ... "$ARGN" ], "ports": [ { "name": "https", "hostPort": 443, "containerPort": 443 }, { "name": "local", "hostPort": 8080, "containerPort": 8080 } ], "volumeMounts": [ { "name": "srvkube", "mountPath": "/srv/kubernetes", "readOnly": true }, { "name": "etcssl", "mountPath": "/etc/ssl", "readOnly": true } ], "livenessProbe": { "httpGet": { "path": "/healthz", "port": 8080 }, "initialDelaySeconds": 15, "timeoutSeconds": 15 } } ], "volumes": [ { "name": "srvkube", "hostPath": { } }, { "name": "etcssl", "hostPath": { "path": "/etc/ssl" } } ] } }

可選設定的apiserver的選項：

• –cloud-provider= 參見 cloud providers
  –
• -cloud-config= 參見 cloud providers
• 如果你想在主節點執行proxy，你需要設定 —address=${MASTER_IP} 或者 –bindaddress=127.0.0.1 和 –address=127.0.0.1 。
• –cluster-name=$CLUSTER_NAME
• –service-cluster-ip-range=$SERVICE_CLUSTER_IP_RANGE
• –etcd-servers=http://127.0.0.1:4001
• –tls-cert-file=/srv/kubernetes/server.cert
• –tls-private-key-file=/srv/kubernetes/server.key
• –admission-control=$RECOMMENDED_LIST
  參考 admission controllers.
• 只有當你相信你的叢集使用者可以使用root許可權來執行pod時，開啟這個選項 –allowprivileged=true ,

如果你是按照firewall-only的安全方式來配置的，你需要以下設定：

• –token-auth-file=/dev/null
• —insecure-bind-address=$MASTER_IP
• –advertise-address=$MASTER_IP

如果你是按照HTTPS的安全方式來配置的，你需要以下設定：

• –client-ca-file=/srv/kubernetes/ca.crt
• –token-auth-file=/srv/kubernetes/known_tokens.csv
• –basic-auth-file=/srv/kubernetes/basic_auth.csv

這個pod使用 hostPath 載入多個節點檔案系統目錄。這些載入的目錄的用途是：

• 載入 /etc/ssl 目錄可以允許apiserver找到SSL根證書，從而驗證例如雲服務提供商所提供的外部服務。
  如果你不使用任何雲服務提供商，你就不需要配置這裡（比如，只使用物理裸機）。
• 載入 /srv/kubernetes 目錄可以允許讀取儲存在節點磁碟上的證書和認證資訊。
• 可選, 你也可以加在 /var/log 目錄從而將日誌記錄在這個目錄裡(沒有在template裡舉例標明)。
  如果你想用類似journalctl的工具從根檔案系統來訪問日誌的話，可以載入這個目錄。 TODO 描述如何架設proxy-ssh。

Cloud Providers

Apiserver支援多個cloud providers。

• –cloud-provider 選項的值可以
  是 aws ， gce ， mesos ， openshift ， ovirt ， rackspace ， vagrant 或者不´未設定。
• 未設定選項可以用來設定物理裸機。
• 在這裡新增新的IaaS。

一些cloud providers需要配置檔案。這種情況下，你需要將配置檔案放置在apiserver的映象中或者通過 hostPath 來載入。

• 如果cloud providers需要配置檔案，設定 —cloud-config= 這個選項。
• aws ， gce ， mesos ， openshift ， ovirt 和 rackspace 會使用到這個選項。
• 你必須需要將配置檔案放置在apiserver的映象中或者通過 hostPath 來載入。
• 雲配置檔案的語法Gcfg。
• AWS格式是用型別來定義的AWSCloudConfig。
• 其他的雲服務提供商也有類似的對應檔案。
• 比如在GCE裡: 在這個檔案找 gce.conf 位元組。

Scheduler pod template

完成scheduler pod的template：

{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "kube-scheduler" }, "spec": { "hostNetwork": true, "containers": [ { "name": "kube-scheduler", "image": "$HYBERKUBE_IMAGE", "command": [ "/hyperkube", "scheduler", "--master=127.0.0.1:8080", "$SCHEDULER_FLAG1", ... "$SCHEDULER_FLAGN" ], "livenessProbe": { "httpGet": { "host" : "127.0.0.1", "path": "/healthz", "port": 10251 }, "initialDelaySeconds": 15, "timeoutSeconds": 15 } } ] } }

通常，不需要額外設定scheduler。

你或許想載入 /var/log 並將輸出記錄在這個日誌目錄裡。

Controller Manager Template

完成controller manager pod的template：

{ "kind": "Pod", "apiVersion": "v1", "metadata": { "name": "kube-controller-manager" },"spec": { "hostNetwork": true, "containers": [ { "name": "kube-controller-manager", "image": "$HYPERKUBE_IMAGE", "command": [ "/hyperkube", "controller-manager", "$CNTRLMNGR_FLAG1", ... "$CNTRLMNGR_FLAGN" ], "volumeMounts": [ { "name": "srvkube", "mountPath": "/srv/kubernetes", "readOnly": true }, { "name": "etcssl", "mountPath": "/etc/ssl", "readOnly": true } ], "livenessProbe": { "httpGet": { "host": "127.0.0.1", "path": "/healthz", "port": 10252 }, "initialDelaySeconds": 15, "timeoutSeconds": 15 } } ], "volumes": [ { "name": "srvkube", "hostPath": { "path": "/srv/kubernetes" } }, { "name": "etcssl", "hostPath": { "path": "/etc/ssl" } } ] } }

配合controller manager所使用的選項：

• –cluster-name=$CLUSTER_NAME
• —cluster-cidr=
  TODO: 解釋這個選項
• –allocate-node-cidrs=
  TODO: 解釋這個選項
• –cloud-provider= 和 –cloud-config 在apiserver章節裡解釋過。
• –service-account-private-key-file=/srv/kubernetes/server.key ，這個值是service
  account功能所使用的。
• –master=127.0.0.1:8080

執行和驗證Apiserver，Scheduler和Controller Manager

將每個完成的pod template放置在kubelet的配置資料夾中（資料夾地址是在kubelet的 –config= 選項所指向的地址， 通常是 /etc/kubernetes/manifests ）。沒有放置順序關係:scheduler和controller manager會一直嘗試連線到apiserver，直到連線成功。

用 ps 或者 docker ps 來檢測每一個程序是否正常執行。 比如，你可以這樣看apiserver的容器是否被kubelet啟動了：

$ sudo docker ps | grep apiserver: 5783290746d5 gcr.io/google_containers/kube-apiserver:e36bf367342b5a80d7467fd7611ad873........

之後嘗試連線apiserver:

$ echo $(curl -s http://localhost:8080/healthz) ok
$ curl -s http://localhost:8080/api { "versions": [ "v1" ] }

如果kubelets使用 –register-node=true 這個選項，他們會開始自動註冊到apiserver上。很快，你就可以使用 kubectl get nodes 命令看到所有的節點。否則，你需要手動註冊這些節點。

TODO 如何開啟日誌。

TODO 如何開啟監控。

TODO 如何執行DNS。

故障排除

執行validate-cluster

TODO 解釋如何執行“cluster/validate-cluster.sh”。

檢查pods和services

你可以嘗試這閱讀“檢查的叢集”這一節，例如GCE。你應該檢查Service。通過“mirro pods”去檢查apiserver，scehduler和controller-manager以及執行的外掛。

到這裡你應該能夠執行一些基本的例項了，例如nginx example。

執行測試

你可以試著執行一致性測試. 測試失敗的結果可能會給你些排除故障的線索。

節點之間必須用私有IP連結。可以通過ping或者SSH來確定節點之間的聯通。

本文轉移K8S技術社群-ofollow,noindex">從零開始k8s