2. 程式人生 > >Kubernetes高可用Master節點安裝_Kubernetes中文社群

Kubernetes高可用Master節點安裝_Kubernetes中文社群

阿新 • • 發佈：2018-12-27

前言

這是和我一步步部署kubernetes叢集專案((fork自opsnull))中的一篇文章，下文是結合我之前部署kubernetes的過程產生的kuberentes環境，部署master節點的kube-apiserver、kube-controller-manager和kube-scheduler的過程。

高可用Kubernetes Master節點安裝

kubernetes master 節點包含的元件：

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager

目前這三個元件需要部署在同一臺機器上。

  • kube-scheduler
    、kube-controller-manager 和 kube-apiserver 三者的功能緊密相關；
  • 同時只能有一個 kube-scheduler、kube-controller-manager 程序處於工作狀態，如果執行多個，則需要通過選舉產生一個 leader；

本文件記錄部署一個三個節點的高可用 kubernetes master 叢集步驟。（後續建立一個 load balancer 來代理訪問 kube-apiserver 的請求）

TLS 證書檔案

pem和token.csv證書檔案我們在TLS證書和祕鑰這一步中已經建立過了。我們再檢查一下。

$ ls /etc/kubernetes/ssl
admin-key.pem  admin.pem  ca-key.pem  ca.pem  kube-proxy-key.pem  kube-proxy.pem  kubernetes-key.pem  kubernetes.pem

下載最新版本的二進位制檔案

有兩種下載方式

方式一

從 github release 頁面 下載釋出版 tarball，解壓後再執行下載指令碼

$ wget https://github.com/kubernetes/kubernetes/releases/download/v1.6.0/kubernetes.tar.gz
$ tar -xzvf kubernetes.tar.gz
...
$ cd kubernetes
$ ./cluster/get-kube-binaries.sh
...

方式二

從 CHANGELOG頁面 下載 client 或 server tarball 檔案

server

的 tarball kubernetes-server-linux-amd64.tar.gz 已經包含了 client(kubectl) 二進位制檔案，所以不用單獨下載kubernetes-client-linux-amd64.tar.gz檔案；

$ # wget https://dl.k8s.io/v1.6.0/kubernetes-client-linux-amd64.tar.gz
$ wget https://dl.k8s.io/v1.6.0/kubernetes-server-linux-amd64.tar.gz
$ tar -xzvf kubernetes-server-linux-amd64.tar.gz
...
$ cd kubernetes
$ tar -xzvf  kubernetes-src.tar.gz

將二進位制檔案拷貝到指定路徑

$ cp -r server/bin/{kube-apiserver,kube-controller-manager,kube-scheduler,kubectl,kube-proxy,kubelet} /root/local/bin/

配置和啟動 Kube-Apiserver

建立 kube-apiserver的service配置檔案

serivce配置檔案/usr/lib/systemd/system/kube-apiserver.service內容：

[Unit]
Description=Kubernetes API Service
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target
After=etcd.service

