k8s 二進制安裝優化架構之部署負載均衡，加入master02

一? ? 實驗環境

二? ??部署 CoreDNS

1，所有node加載coredns.tar?鏡像? ?

2，在 master01 節點部署 CoreDNS?

3，?DNS 解析測試

4，?報錯分析

5，重新??DNS 解析測試

三? ? ? ?master02 節點部署

1，從master01?傳etcd?目錄到 master02 節點

2，從master01?傳? kubernetes? 目錄到 master02 節點

3，從master01傳/root/.kube到 master02 節點

4，?從master01?傳服務管理文件到 master02 節點

5，修改配置文件kube-apiserver中的IP

6,?master02 節點上啟動各服務并設置開機自啟

7,?master02? 將?可執行文件都做軟連接

8，驗證?master02?是否安裝成功

四? ? ?負載均衡部署

1，架構圖

2，k8s 集群做 nginx +keepalive 負載均衡高可用的必要性

3，?部署兩臺nginx?負載均衡服務器

3.1，配置nginx的官方在線yum源，配置本地nginx的yum源

3.2，?安裝nginx

3.3，修改nginx配置文件，配置四層反向代理負載均衡，指定k8s群集2臺master的節點ip和6443端口

3.4??檢查配置文件語法

3.5?啟動nginx服務，查看已監聽6443端口

4，部署keepalived服務?解決nginx?單點故障

4.1? 安裝keepalived

4.2?修改keepalived配置文件

4.3?創建nginx狀態檢查腳本

4.4?啟動keepalived服務

5,??使用一個VIP把node節點與master節點都關聯起來

5.1 修改node節點上的bootstrap.kubeconfig??配置文件為VIP

5.2?修改node節點上的kubelet.kubeconfig? 配置文件為VIP

5.3??修改node節點上的kube-proxy.kubeconfig配置文件為VIP

5.4??重啟kubelet和kube-proxy服務

6,? 查看nginx 和 node 、 master 節點的連接狀態

7，測試創建pod

7.1?測試創建pod

7.2?查看Pod的狀態信息

7.3?curl命令訪問

7.4?查看nginx日志

7.5? 查看service

五? ??部署 Dashboard

1，Dashboard 介紹

2，?準備Dashboard?和?metrics-scraper.tar

3，master01 節點上傳 recommended.yaml 文件到 /opt/k8s 目錄中

4,?執行?ymal?文件

5，創建service account并綁定默認cluster-admin管理員集群角色

6，?查看token 令牌

7，?瀏覽器登錄Dashboard?

8，在Dashboard? 創建6臺pod

六? ?總結

一? ? 實驗環境

k8s集群master01：192.168.217.66? ? kube-apiserver kube-controller-manager kube-scheduler etcd
k8s集群master02：192.168.217.77

?k8s集群node01：192.168.217.88? ? kubelet kube-proxy docker?
?k8s集群node02：192.168.217.99?

etcd集群節點1：192.168.217.66? ? etcd
etcd集群節點2：192.168.217.88? ? etcd

etcd集群節點3：192.168.217.99? ? etcd

?負載均衡nginx+keepalive01（master）：192.168.217.22
?負載均衡nginx+keepalive02（backup）：192.168.217.44

二? ??部署 CoreDNS

CoreDNS：可以為集群中的 service 資源創建一個域名與 IP 的對應關系解析

node加載coredns.tar?鏡像? ??

master?執行ymal?文件

1，所有node加載coredns.tar?鏡像? ?

拖入壓縮包

docker load -i coredns.tar?載入鏡像

2，在 master01 節點部署 CoreDNS?

上傳 coredns.yaml 文件到 /opt/k8s 目錄中，部署 CoreDNS

查看?kube-system? 的命名空間

3，?DNS 解析測試

