在開始之前，部署kubernetes叢集機器需要滿足以下幾個條件：
三台機器，作業系統 centos7.7（mini）
硬體配置：2gbram，2vcpu+，硬碟30gb+
叢集中所有機器之間網絡互通，且可通路外網。
采用nat網絡模型（依自己情況而定）
角色
ip
master
192.168.50.128
node0
node1
192.168.50.131
node2
192.168.50.132
軟體
版本
docker
19.03.12
kubernetes
1.18.6
etcd
3.4.9
主機
安裝元件
kube-apiserver，kube-controller-manager，kube-scheduler，etcd
kubelet，kube-proxy，etcd
master節點設定：
node1從節點設定：
node2從節點設定：
根據自己的節點命名情況來設定即可。
所有的節點都要添加hosts解析記錄
在master1節點生成密鑰對，并分發給其他的所有主機。
分發公鑰
通過下載下傳kernel image的rpm包進行安裝。
centos7：<code>http://elrepo.org/linux/kernel/el7/x86_64/rpms/</code>
編寫shell腳本更新核心
注意：一定要重新開機機器
驗證核心版本
第一條是臨時關閉，當然也可以使用第二條永久關閉，後者手動在<code>/etc/fstab</code>檔案中将<code>swap</code>挂載所在的行注釋掉即可。
使其立即生效
所有的節點均采用阿裡雲官網的base和epel源
将上面的第5-8步驟寫成shell腳本自動化快速完成
在其他的節點執行此腳本跑一下即可。
<code>etcd</code> 是一個分布式鍵值存儲系統，kubernetes使用<code>etcd</code>進行狀态和資料存儲，是以我們需要提前準備好<code>etcd</code>，不過為解決<code>etcd</code>單點故障問題，應采用叢集方式部署，這裡使用3台組建叢集。
為了節約資源利用，我這裡複用了兩個node節點，這樣子這三台主機便可組建一個叢集。當然，建議是獨立于k8s叢集之外部署，畢竟資料很重要。
etcd節點名稱
etcd-01
etcd-02
etcd-03
在kubernetes中，使用<code>openssl</code>生成證書會及其麻煩，如果我們可以把預先的證書機構、使用期等時間寫在json檔案裡面會更加高效和自動化。而<code>cfssl</code>就是這樣的一款工具，<code>cfssl</code>采用go語言編寫，是一個開源的證書管理工具，cfssljson用來從cfssl程式擷取json輸出，并将證書，密鑰，csr和bundle寫入檔案中。
在master節點操作：
授權并重命名：
移動到環境變量<code>/usr/local/bin</code>目錄下
由于kubernetes各元件需要使用x509證書對通信進行加密和認證，是以需要建立一套ca（certificate autority），是自簽名的根證書，用來簽名後續需要建立的其它證書；
這裡建立的ca是一個私有的内部認證中心，這個認證中心也需要一個ca證書和相應的ca私鑰，ca私鑰需要妥善保管，任何擁有它的人，都可以充當ca頒發證書。
再次強調一下，ca證書的請求json檔案是叢集所有節點共享的，隻需要建立一個，它後續建立的所有其它子ca證書的基礎，子ca證書都會根據這裡config中的<code>profile</code>段來生成證書的相關資訊；
ca-config.json 這個配置檔案隻是告訴我們頒發有什麼功能的證書，它用于配置證書的使用場景（profile）和具體參數(usage、過期時間、服務端認證、用戶端認證、加密等)。 default是預設政策，指定證書預設有效期是10年； profiles是定義使用場景，這裡隻是kubernetes，其實可以定義多個場景，分别指定不同的過期時間,使用場景等參數,後續簽名證書時使用某個profile; signing: 表示該證書可用于簽名其它證書,生成的ca.pem證書中的ca=true; server auth: 表示client 可以用該ca 對server 提供的證書進行校驗; client auth: 表示server 可以用該ca 對client 提供的證書進行驗證。
gencert：生成新的key（密鑰）和簽名證書 --initca：初始化一個新ca
<code>hosts</code>字段中ip為所有etcd節點的叢集内部通信ip，有幾個etcd節點，就寫多少個ip。當然，為友善後期擴容可以多些幾個預留的ip。
<code>gencert</code>: 生成新的key(密鑰)和簽名證書 <code>-initca</code>：初始化一個新ca <code>-ca</code>：指明ca的證書 <code>-ca-key</code>：指明ca的私鑰檔案 -<code>config</code>：指明請求證書的json檔案 <code>-profile</code>：與<code>config</code>中的<code>profile</code>對應，是指根據<code>config</code>中的<code>profile</code>段來生成證書的相關資訊
将前面兩步建立的證書都分發給其他etcd節點。
寫一個shell腳本，先在目标主機建立存放etcd證書的目錄，接着複制證書
補充：事實上隻需要分發<code>ca.pem</code>公鑰即可，<code>ca-key.pem</code>是私鑰，很多元件不需要，除非你確定使用它，你才分發到伺服器上面，以免造成私鑰洩露。不過我們不需要考慮太多，是以把私鑰也分發到了伺服器上面。
以下在節點1操作，部署完成後，将節點1生成的所有的檔案拷貝到節點2和節點3
這裡解釋一下配置
配置選項
選項說明
<code>etcd_name</code>
節點名稱，如果<code>etcd_initial_cluster_state="new"</code>這個值為<code>new</code>，哪麼<code>etcd_name</code>的參數值必須位于<code>etcd_initial_cluster</code>清單中
<code>etcd_data_dir</code>
指定節點的資料存儲目錄（包括：節點id、叢集id、叢集初始化配置、snapshot檔案等），如果未指定，會寫在目前目錄
<code>etcd_listen_peer_urls</code>
與叢集其它成員之間的通信位址
<code>etcd_listen_client_urls</code>
監聽本地端口，對外提供服務的位址
<code>etcd_initial_advertise_peer_urls</code>
通告給叢集其它節點，本地的對等url位址
<code>etcd_advertise_client_urls</code>
用戶端url，用于通告叢集的其餘部分資訊
<code>etcd_initial_cluster</code>
叢集中的所有資訊節點
<code>etcd_initial_cluster_token</code>
叢集的token，整個叢集中保持一緻
<code>etcd_initial_cluster_state</code>
初始化叢集狀态，預設為<code>new</code>
說明一下etcd服務啟動幾個選項的意義：
<code>--cert-file</code>
用戶端與伺服器之間tls證書檔案的路徑
<code>--key-file</code>
用戶端與伺服器之間tls密鑰檔案的路徑
<code>--peer-cert-file</code>
對等伺服器tls證書檔案的路徑
--peer-key-file`
對等伺服器tls密鑰檔案的路徑
<code>--trusted-ca-file</code>
簽名client證書的ca證書，用于驗證client證書
<code>--peer-trusted-ca-file</code>
簽名對等伺服器證書的ca證書。
節點1的配置檔案和systemd啟動腳本都設定好了，是以現在傳輸一下節點2和節點3的服務配置
其他另外節點2和節點3分别修改etcd.conf配置檔案中的節點名稱和目前伺服器ip
節點2的etcd配置檔案
節點3的etcd配置檔案
在master節點執行一個腳本來。
檢視叢集狀态
如果列印的每個etcd節點顯示都為<code>healthy</code>，說明叢集部署成功。如有問題就查messages日志
檢視叢集成員
所有node節點都部署docker服務
方法：浏覽器打開<code>mirrors.aliyun.com</code>網站，找到docker-ce，即可看到鏡像倉庫yum源
寫個腳本執行友善
列出所有可以安裝的版本
這裡我們安裝18.09版本的docker-ce
檢視版本号，檢測docker是否安裝成功
上面的這種檢視docker client的版本的。建議使用下面這種方法檢視docker-ce版本号，這種方法把docker的client端和server端的版本号檢視的一清二楚。
預設的鏡像倉庫位址是docker官方的，國内通路異常緩慢，是以更換為個人阿裡雲的源。
由于重新加載docker倉庫源，是以需要重新開機docker
我們操作的流程是
制作叢集證書
部署<code>kube-apiserver</code>元件
部署<code>kube-controller-manager</code>元件
部署<code>kube-scheduler</code>元件
現在我們建立一套kubernetes叢集的根ca證書。用于簽發所有的k8s元件。
将上面臨時目錄生成的證書都複制在kubernetes的證書目錄下：
kubernetes現托管在github上面，我們可以看到kubernetes任何版本的更新、下載下傳等資訊
點選右側的<code>releases</code>按鈕，即可看到k8s版本，可以看到目前已經釋出了671次版本。
目前最新的文檔版本是1.18.5。不過這節課我示範的是1.18.4版本。
隻需要下載下傳一個server包就夠了，包含了master和worker node二進制檔案
詳情介紹：<code>https://github.com/kubernetes/kubernetes/blob/master/changelog/changelog-1.18.md</code>
下載下傳連結：<code>https://dl.k8s.io/v1.18.4/kubernetes-server-linux-amd64.tar.gz</code>
考慮到科學上網問題，是以給大家介紹一個連結：<code>https://storage.googleapis.com/kubernetes-release/release/v1.18.4/kubernetes-server-linux-amd64.tar.gz</code>
kubernetes證書路徑是<code>/etc/kubernetes/ssl</code> 配置檔案路徑是<code>/etc/kubernetes/cfg</code> 二進制可執行程式包直接放在環境變量<code>/usr/local/bin</code> 日志路徑是<code>/var/log/kubernetes</code>
建立<code>kube-apiserver</code>配置檔案
為了使用eof保留換行符，是以要寫兩個<code>\\</code>
配置檔案詳細解釋如下：
<code>--logtostderr=false</code>
輸出日志到檔案中（檔案路徑由<code>--log-dir</code>指定），不輸出到标準錯誤控制台
<code>--v=2</code>
指定輸出日志的級别
<code>--advertise-address</code>
向叢集成員通知 apiserver 消息的 ip 位址，這個位址必須能夠被叢集中其他成員通路，如果 ip 位址為空，将會使用 <code>--bind-address</code>，如果未指定<code>--bind-address</code>，将會使用主機的預設接口位址
<code>--etcd-servers</code>
連接配接的 etcd 伺服器清單 , 形式為（<code>scheme://ip:port</code>)，使用逗号分隔
<code>--etcd-cafile</code>
用于etcd 通信的 ssl ca 檔案
<code>--etcd-certfile</code>
用于 etcd 通信的的 ssl 證書檔案
<code>--etcd-keyfile</code>
用于 etcd 通信的 ssl 密鑰檔案
<code>--service-cluster-ip-range</code>
service網絡位址配置設定 ，cidr 表示的 ip 範圍，服務的 cluster ip 将從中配置設定， 一定不要和配置設定給 nodes 和 pods 的 ip 範圍産生重疊
<code>--bind-address</code>
監聽 --seure-port 的 ip 位址，被關聯的接口必須能夠被叢集其它節點和 cli/web 用戶端通路，如果為空，則将使用所有接口（<code>0.0.0.0</code>）
<code>--secure-port=6443</code>
用于監聽具有認證授權功能的 https 協定的端口，預設值是6443
<code>--allow-privileged</code>
是否啟用授權功能
--service-node-port-range
service使用的端口範圍
<code>--default-not-ready-toleration-seconds</code>
表示 notready狀态的容忍度秒數
<code>--default-unreachable-toleration-seconds</code>
表示 unreachable狀态的容忍度秒數：
<code>--max-mutating-requests-inflight=2000</code>
在給定時間内進行中可變請求的最大數量，當超過該值時，服務将拒絕所有請求，0 值表示沒有限制（預設值 200）
<code>--default-watch-cache-size=200</code>
預設監視緩存大小，0 表示對于沒有設定預設監視大小的資源，将禁用監視緩存
<code>--delete-collection-workers=2</code>
用于 deletecollection 調用的工作者數量，這被用于加速 namespace 的清理( 預設值 1)
<code>--enable-admission-plugins</code>
資源限制的相關配置
<code>--authorization-mode</code>
在安全端口上進行權限驗證的插件的順序清單，以逗号分隔的清單，包括：alwaysallow,alwaysdeny,abac,webhook,rbac,node.（預設值 "alwaysallow"）
<code>--enable-bootstrap-token-auth</code>
啟用此選項以允許 'kube-system' 命名空間中的<code>'bootstrap.kubernetes.io/token'</code> 類型密鑰可以被用于 tls 的啟動認證
<code>--token-auth-file</code>
聲明bootstrap token檔案
<code>--kubelet-certificate-authority</code>
證書 authority 的檔案路徑
<code>--kubelet-client-certificate</code>
用于 tls 的用戶端證書檔案路徑
<code>--kubelet-client-key</code>
用于 tls 的用戶端證書密鑰檔案路徑
<code>--tls-private-key-file</code>
包含比對<code>--tls-cert-file</code>的 x509 證書私鑰的檔案
--service-account-key-file
包含 pem 加密的 x509 rsa 或 ecdsa 私鑰或公鑰的檔案，用于驗證 serviceaccount 令牌，如果設定該值，--tls-private-key-file 将會被使用，指定的檔案可以包含多個密鑰，并且這個标志可以和不同的檔案一起多次使用
<code>--audit-log-maxage</code>
基于檔案名中的時間戳，舊審計日志檔案的最長保留天數
<code>--audit-log-maxbackup</code>
舊審計日志檔案的最大保留個數
<code>--audit-log-maxsize</code>
審計日志被輪轉前的最大兆位元組數
<code>--audit-log-path</code>
如果設定，表示所有到apiserver的請求都會記錄到這個檔案中，‘-’表示寫入标準輸出
當叢集開啟了 tls 認證後，每個節點的 kubelet 元件都要使用由 apiserver 使用的 ca 簽發的有效證書才能與 apiserver 通訊；此時如果節點多起來，為每個節點單獨簽署證書将是一件非常繁瑣的事情； tls bootstrapping 功能就是讓 node節點上的kubelet元件先使用一個預定的低權限使用者連接配接到 apiserver，然後向 apiserver 申請證書，kubelet 的證書由 apiserver 動态簽署；
把上面的token值拿下來，後面的照着寫就行。
上面的變量引用符号<code>$</code>前面加上轉義符<code>\</code>，這是在使用eof寫入檔案需要注意的地方。
kube-controller-manager（k8s控制器管理器）是一個守護程序，它通過kube-apiserver監視叢集的共享狀态（kube-apiserver收集或監視到的一些叢集資源狀态，供kube-controller-manager或其它用戶端watch）, 控制器管理器并嘗試将目前的狀态向所定義的狀态遷移（移動、靠近），它本身是有狀态的，會修改叢集狀态資訊，如果多個控制器管理器同時生效，則會有一緻性問題，是以kube-controller-manager的高可用，隻能是主備模式，而kubernetes叢集是采用租賃鎖實作leader選舉，需要在啟動參數中加入 <code>--leader-elect=true</code>。
選項意義
<code>--leader-elect</code>
高可用時啟用選舉功能。這裡隻有一個controller-manager，是以不需要啟用選舉功能
<code>--master</code>
通過本地非安全本地端口8080連接配接apiserver
監控位址
<code>--allocate-node-cidrs</code>
是否應在node節點上配置設定和設定pod的cidr
<code>--cluster-cidr</code>
controller manager在啟動時如果設定了--cluster-cidr參數，那麼為每個沒有設定spec.podcidr的node節點生成一個cidr位址，并用該cidr位址設定節點的spec.podcidr屬性，防止不同的節點的cidr位址發生沖突
叢集services 的cidr範圍
<code>--cluster-signing-cert-file</code>
指定用于叢集簽發的所有叢集範圍内證書檔案（根證書檔案）
<code>--cluster-signing-key-file</code>
指定叢集簽發證書的key
<code>--root-ca-file</code>
如果設定，該根證書權限将包含service acount的toker secret，這必須是一個有效的pem編碼ca 包
<code>--service-account-private-key-file</code>
包含用于簽署service account token的pem編碼rsa或者ecdsa私鑰的檔案名
<code>--experimental-cluster-signing-duration</code>
證書簽發時間
排程器的職責主要是為新建立的pod在叢集中尋找最合适的node，并将pod排程到node上，scheduler排程器運作在master節點，它的核心功能是監聽apiserver來擷取節點上為空的pod，然後為pod建立一個binding訓示pod應該排程到哪個節點上，排程結果寫入apiserver。
所有元件都已經啟動成功，通過kubectl工具檢視目前叢集元件狀态：
看到第二列的狀态值都是<code>healthy</code>，說明master節點元件運作正常。
對于我們這裡的二進制部署的一主多從，在企業中适合測試環境，是以為了更多的複用機器資源，主master節點也應該作為node節點跑pod。
下面依然在master這個節點上操作，讓其再成為節點
複制二進制包
将kubernetes解壓的二進制包程式<code>kubelet，kube-proxy</code>複制到本地環境變量路徑下。
配置檔案解釋說明
<code>--hostname-override</code>
用來配置該節點在叢集中顯示的主機名，kubelet設定了<code>-–hostname-override</code>參數後，<code>kube-proxy</code>也需要設定，否則會出現找不到node的情況
<code>--container-runtime</code>
指定容器運作時引擎
<code>--network-plugin</code>
啟用cni網絡插件
<code>--kubeconfig</code>
kubelet作為用戶端使用的kubeconfig認證檔案，此檔案是由kube-controller-mananger生成的
<code>--bootstrap-kubeconfig</code>
指定令牌認證檔案
<code>--config</code>
指定kubelet配置檔案
<code>--cert-dir</code>
設定<code>kube-controller-manager</code>生成證書和私鑰的目錄
<code>--image-pull-progress-deadline</code>
鏡像拉取進度最大時間，如果在這段時間拉取鏡像沒有任何進展，将取消拉取，預設：1m0s
<code>--pod-infra-container-image</code>
每個pod中的<code>network/ipc</code>名稱空間容器将使用的鏡像
簡單說幾個比較重要的選項配置意義
<code>address</code>
kubelet 服務監聽的位址
<code>port: 10250</code>
kubelet 服務的端口，預設 <code>10250</code>
<code>readonlyport</code>
沒有認證/授權的隻讀 kubelet 服務端口 ，設定為 0 表示禁用，預設 `10255
<code>clusterdns</code>
dns 伺服器的ip位址清單
<code>clusterdomain</code>
叢集域名, kubelet 将配置所有容器除了主機搜尋域還将搜尋目前域
生成 kubelet bootstrap kubeconfig 配置檔案
拷貝到配置檔案路徑<code>/etc/kubernetes/cfg</code>
cni，全名叫做：容器網絡接口。是cncf旗下的一個項目，由一組用于配置容器的網絡接口的規範和庫組成。cni主要用于解決容器網絡互聯的配置并支援多種網絡模型。
此指令可以看到所有請求，所有為<code>pending</code>狀态，則是需要準許的。
把上面的指令的<code>name</code>字段的值拿過來。
檢視節點
注意：這裡的<code>status</code>狀态值還是<code>notready</code>，是因為網絡插件還沒有部署好。接着往下即可。
kube-proxy是什麼，這裡就不得不提前說下service，service是一組pod的抽象集合，它相當于一組pod的負載均衡器，負責将請求分發到對應的pod，kube-proxy就是負責service的實作的，當請求到達service時，它通過label關聯到後端并轉發到某個pod；kube-proxy提供了三種負載均衡模式：使用者空間、iptables、ipvs，我們采用的是iptables負載均衡模式。
簡單說一下上面配置的選項意義
選項配置
clientconnection
與kube-apiserver互動時的參數設定
burst: 200
臨時允許該事件記錄值超過qps設定值
kubeconfig
kube-proxy 用戶端連接配接 kube-apiserver 的 kubeconfig 檔案路徑設定
qps: 100
與kube-apiserver互動時的qps，預設值5
bindaddress
kube-proxy監聽位址
healthzbindaddress
用于檢查服務的ip位址和端口
metricsbindaddress
metrics服務的ip位址和端口。預設：127.0.0.1:10249
clustercidr
kube-proxy 根據 --cluster-cidr 判斷叢集内部和外部流量，指定 --cluster-cidr 或 --masquerade-all 選項後 kube-proxy 才會對通路 service ip 的請求做 snat
hostnameoverride
參數值必須與 kubelet 的值一緻，否則 kube-proxy 啟動後會找不到該 node，進而不會建立任何 ipvs 規則；
建立證書請求檔案
生成證書
kube-proxy是作為kube-apiserver的用戶端，由于我們啟用了tls，是以需要認證通路，這裡我們需要使用到之前生成的證書。
拷貝到配置檔案指定的路徑下：
在執行kubectl exec、run、logs 等指令時，apiserver會轉發到kubelet。這裡定義 rbac規則，授權apiserver調用kubelet api"
flannel是 coreos 團隊針對 kubernetes 設計的一個覆寫網絡（overlay network）工具，其目的在于幫助每一個使用 kuberentes 的 coreos 主機擁有一個完整的子網。 flannel通過給每台主控端配置設定一個子網的方式為容器提供虛拟網絡，它基于<code>linux tun/tap</code>，使用udp封裝ip包來建立overlay網絡，并借助etcd維護網絡的配置設定情況
事實上很多使用者都不能成功，因為國内網絡受限，是以可以這樣子來做。 修改hosts檔案，加上如下解析記錄
編輯鏡像源，預設的鏡像位址我們修改一下。把yaml檔案中所有的<code>quay.io</code>修改為 <code>quay-mirror.qiniu.com</code>
此時儲存儲存退出。在master節點執行此指令。
這樣子就可以成功拉取flannel鏡像了。當然你也可以直接使用我提供給大家的<code>kube-flannel.yml</code>檔案
檢視flannel是否正常
如果你想檢視flannel這些pod運作是否正常，使用如下指令：
注意：稍等1-3分鐘後，如果第三字段<code>status</code>不是處于<code>running</code>狀态的話，并且<code>status</code>字段數值一直在漸漸變大，說明flannel是異常的，需要排查問題所在。
目前節點狀态是<code>ready</code>，表示叢集節點現在是可用的。
如果有以下報錯：
或者是
上面的這些都表示是網絡問題不能拉取鏡像，我這裡給大家提前準備了flannel的鏡像。導入一下就可以了。
coredns用于叢集中pod解析service的名字，kubernetes基于coredns用于服務發現功能。
安裝coredns1.6.7（目前較新版本）。如果之前修改了podip的網段，那麼這裡需要自行修改此檔案的clusterip參數。其他可保持不變
檢視pod狀态
隻要能出結果，解析就是沒有問題的。
在master節點操作，把檔案遠端複制給node節點
在node1節點上操作
修改為<code>--hostname-override-=node1</code>
修改為<code>hostnameoverride: node1</code>
下面的是在<code>master</code>節點操作的
上面的<code>condition</code>為<code>pending</code>狀态的表示将要被加入叢集的節點。是以記錄前面的<code>name</code>字段
稍等兩分鐘
按照上面的前五步繼續執行即可。做完之後如下所示：
至此，二進制單節點叢集部署已經完成，接下來我們可以測試一下叢集是否可用。
現在我們在kubernetes叢集中建立一個nginx的pod，驗證是否能正常運作。
在master節點執行一下步驟：
現在我們檢視pod和service
列印的結果中，前半部分是pod相關資訊，後半部分是service相關資訊。我們看<code>service/nginx</code>這一行可以看出service暴漏給叢集的端口是<code>30249</code>。記住這個端口。
然後從pod的詳細資訊可以看出此時pod在<code>node2</code>節點之上。node2節點的ip位址是<code>192.168.50.132</code>
那現在我們通路一下。打開浏覽器(建議火狐浏覽器)，通路位址就是：http://192.168.50.132:30249
先把dashboard的配置檔案下載下傳下來。由于我們之前已經添加了hosts解析，是以可以下載下傳。
預設dashboard隻能叢集内部通路，修改service為nodeport類型，暴露到外部：
大概在此檔案的32-44行之間，修改為如下：
運作此yaml檔案
主要是看<code>status</code>這一列的值，如果是<code>running</code>，并且<code>restarts</code>字段的值為0（隻要這個值不是一直在漸漸變大），就是正常的，目前來看是沒有問題的。我們可以繼續下一步。
檢視此dashboard的pod運作所在的節點
從上面可以看出，<code>kubernetes-dashboard-9774cc786-ccvcf</code>運作所在的節點是<code>node2</code>上面，并且暴漏出來的端口是<code>30001</code>，是以通路位址是： https://192.168.50.132:30001
用火狐浏覽器通路，通路的時候會讓輸入token，從此處可以檢視到token的值。
把上面的token值輸入進去即可進去dashboard界面。
不過現在我們雖然可以登陸上去，但是我們權限不夠還檢視不了叢集資訊，因為我們還沒有綁定叢集角色，同學們可以先按照上面的嘗試一下，再來做下面的步驟
再次使用輸出的token登陸dashboard即可。