[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/apiserver
ExecStart=/usr/bin/kube-apiserver \
	    $KUBE_LOGTOSTDERR \
	    $KUBE_LOG_LEVEL \
	    $KUBE_ETCD_SERVERS \
	    $KUBE_API_ADDRESS \
	    $KUBE_API_PORT \
	    $KUBELET_PORT \
	    $KUBE_ALLOW_PRIV \
	    $KUBE_SERVICE_ADDRESSES \
	    $KUBE_ADMISSION_CONTROL \
	    $KUBE_API_ARGS
Restart=on-failure
Type=notify
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

/etc/kubernetes/config檔案的內容為：

###
# kubernetes system config
#
# The following values are used to configure various aspects of all
# kubernetes services, including
#
#   kube-apiserver.service
#   kube-controller-manager.service
#   kube-scheduler.service
#   kubelet.service
#   kube-proxy.service
# logging to stderr means we get it in the systemd journal
KUBE_LOGTOSTDERR="--logtostderr=true"

# journal message level, 0 is debug
KUBE_LOG_LEVEL="--v=0"

# Should this cluster be allowed to run privileged docker containers
KUBE_ALLOW_PRIV="--allow-privileged=true"

# How the controller-manager, scheduler, and proxy find the apiserver
#KUBE_MASTER="--master=http://sz-pg-oam-docker-test-001.tendcloud.com:8080"
KUBE_MASTER="--master=http://172.20.0.113:8080"

該配置檔案同時被kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy使用。

apiserver配置檔案/etc/kubernetes/apiserver內容為：

###
## kubernetes system config
##
## The following values are used to configure the kube-apiserver
##
#
## The address on the local server to listen to.
#KUBE_API_ADDRESS="--insecure-bind-address=sz-pg-oam-docker-test-001.tendcloud.com"
KUBE_API_ADDRESS="--advertise-address=172.20.0.113 --bind-address=172.20.0.113 --insecure-bind-address=172.20.0.113"
#
## The port on the local server to listen on.
#KUBE_API_PORT="--port=8080"
#
## Port minions listen on
#KUBELET_PORT="--kubelet-port=10250"
#
## Comma separated list of nodes in the etcd cluster
KUBE_ETCD_SERVERS="--etcd-servers=https://172.20.0.113:2379,172.20.0.114:2379,172.20.0.115:2379"
#
## Address range to use for services
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
#
## default admission control policies
KUBE_ADMISSION_CONTROL="--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota"
#
## Add your own!
KUBE_API_ARGS="--authorization-mode=RBAC --runtime-config=rbac.authorization.k8s.io/v1beta1 --kubelet-https=true --experimental-bootstrap-token-auth --token-auth-file=/etc/kubernetes/token.csv --service-node-port-range=30000-32767 --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem --client-ca-file=/etc/kubernetes/ssl/ca.pem --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem --etcd-cafile=/etc/kubernetes/ssl/ca.pem --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem --enable-swagger-ui=true --apiserver-count=3 --audit-log-maxage=30 --audit-log-maxbackup=3 --audit-log-maxsize=100 --audit-log-path=/var/lib/audit.log --event-ttl=1h"
  • --authorization-mode=RBAC 指定在安全埠使用 RBAC 授權模式，拒絕未通過授權的請求；
  • kube-scheduler、kube-controller-manager 一般和 kube-apiserver 部署在同一臺機器上，它們使用非安全埠和 kube-apiserver通訊;
  • kubelet、kube-proxy、kubectl 部署在其它 Node 節點上，如果通過安全埠訪問 kube-apiserver，則必須先通過 TLS 證書認證，再通過 RBAC 授權；
  • kube-proxy、kubectl 通過在使用的證書裡指定相關的 User、Group 來達到通過 RBAC 授權的目的；
  • 如果使用了 kubelet TLS Boostrap 機制，則不能再指定 --kubelet-certificate-authority、--kubelet-client-certificate 和 --kubelet-client-key 選項，否則後續 kube-apiserver 校驗 kubelet 證書時出現 ”x509: certificate signed by unknown authority“ 錯誤；
  • --admission-control 值必須包含 ServiceAccount；
  • --bind-address 不能為 127.0.0.1；
  • runtime-config配置為rbac.authorization.k8s.io/v1beta1，表示執行時的apiVersion；
  • --service-cluster-ip-range 指定 Service Cluster IP 地址段，該地址段不能路由可達；
  • 預設情況下 kubernetes 物件儲存在 etcd /registry 路徑下，可以通過 --etcd-prefix引數進行調整；

啟動kube-apiserver

$ systemctl daemon-reload
$ systemctl enable kube-apiserver
$ systemctl start kube-apiserver
$ systemctl status kube-apiserver

配置和啟動 Kube-Controller-Manager

建立 kube-controller-manager的serivce配置檔案

檔案路徑/usr/lib/systemd/system/kube-controller-manager.service

Description=Kubernetes Controller Manager
Documentation=https://github.com/GoogleCloudPlatform/kubernetes

[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/controller-manager
ExecStart=/usr/bin/kube-controller-manager \
	    $KUBE_LOGTOSTDERR \
	    $KUBE_LOG_LEVEL \
	    $KUBE_MASTER \
	    $KUBE_CONTROLLER_MANAGER_ARGS
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

配置檔案/etc/kubernetes/controller-manager。

###
# The following values are used to configure the kubernetes controller-manager

# defaults from config and apiserver should be adequate

# Add your own!
KUBE_CONTROLLER_MANAGER_ARGS="--address=127.0.0.1 --service-cluster-ip-range=10.254.0.0/16 --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/ssl/ca.pem --cluster-signing-key-file=/etc/kubernetes/ssl/ca-key.pem  --service-account-private-key-file=/etc/kubernetes/ssl/ca-key.pem --root-ca-file=/etc/kubernetes/ssl/ca.pem --leader-elect=true"
  • --service-cluster-ip-range 引數指定 Cluster 中 Service 的CIDR範圍，該網路在各 Node 間必須路由不可達，必須和 kube-apiserver 中的引數一致；
  • --cluster-signing-* 指定的證書和私鑰檔案用來簽名為 TLS BootStrap 建立的證書和私鑰；
  • --root-ca-file 用來對 kube-apiserver 證書進行校驗，指定該引數後，才會在Pod 容器的 ServiceAccount 中放置該 CA 證書檔案；
  • --address 值必須為 127.0.0.1，因為當前 kube-apiserver 期望 scheduler 和 controller-manager 在同一臺機器，否則：
  $ kubectl get componentstatuses
  NAME                 STATUS      MESSAGE                                                                                        ERROR
  scheduler            Unhealthy   Get http://127.0.0.1:10251/healthz: dial tcp 127.0.0.1:10251: getsockopt: connection refused   
  controller-manager   Healthy     ok                                                                                             
  etcd-2               Unhealthy   Get http://172.20.0.113:2379/health: malformed HTTP response "\x15\x03\x01\x00\x02\x02"        
  etcd-0               Healthy     {"health": "true"}                                                                             
  etcd-1               Healthy     {"health": "true"}

啟動 Kube-Controller-Manager

$ systemctl daemon-reload
$ systemctl enable kube-controller-manager
$ systemctl start kube-controller-manager

配置和啟動 Kube-Scheduler

建立 kube-scheduler的serivce配置檔案

檔案路徑/usr/lib/systemd/system/kube-scheduler.serivce。

[Unit]
Description=Kubernetes Scheduler Plugin
Documentation=https://github.com/GoogleCloudPlatform/kubernetes

[Service]
EnvironmentFile=-/etc/kubernetes/config
EnvironmentFile=-/etc/kubernetes/scheduler
ExecStart=/usr/bin/kube-scheduler \
            $KUBE_LOGTOSTDERR \
            $KUBE_LOG_LEVEL \
            $KUBE_MASTER \
            $KUBE_SCHEDULER_ARGS
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

配置檔案/etc/kubernetes/scheduler。

###
# kubernetes scheduler config

# default config should be adequate

# Add your own!
KUBE_SCHEDULER_ARGS="--leader-elect=true --address=127.0.0.1"
  • --address 值必須為 127.0.0.1，因為當前 kube-apiserver 期望 scheduler 和 controller-manager 在同一臺機器；

啟動 Kube-Scheduler

$ systemctl daemon-reload
$ systemctl enable kube-scheduler
$ systemctl start kube-scheduler

驗證 Master 節點功能

$ kubectl get componentstatuses
NAME                 STATUS    MESSAGE              ERROR
scheduler            Healthy   ok                   
controller-manager   Healthy   ok                   
etcd-0               Healthy   {"health": "true"}   
etcd-1               Healthy   {"health": "true"}   
etcd-2               Healthy   {"health": "true"}

後記

當時在配置過程中遇到了問題TLS認證相關的問題，其實就是因為配置apiserver時候etcd的協議寫成了http導致的，應該是用https。

究竟如何實現kubernetes master的高可用還需要繼續探索。

相關推薦

Kubernetes高可用Master節點安裝_Kubernetes中文社群

前言 這是和我一步步部署kubernetes叢集專案((fork自opsnull))中的一篇文章，下文是結合我之前部署kubernetes的過程產生的kuberentes環境，部署master節點的kube-apiserver、kube-controller-manager和kube-sche

關於Kubernetes Master高可用的一些策略_Kubernetes中文社群

Kubernetes高可用也許是完成了初步的技術評估，打算將生產環境遷移進Kubernetes叢集之前普遍面臨的問題。 為了減少因為伺服器當機引起的業務中斷，生產環境中的業務系統往往已經做好了高可用，而當引入Kubernetes這一套新的叢集管理系統之後， 伺服器不再是單一的個體，位於中央位置

CentOS 7上搭建安全、容災、高可用的etcd叢集_Kubernetes中文社群

【編者的話】etcd 是 CoreOS 團隊發起的開源專案，基於 Go 語言實現，做為一個分散式鍵值對儲存，通過分散式鎖，leader選舉和寫屏障(write barriers)來實現可靠的分散式協作。 本文目標是部署一個基於TLS（Self-signed certificates）的安全、快

基於Rancher進行Kubernetes的離線安裝_Kubernetes中文社群

1、環境準備 在進行Kubernetes部署之前，需要提供其要求的軟硬體環境。此文件描述的場景：在無法直接連線網際網路的情況下，如何進行安裝部署Kubernetes。 1.1 作業系統 作業系統推薦使用： Ubuntu 16.04 (64-bit) Red Hat Enterprise Li

原生加速中國區Kubernetes安裝_Kubernetes中文社群

教你如何在中國區加速部署k8s，且實現自定義設定擁有k8s映象的倉庫與其名稱空間。 概述 Kubernetes是一個強大的容器編排工具，幫助使用者在可伸縮性系統上可靠部署和執行容器化應用。在容器領域內，K8s已毋庸置疑成為了容器編排和管理的社群標準，連Docker官方都已宣佈支援K8s。在容器

Kubernetes 相容 CSI 做的工作_Kubernetes中文社群

他有兩個模式，一個模式是自己給 node 打上這個 annotation，並且在退出的時候把這個 annotation 去掉。 另一個模式是交給 kubelet 的 pluginswatcher 來管理， kubelet 自己會根據 device-driver-registrar 提供的 unix doma

使用CoreDNS實現Kubernetes基於DNS的服務發現_Kubernetes中文社群

1.Kubernetes基於DNS的服務發現 在Kubernetes叢集推薦使用Service Name作為服務的訪問地址，因此需要一個Kubernetes叢集範圍的DNS服務實現從Service Name到Cluster Ip的解析，這就是Kubernetes基於DNS的服務發現功能。 在從

民生銀行基於Kubernetes+GPU構建Tensorflow應用實踐_Kubernetes中文社群

左宇鵬 2014年畢業於北京工業大學計算機學院，曾就職於某大型國企從事資料庫運維工作。2018年3月加入民生銀行資訊科技部系統管理中心團隊，目前主要致力於基於kubernetes和docker的容器平臺和ceph分散式儲存的研究和運維工作。 背景 近年來，隨著人工智慧、機器學習、深度學習等技術

小紅書在Kubernetes容器環境的CD實踐_Kubernetes中文社群

前言 容器推出以來，給軟體開發帶來了極具傳染性的振奮和創新，並獲得了來自各個行業、各個領域的巨大的支援——從大企業到初創公司，從研發到各類IT人員等等。跨境知名電商小紅書隨著業務的鋪開，線上部署單元的數量急劇增加，以 Jenkins 呼叫指令碼進行檔案推送的部署模式已經不能適應需求。這一期實踐

Helm 成功逆襲，脫離Kubernetes，被CNCF納入麾下_Kubernetes中文社群

許多開發者在使用Kubernetes時，都會利用其內部的Helm，管理Kubernetes Charts，通過Helm工具，使用者可以簡化Kubernetes應用的部署和管理，提高效率。而寄生於Kubernetes的Helm隨著Kubernetes聲勢也逐漸壯大。經CNCF基金會的技術監督委員

Kubernetes 中的幾種儲存_Kubernetes中文社群

參考：https://kubernetes.io/docs/concepts/storage/volumes/ 一個執行中的容器，預設情況下，對檔案系統的寫入，都是發生在其分層檔案系統的可寫層的，一旦容器執行結束，所有寫入都會被丟棄。因此需要對持久化支援。 Kubernetes 中通過 Vol

91APP新零售平臺實踐分享：靠Kubernetes實現IT微服務架構_Kubernetes中文社群

儘管多數是.NET系統，91APP也積極擁抱輕量級容器技術，通過“鄉村包圍城市”的策略，新興系統先擁抱容器，下一步想轉型更高彈性的微服務架構，關鍵就是匯入Kubernetes來管理複雜的容器叢集 臺灣知名的新零售平臺供貨商91APP，已有超過1萬家品牌企業，通過91APP平臺經營電商生意。為了

Kubernetes 1.7.6 版本釋出_Kubernetes中文社群

[fluentd-gcp addon] Fluentd will trim lines exceeding 100KB instead of dropping them. (#52289, @crassirostris) Cluster Autoscaler 0.6.2 (#52359, @mwielgus

Kubernetes 1.7.4 版本釋出_Kubernetes中文社群

昨天Kubernetes 1.7.4 版本釋出了，相比1.7.3版本共有17處明顯變化，例如： 修復建立或更新ELB會修改全域性定義的Security Group Bug（＃49805，@ nbutton23） 修復kubefed在不同版本RBAC建立問題（＃50537，@liggitt）

Kubernetes 1.7.2 版本釋出_Kubernetes中文社群

Kubernetes 1.7.2 版本釋出了，該版本從1.7.1版本以來有15處修改，其中修復一個Pod BUG＃48786， 下載k8s 1.7.2版本，檢視 1.7 版本相關介紹。 以下是 1.7.2版本更新內容： Use port 20256 for node-problem-dete

Linkerd + Namerd，實現Kubernetes 叢集的灰度釋出_Kubernetes中文社群

主要內容源於 https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubernetes-part-iv-continuous-deployment-via-traffic-shifting/ ，砍掉了 Jenkins 等附加部分，更換了更

Aruba 儲存平臺統一了Kubernetes和OpenStack的SDS控制_Kubernetes中文社群

OpenSDS Aruba是儲存平臺中統一Kubernetes和OpenStack的儲存控制，可以使用基於主機副本或基於儲存的副本為終端使用者提供資料儲存服務。 2018年7月6日在舊金山OpenSDS社群宣佈釋出了Aruba控制器軟體，這是其用於SDS控制器的開源軟體的第一個版本。OpenS

Kubernetes 的審計日誌和採集_Kubernetes中文社群

基礎操作 一個正常執行的 Kubernetes 叢集，除了利用訪問控制對叢集操作的許可進行限制之外，對於操作過程的跟蹤審計也是比不可少的，圍繞不同的實體，例如使用者、節點以及各種工作負載進行觀測是很有必要的。Kubernetes 的 API Server 提供了審計日誌支援，利用審計日誌的方式

微軟開始試用Kubernetes管理Azure IoT Edge應用_Kubernetes中文社群

今年微軟開發者大會Build上，在整合Azure及Kubernetes的新應用領域上了許多新菜，除了簡化Kubernetes叢集部署工作，還推出原生健康檢查預覽版功能，逐漸完善Azure環境中使用Kubernetes的必備周邊工具。 Azure IoT Edge是什麼？ 邊緣計算是將雲端的計

Kubernetes(k8s)部署安全最佳實踐_Kubernetes中文社群

編者按：本文作者是來自 Aqua Security 的 Amir Jerbi 和 Michael Cherny，他們以大量的案例和經驗為基礎，總結並描述了 Kubernetes 部署中的最佳安全實踐。 Kubernetes 提供了很多能夠提高應用安全的方法。要進行這些配置，就要掌握 Kuber