kubectl run -it --rm dns-test --image=busybox:1.28.4 sh####################
--rm: 這個選項告訴 Kubernetes 當Pod中的容器終止時，自動刪除該Pod。這對于一次性任務特別有用，可以避免遺留不再需要的Pod。dns-test: 這是給新創建的 Pod 指定的名字sh: 這部分指定了在容器啟動后要執行的命令。在這里，sh 是Shell的命令，意味著啟動容器后會直接進入一個Shell環境。用戶可以通過這個Shell與容器內部進行交互，執行各種命令等

4，?報錯分析

如果出現以下報錯

需要添加 rbac的權限 ?直接使用kubectl綁定 ?clusteradmin 管理員集群角色 ?授權操作權限

在master01:

 kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous############   
返回結果
clusterrolebinding.rbac.authorization.k8s.io/cluster-system-anonymous created

kubectl create clusterrolebinding 命令用于在 Kubernetes 集群中創建一個新的 ClusterRoleBinding 資源。ClusterRoleBinding 將ClusterRole（一組權限）綁定到用戶、組或其他實體，決定了這些實體在集群范圍內能夠執行的操作。下面是給定命令的詳細解釋：

kubectl create clusterrolebinding: 指令部分，表示要創建一個新的 ClusterRoleBinding 對象。

cluster-system-anonymous: 這是新創建的 ClusterRoleBinding 的名稱。你可以自定義此名稱，以便于管理和識別該ClusterRoleBinding的目的或作用。

--clusterrole=cluster-admin: 這個選項指定了要綁定的ClusterRole。在這個例子中，使用的是 cluster-admin，這是Kubernetes內置的ClusterRole，擁有對整個集群的完全管理權限。這意味著通過此ClusterRoleBinding關聯的用戶或組將擁有所有可能的權限。

--user=system:anonymous: 這個選項指定了ClusterRoleBinding將應用到的用戶。在這個命令中，用戶是 system:anonymous。在Kubernetes中，system:anonymous 是一個特殊用戶，代表未認證的請求者，即任何未提供有效認證信息的訪問嘗試都會被視為這個用戶。通過這種方式，此命令實際上是在賦予所有未經身份驗證的訪問者集群管理員權限，這是一個非常危險的配置，通常不推薦在生產環境中使用，因為這會極大地降低集群的安全性。

總結起來，這條命令創建了一個名為 cluster-system-anonymous 的ClusterRoleBinding，將集群管理員（cluster-admin）權限賦予了匿名用戶（system:anonymous）。這是一種極端情況下的配置，實際操作中應謹慎使用此類權限分配，以免造成安全風險。

5，重新??DNS 解析測試

三? ? ? ?master02 節點部署

在企業里 master最少3臺有個leader

大體思路?是傳?master需要的

etcd? ? kubernetes? 目錄? ?以及/root/.kube(kubectl?的配置文件以及緩存)? ? ?以及所有服務的system?單元文件

最后一個一個啟動

1，從master01?傳etcd?目錄到 master02 節點

2，從master01?傳? kubernetes? 目錄到 master02 節點

3，從master01傳/root/.kube到 master02 節點

cache: 這個目錄通常用于存放由kubectl命令行工具緩存的各種數據，比如API資源的本地副本或者上次查詢的結果，以便提高后續命令的執行速度。這些信息幫助減少不必要的API服務器查詢，提升交互效率。

config: 這是一個非常重要的文件，全名為config.yaml或config（取決于操作系統顯示設置），它包含了Kubernetes配置信息，尤其是與集群連接相關的設置。這個文件定義了如何連接到Kubernetes API服務器（apiserver）、認證憑據（如token或client證書）、上下文（clusters）、用戶（users）以及默認的命名空間（namespace）等。當你使用kubectl命令行工具時，它會默認查找這個文件來確定如何與Kubernetes集群進行通信。

簡而言之，.kube/cache是kubectl用于緩存數據以提高效率的目錄，而.kube/config則是一個關鍵的配置文件，用于存儲與Kubernetes集群交互所需的認證和配置細節

4，?從master01?傳服務管理文件到 master02 節點

