為了能夠統一管理集群上大量的資源，我們需要給Pod添加一些元數據信息
Pod 標簽:Lable Key=value
而且在Key和value還有一定的限制，定義完后就可以使用所謂的標簽選擇器了，定義過濾條件來挑選符合我們的pod資源
我們知道在K8s上我們運行的容器以后，同一類容器，或者運行pod之后，同一類pod可能不止一個，既然如此，(1)當用戶請求到達是我們如何去接入用戶請求，到底給同一類的pod中哪一個pod來相應
(2)pod是需要所謂的控制器來管理pod的，盡量不要人手工去管理它
pod我們可以自己分類:
(1)自主式pod:自我管理的，創建以后，任然是提交給API Server,由API Server接收后借助Scheduler將其調度到指定的node節點，然后由node啟動此節點，如果有pod中容器出現問題了，需要重啟容器，那是由Keepalived來完成，但是如果節點故障了,pod也就消失了，所以，它有這樣的壞處，沒辦法實現全局的調度，所以建議使用第二種pod
(2)控制器管理的pod，正是控制器這種機制的使用，使得在K8S上的集群設計中，pod完全就可以叫做有生命周期的對象，而后由調度器調度到集群中的某節點，運行以后，它的任務終止也就隨着被刪除掉，但是有一些任務，大家知道傳統上有nginx、tomcat，它們是做為守護進程運行的，那么這種運行為pod容器的話，我們要確保它是時刻運行的，一旦出現故障我們要第一時間發現，要么是重建取代它，要么是重啟，那么pod控制器就可以觀測並實現
pod控制器早期的時候是:
RreplicationContrller,副本控制器
當我們啟動一個pod時候，比如一個nginx pod，這個pod不夠了，我可以再起一個副本，而后呢，控制器專門控制着同一pod資源，使得pod多退少補
萬一另一個pod調度到另一個node上運行，但是調度到的node也宕機了，那么就少了一個副本，但是控制器會重新請求一個API Server重新創建一個新pod，API Server借助Scheeduler調度以后，找另外一個node然后把pod再起起來，到此為止又是符合人們期望的
滾動更新:
比如此前啟動容器是靠所謂的1.0版的鏡像啟動的，后來做了有1.1的鏡像，那么現在需要pod中的容器替換成1.1的鏡像那么怎么辦？可以做滾動更新，比如先創建新版本的pod然后再慢慢去除老的pod
此外還可以回滾操作:
新版本的控制器為ReplicaSet
像Deployment這種控制器還二級控制器叫HPA (HorizonlPodAutoscaler)
我們叫做水平pod自動伸縮器
解釋:
容器承載不了這么多流量訪問怎么辦？所以我們需要加更多的pod資源了,到底應該加幾個呢？所以HP控制器可自動監控着，自動進行擴展，比如他會自動分析現在的cpu、內存利用率有多高，確保平均低於百60%，那么一計算，需要額外加兩個，那么就HPA自動給加上兩個，一旦小了也可以減少，可以確保有幾個存在
服務發現:
此前我們配置個LAMP服務在Nginx端:我們通過配置文件寫好對應后面那個M或者P的地址是什么,萬一我們pod中的M、P發生變化了，地址是不是發生變化了，那么我們使用主機名可不可以，但是有沒有想過新起一個pod主機名也變了，因為它已經是全新的pod了，大家想下應該怎么做？使用服務發現
客戶端每次去訪問后端的服務時，我們客戶端不是直接訪問的，因為它不知道后端是誰的，它需要先去找一個位置看看有沒有這么一個服務
如果客戶訪問不到后端服務，定義為超時，那么這個攤位會自動移出該pod注冊的信息，新建的pod會在攤位會注冊服務信息
pod是有生命周期的，一個pod隨時可能離去，隨時也可能創建新的pod，假如它們提供的是同一種服務，我們客戶端是沒有辦法采用固定的手段來訪問這個pod的，因為pod是隨時變化的，無論你是使用主機名還是ip地址都隨時會替換掉，那怎么辦？這就需要用到服務發現機制了,那么K8S為同一類pod或同一組pod與客戶端之間添加了中間層這個中間層是固定的，這個中間層就叫做service,service只要不刪除，它的地址是固定的，名稱服務名也是固定的，這個服務不但能夠提供一個穩定的訪問入口還能起到調度的做作用，就算pod宕機了創建新的pod service會自動把pod關聯進來，大家知道pod有一個固定的元數據，叫標簽，它就是通過標簽來關聯的，關聯后能夠自動探測pod的IP地址和服務端口
而在K8S當中，service可不是什么應用程序，也不是什么組件，它只不過是iptables的DNAT規則
AddOns:附件:dns只是它們當中的一個
改附件能夠動態刪除動態變動:比如你把service名稱改了，它會自動觸發dns中的解析記錄，把解析記錄名稱也改了，客戶端訪問的時候，dns解析的是service的地址而不是pod的地址
service是端口代理，大家知道是DNAT實現，但是后面很多pod資源，所以DNAT認為是多目標調度了，對Linux來講iptables已經把負載均衡的功能主要交給IPVS來實現，所以調度效果上是不太近人意
所以在K8S的1.11版中，已經把iptables規則改為了IPVS規則，也就是說你每創建一個service的時候就相當於創建了一個IPVS規則
用Nginx+tomcat+mysql的例子類比所有的k8s集群架構:
K8S中，dns自身也是個pod
K8S有三種網絡:
它們的網絡關系是一層一層相互代理的
K8S的三類通信方式:
如果pod發生改變了，那么service怎么才能發現呢？當然是靠Lable標簽，service怎么又能改變所有節點上ipvs或iptables規則呢？這需要專門的組建來實現，在每一個node節點上有一個組件，這個組件一般是運行在node之上的守護進程叫kube-proxy,它負責隨時與API Server進行通信，因為每一個pod發生變化后，這個結果需要保存在API Server中的，而API Server內容發生改變后會生成一個通知事件，這個事件可以被任何關聯的組件知道，比如kube-proxy組件，一旦發現service背后的pod發生改變地址發生改變，則對應的由kube-proxy在本地反應到iptables或ipvs規則中，所以service是靠kube-proxy實現的
所以大家發現API Server需要存儲集群中各對象的各種狀態信息，所以是存儲不下的，怎么辦呢？存哪里呢不能存內存也不能存磁盤，所以要存儲在各Master共享存儲中，這個存儲叫做k8s的etcd，
etcd: 是一個鍵值對存儲，
所有集群的節點狀態信息都存儲在etcd中，如果，它出現了故障，那么集群也完了，所以需要對它做高可用，至少有三個節點
etcd一般有兩個端口，一個用於集群外部通信(向客戶端提供服務)，一個用於集群內部通信
內部通信需要專門的證書，叫點對點通信的證書來配置https，
而向客戶端(API Server)提供服務的時候通過https協議，要想加密又要另外一套證書來實現
而客戶端向API Server通信又需要另外一套ca頒發的證書
CNI:
插件體系來接入外部的網絡服務解決方案，CNI叫做容器網絡接口
k8s如果成千上萬個pod都能夠直接通信的話那么不安全，特別是多租戶的環境中，所以pod的網絡還是依賴service
事實上pod之間是可以直接通信的，那么怎么才能安全？用隔離，網絡策略所以引入K8S的另一個組件:名稱空間，注意不是docker上的名稱空間
名稱空間:
K8S網絡:
