K8S 組件介紹 文檔 ： http://docs.kubernetes.org.cn/230.html
Kube-apiserver
kube-apiserver用于暴露Kubernetes API畜疾。任何的資源請(qǐng)求/調(diào)用操作都是通過kube-apiserver提供的接口進(jìn)行，是整個(gè)系統(tǒng)的數(shù)據(jù)總線和數(shù)據(jù)中心
apiserver 目前在master監(jiān)聽兩個(gè)端口
通過參數(shù) --insecure-port 8080 監(jiān)聽一個(gè)非安全的127.0.0.1本地端口(默認(rèn)為8080)
通過參數(shù) --bind-address=10.0.0.3 監(jiān)聽一個(gè)對(duì)外訪問且安全(https)的端口(默認(rèn)為6443)
curl 127.0.0.1:8080/ #查看所有api
Kube-scheduler
kube-scheduler是 Kubernetes集群的pod調(diào)度器御毅，是一個(gè)擁有豐富策略、能夠感知拓?fù)渥兓阏恪⒅С痔囟ㄘ?fù)載的功能組件效床，調(diào)度器顯著影響可用性候引、性能
通過調(diào)度算法為待調(diào)度的Pod從可用Node列表中選擇一個(gè)最適合Node，并將信息寫入etcd中
Kube-controller-manager
kube-controller-manager作為集群內(nèi)部的管理控制中心畔况，負(fù)責(zé)集群內(nèi)的Node鲸鹦、Pod副本、服務(wù)端點(diǎn)(Endpoint)跷跪、命名空間(Namespace)馋嗜、服務(wù)賬號(hào)(ServiceAccount)、資源定額(ResourceQuota)的管理吵瞻，每個(gè)Controller通過API Server提供的接口實(shí)時(shí)監(jiān)控整個(gè)集群的每個(gè)資源對(duì)象狀態(tài),當(dāng)某個(gè)Node意外宕機(jī)時(shí)葛菇，Controller Manager會(huì)及時(shí)發(fā)現(xiàn)并執(zhí)行自動(dòng)化修復(fù)流程甘磨，確保集群始終處于預(yù)期的工作狀態(tài)
Kubelet
在kubernetes集群中，每個(gè)Node節(jié)點(diǎn)都會(huì)啟動(dòng)kubelet進(jìn)程眯停，用來處理Master節(jié)點(diǎn)下發(fā)到本節(jié)點(diǎn)的任務(wù)济舆，管理Pod和其中的容器。它會(huì)監(jiān)視已分配給節(jié)點(diǎn)的pod莺债，向master匯報(bào)node節(jié)點(diǎn)的狀態(tài)信息滋觉，接受指令并在Pod中創(chuàng)建docker容器，返回pod的運(yùn)行狀態(tài)齐邦，在node節(jié)點(diǎn)執(zhí)行容器健康檢查
Etcd
etcd 是Kubernetes默認(rèn)使用的key-value數(shù)據(jù)存儲(chǔ)系統(tǒng)椎侠，用于保存所有集群數(shù)據(jù)，包括k8s集群的配置信息和各種資源的狀態(tài)信息
export ETCDCTL_API=3
etcdctl --help
etcdctl member list #查看etcd成員信息
etcdctl get / --prefix --keys-only #查看etcd數(shù)據(jù)信息
etcdctl put /yunge "18" #添加數(shù)據(jù)
etcdctl get /yunge#獲取時(shí)間
etcdctl del /yunge #刪除數(shù)據(jù)
etcd數(shù)據(jù)watch機(jī)制
基于不斷監(jiān)看數(shù)據(jù)措拇，發(fā)生變化就主動(dòng)觸發(fā)通知客戶端我纪，Etcd v3 的watch機(jī)制支持watch某個(gè)固定的key，也支持watch一個(gè)范圍丐吓。
etcdctl watch /yunge
etcdctl put /yunge "18" #另一個(gè)終端執(zhí)行浅悉，watch終端會(huì)接收
etcd數(shù)據(jù)備份與恢復(fù)機(jī)制
etcdctl snapshot save etcd.db #備份數(shù)據(jù)
etcdctl snapshot restore etcd.db --data-dir=/opt/etcd #數(shù)據(jù)恢復(fù)到新目錄
Kubernetes網(wǎng)絡(luò)代理運(yùn)行在 node上，kube-proxy它是實(shí)現(xiàn)K8S Service的通信與負(fù)載均衡機(jī)制的重要組件券犁，從apiserver獲取信息并創(chuàng)建代理服務(wù)仇冯，實(shí)現(xiàn)server到Pod的請(qǐng)求路由和轉(zhuǎn)發(fā)，從而實(shí)現(xiàn)K8s層級(jí)的虛擬轉(zhuǎn)發(fā)網(wǎng)絡(luò)族操。其實(shí)就是kube-proxy通過在主機(jī)上維護(hù)網(wǎng)絡(luò)規(guī)則并執(zhí)行連接轉(zhuǎn)發(fā)來實(shí)現(xiàn)Kubernetes服務(wù)訪問
Kube-Proxy
Kube-Proxy工作模式
iptables
Kube-Proxy 監(jiān)聽Kubernetes Master增加和刪除Service消息。對(duì)于每一個(gè)Service比被，Kube Proxy 創(chuàng)建相應(yīng)的IPtables規(guī)則色难，并將發(fā)送到Service Cluster IP的流量轉(zhuǎn)發(fā)到后端提供服務(wù)的Pod的相應(yīng)端口上
雖然可以通過Service的ClusterIP和服務(wù)端口訪問到后端Pod提供的服務(wù)，但該Cluster IP Ping不通等缀。其原因是 Cluster IP 只是 IPtables 中的規(guī)則枷莉，并不對(duì)應(yīng)到一個(gè)任何網(wǎng)絡(luò)設(shè)備
ipvs
IPVS 模式的Cluster IP是可以Ping通的
在大規(guī)模集群中，推薦使用性能更好的IPVS尺迂，基于IPVS的kube-proxy具有更復(fù)雜的負(fù)載平衡算法（最小連接笤妙，局部性，加權(quán)噪裕，持久性）
--proxy-mode=iptables #IPtables是默認(rèn)轉(zhuǎn)發(fā)模式蹲盘，建議修改為IPVS
systemctl daemon-reload
systemctl restart kube-proxy
reboot
ipvsadm -Ln #重啟查看IPvs規(guī)則
網(wǎng)絡(luò)組件
k8s中的網(wǎng)絡(luò)主要涉及到pod的的各種訪問需求
k8s的網(wǎng)絡(luò)基于第三方插件實(shí)現(xiàn)，但是定義了一些插件兼容規(guī)范膳音，該規(guī)范由CoreOS和Google定制的CNI(Container Network Interface)召衔，凡是遵循CNI標(biāo)準(zhǔn)的網(wǎng)絡(luò)插件都可以在K8S中使用。目前常用的的CNI網(wǎng)絡(luò)插件有flannel和calico
Flannel
由CoreOS開源的針對(duì)k8s的網(wǎng)絡(luò)服務(wù)祭陷，其目的為解決k8s集群中各主機(jī)上的pod相互通信的問題苍凛，其借助etcd維護(hù)網(wǎng)絡(luò)IP地址分配趣席，并為每一個(gè)node服務(wù)器分配一個(gè)不同的IP地址段
UDP：早期版本的Flannel使用UDP封裝完成報(bào)文的跨越主機(jī)轉(zhuǎn)發(fā)，其安全性及性能略有不足
VXLAN：Linux 內(nèi)核在2012年底的v3.7.0之后加入了VXLAN協(xié)議支持醇蝴，VXLAN本質(zhì)上是一種tunnel(隧道)協(xié)議宣肚，vxlan是overlay中的一種隧道封裝技術(shù)，實(shí)際上是將數(shù)據(jù)鏈路層的以太網(wǎng)幀封裝成傳輸層的UDP數(shù)據(jù)報(bào)文悠栓，然后在網(wǎng)絡(luò)層傳輸霉涨，最終實(shí)現(xiàn)的效果類似于在數(shù)據(jù)鏈路層的報(bào)文傳輸
Host-gw：也就是Host GateWay，通過在node節(jié)點(diǎn)上創(chuàng)建到達(dá)各目標(biāo)容器地址的路由表而完成報(bào)文的轉(zhuǎn)發(fā)闸迷，因此這種方式要求各node節(jié)點(diǎn)本身必須處于同一個(gè)局域網(wǎng)(二層網(wǎng)絡(luò))中嵌纲，因此不適用于網(wǎng)絡(luò)變動(dòng)頻繁或比較大型的網(wǎng)絡(luò)環(huán)境，但是其性能較好腥沽，和calico不開啟IPIP網(wǎng)絡(luò)類似
Cni0:網(wǎng)橋設(shè)備逮走，每創(chuàng)建一個(gè)pod都會(huì)創(chuàng)建一對(duì)veth pair，其中一端是pod中的eth0今阳，另一端是Cni0網(wǎng)橋中的端口（網(wǎng)卡）师溅，Pod中從網(wǎng)卡eth0發(fā)出的流量都會(huì)發(fā)送到Cni0網(wǎng)橋設(shè)備的端口（網(wǎng)卡）上，Cni0設(shè)備獲得的ip地址是該節(jié)點(diǎn)分配到的網(wǎng)段的第一個(gè)地址
Flannel不同node上的pod的通信流程
Flannel.1 是一個(gè)overlay網(wǎng)絡(luò)設(shè)備盾舌，用來進(jìn)行vxlan報(bào)文的處理(封包和解包)墓臭，不同node之間的pod數(shù)據(jù)流量都從overlay設(shè)備以隧道的形式發(fā)送到對(duì)端，flannel在進(jìn)行路由轉(zhuǎn)發(fā)的基礎(chǔ)上進(jìn)行了封裝和解包的操作
Calico
Calico是一個(gè)純?nèi)龑拥木W(wǎng)絡(luò)解決方案妖谴，為容器提供多node間的訪問通信窿锉，calico將每一個(gè)node節(jié)點(diǎn)都當(dāng)做為一個(gè)路由器，各節(jié)點(diǎn)通過BGP(Border Gateway Protocol) 邊界網(wǎng)關(guān)協(xié)議學(xué)習(xí)并在node節(jié)點(diǎn)生成路由規(guī)則膝舅，從而將不同node節(jié)點(diǎn)上的pod連接起來進(jìn)行通信
calico
node節(jié)點(diǎn)所連接的物理交換機(jī)需支持BGP協(xié)議嗡载，許多公有云無法支持BGP協(xié)議，所以公有云環(huán)境使用flannel
在自建IDC或服務(wù)器托管的場(chǎng)合仍稀，可以使用calico洼滚，提前做好k8s網(wǎng)絡(luò)規(guī)劃、子網(wǎng)劃分
BGP是一個(gè)去中心化的協(xié)議技潘，它通過自動(dòng)學(xué)習(xí)和維護(hù)路由表實(shí)現(xiàn)網(wǎng)絡(luò)的可用性遥巴，但是并不是所有的網(wǎng)絡(luò)都支持BGP，calico 還支持IP-in-IP的疊加模型享幽，簡(jiǎn)稱IPIP铲掐，IPIP可以實(shí)現(xiàn)跨不同網(wǎng)段建立路由通信，但是會(huì)存在安全性問題值桩，其在內(nèi)核內(nèi)置迹炼，可以通過Calico的配置文件設(shè)置是否啟用IPIP
IPIP是一種將各Node的路由之間做一個(gè)tunnel，再把兩個(gè)網(wǎng)絡(luò)連接起來的模式。啟用IPIP模式時(shí)斯入，Calico將在各Node上創(chuàng)建一個(gè)名為"tunl0"的虛擬網(wǎng)絡(luò)接口砂碉，建議關(guān)閉IPIP
BGP模式則直接使用物理機(jī)作為虛擬路由路（vRouter），不再創(chuàng)建額外的tunnel
兩者大致區(qū)別：
與Flannel不同刻两，Calico不使用overlay網(wǎng)絡(luò)增蹭。相反，Calico配置第3層網(wǎng)絡(luò)磅摹，該網(wǎng)絡(luò)使用BGP路由協(xié)議在主機(jī)之間路由數(shù)據(jù)包滋迈。這意味著在主機(jī)之間移動(dòng)時(shí)，不需要將數(shù)據(jù)包進(jìn)行額外的封裝和解包操作户誓，所以性能會(huì)相對(duì)高一些
calicoctl node status #驗(yàn)證當(dāng)前路由表