scp /usr/lib/systemd/system/{kube-apiserver,kube-controller-manager,kube-scheduler}.service root@master02:/usr/lib/systemd/system/

5，修改配置文件kube-apiserver中的IP

去master02

vim /opt/kubernetes/cfg/kube-apiserver

將第5行? ?7行? ?改成自己的ip

6,?master02 節點上啟動各服務并設置開機自啟

systemctl start kube-apiserver.service
systemctl enable kube-apiserver.service
systemctl start kube-controller-manager.service
systemctl enable kube-controller-manager.service
systemctl start kube-scheduler.service
systemctl enable kube-scheduler.service

7,?master02? 將?可執行文件都做軟連接

8，驗證?master02?是否安裝成功

查看node節點狀態

-o=wide：輸出額外信息；對于Pod，將輸出Pod所在的Node名
//此時在master02節點查到的node節點狀態僅是從etcd查詢到的信息，而此時node節點實際上并未與master02節點建立通信連接，因此需要使用一個VIP把node節點與master節點都關聯起來

四? ? ?負載均衡部署

1，架構圖

2，k8s 集群做 nginx +keepalive 負載均衡高可用的必要性

負載均衡器：

分攤master流量

且 node回包的時候 ?也是經過負載均衡器

所有master 不需要指向node

3，?部署兩臺nginx?負載均衡服務器

3.1，配置nginx的官方在線yum源，配置本地nginx的yum源

兩個nginx服務器

