譯者：王樂

這部文檔是面對想要學習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

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實例。

推薦方式: 運行一個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 如何開啟監控。

DNS

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安装文档_Kubernetes（k8s）中文文档 从零开始k8s_Kubernetes中文社区的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。