kubeadm部署k8s_(Ansible）三分钟部署一套高可用/可扩展的kubeadm集群
介紹
容器的興起改變了我們開發，部署和維護軟件的方式。容器使我們能夠將構成應用程序的不同服務打包到單獨的容器中，并在一組虛擬機和物理機上部署這些容器。這就產生了容器編排工具，可以自動執行基于容器的應用程序的部署，管理，擴展和可用性。Kubernetes允許大規模部署和管理基于容器的應用程序。
Kubernetes的主要優點之一是如何通過使用容器的動態調度為基于容器的分布式應用程序帶來更高的可靠性和穩定性。但是，當組件或其主節點出現故障時，如何確保Kubernetes本身保持正常運行？
那就需要HA來完成了，相信大家也比較熟悉
為什么我們需要Kubernetes高可用性（HA）？
Kubernetes高可用性是關于建立Kubernetes及其支持組件的方式，它沒有單點故障。單個主群集很容易發生故障，而多主群集則使用多個主節點，每個主節點都可以訪問相同的工作節點。在單個主集群中，重要組件（如API服務器，控制器管理器）僅位于單個主節點上，如果失敗，則無法創建更多服務，pod等。但是，在Kubernetes HA環境下，這些重要組件將復制到多個主機（通常是三個主機），如果任何一個主機發生故障，其他主機將保持群集正常運行。
高可用性是可靠性工程的重要組成部分，重點在于使系統可靠并避免整個系統出現任何單點故障。乍一看，其實現看似相當復雜，但是高可用性為需要增強穩定性和可靠性的系統帶來了巨大優勢。使用高可用性群集是構建可靠基礎架構的最重要方面之一。
所以這里我自己寫了一套基于Ansible的kubeadm高可用k8s集群，并覆蓋了在生產當中的多個方方面面
說到集群部署方式這里也有很多人去使用二進制也有一部分人去使用kubeadm，這里我非常建議大家去使用kubeadm去部署k8s集群，也是官方推薦去使用的
為什么建議使用kubeadm部署k8s集群？
2015年夏天。Kubernetes1.0剛剛發布，但存在一個巨大的用戶體驗問題：沒有簡單的安裝方法。愿意嘗試Kubernetes的每個人都必須忍受弄清楚如何自行創建集群的麻煩。這不是一件容易的事，因為Kubernetes由多個服務組成，每個服務都必須以正確的方式進行配置。
最初，僅提供kube-up。這是一個僅用于測試目的的小型Shell腳本。但是很快就出現了各種各樣的解決方案-一些諸如kube-up之類的shell腳本，而其他工具（如Ansible，Chef，Puppet等）開始發揮作用。由于有了這些解決方案，kops，kubernetes-anywhere和kubespray變得更加廣泛地被使用和采用。但是，它們都不是完美的。社區開始在外界尋找靈感，并以Docker Swarm的形式找到了靈感。
是的，沒錯，Swarm易于部署。只需在單個節點上運行“ init”命令，然后使用打印的“ join”命令附加所有其他節點即可。Kubernetes社區中的許多人問自己：“為什么我們不能有一個同樣簡單的部署過程？” 這就是kubeadm的起源。
目的是提供盡可能簡單的用戶界面，但保留Kubernetes模塊化設計的一些好處。在設計過程的早期，決定由用戶負責提供CRI，kubelet守護程序和網絡插件-這些已超出了kubeadm的范圍。
除了處理最初的集群部署之外，kubeadm的設計還允許無縫升級，修改和拆除現有集群。用戶也可以選擇提供自己的etcd集群，也可以依靠kubeadm進行設置。
確定了這些設計目標后，Kubernetes的SIG（特殊興趣小組）集群生命周期就開始了kubeadm的工作。首次發布的版本是Kubernetes 1.5的一部分。從那時起，kubeadm一直穩步發展
目前，kubeadm可以單或多主（高可用性）模式部署，升級，修改和拆除Kubernetes集群。可以同時使用kubeadm創建的現有配置和etcd配置。Kubeadm還部署Kube-proxy和DNS插件（kube-dns或CoreDNS，后者為默認設置）。除了Docker外，kubeadm和Kubernetes還可使用許多不同的CRI，其中容器式和CRI-O是最受歡迎的。
當然社區也是在集群部署層面給予最大的支持使kubeadm實現普遍可用性、完整性，在高可用方面k8s官方給出了一部分文檔，幾乎都是手動去部署的，部署一套完整的kubernetes集群確實讓你浪費很多的時間，所以我這里準備了Devops自動化運維工具Ansible部署了一套完整的k8s集群，完全基于離線方式
適用于企業當中，無網也可以安裝，當然也適合當做你的學習環境
集群設計
其中我在設計部署集群當中也加入了不少生產當中最佳實踐以及集群優化的部分給集群帶來穩定性、可靠性做了不少相關工作
目前是第一個版本1.0，集群版本是19.2，后續也會繼續完善1、Ansible自動化部署v1.0版本 集群19.2
一、kubeadm集群離線高可用
支持Calico（BGP、IPIP）
支持Node節點擴容
支持Docker大規模穩定性、安全調優
支持kubernetes集群大規模穩定性調優、安全調優
支持kubernetes水平pod自動縮放HPA
支持集群nodelocaldns解決5s延遲問題
支持NFS動態存儲實現pv自動供給
支持一鍵證書到期續期
支持集群升級
支持kuboard UI
支持集群卸載
2、v2.0版本 集群xxx
一、kubeadm單節點master、多節點master
支持Calico（BGP、IPIP、RR）
支持Master節點擴容
支持Node節點擴容
支持Harbor高可用
支持Docker大規模穩定性、安全調優
支持kubernetes大規模集群穩定性、安全調優
支持kubernetes水平pod自動縮放HPA
支持kubernetes垂直容器縮放VPA
支持集群nodelocaldns解決5s延遲問題
支持NFS動態存儲實現pv自動供給
支持一鍵證書到期續期
支持集群升級
支持聯邦集群
支持kuboard UI
支持集群卸載
支持Docker、kubernetes安全合規基準檢測
支持kubernetes集群部署配置最佳實踐web
3、v3.0版本 集群xxx
一、kubeadm單節點master、多節點master
支持Calico（BGP、IPIP、RR）
支持Weave網絡CNI
支持Node節點擴容
支持Harbor高可用
支持Docker大規模穩定性、安全調優
支持kubernetes大規模集群穩定性、安全調優
支持kubernetes水平pod自動縮放HPA
支持kubernetes垂直容器縮放VPA
支持kubernetes故障檢測能力NPD
支持集群nodelocaldns解決5s延遲問題
支持NFS動態存儲實現pv自動供給
支持Ceph-CSI動態實現pv自動供給
支持一鍵證書到期續期
支持集群升級
支持聯邦集群
支持Kuboard UI
支持集群卸載
支持集群故障排除工具kube-Debug
支持Docker、kubernetes安全合規基準檢測
支持kubernetes集群部署配置最佳實踐web
支持高可用prometheus-operator以及告警
支持高可用elasticsearch-operator以及告警
5、5.0版本 集群xxx
一、kubeadm單節點master、多節點master
支持Calico（BGP、IPIP、RR）
支持Weave網絡CNI
支持Macvlan網絡CNI
支持Multus pod多網卡多CNI集成
支持Node節點擴容
支持Harbor高可用
支持Docker大規模穩定性、安全調優
支持kubernetes大規模集群穩定性、安全調優
支持kubernetes水平pod自動縮放HPA
支持kubernetes垂直容器縮放VPA
支持kubernetes故障檢測能力NPD
支持kubernetes事件驅動自動縮放KEDA
支持集群nodelocaldns解決5s延遲問題
支持NFS動態存儲實現pv自動供給
支持Ceph-CSI動態實現pv自動供給
支持Ceph-Rook
支持一鍵證書到期續期
支持集群升級
支持聯邦集群
支持Kuboard UI
支持集群卸載
支持Descheduler平衡調度
支持容器可視化小工具
支持集群故障排除工具kube-Debug
支持集群災難備份
支持Docker、kubernetes安全合規基準檢測
支持kubernetes集群部署配置最佳實踐web
支持高可用prometheus-operator
支持高可用elasticsearch-operator
支持對接jenkins 完成CI/CD
部署相對來講比如容易，我封裝的就3條命令，幾乎小白也可以聽懂
Devops工具介紹：Ansible
如果需要并行部署數百個服務器或客戶端節點（可能是本地或在云中），并且需要配置它們中的每一個，那么該怎么辦？你怎么做呢？你從哪里開始？存在許多配置管理框架來解決大多數的問題，而Ansible是這樣一種框架。
可能已經聽說過Ansible，但是對于那些不知道或不知道Ansible是什么的人，我可以這么說，Ansible是配置管理和供應工具。它與其他工具（例如Puppet，Chef和Salt）非常相似。
Ansible可以使個人以及團隊輕松快速上手。這是因為Ansible使用YAML作為基礎來配置，配置和部署。并且由于這種方法，任務以特定順序執行。在執行過程中，如果您遇到語法錯誤，一旦遇到錯誤，它將失敗，從而可能更易于調試，也方便企業運維人員或者開發人員來維護這么一套框架，對于目前kubernetes以及像Ceph集群這樣的多臺服務器組成的集群，非常適合用它來實現與管理，而很多企業也要求這項技能是必會的，相信你使用了這套我部署的k8s集群的框架也會學習到很多的語法以及Ansible-playbook的最佳實踐
步入主題，環境要求
節點規模 Master規格
- 1-5個節點 4C8G(不建議2C4G)
- 6-20個節點 4C16G
- 21-100個節點 8C32G
- 100-200個節點 16C64G
Node節點規格 根據個人業務量而定，不建議2C4G（生產環境）
部署介紹一、自動化安裝Ansible
設置主機名
hostnamectl set-hostname m1 hostnamectl set-hostname m2 hostnamectl set-hostname m3 hostnamectl set-hostname n1執行
#bash kubefetch.sh
則會自動安裝Ansible 2.9.10的版本
二、配置部署集群的hosts文件
使用Ansible的都知道hosts它是讓我們定義哪些節點將成為控制節點的遠程節點的一個作用，當然部署我一般將ansible也部署在master節點上，這樣也會節省服務器的開支。
這里kubefetch組需要將你的所有的主機都填寫上，ha-master需要寫一個VIP虛擬的地址來作為HA的地址
master可以寫5臺或者3臺，node節點根據你的節點數量進行配置，add-node如果你想增加擴容節點的時候可以寫上它
all:vars里面則是全部的變量，這里我拿了出來就是方面你自己去組網，也可以按上面默認的配置，默認網絡采用的Calico的BGP模式，docker 0的地址我通過bip的方式重新定義了docker 0網段，就是因為企業當中的內網地址可能會沖突，所以部署的過程中需要你個人去注意一下，如果內網不沖突則可以使用，這里作為默認值來使用
下面是hosts文件的示例，可以根據以下配置來完成你的集群部署
#cat hosts
三、執行系統初始化操作，并且包含內核的優化
我們知道如何使用AdHoc方法運行Ansible任務 。盡管對于在所有服務器上安裝軟件包或執行命令之類的簡單任務很有用，但在處理多個任務時卻無濟于事。
Ansible Playbook則就是此類方案的解決方案，主要用來解決復雜的流程化任務
從基本形式來說，劇本是由一個或多個任務組成的YAML文件。除了任務之外，我們還可以包含變量，文件，模板等。很容易理解YAML文件，如果你使用過playbook，那就更好了
在高級形式中，劇本中會有很多劇本，相應的任務（劇本）位于不同的文件夾中，每個文件夾包含因變量，文件，模板，自定義模塊等。當然部署中為了嵌套每個playbook以及roles角色，我已經在此劇本中清晰到具體細節，方便你知道具體執行了哪些操作，調用了哪個playbook以及roles角色
這里介紹了執行時輸入的遠程主機的密碼，默認設置的都是一樣的，也可以-k 也可以執行[root@m1 kubefetch]# ansible-playbook init-host.yml --ask-pass
四、開始正式部署完整的kubernetes集群
此劇本包含了所有的引用，執行所有的playbook,都調用到此腳本當中[root@m1 kubefetch]# ansible-playbook site-all.yml
部署完成之后看到此頁面就相當于一組高可用的kubeadm集群已經部署起來了
訪問192.168.30.61:30001，則直接會進入UI的頁面，這里登陸之后需要將輸出的Token的值添加到頁面當中就可以使用了
進入終端查看當前的節點信息
[root@m1 kubefetch]# kubectl get node NAME STATUS ROLES AGE VERSION m1 Ready master 119m v1.19.2 m2 Ready master 117m v1.19.2 m3 Ready master 117m v1.19.2 n1 Ready <none> 116m v1.19.2calicoctl允許您從命令行創建，讀取，更新和刪除Calico對象。calico會將對象存儲存在etcd或Kubernetes的兩個數據存儲之一中。在安裝Calico時通常會確定數據存儲的選擇。
[root@m1 kubefetch]# calicoctl node status Calico process is running.IPv4 BGP status +---------------+-------------------+-------+----------+-------------+ | PEER ADDRESS | PEER TYPE | STATE | SINCE | INFO | +---------------+-------------------+-------+----------+-------------+ | 192.168.30.62 | node-to-node mesh | up | 13:06:13 | Established | | 192.168.30.63 | node-to-node mesh | up | 13:06:13 | Established | | 192.168.30.64 | node-to-node mesh | up | 13:06:13 | Established | | 192.168.30.65 | node-to-node mesh | up | 13:07:27 | Established | +---------------+-------------------+-------+----------+-------------+IPv6 BGP status No IPv6 peers found.[root@m1 kubefetch]# calicoctl get ippool -owide NAME CIDR NAT IPIPMODE VXLANMODE DISABLED SELECTOR default-ipv4-ippool 10.244.0.0/16 true Never Never false all()查看部署之后所有的pod列表
[root@m1 ~]# kubectl get po -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-6d5c8f4db4-dgcmk 1/1 Running 0 124m kube-system calico-node-6n9r7 1/1 Running 0 124m kube-system calico-node-cd8zp 1/1 Running 0 123m kube-system calico-node-ncfww 1/1 Running 0 124m kube-system calico-node-qrl7g 1/1 Running 0 124m kube-system coredns-f9fd979d6-lr5m8 1/1 Running 0 126m kube-system coredns-f9fd979d6-mjqrx 1/1 Running 0 126m kube-system etcd-m1 1/1 Running 0 126m kube-system etcd-m2 1/1 Running 0 124m kube-system etcd-m3 1/1 Running 0 123m kube-system kube-apiserver-m1 1/1 Running 0 126m kube-system kube-apiserver-m2 1/1 Running 0 124m kube-system kube-apiserver-m3 1/1 Running 1 124m kube-system kube-controller-manager-m1 1/1 Running 2 126m kube-system kube-controller-manager-m2 1/1 Running 0 124m kube-system kube-controller-manager-m3 1/1 Running 0 124m kube-system kube-proxy-bhm9r 1/1 Running 0 126m kube-system kube-proxy-f5xjq 1/1 Running 0 124m kube-system kube-proxy-gwfqr 1/1 Running 0 123m kube-system kube-proxy-hfwp8 1/1 Running 0 124m kube-system kube-scheduler-m1 1/1 Running 1 126m kube-system kube-scheduler-m2 1/1 Running 0 124m kube-system kube-scheduler-m3 1/1 Running 0 124m kube-system kuboard-756bb445c7-dgtt2 1/1 Running 0 122m五、擴容Node節點
生產環境中如果你的節點資源不夠用了，想擴容節點的話，支持擴容
執行以下配置，當然你的hosts文件中需要添加對應擴容Node節點的IP，這樣ansible才能安排執行的工作
安裝完之后會發現多了一個節點，你也可以直接添加多個節點進行一同執行
[root@m1 kubefetch]# kubectl get node NAME STATUS ROLES AGE VERSION m1 Ready master 153m v1.19.2 m2 Ready master 151m v1.19.2 m3 Ready master 151m v1.19.2 n1 Ready <none> 150m v1.19.2 n2 Ready <none> 88s v1.19.2六、大規模k8s集群、穩定性、安全性調優
我還做了一些集群的優化的工作對你的集群進行加固，穩定性、可靠性、安全性的調優
包含了ETCD、Docker、Kubernetes、DNS+nodelocaldns
大規模調優會單獨拿出一篇博文來介紹這里暫時不占有大幅篇文
如果你想進行集群調優的話可以執行這條playbook并包含了上述優化條件[root@m1 kubefetch]# ansible-playbook site-all-optimize.yml
執行結束之后會自動重啟你的主機，讓所有的pod緩存命中nodelocaldns cache的地址，解決5s延遲問題，具體詳細博文，如何產生的延遲可以參考我之前的博客coredns+nodelocaldns解決5s延遲
[root@m1 ~]# kubectl get po -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system calico-kube-controllers-6d5c8f4db4-dgcmk 1/1 Running 2 3h1m kube-system calico-node-2t4fb 1/1 Running 1 31m kube-system calico-node-6n9r7 1/1 Running 2 3h1m kube-system calico-node-cd8zp 1/1 Running 2 3h kube-system calico-node-ncfww 1/1 Running 2 3h1m kube-system calico-node-qrl7g 1/1 Running 2 3h1m kube-system coredns-f9fd979d6-lr5m8 1/1 Running 2 3h3m kube-system coredns-f9fd979d6-mjqrx 1/1 Running 2 3h3m kube-system etcd-m1 1/1 Running 4 3h3m kube-system etcd-m2 1/1 Running 2 3h1m kube-system etcd-m3 1/1 Running 3 3h1m kube-system kube-apiserver-m1 1/1 Running 1 24m kube-system kube-apiserver-m2 1/1 Running 1 24m kube-system kube-apiserver-m3 1/1 Running 1 23m kube-system kube-controller-manager-m1 1/1 Running 2 24m kube-system kube-controller-manager-m2 1/1 Running 1 24m kube-system kube-controller-manager-m3 1/1 Running 1 24m kube-system kube-proxy-bhm9r 1/1 Running 2 3h3m kube-system kube-proxy-cwgfr 1/1 Running 1 31m kube-system kube-proxy-f5xjq 1/1 Running 2 3h1m kube-system kube-proxy-gwfqr 1/1 Running 2 3h kube-system kube-proxy-hfwp8 1/1 Running 2 3h1m kube-system kube-scheduler-m1 1/1 Running 4 3h3m kube-system kube-scheduler-m2 1/1 Running 5 3h1m kube-system kube-scheduler-m3 1/1 Running 3 3h1m kube-system kuboard-756bb445c7-dgtt2 1/1 Running 2 179m kube-system node-local-dns-2crt5 1/1 Running 1 24m kube-system node-local-dns-7stq5 1/1 Running 1 24m kube-system node-local-dns-h4z8x 1/1 Running 1 24m kube-system node-local-dns-qqswn 1/1 Running 1 24m kube-system node-local-dns-zfhk9 1/1 Running 1 24m七、證書到期更換
我們知道使用 kubeadm 安裝 kubernetes 集群非常方便，但是也有一個比較煩人的問題就是默認的證書有效期只有一年時間，所以需要考慮證書升級的問題，kubeadm 會在控制面板升級的時候自動更新所有證書，所以使用 kubeadm 搭建得集群最佳的做法是經常升級集群，這樣可以確保你的集群保持最新狀態版本并保持合理的安全性。但是對于實際的生產環境我們可能并不會去頻繁得升級集群，所以這個時候我們就需要去手動更新證書。
當然升級集群我這里已經準備了自動化部署playbook的劇本，一鍵執行則直接更換證書
[root@m1 kubefetch]# ansible-playbook site-cluster-certs-update.yml ok: [192.168.30.62] => {"check_expiration.stdout_lines": ["[check-expiration] Reading configuration from the cluster...", "[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'", "", "CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED", "admin.conf Oct 06, 2021 10:27 UTC 360d no ", "apiserver Oct 06, 2021 10:27 UTC 360d ca no ", "apiserver-etcd-client Oct 06, 2021 10:27 UTC 360d etcd-ca no ", "apiserver-kubelet-client Oct 06, 2021 10:27 UTC 360d ca no ", "controller-manager.conf Oct 06, 2021 10:27 UTC 360d no ", "etcd-healthcheck-client Oct 06, 2021 10:27 UTC 360d etcd-ca no ", "etcd-peer Oct 06, 2021 10:27 UTC 360d etcd-ca no ", "etcd-server Oct 06, 2021 10:27 UTC 360d etcd-ca no ", "front-proxy-client Oct 06, 2021 10:27 UTC 360d front-proxy-ca no ", "scheduler.conf Oct 06, 2021 10:27 UTC 360d no ", "", "CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED", "ca Oct 04, 2030 10:25 UTC 9y no ", "etcd-ca Oct 04, 2030 10:25 UTC 9y no ", "front-proxy-ca Oct 04, 2030 10:25 UTC 9y no "替換更新證書之后，則時間又換到了364d,并成功替換了證書
ok: [192.168.30.62] => {"renew_result.stdout_lines": ["[check-expiration] Reading configuration from the cluster...", "[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'", "", "CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED", "admin.conf Oct 06, 2021 14:08 UTC 364d no ", "apiserver Oct 06, 2021 14:08 UTC 364d ca no ", "apiserver-etcd-client Oct 06, 2021 14:08 UTC 364d etcd-ca no ", "apiserver-kubelet-client Oct 06, 2021 14:08 UTC 364d ca no ", "controller-manager.conf Oct 06, 2021 14:08 UTC 364d no ", "etcd-healthcheck-client Oct 06, 2021 14:08 UTC 364d etcd-ca no ", "etcd-peer Oct 06, 2021 14:08 UTC 364d etcd-ca no ", "etcd-server Oct 06, 2021 14:08 UTC 364d etcd-ca no ", "front-proxy-client Oct 06, 2021 14:08 UTC 364d front-proxy-ca no ", "scheduler.conf Oct 06, 2021 14:08 UTC 364d no ", "", "CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED", "ca Oct 04, 2030 10:25 UTC 9y no ", "etcd-ca Oct 04, 2030 10:25 UTC 9y no ", "front-proxy-ca Oct 04, 2030 10:25 UTC 9y no "八、自動部署Metrics Server采集指標器
Metrics server是一種可伸縮的、高效的容器資源指標源，用于Kubernetes內置的自動縮放管道。
Metrics server從Kubelets收集資源指標，并通過Metrics API在Kubernetes apiserver中公開它們，以便HPA和VPA使用。Metrics API也可以被kubectl top訪問，這使得它更容易調試自動排序管道。
Metrics server并不用于非自動加碼的目的。例如，不要使用它將指標轉發到監視解決方案，或者將其作為監視解決方案指標的來源。
在大多數集群上工作的單一部署,可擴展支持最多5,000個節點集群 資源效率:Metrics server每個節點使用0.5m核心CPU和4 MB內存
部署metrics server有的集群部署可能會遇到問題，這里我找到合適的方法來部署，這里你無需知道如何部署的，直接知道playbook則會幫助你正確安裝metrics server服務指標采集器
[root@m1 kubefetch]# ansible-playbook site-metrics-server.yml [root@m1 kubefetch]# kubectl top no NAME CPU(cores) CPU% MEMORY(bytes) MEMORY% m1 189m 9% 1277Mi 74% m2 137m 6% 1255Mi 72% m3 126m 6% 1213Mi 70% n1 61m 3% 624Mi 36% n2 67m 3% 597Mi 34% kube-system metrics-server-5f4d886f76-z5rzg 1/1 Running 2 31m 10.244.139.194 m2 <none> <none>九、自動化實現NFS動態存儲實現pv自動供給
Kubernetes Storage允許容器化的應用程序無縫訪問存儲資源，而無需知道容器在消耗數據。Kubernetes允許應用程序訪問存儲的一種方式是標準的網絡文件服務（NFS）協議。在本文中，將實現直接從Kubernetes容器中的容器安裝NFS文件共享。
Kubernetes volumes 和NFS Kubernetes volumes是抽象的存儲單元，它允許集群中的節點在它們之間寫入，讀取和共享數據。Kubernetes提供了許多存儲插件，可用于訪問存儲服務和平臺。其中之一是NFS插件。網絡文件系統（NFS）是一種標準協議，可讓將存儲設備安裝為本地驅動器。Kubernetes允許將卷作為本地驅動器安裝在容器上。NFS集成對于將工作負載遷移到Kubernetes非常有用，因為代碼通常會通過NFS訪問數據。有兩種方法可以通過Kubernetes中的NFS訪問數據：臨時NFS卷-這使您可以連接到已經擁有的現有NFS存儲。帶有NFS的持久卷-這使您可以在群集中設置可通過NFS訪問的托管資源。
在Kubernetes上使用NFS的優勢您應考慮在Kubernetes中使用NFS的一些原因：使用現有存儲-你可以使用標準接口在本地或云中掛載當前正在使用的現有數據卷。持久性-常規的Kubernetes Volume是短暫的，這意味著當其pod關閉時，它會被拆除。但是，可以在Pod定義中定義的NFS卷為你提供持久性，而不必定義持久卷。即使Pod關閉，通過NFS保存的所有數據也將存儲在連接的存儲設備中。還可以選擇定義一個Kubernetes持久卷，以通過NFS接口公開其數據。共享數據-由于其持久性，NFS卷可用于在同一Pod或不同Pod中的容器之間共享數據。同時安裝-NFS卷可以同時由多個節點安裝，并且多個節點可以同時寫入同一NFS卷。一個重要的警告是，要使NFS卷正常工作，必須設置一臺通過NFS公開存儲的服務器。Kubernetes將不會為你管理現有的NFS卷。
部署的時候需要注意exports出去的網段，需要在公共變量寫上對應的，默認Master1作為NFS的服務端地址
具體NFS 數據卷的使用可參考我之前的博客
#Segment addresses of NFS Exports were generally used for PV and PVC storage nfs_exports_segment = 192.168.30.0/24[root@m1 kubefetch]# ansible-playbook site-nfs-client.yml [root@m1 kubefetch]# kubectl get po -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nfs-client-provisioner-66bbdf6495-shkv4 1/1 Running 0 23s 10.244.217.0 n2 <none> <none>其他的節點都會作為客戶端來使用并掛載上。默認客戶端地址都在/mnt下 192.168.30.61:/opt/nfs 48G 11G 37G 23% /mnt以上就是V1版本的全部內容，如有需要可評論并添加kubefetch，獲取安裝包地址
總結
以上是生活随笔為你收集整理的kubeadm部署k8s_(Ansible）三分钟部署一套高可用/可扩展的kubeadm集群的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 该线程或进程自上一个步骤以来已更改_多线
- 下一篇： esxi 7.0 封装瑞昱网卡驱动_小科