控制平面：
- API-Service: 運行於6443端口
- 接入master節點地址的6443端口進行交互
- 用戶認證， 雙向認證
- Scheduler
- Controller
工作平面：kube-proxy每個節點都有
核心資源:
- Pod
- Pod Controller
- deployment
- Service
和解循環（Reconciliation Loop）
- 客戶端向API Server提交POST請求以創建對象
- 通過JSON格式的body提交
- Yaml格式需要事先完成向JSON的轉換
- 對象匹配信息保存於etcd中，其定義出的狀態也稱為“期望的狀態（spec）”
- 控制器負責將其創建為k8s集群上的具體對象，並確保其當前狀態（status）與用戶定義的期望狀態相同
- status控制器自行維護，而spec則由用戶進行提交
- 活動對象在運行過程中因節點故障等原因可能會在某一時刻導致status不再吻合於spec
- 控制器通過和解循環（loop）不間斷地監控相關對象的當前狀態，在對象的當前狀態發生改變時運行合適的操作讓其當前狀態無限接近於期望的狀態
資源對象的配置格式
- API Server接受和返回的所有JSON對象都遵循同一個模式，他們都具有“kind”和"apiVersion"字段，用於表示對象所屬的資源類型、API群組及相關版本
- 大多數的對象或列表的資源還需要具有三個嵌套的字段metadata、spec、和status
- metadata字段為資源提供元數據信息，例如名稱、隸屬的名稱空間和標簽等
- spec用於定義用戶期望的狀態，不同的資源類型，其狀態的意義各不相同，例如pod資源最為核心的功能在於運行容器
- status則記錄着活動對象的當前狀態信息，它由kubernetes系統自行維護，對用戶來說是只讀字段
- “kubectl api-resources”命令可以獲取集群支持所使用的所有資源類型
管理資源對象
資源對象管理方式
- kubectl的命令可分為三類
- 陳述式命令
- 陳述式對象配置
- 聲明式對象配置
- 第一種方式即用到的run、expose、delete和get等命令，它們直接作用於kubernetes系統上的活動對象，簡單易用，但不支持代碼服用、修改復審及審計日志功能，這些功能的實現通常要依賴於資源配置文件中這些文件也被稱為資源清單。
我們可以使用以下命令快速導出資源的yaml文件，但是需要在導出的文件上做自己的配置修改后才能使用：
# kubectl get xxx -o yaml --export > desc_file
陳述式配置文件創建一個develop的namespace：
聲明式創建test的namespace：
- 聲明式相比於陳述式的好處是：修改了yaml文件之后直接apply就可以完成修改變動，而create不行
- apply可以直接指定一個目錄，目錄中的配置清單會被全部應用，而create不支持
API資源類型
♠♠♠默認情況下 pod 10.244.0.0/16 能否被集群外部訪問？ 10.244.0.0/16是flannel網絡插件內部網段 ♠♠♠
- 默認情況下答案是不能的
- 解決辦法
- 通過service NodePort 暴露每個節點上的一個端口映射
- 通過hostPort 暴露指定節點端口
- 通過hostNetwork 共享宿主機端口網絡