連接上文
在上文已經(jīng)成功部署了etcd分布式數(shù)據(jù)庫、master01節(jié)點(diǎn)，
本文將承接上文的內(nèi)容，繼續(xù)部署Kubernetes集群中的 worker node 節(jié)點(diǎn)和 CNI 網(wǎng)絡(luò)插件
?1.? 部署 Worker Node 組件
?1.1 work node 組件部署前需了解的節(jié)點(diǎn)注冊(cè)機(jī)制
kubelet 采用 TLS Bootstrapping 機(jī)制，自動(dòng)完成到 kube-apiserver 的注冊(cè)，在 node 節(jié)點(diǎn)量較大或者后期自動(dòng)擴(kuò)容時(shí)非常有用。 ?
Master apiserver 啟用 TLS 認(rèn)證后，node 節(jié)點(diǎn) kubelet 組件想要加入集群，必須使用CA簽發(fā)的有效證書才能與 apiserver 通信，當(dāng) node 節(jié)點(diǎn)很多時(shí)，簽署證書是一件很繁瑣的事情。因此 Kubernetes 引入了 TLS bootstraping 機(jī)制來自動(dòng)頒發(fā)客戶端證書，kubelet 會(huì)以一個(gè)低權(quán)限用戶自動(dòng)向 apiserver 申請(qǐng)證書，kubelet 的證書由 apiserver 動(dòng)態(tài)簽署。
?? ?kubelet 首次啟動(dòng)通過加載 bootstrap.kubeconfig 中的用戶 Token 和 apiserver CA 證書發(fā)起首次 CSR 請(qǐng)求，這個(gè) Token 被預(yù)先內(nèi)置在 apiserver 節(jié)點(diǎn)的 token.csv 中，其身份為 kubelet-bootstrap 用戶和 system:kubelet-bootstrap 用戶組；想要首次 CSR 請(qǐng)求能成功（即不會(huì)被 apiserver 401 拒絕），則需要先創(chuàng)建一個(gè) ClusterRoleBinding，將 kubelet-bootstrap 用戶和 system:node-bootstrapper 內(nèi)置 ClusterRole 綁定（通過 kubectl get clusterroles 可查詢），使其能夠發(fā)起 CSR 認(rèn)證請(qǐng)求。
?
TLS bootstrapping 時(shí)的證書實(shí)際是由 kube-controller-manager 組件來簽署的，也就是說證書有效期是 kube-controller-manager 組件控制的；kube-controller-manager 組件提供了一個(gè) --experimental-cluster-signing-duration 參數(shù)來設(shè)置簽署的證書有效時(shí)間；默認(rèn)為 8760h0m0s，將其改為 87600h0m0s，即 10 年后再進(jìn)行 TLS bootstrapping 簽署證書即可。 ??
?也就是說 kubelet 首次訪問 API Server 時(shí)，是使用 token 做認(rèn)證，通過后，Controller Manager 會(huì)為 kubelet 生成一個(gè)證書，以后的訪問都是用證書做認(rèn)證了。
?
?1.2?Worker Node 組件部署步驟
//在所有 node 節(jié)點(diǎn)上操作
#創(chuàng)建kubernetes工作目錄
mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
?
#上傳 node.zip 到 /opt 目錄中，解壓 node.zip 壓縮包，獲得kubelet.sh、proxy.sh
cd /opt/
unzip node.zip
chmod +x kubelet.sh proxy.sh
?
//在 master01 節(jié)點(diǎn)上操作
#把 kubelet、kube-proxy 拷貝到 node 節(jié)點(diǎn)
cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root@192.168.50.21:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.50.22:/opt/kubernetes/bin/
?
#上傳 kubeconfig.sh 文件到 /opt/k8s/kubeconfig 目錄中，生成 kubeconfig 的配置文件
mkdir /opt/k8s/kubeconfig
?
cd /opt/k8s/kubeconfig
chmod +x kubeconfig.sh
./kubeconfig.sh 192.168.50.20?/opt/k8s/k8s-cert/
?
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.50.21:/opt/kubernetes/cfg/
scp bootstrap.kubeconfig kube-proxy.kubeconfig root@192.168.50.22:/opt/kubernetes/cfg/
?
#RBAC授權(quán)，使用戶 kubelet-bootstrap 能夠有權(quán)限發(fā)起 CSR 請(qǐng)求
kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
?
//在 node01 節(jié)點(diǎn)上操作
#啟動(dòng) kubelet 服務(wù)
cd /opt/
./kubelet.sh 192.168.50.21
ps aux | grep kubelet
?
//在 master01 節(jié)點(diǎn)上操作，通過 CSR 請(qǐng)求
#檢查到 node01 節(jié)點(diǎn)的 kubelet 發(fā)起的 CSR 請(qǐng)求，Pending 表示等待集群給該節(jié)點(diǎn)簽發(fā)證書
kubectl get csr
?
#通過 CSR 請(qǐng)求
kubectl certificate approve （上面選項(xiàng)中REQUESTOR的值 ?）
?
#Approved,Issued 表示已授權(quán) CSR 請(qǐng)求并簽發(fā)證書
kubectl get csr
?
?
#查看節(jié)點(diǎn)，由于網(wǎng)絡(luò)插件還沒有部署，節(jié)點(diǎn)會(huì)沒有準(zhǔn)備就緒 NotReady
kubectl get node
?
?
//在 node01 節(jié)點(diǎn)上操作
#加載 ip_vs 模塊
for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
?
#啟動(dòng)proxy服務(wù)
cd /opt/
./proxy.sh 192.168.50.21
ps aux | grep kube-proxy
?
注意：這里的notready是因?yàn)閚ode節(jié)點(diǎn)上的網(wǎng)絡(luò)插件還沒有部署好，所以會(huì)這樣顯示，
接下來會(huì)重點(diǎn)介紹k8s的網(wǎng)絡(luò)插件，再繼續(xù)部署?
node02節(jié)點(diǎn)同樣的操作
?2.?k8s的CNI網(wǎng)絡(luò)插件模式
2.1 k8s的三種網(wǎng)絡(luò)模式?
K8S 中 Pod 網(wǎng)絡(luò)通信：
（1）Pod 內(nèi)容器與容器之間的通信
在同一個(gè) Pod 內(nèi)的容器（Pod 內(nèi)的容器是不會(huì)跨宿主機(jī)的）共享同一個(gè)網(wǎng)絡(luò)命令空間，相當(dāng)于它們?cè)谕慌_(tái)機(jī)器上一樣，可以用 localhost 地址訪問彼此的端口。
（2）同一個(gè) Node 內(nèi) Pod 之間的通信
每個(gè) Pod 都有一個(gè)真實(shí)的全局 IP 地址，同一個(gè) Node 內(nèi)的不同 Pod 之間可以直接采用對(duì)方 Pod 的 IP 地址進(jìn)行通信，Pod1 與 Pod2 都是通過 Veth 連接到同一個(gè) docker0 網(wǎng)橋，網(wǎng)段相同，所以它們之間可以直接通信。
（3）不同 Node 上 Pod 之間的通信
Pod 地址與 docker0 在同一網(wǎng)段，docker0 網(wǎng)段與宿主機(jī)網(wǎng)卡是兩個(gè)不同的網(wǎng)段，且不同 Node 之間的通信只能通過宿主機(jī)的物理網(wǎng)卡進(jìn)行。
要想實(shí)現(xiàn)不同 Node 上 Pod 之間的通信，就必須想辦法通過主機(jī)的物理網(wǎng)卡 IP 地址進(jìn)行尋址和通信。因此要滿足兩個(gè)條件：Pod 的 IP 不能沖突；將 Pod 的 IP 和所在的 Node 的 IP 關(guān)聯(lián)起來，通過這個(gè)關(guān)聯(lián)讓不同 Node 上 Pod 之間直接通過內(nèi)網(wǎng) IP 地址通信。
Overlay Network：
疊加網(wǎng)絡(luò)，在二層或者三層基礎(chǔ)網(wǎng)絡(luò)上疊加的一種虛擬網(wǎng)絡(luò)技術(shù)模式，該網(wǎng)絡(luò)中的主機(jī)通過虛擬鏈路隧道連接起來（類似于VPN）。
VXLAN：
將源數(shù)據(jù)包封裝到UDP中，并使用基礎(chǔ)網(wǎng)絡(luò)的IP/MAC作為外層報(bào)文頭進(jìn)行封裝，然后在以太網(wǎng)上傳輸，到達(dá)目的地后由隧道端點(diǎn)解封裝并將數(shù)據(jù)發(fā)送給目標(biāo)地址。
?
2.2 ?Flannel 插件
Flannel 的功能是讓集群中的不同節(jié)點(diǎn)主機(jī)創(chuàng)建的 Docker 容器都具有全集群唯一的虛擬 IP 地址。
Flannel 是 Overlay 網(wǎng)絡(luò)的一種，也是將 TCP 源數(shù)據(jù)包封裝在另一種網(wǎng)絡(luò)包里面進(jìn)行路由轉(zhuǎn)發(fā)和通信，目前支持 udp、vxlan、 host-GW 3種數(shù)據(jù)轉(zhuǎn)發(fā)方式。
UDP（默認(rèn)方式，基于應(yīng)用轉(zhuǎn)發(fā)，配置簡單，性能最差） VXLAN（基于內(nèi)核轉(zhuǎn)發(fā)） Host-gw（性能最好、配置麻煩） ?
（1）Flannel UDP 模式（端口8285）?
udp模式的工作原理：（基于應(yīng)用進(jìn)行轉(zhuǎn)發(fā)，F(xiàn)lannel提供路由表，F(xiàn)lannel封裝、解封裝）
數(shù)據(jù)從 node01 上 Pod 的源容器中發(fā)出后，經(jīng)由所在主機(jī)的 docker0 虛擬網(wǎng)卡轉(zhuǎn)發(fā)到 flannel0 虛擬網(wǎng)卡，flanneld 服務(wù)監(jiān)聽在 flannel0 虛擬網(wǎng)卡的另外一端。
Flannel 通過 Etcd 服務(wù)維護(hù)了一張節(jié)點(diǎn)間的路由表。源主機(jī) node01 的 flanneld 服務(wù)將原本的數(shù)據(jù)內(nèi)容封裝到 UDP 中后根據(jù)自己的路由表通過物理網(wǎng)卡投遞給目的節(jié)點(diǎn) node02 的 flanneld 服務(wù)，數(shù)據(jù)到達(dá)以后被解包，然后直接進(jìn)入目的節(jié)點(diǎn)的 flannel0 虛擬網(wǎng)卡，之后被轉(zhuǎn)發(fā)到目的主機(jī)的 docker0 虛擬網(wǎng)卡，最后就像本機(jī)容器通信一樣由 docker0 轉(zhuǎn)發(fā)到目標(biāo)容器。
ETCD 之 Flannel 提供說明：
- 存儲(chǔ)管理Flannel可分配的IP地址段資源
- 監(jiān)控 ETCD 中每個(gè) Pod 的實(shí)際地址，并在內(nèi)存中建立維護(hù) Pod 節(jié)點(diǎn)路由表
（2） vxlan 模式（端口4789）
vxlan 是一種overlay（虛擬隧道通信）技術(shù)，通過三層網(wǎng)絡(luò)搭建虛擬的二層網(wǎng)絡(luò)，跟 udp 模式具體實(shí)現(xiàn)不太一樣：
1）udp模式是在用戶態(tài)實(shí)現(xiàn)的，數(shù)據(jù)會(huì)先經(jīng)過tun網(wǎng)卡，到應(yīng)用程序，應(yīng)用程序再做隧道封裝，再進(jìn)一次內(nèi)核協(xié)議棧，而vxlan是在內(nèi)核當(dāng)中實(shí)現(xiàn)的，只經(jīng)過一次協(xié)議棧，在協(xié)議棧內(nèi)就把vxlan包組裝好。
2）udp模式的tun網(wǎng)卡是三層轉(zhuǎn)發(fā)，使用tun是在物理網(wǎng)絡(luò)之上構(gòu)建三層網(wǎng)絡(luò)，屬于ip in udp，vxlan模式是二層實(shí)現(xiàn)， overlay是二層幀，屬于mac in udp。
3）vxlan由于采用mac in udp的方式，所以實(shí)現(xiàn)起來會(huì)涉及mac地址學(xué)習(xí)，arp廣播等二層知識(shí)，udp模式主要關(guān)注路由
?
Flannel VXLAN模式跨主機(jī)的工作原理：（Flannel提供路由表，由內(nèi)核封裝、解封裝）
1、數(shù)據(jù)幀從主機(jī)A上Pod的源容器中發(fā)出后，經(jīng)由所在主機(jī)的docker0/cni0 網(wǎng)絡(luò)接口轉(zhuǎn)發(fā)到flannel.1 接口
2、flannel.1 收到數(shù)據(jù)幀后添加VXLAN 頭部，封裝在UDP報(bào)文中
3、主機(jī)A通過物理網(wǎng)卡發(fā)送封包到主機(jī)B的物理網(wǎng)卡中
4、主機(jī)B的物理網(wǎng)卡再通過VXLAN 默認(rèn)端口8472轉(zhuǎn)發(fā)到flannel.1 接口進(jìn)行解封裝
（官方給出的預(yù)設(shè)接口為4789，而實(shí)際運(yùn)用的其實(shí)為8472端口）
5、解封裝以后，內(nèi)核將數(shù)據(jù)幀發(fā)送到Cni0， 最后由Cni0 發(fā)送到橋接到此接口的容器B中。
?
3) UDP和VXLAN的區(qū)別?
由于UDP模式是在用戶態(tài)做轉(zhuǎn)發(fā)（即基于應(yīng)用進(jìn)行轉(zhuǎn)發(fā)，由應(yīng)用程序進(jìn)行封裝和解封裝），會(huì)多一次報(bào)文隧道封裝，因此性能上會(huì)比在內(nèi)核態(tài)做轉(zhuǎn)發(fā)的VXLAN模式差。
UDP和VXLAN的區(qū)別：
UDP基于應(yīng)用程序進(jìn)行轉(zhuǎn)發(fā)，由應(yīng)用程序進(jìn)行封裝和解封裝；VXLAN由內(nèi)核進(jìn)行封裝和解封裝，內(nèi)核效率比應(yīng)用程序要高，所以VXLAN比UDP要快。
UDP是數(shù)據(jù)包，VXLAN是數(shù)據(jù)幀。
UDP的網(wǎng)卡Flannel0，VXLAN的網(wǎng)卡Flannel.1。
?
（4）知識(shí)延申：vlan和vxlan的區(qū)別?
1）vxlan支持更多的二層網(wǎng)絡(luò)
vlan使用12位bit表示vlan ID，因此最多支持2^12=4096個(gè)vlan（可用數(shù)量為4094）
vxlan使用的ID使用24位bit，最多可以支持2^24個(gè)
2）vxlan對(duì)已有的網(wǎng)絡(luò)路徑利用效率更高
vlan使用STP（spanning tree protocol）避免環(huán)路，會(huì)將一半的網(wǎng)絡(luò)路徑阻塞。
vxlan的數(shù)據(jù)包封裝成UDP通過網(wǎng)絡(luò)層傳輸，可以使用所有的網(wǎng)絡(luò)路徑。
3）vxlan可以防止物理交換機(jī)Mac表耗盡
vlan需要在交換機(jī)的Mac表中記錄Mac物理地址。
vxlan采用隧道機(jī)制，Mac物理地址不需記錄在交換機(jī)。
4）VXLAN在一定程度上可以實(shí)現(xiàn)邏輯網(wǎng)絡(luò)拓?fù)浜臀锢砭W(wǎng)絡(luò)拓?fù)涞慕怦?/strong>
VXLAN技術(shù)通過隧道技術(shù)在物理的三層網(wǎng)絡(luò)中虛擬二層網(wǎng)絡(luò)，處于VXL AN網(wǎng)絡(luò)的終端無法察覺到VXL AN的通信過程，這樣也就使得邏輯網(wǎng)絡(luò)拓?fù)浜臀锢砭W(wǎng)絡(luò)拓?fù)鋵?shí)現(xiàn)了一定程度的解耦，網(wǎng)絡(luò)拓?fù)涞呐渲脤?duì)于物理設(shè)備的配置的依賴程度有所降低，配置更靈活更方便。
5）VXLAN技術(shù)還具有多租戶支持的特性
VLAN技術(shù)僅僅解決了二層網(wǎng)絡(luò)廣播域分割的問題，而VXL AN技術(shù)還具有多租戶支持的特性，通過VXLAN分割，各個(gè)租戶可以獨(dú)立組網(wǎng)、通信，地址分配方面和多個(gè)租戶之間地址沖突的問題也得到了解決。
?
2.3??Calico 插件
（1） k8s組網(wǎng)方案對(duì)比?
1）flannel 方案：
需要在每個(gè)節(jié)點(diǎn)_上把發(fā)向容器的數(shù)據(jù)包進(jìn)行封裝后，再用隧道將封裝后的數(shù)據(jù)包發(fā)送到運(yùn)行著目標(biāo)Pod的node節(jié)點(diǎn)上。目標(biāo)node節(jié)點(diǎn)再負(fù)責(zé)去掉封裝，將去除封裝的數(shù)據(jù)包發(fā)送到目標(biāo)Pod上。數(shù)據(jù)通信性能則大受影響。
2）calico方案：
Calico不使用隧道或NAT來實(shí)現(xiàn)轉(zhuǎn)發(fā)，而是把Host當(dāng)作Internet中的路由器，使用BGP同步路由，并使用iptables來做安全訪問策略，完成跨Host轉(zhuǎn)發(fā)來。
采用直接路由的方式，這種方式性能損耗最低，不需要修改報(bào)文數(shù)據(jù)，但是如果網(wǎng)絡(luò)比較復(fù)雜場(chǎng)景下，路由表會(huì)很復(fù)雜，對(duì)運(yùn)維同事提出了較高的要求。
?
（2）Calico的組成和工作原理
基于三層路由表進(jìn)行轉(zhuǎn)發(fā)，不需要封裝和解封裝。
Calico主要由三個(gè)部分組成：
- Calico CNI插件：主要負(fù)責(zé)與kubernetes對(duì)接，供kubelet 調(diào)用使用。
- Felix：負(fù)責(zé)維護(hù)宿主機(jī)上的路由規(guī)則、FIB轉(zhuǎn)發(fā)信息庫等。
- BIRD：負(fù)責(zé)分發(fā)路由規(guī)則，類似路由器。
- Confd：配置管理組件。
Calico工作原理：
1 Calico是通過路由表來維護(hù)每個(gè)pod的通信。
2 Calico 的CNI插件會(huì)為每個(gè)容器設(shè)置一個(gè) veth pair設(shè)備，然后把另一端接入到宿主機(jī)網(wǎng)絡(luò)空間，由于沒有網(wǎng)橋，CNI插件還需要在宿主機(jī)上為每個(gè)容器的veth pair設(shè)備配置一條路由規(guī)則，用于接收傳入的IP包。
3 有了這樣的veth pair設(shè)備以后，容器發(fā)出的IP包就會(huì)通過veth pair設(shè)備到達(dá)宿主機(jī)，然后宿主機(jī)根據(jù)路由規(guī)則的下一跳地址，發(fā)送給正確的網(wǎng)關(guān)，然后到達(dá)目標(biāo)宿主機(jī)，再到達(dá)目標(biāo)容器
4 這些路由規(guī)則都是Felix 維護(hù)配置的，而路由信息則是Calico BIRD 組件基于BGP（動(dòng)態(tài)路由協(xié)議，可以選路）分發(fā)而來。
5 calico實(shí)際上是將集群里所有的節(jié)點(diǎn)都當(dāng)做邊界路由器來處理，他們一起組成了一個(gè)全互聯(lián)的網(wǎng)絡(luò)，彼此之間通過BGP交換路由，這些節(jié)點(diǎn)我們叫做BGP Peer。
?
2.4??flannel和calico對(duì)比?
flannel
配置方便，功能簡單，是基于overlay疊加網(wǎng)絡(luò)實(shí)現(xiàn)的（在原有數(shù)據(jù)包中再封裝一層），由于要進(jìn)行封裝和解封裝的過程對(duì)性能會(huì)有一定的影響，同時(shí)不具備網(wǎng)絡(luò)策略配置能力。
三種模式：UDP、 VXLAN、HOST-GW
默認(rèn)網(wǎng)段是：10.244.0.0/16
calico
功能強(qiáng)大，基于路由表進(jìn)行轉(zhuǎn)發(fā)，沒有封裝和解封裝的過程，對(duì)性能影響較小，具有網(wǎng)絡(luò)策略配置能力，但是路由表維護(hù)起來較為復(fù)雜。
模式：BGP、IPIP
默認(rèn)網(wǎng)段192 .168.0.0/16
目前比較常用的CNI網(wǎng)絡(luò)組件是flannel和calico，flannel的功能比較簡單，不具備復(fù)雜的網(wǎng)絡(luò)策略配置能力，calico是比較出色的網(wǎng)絡(luò)管理插件，但具備復(fù)雜網(wǎng)絡(luò)配置能力的同時(shí)，往往意味著本身的配置比較復(fù)雜，所以相對(duì)而言，比較小而簡單的集群使用flannel，考慮到日后擴(kuò)容，未來網(wǎng)絡(luò)可能需要加入更多設(shè)備，配置更多網(wǎng)絡(luò)策略，則使用calico更好。
（flannel在封裝和解封裝的過程中，會(huì)有性能損耗。calico沒有封裝解封裝過程，沒有性能損耗）
?
3.?部署網(wǎng)絡(luò)組件
?3.1 部署 flannel
//在node1節(jié)點(diǎn)上操作
#上傳 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目錄中
cd /opt/
docker load -i flannel.tar
?
mkdir /opt/cni/bin -p
tar zxvf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin
?
//在node2節(jié)點(diǎn)上操作
#上傳 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目錄中
cd /opt/
docker load -i flannel.tar
?
mkdir /opt/cni/bin -p
tar zxvf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin
?
?
//在 master01 節(jié)點(diǎn)上操作
#上傳 kube-flannel.yml 文件到 /opt/k8s 目錄中，部署 CNI 網(wǎng)絡(luò)
cd /opt/k8s
kubectl apply -f kube-flannel.yml?
?
kubectl get pods -n kube-system
?
?
kubectl get nodes
?文章來源地址http://www.zghlxwxcb.cn/news/detail-493291.html
3.2? ?部署 Calico?
??該網(wǎng)絡(luò)插件和flannel插件? 選擇其一部署即可（由于yaml文件過于復(fù)雜，本次就不再展示）
//在 master01 節(jié)點(diǎn)上操作
#上傳 calico.yaml 文件到 /opt/k8s 目錄中，部署 CNI 網(wǎng)絡(luò)
cd /opt/k8s
vim calico.yaml
#修改里面定義Pod網(wǎng)絡(luò)（CALICO_IPV4POOL_CIDR），與前面kube-controller-manager配置文件指定的cluster-cidr網(wǎng)段一樣
? ? - name: CALICO_IPV4POOL_CIDR ? ? ? #3878行
? ? ? value: "192.168.0.0/16" ? ? ? ? ? ? ? ? ? ? ?#3879行 ? ? 10.244.0.0/16
??
kubectl apply -f calico.yamlkubectl get pods -n kube-system
NAME ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? READY ? STATUS ? ?RESTARTS ? AGE
calico-kube-controllers-659bd7879c-4h8vk ? 1/1 ? ? Running ? 0 ? ? ? ? ?58s
calico-node-nsm6b ? ? ? ? ? ? ? ? ? ? ? ? ?1/1 ? ? Running ? 0 ? ? ? ? ?58s
calico-node-tdt8v ? ? ? ? ? ? ? ? ? ? ? ? ?1/1 ? ? Running ? 0 ? ? ? ? ?58s#等 Calico Pod 都 Running，節(jié)點(diǎn)也會(huì)準(zhǔn)備就緒
kubectl get nodes
?4.部署 CoreDNS
?CoreDNS：可以為集群中的 service 資源創(chuàng)建一個(gè)域名與 IP 的對(duì)應(yīng)關(guān)系解析。
service發(fā)現(xiàn)是k8s中的一個(gè)重要機(jī)制，其基本功能為：在集群內(nèi)通過服務(wù)名對(duì)服務(wù)進(jìn)行訪問，即需要完成從服務(wù)名到ClusterIP的解析。
k8s主要有兩種service發(fā)現(xiàn)機(jī)制：環(huán)境變量和DNS。沒有DNS服務(wù)的時(shí)候，k8s會(huì)采用環(huán)境變量的形式，但一旦有多個(gè)service，環(huán)境變量會(huì)變復(fù)雜，為解決該問題，我們使用DNS服務(wù)。
?
//在所有 node 節(jié)點(diǎn)上操作
#上傳 coredns.tar 到 /opt 目錄中
cd /opt
docker load -i coredns.tar
?
?
?文章來源：http://www.zghlxwxcb.cn/news/detail-493291.html
//在 master01 節(jié)點(diǎn)上操作
#上傳 coredns.yaml 文件到 /opt/k8s 目錄中，部署 CoreDNS?
cd /opt/k8s
kubectl apply -f coredns.yaml
?
kubectl get pods -n kube-system?
?
#DNS 解析測(cè)試
kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
?
/ # nslookup kubernetes
?
?
?
到了這里，關(guān)于【云原生】二進(jìn)制部署k8s集群（中）搭建node節(jié)點(diǎn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
