距離上次更新已經有一個月了，主要是最近工作上的變動有點頻繁，現在才暫時穩定下來。這篇博客的本意是帶大家從零開始搭建K8S集群的。但是我后面一想，如果是我看了這篇文章，會收獲什么？就是跟着步驟一步一走嗎？是我的話我會選擇拒絕，所以我加了關於K8S的簡單介紹，每一步的步驟都添加了解釋。由於篇幅和時間原因，我只介紹了K8S中較為核心的Pod和Service。
文章前半段會簡單的介紹一下K8S，后半段會介紹如何從零開始慢慢的搭建集群。如果想直接開始着手搭建集群，則可以直接從第三章開始看。
1. K8S是什么
K8S全稱kubernetes，是由Google在2014年開源的生產級別的容器編排系統，或者說是微服務和雲原生平台。雖說14年才開源，但實際上K8S是Google內部的容器編排系統Borg的開源版本，在Google內部已經用了十多年了。下面是一個關於K8S的Logo來源的小插曲。
Kubernetes由谷歌在2014年首次對外宣布 。它的開發和設計都深受谷歌的Borg系統的影響，它的許多頂級貢獻者之前也是Borg系統的開發者。在谷歌內部，Kubernetes的原始代號曾經是Seven，即星際迷航中友好的Borg(博格人)角色。Kubernetes標識中舵輪有七個輪輻就是對該項目代號的致意。
不過也有一個說法是，Docker的Logo是一個馱着集裝箱的鯨魚，也就是運輸船，K8S的Logo是一個船舵，旨在引領着Docker（或者說容器技術）走向遠方。
2. 簡單了解K8S
看了很多官方文章，是真官方。官方什么意思呢，就是有可能看完了約等於沒有看，一樣的啥都不知道。
所以我想寫這樣一篇文章，給那些看完文檔仍然不太理解或者說完全沒了解過K8S的老鐵一點小幫助。那么讓我們回到最初對K8S的定義，它是一個微服務框架。
說到微服務框架，我們就不得不提一下目前業界十分主流的微服務框架，與這些你十分熟悉的框架進行對比，你就會很清晰的知道K8S能做什么了。目前很主流的微服務框架和平台有Spring Cloud、Dubbo和K8S。
Spring Cloud來自Netflix，Dubbo來自阿里，而K8S則來自Google。說的直觀一點，這三個框架都是針對微服務的解決方案。可能有人會說，K8S不是一個容器編排系統嗎？怎么跟Spring Cloud這種軟件層面上的微服務框架做起了對比呢？
老鐵別慌，等我們慢慢深入這個概念。
我們都知道，如果我們需要使用微服務，那么肯定少不了一些底層的基礎設施的支撐，例如服務注冊與發現、負載均衡、日志監控、配置管理、集群自愈和容錯、彈性伸縮…等等。我沒有列舉完，如其實這些組件都可以統稱為微服務的公共關注點。那我們是不是可以說，只要能夠提供的這些功能，它就算一個微服務框架呢？
以上的大多數功能，K8S都是內置的。故我們可以說K8S是一個與Docker Swarm相類似的容器編排系統，但是由於K8S內置了微服務的解決方案，它同時也是一個功能完備的微服務框架。
2.1 Pod的概念
在Docker Swarm中，調度的最小單位是容器，而在K8S中，調度的最小是Pod，那啥是Pod呢？
Pod是K8S設計的一個全新的概念，在英文中的原意是表達一群鯨魚或者是一個豌豆莢的意思。換句話說，一個Pod中可以運行一個或者多個容器。
在一個集群中，K8S會為每個Pod都分配一個集群內唯一的IP地址。因為K8S要求底層網絡支持集群內的任意節點之間的兩個Pod能夠直接通信。這些容器共享當前Pod的文件系統和網絡。而這些容器之所以能夠共享，是因為Pod中有一個叫Pause的根容器，其余的用戶業務容器都是共享這個根容器的IP和Volume。所以這些容器之間都可以通過localhost進行通信。
有人可能會問，為什么要引入根容器這個概念？那是因為如果沒有根容器的話，當一個Pod中引入了多個容器的時候，我們應該用哪一個容器的狀態來判斷Pod的狀態呢？所以才要引入與業務無關且不容易掛掉的Pause容器作為根容器，用根容器的狀態來代表整個容器的狀態。
熟悉Spring Cloud或者微服務的都知道，微服務中最忌諱的就是出現單點的情況。
所以針對同一個服務我們一般會部署2個或者更多個實例。在K8S中，則是會部署多個Pod副本，組成一個Pod集群來對外提供服務。
而我們前面提過，K8S會為每一個Pod提供一個唯一的IP地址，客戶端就需要通過每個Pod的唯一IP+容器端口來訪問到具體的Pod，這樣一來，如果客戶端把調用地址寫死，服務器就沒有辦法做負載均衡，而且，Pod重啟之后IP地址是會變的，難道每次重啟都要通知客戶端IP變更嗎？
為了解決這個問題，就要引出Service的概念了。
2.2 Service
Service是K8S中最核心的資源對象之一，就是用於解決上面提到的問題。我個人認為與Swarm中的Service概念沒有太大的區別。
一旦Service被創建，K8S會為其分配一個集群內唯一的IP，叫做ClusterIP，而且在Service的整個生命周期中，ClusterIP不會發生變更，這樣一來，就可以用與Docker Swarm類似的操作，建立一個ClusterIP到服務名的DNS域名映射即可。
值得注意的是，ClusterIP是一個虛擬的IP地址，無法被Ping，僅僅只限於在K8S的集群內使用。
而Service對客戶端，屏蔽了底層Pod的尋址的過程。並且由kube-proxy進程將對Service的請求轉發到具體的Pod上，具體到哪一個，由具體的調度算法決定。這樣以來，就實現了負載均衡。
而Service是怎么找到Pod的呢？這就需要繼續引入另外一個核心概念Label了。
2.3 Label
Lable本質上是一個鍵值對，具體的值由用戶決定。Lable就是標簽，可以打在Pod上，也可以打到Service上。總結來說，Label與被標記的資源是一個一對多的關系。
例如，我們給上面所描述的Pod打上了role=serviceA的標簽，那么只需要在Service中的Label Selector中加入剛剛那個標簽，這樣一來，Service就可以通過Label Selector找到打了同一Label的Pod副本集了。
接下來，再簡單的介紹一下其他的K8S核心概念。
2.4 Replica Set
上面提到過部署多個Pod，是怎么一回事呢？K8S最開始有一個概念叫Replication Controller，不過現在已經慢慢的被Replica Set所替代，RS也叫下一代的RC。簡單來說Replica Set定義了一種期望的場景，即讓任何時候集群內的Pod副本數量都符合預期的值。
一旦被創建，集群就會定期的檢測當前存活的Pod數量，如果多了，集群就會停掉一些Pod。相反，如果少了就會創建一些Pod。這樣一來可以避免什么問題呢？假設某個服務有兩個實例在運行，其中一個意外掛掉了，如果我們設置了副本數量是2，那么集群就會自動創建一個Pod，以保證集群內始終有兩個Pod在運行。
K8S的東西就簡單的介紹這么多，接下來讓我們進入集群的搭建環節。
3. 搭建K8S的准備工作
不知道從哪篇博客開始，不是很願意寫這種純TODO類的博文，但是我自己躺坑之后發現，我自己這個還真是我目前見過最簡單的。
我看到的有些安裝分了很多種情況，但是當一個初學者來看的時候，可能反而會讓他看懵逼。所以接下來的安裝會有些硬核。不分情況，就只有一種情況，一把梭安裝就完事。
系統 版本 Ubuntu 18.04
K8S 版本 v1.16.3
Docker 版本 v19.03.5
Flannel 版本 v0.11.0
如果你問我，如果沒有機器看了你的文章也能的擁有自己的集群嗎？那么請看下圖…
3.1 准備工作
我們先假設以下的情況成立。
機器：有2-3台物理機或虛擬機
系統：Ubuntu 18.04 且已換好國內的源
如果以上基本不成立，本篇文章到此結束，謝謝觀看…
3.2 安裝Docker
我也不需要介紹各種情況了，直接登上機器，創建一個shell腳本，例如叫install_docker.sh，一把梭代碼如下。
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates
curl gnupg-agent software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo apt-key fingerprint 0EBFCD88
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-get -y install docker-ce docker-ce-cli containerd.io
然后執行sh install_docker.sh，等待命令跑完，驗證docker是否安裝好即可。直接敲docker + 回車。
3.3 安裝Kubernetes
同理，新建一個shell腳本，例如install_k8s.sh。一把梭代碼如下。
sudo curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo apt-get update
cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get install -y kubelet kubeadm kubectl --allow-unauthenticated
然后執行sh install_k8s.sh，等待命令跑完，驗證k8s是否安裝好即可。直接敲kubectl + 回車。
3.4 關閉Swap
先給出一把梭，不要耽誤了正在安裝的老鐵。為什么要關閉后面再說。
- 暫時關閉 直接使用命令
sudo swapoff -a，但是重啟之后會生效。會導致k8s無法正常運行。 - 永久關閉 建議一勞永逸，
sudo vim /etc/fstab將有swap.img那行注釋掉，保存即可。
那么，swap是啥呢？它是系統的交換分區，你可以理解為虛擬內存。當系統內存不足的時候，會將一部分硬盤空間虛擬成內存使用。那為什么K8S需要將其關掉呢？可以從下圖看看訪問內存和訪問硬盤速度上的差異就知道了。
總的來說是為了性能考慮，所以就需要避免開啟swap交換，K8S希望所有的服務都不應該超過集群或節點CPU和內存的限制。
4. 初始化Master節點
到這，准備工作就完成了，可以開始安裝K8S的master節點了，登上要作為master節點的機器。
4.1 設置HostName
老規矩，先上命令，再說為什么要設置。
sudo hostnamectl set-hostname master-node
自定義修改了主機名，在之后查看集群內節點時，每個節點的名字就不會顯示K8S自動生成的名字，便於查看和記憶。例如，在其他的Node節點你可以將master-node改為slave-node-1或worker-node-2，效果如下。
4.2 初始化集群
在機器上執行如下命令。
sudo kubeadm init --pod-network-cidr=10.244.0.0/16
然后，抱起吉他，等待命令執行完。
這里需要特別注意一下。這個命令執行完成之后，會打印一個有kubeadm join的命令，需要保存下來。
大概長這樣。
kubeadm join 你的IP地址:6443 --token 你的TOKEN --discovery-token-ca-cert-hash sha256:你的CA證書哈希
顧名思義，這個命令用於其他節點加入到集群中，而且Token是有時效性的，過期時間一般是86400000毫秒。
如果失效，就需要重新生成。如果你真的又沒有保存，又失效了…我還是給你准備了兩個補救措施。如果命令保存下來了，那么請直接跳過這兩個補救措施。
token. 通過命令
Kubeadm token list找回ca-cert. 執行命令
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'找回
4.3 普通用戶可執行
把下面的指令一把梭即可。
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
主要是，為了不那么麻煩，在控制節點上執行kubectl這類的命令時，不用每次都sudo。
4.4 安裝網絡通信插件
執行如下命令，安裝網絡插件Flannel。
sudo kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
可以看到，如果不安裝Flannel，我們剛剛Init好的Master節點會處於NOT_READY的狀態。安裝好之后，可以通過命令kubectl get nodes來查看所有的節點的狀態。也可以通過kubectl get pods --all-namespaces來查看當前集群中所有Pod的狀態。這里需要注意的是，只有在master節點是READY，所有Pod的狀態是RUNNING之后，才可以進行下一步。
為什么要裝網絡插件呢？
那是因為K8S要求集群內的所有節點之間的Pod網絡是互通的。換句話說，Flannel可以讓集群內不同節點上的容器都有一個在當前集群內唯一的虛擬IP地址。這樣以來，就可以實現，跨節點的Pod與Pod直接通信。
這樣一來，將復雜的網絡通信，簡單的變成了兩個IP地址之間的通信。這主要是通過虛擬二層網絡實現的。看似是這個節點的Pod直接和另一個節點上的Pod進行了通信，最終還是通過節點的物理網卡流出的。
5. Slave節點加入集群
到此，一個單點的集群就已經搭建好了。現在我們要做的是，登錄准備好的另一台（我只有兩台，如果你有3台或者4天，把這個章節反復走幾次就好了）服務器。
5.1 設置HostName
執行如下命令。
sudo hostnamectl set-hostname slave-node
因為當前節點不是master了，所以主機名設置成了slave-node。
5.2 加入集群
重點來了，執行上一章節生成的kubeadm join命令即可。等待執行完畢之后，就可以在master節點上通過命令kubectl get nodes看到slave-node已經加入了集群。
對於Slave節點的操作就沒了。
6. 感謝閱讀
關於K8S就簡單的介紹到這里，由於篇幅和時間的原因，很多概念都沒有介紹，例如Deployment、Volume、ConfigMap等等。僅僅只介紹了較為核心的Pod和Service，以及相關的東西。畢竟，如果想要把K8S的核心理念介紹完，一篇博客的篇幅是肯定不夠的，后面我再單獨詳細的介紹吧。
第一次在博客里求贊啊，之前完全是隨緣。不過我后來發現，打開博客看到大家的點贊和留言，這對我來說是一種莫大的鼓勵。
如果你覺得這篇文章對你有幫助，還麻煩點個贊，關個注，分個享，留個言
也可以微信搜索公眾號【SH的全棧筆記】，當然也可以直接掃描二維碼關注