cat > /etc/yum.repos.d/nginx.repo << 'EOF'
[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
EOF

3.2，?安裝nginx

兩個nginx服務器

3.3，修改nginx配置文件，配置四層反向代理負載均衡，指定k8s群集2臺master的節點ip和6443端口

兩個nginx服務器

vim /etc/nginx/nginx.conf

stream {log_format  main  '$remote_addr $upstream_addr - [$time_local] $status $upstream_bytes_sent';access_log  /var/log/nginx/k8s-access.log  main;upstream k8s-apiserver {server 192.168.217.66:6443;server 192.168.217.77:6443;}server {listen 6443;proxy_pass k8s-apiserver;}
}

解釋：

這段配置是Nginx的一個配置片段，用于設置一個反向代理和負載均衡，特別是針對Kubernetes（k8s）API服務器的流量管理。下面逐行解釋各部分：

stream: 這里其實有一個小誤解，正確的配置應該是放在http塊中而非stream，因為log_format, access_log, upstream, 和 server 配置都是HTTP相關的，而不是TCP/UDP流處理。stream模塊用于處理四層協議（TCP/UDP）的負載均衡，而這里明顯是在配置HTTP七層協議的負載均衡。因此，下面的解釋基于它是HTTP配置的假設。

log_format main ...: 定義了名為main的日志格式，用于記錄客戶端IP地址(remote_addr)，上游服務器地址(remotea?ddr)，上游服務器地址(upstream_addr)，請求時間(time_local)，HTTP響應狀態碼(timel?ocal)，HTTP響應狀態碼(status)，以及發送給客戶端的字節數($upstream_bytes_sent)。

access_log /var/log/nginx/k8s-access.log main;: 指定了訪問日志的存儲位置為/var/log/nginx/k8s-access.log，并且使用前面定義的main日志格式來記錄日志。

upstream k8s-apiserver {...}: 定義了一個名為k8s-apiserver的上游服務器組（可以理解為真實服務器），包含兩個Kubernetes API服務器的地址：192.168.10.80:6443 和 192.168.10.20:6443。Nginx會根據負載均衡策略（默認是輪詢）將請求分發到這兩個地址之一。

server {...}: 定義了一個監聽在6443端口上的Nginx服務器塊。

listen 6443;: 指定該Nginx服務器監聽在6443端口，這通常是Kubernetes API服務器的默認端口。
proxy_pass k8s-apiserver;: 設置代理傳遞目標為之前定義的k8s-apiserver上游服務器組，這意味著所有到達Nginx此端口的請求會被轉發到這兩個Kubernetes API服務器之一。

總結來說，這段配置的作用是設置了一個Nginx作為Kubernetes API服務器的反向代理和負載均衡器，它監聽在6443端口，接收對Kubernetes API的請求，并將這些請求透明地分發到兩個Kubernetes API服務器實例上，同時記錄相關訪問日志。這樣不僅提升了Kubernetes API服務的可用性和響應能力，還便于日志審計和故障排查。

3.4??檢查配置文件語法

兩個nginx服務器

3.5?啟動nginx服務，查看已監聽6443端口

兩個nginx服務器

4，部署keepalived服務?解決nginx?單點故障

4.1? 安裝keepalived

兩個nginx服務器

4.2?修改keepalived配置文件

ng01

vim /etc/keepalived/keepalived.conf

注意此處vip?地址? 需要與master01? ?/opt/k8s/k8s-cert/k8s-cert.sh 中的vip?一致

vim /etc/keepalived/keepalived.conf
! Configuration File for keepalivedglobal_defs {# 接收郵件地址notification_email {acassen@firewall.locfailover@firewall.locsysadmin@firewall.loc}# 郵件發送地址notification_email_from Alexandre.Cassen@firewall.locsmtp_server 127.0.0.1smtp_connect_timeout 30router_id NGINX_MASTER       #ng01節點的為 NGINX_MASTER，ng02節點的為 NGINX_BACKUP
}#添加一個周期性執行的腳本
vrrp_script check_nginx {script "/etc/nginx/check_nginx.sh"  #指定檢查nginx存活的腳本路徑
}vrrp_instance VI_1 {state MASTER                        #ng01節點的為 MASTER，ng02節點的為 BACKUPinterface ens33                     #指定網卡名稱 ens33virtual_router_id 51        #指定vrid，兩個節點要一致priority 100                        #ng01節點的為 100，ng02節點的為 90advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {192.168.217.100/24      #指定 VIP}track_script {check_nginx                     #指定vrrp_script配置的腳本}
}

ng02
?

vim /etc/keepalived/keepalived.conf
! Configuration File for keepalivedglobal_defs {# 接收郵件地址notification_email {acassen@firewall.locfailover@firewall.locsysadmin@firewall.loc}# 郵件發送地址notification_email_from Alexandre.Cassen@firewall.locsmtp_server 127.0.0.1smtp_connect_timeout 30router_id NGINX_BACKUP       #ng01節點的為 NGINX_MASTER，ng02節點的為 NGINX_BACKUP
}#添加一個周期性執行的腳本
vrrp_script check_nginx {script "/etc/nginx/check_nginx.sh"  #指定檢查nginx存活的腳本路徑
}vrrp_instance VI_1 {state BACKUP                        #ng01節點的為 MASTER，ng02節點的為 BACKUPinterface ens33                     #指定網卡名稱 ens33virtual_router_id 51        #指定vrid，兩個節點要一致priority 90                 #ng01節點的為 100，ng02節點的為 90advert_int 1authentication {auth_type PASSauth_pass 1111}virtual_ipaddress {192.168.217.100/24      #指定 VIP}track_script {check_nginx                     #指定vrrp_script配置的腳本}
}

4.3?創建nginx狀態檢查腳本

兩個nginx服務器

vim /etc/nginx/check_nginx.sh

#!/bin/bash
#egrep -cv "grep|$$" 用于過濾掉包含grep 或者 $$ 表示的當前Shell進程ID，即腳本運行的當前進程ID號
count=$(ps -ef | grep nginx | egrep -cv "grep|$$")if [ "$count" -eq 0 ];thensystemctl stop keepalived
fi

加執行?權限

4.4?啟動keepalived服務

兩個nginx服務器

（一定要先啟動了nginx服務，再啟動keepalived服務）

查看VIP是否生成?ng01

5,??使用一個VIP把node節點與master節點都關聯起來

所有node

5.1 修改node節點上的bootstrap.kubeconfig??配置文件為VIP

vim bootstrap.kubeconfig?

5.2?修改node節點上的kubelet.kubeconfig? 配置文件為VIP

vim kubelet.kubeconfig

5.3??修改node節點上的kube-proxy.kubeconfig配置文件為VIP

vim kube-proxy.kubeconfig

5.4??重啟kubelet和kube-proxy服務

6,? 查看nginx 和 node 、 master 節點的連接狀態

ng01

ng02

7，測試創建pod

master01 節點

7.1?測試創建pod

創建nginx?pod

7.2?查看Pod的狀態信息

//READY為1/1，表示這個Pod中有1個容器
?

7.3?curl命令訪問

在對應網段的node節點上操作，可以直接使用瀏覽器或者curl命令訪問

node01

7.4?查看nginx日志

master01節點

網關訪問

7.5? 查看service

master01節點

五? ??部署 Dashboard

1，Dashboard 介紹

儀表板是基于Web的Kubernetes用戶界面。您可以使用儀表板將容器化應用程序部署到Kubernetes集群，對容器化應用程序進行故障排除，并管理集群本身及其伴隨資源。您可以使用儀表板來概述群集上運行的應用程序，以及創建或修改單個Kubernetes資源（例如deployment，job，daemonset等）。例如，您可以使用部署向導擴展部署，啟動滾動更新，重新啟動Pod或部署新應用程序。儀表板還提供有關群集中Kubernetes資源狀態以及可能發生的任何錯誤的信息。

2，?準備Dashboard?和?metrics-scraper.tar

node01? node02

準備壓縮包

加載Dashboard? 鏡像（可視化工具）

這是監控數據的

3，master01 節點上傳 recommended.yaml 文件到 /opt/k8s 目錄中

master01

#默認Dashboard只能集群內部訪問，修改Service為NodePort類型，暴露到外部：
kind: Service
apiVersion: v1
metadata:labels:k8s-app: kubernetes-dashboardname: kubernetes-dashboardnamespace: kubernetes-dashboard
spec:ports:- port: 443targetPort: 8443nodePort: 30001     #添加type: NodePort          #添加selector:k8s-app: kubernetes-dashboard

4,?執行?ymal?文件

master01

5，創建service account并綁定默認cluster-admin管理員集群角色

創建service account

kubectl create serviceaccount dashboard-admin -n kube-system

kubectl create serviceaccount dashboard-admin -n kube-system 是一個 Kubernetes 命令，用于在 Kubernetes 集群中創建一個新的服務賬戶（service account）。下面是對這個命令各部分的詳細解釋：

kubectl: 這是 Kubernetes 的命令行工具，用于與 Kubernetes 集群進行交互，執行各種管理任務，如部署應用、檢查集群狀態等。

create: 這是一個 kubectl 動作，表示你要創建一個新的資源對象，如 Pod、Service、Deployment 或者在這個情況下，是 ServiceAccount。

serviceaccount: 這個關鍵詞告訴 kubectl 你要創建的資源類型是 ServiceAccount。ServiceAccount 是 Kubernetes 中的一個特殊類型的對象，它用來為Pods提供身份和憑證，以便Pod內的進程能夠與Kubernetes API進行安全通信。

dashboard-admin: 這是你要創建的服務賬戶的名稱。在這個場景中，"dashboard-admin" 暗示這個服務賬戶可能被設計用來給 Kubernetes Dashboard 或其他需要訪問API權限的組件提供管理員級別的訪問權限，但具體權限由關聯的Role或ClusterRole決定。

-n kube-system: -n 或 --namespace 是一個選項，用于指定資源將被創建在哪個命名空間（namespace）中。在這里，命名空間是 kube-system。kube-system 是 Kubernetes 集群中的一個特殊命名空間，通常用于存放集群的核心組件和服務，如DNS、網絡插件、監控系統等。選擇 kube-system 表示這個服務賬戶將專用于該命名空間內的資源和服務。

綜上所述，這個命令的作用是在 Kubernetes 集群的 kube-system 命名空間中創建一個名為 dashboard-admin 的服務賬戶，它可能被設計用于為Kubernetes Dashboard或類似應用提供必要的API訪問權限。但請注意，實際的權限配置需要通過附加的Role或ClusterRole以及RoleBinding或ClusterRoleBinding來實現。

管理員賬號并賦權

kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin

kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin 是 Kubernetes 中的一個命令，用于創建一個集群角色綁定（ClusterRoleBinding）。這個命令的目的是賦予之前創建的服務賬戶特定的權限。下面是各部分的詳細解釋：

kubectl create clusterrolebinding: 該命令用于創建一個新的集群角色綁定。ClusterRoleBinding 是 Kubernetes 中的一種授權機制，它將 ClusterRole（定義了一組權限）綁定到用戶、組或服務賬戶上，并在整個集群范圍內生效。

dashboard-admin: 這是新創建的集群角色綁定的名稱。它作為一個標識符，方便后續管理和理解這個綁定的用途，這里暗示它與之前創建的 dashboard-admin 服務賬戶相關聯，用于給該服務賬戶分配權限。

--clusterrole=cluster-admin: 這個選項指定了要綁定的 ClusterRole 名稱。cluster-admin 是 Kubernetes 內置的一個超級管理員角色，擁有對整個集群的完全訪問權限。通過此選項，你實際上是將 cluster-admin 這一最廣泛的權限集賦予了即將綁定的對象。

--serviceaccount=kube-system:dashboard-admin: 這個選項指定了要授予上述ClusterRole的服務賬戶及其所在的命名空間。格式為 <namespace>:<serviceaccount-name>。在這個例子中，服務賬戶名為 dashboard-admin，位于 kube-system 命名空間。這意味著 kube-system 命名空間下的 dashboard-admin 服務賬戶將獲得 cluster-admin 角色所包含的所有權限。

綜上所述，這個命令的作用是創建一個集群角色綁定，它將 cluster-admin 這個擁有集群管理員權限的角色綁定給了 kube-system 命名空間下的 dashboard-admin 服務賬戶，從而使該服務賬戶在 Kubernetes 集群中具有了非常廣泛的管理權限。這通常用于需要高度訪問權限的組件，比如 Kubernetes Dashboard 的后端服務，但需要注意的是，這樣的設置應謹慎使用，以避免潛在的安全風險。

6，?查看token 令牌

這個就是Dashboard 令牌

查看token 令牌復制

kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')

這條命令是用來查詢 Kubernetes 集群中與 dashboard-admin 服務賬戶相關的秘密（secrets）詳細信息的。命令分為兩部分，我們逐一解析：

獲取 Secret 名稱:

kubectl -n kube-system get secret: 這部分命令用于列出?kube-system?命名空間中的所有秘密。
| awk '/dashboard-admin/{print $1}': 這里使用管道 (|) 將前一個命令的輸出作為?awk?命令的輸入。awk?是一個強大的文本分析工具，這里使用的規則是，如果輸出行中包含 "dashboard-admin"（這通常意味著與?dashboard-admin?服務賬戶相關的秘密），則打印該行的第一列（即Secret的名稱）。

描述 Secret 信息:

kubectl describe secrets -n kube-system $(...): 這部分利用上一步得到的 Secret 名稱（通過命令替換?$()?實現），在?kube-system?命名空間中執行?describe?命令來展示這些秘密的詳細信息。describe?命令提供了關于資源的更詳盡視圖，包括其元數據、標簽、選擇器等屬性，對于秘密來說，還會展示其類型、數據等敏感內容的加密表示。

總結來說，整個命令的作用是查找 kube-system 命名空間中與 dashboard-admin 服務賬戶相關的所有秘密，并詳細描述這些秘密的信息。這對于調試、審計或理解服務賬戶認證和授權設置特別有用。