一、k8s組成部分
Master
1、 kube-apiserver
封裝了核心對象的增刪改查操作，以REST API接口方式提供給外部和內部組件調用。它維護的REST對象將持久化到Etcd中
2、 kube-controller
負責執行各種控制器，目前已經實現很多控制器來保證Kubernetes的正常運行，部分控制器如下：
Replication Controller（簡稱RC）： 關聯RC和Pod，保證RC定義的副本數量與實際pod的數量是一致的。
Deployment Controller: 關聯RC和Deployment，保證運行指定數量的的pod，當Deployment更新時，控制實現RC和pod的更新。
3、 kube-scheduler
負責集群的資源調度，為新建的Pod分配機器。這部分工作分出來變成一個組件，意味着可以很方便地替換成其他的調度器
Etcd
k8s重要數據都是持久化在Etcd中的
Node
1、kubelet 負責管控容器，Kubelet會從Kubernetes API Server接收Pod的創建請求，啟動和停止容器，監控容器運行狀態並匯報給Kubernetes API Server。 2、kube-proxy 負責為Pod創建代理服務，Kubernetes Proxy會從Kubernetes API Server獲取所有的Service，並根據iptables轉發Service信息到對應的pod。
NOTE:
kube-proxy 要求 NODE 節點操作系統中要具備 /sys/module/br_netfilter 文件，而且還要設置 bridge-nf-call-iptables=1，如果不滿足要求，那么 kube-proxy 只是將檢查信息記錄到日志中，
kube-proxy 仍然會正常運行，但是這樣通過 Kube-proxy 設置的某些 iptables 規則就不會工作
二、k8s的基本概念
Pod
pod是什么？
一個Pod是一個容器環境下的“邏輯主機”，包含一個或者多個相關的容器，一個node節點下可以有多個pod。
pod下的容器共享資源，包括：
PID 命名空間（同一個Pod中應用可以看到其它進程）
網絡 命名空間（同一個Pod的中的應用對相同的IP地址和端口有權限）
IPC 命名空間（同一個Pod中的應用可以通過VPC或者POSIX進行通信）
UTS 命名空間（同一個Pod中的應用共享一個主機名稱）
pod中的網絡
Pod中的所有容器網絡都是共享的，每個pod都有一個ip。通過PodIP，Pod就能夠跨網絡與其他物理機和容器進行通信
Service
service是什么？
Kubernetes提供了強大的服務編排能力，微服務化應用的每一個組件都以Service進行抽象，組件和組件之間只需要訪問Service即可以互相通信，而無須感知組件的集群變化。同時Kubernetes 為Service提供了服務發現的能力，組件和組件之間可以簡單地互相發現.
集群外部默認不能訪問service ip。若需要外部訪問service，Kubernetes提供了NodePort Service、LoadBalancer Service和Ingress可以發布Service
Service由多個pod組成。
兩種服務發現方法：環境變量和DNS
環境變量 原理：環境變量中記錄了Service的虛擬IP以及端口和協議信息。這樣一來，Pod中的程序就可以使用這些環境變量發現Service。 缺點：環境變量是租戶隔離的，即Pod只能獲取同Namespace中的Service的環境變量。另外，Pod和Service的創建順序是有要求的，即Service必須在Pod創建之前被創建，否則Service環境變量不會設置到Pod中。DNS服務發現方式則沒有這些限制 DNS 原理：DNS服務發現方式需要Kubernetes提供Cluster DNS支持，Cluster DNS會監控Kubernetes API，為每一個Service創建DNS記錄用於域名解析，這樣在Pod中就可以通過DNS域名獲取Service的訪問地址。 Pod中的容器使用容器宿主機的DNS域名解析配置/etc/resolv.conf，稱為默認DNS配置，另外，如果Kubernetes部署並設置了Cluster DNS支持，那么在創建Pod的時候，默認會將Cluster DNS的配置寫入Pod中容器的DNS域名解析配置中，稱為Cluster DNS配置。
數據卷
數據卷的作用 數據卷用於實現容器持久化數據，Kubernetes對於數據卷重新定義，提供了豐富強大的功能。數據卷按照功能划分為三類：本地數據卷、網絡數據卷和信息數據。 本地數據卷 1、EmptyDir： Pod被刪除，EmptyDir數據卷也會被刪除，並且永久丟失 2、HostPath 將容器宿主機上的文件系統掛載到Pod中 網絡數據卷 1、NFS 2、iSCSI
信息數據卷
1、Secret 處理敏感數據，比如密碼、Token和密鑰，相比於直接將敏感數據配置在Pod的定義或者鏡像中，Secret提供了更加安全的機制，防止數據泄露
Namespace命名空間
Namespace是Kubernetes提供的多租戶，不同的項目、團隊或者用戶可以通過Namespace進行區分管理，並且設置安全控制和其他策略,實現資源隔離。絕大部分API對象（除了Node）歸屬於Namespace，API對象通過.metadata.namespace指定Namespace，
如果沒有指定Namespace，那么歸屬於默認default。
CNI
通過Kubelet傳遞--network-plugin=cni命令行選項來選擇CNI插件。Kubelet從--cni-conf-dir（默認/etc/cni/net.d）讀取文件，並使用該文件中的CNI配置來設置每個pod的網絡。CNI配置文件必須與CNI規范匹配，並且配置引用的任何所需CNI插件必須
存在於--cni-bin-dir（默認/opt/cni/bin）中。 如果目錄中有多個CNI配置文件，則使用文件名的詞典順序中的第一個。 除了配置文件指定的CNI插件外，Kubernetes還需要標准的CNI lo插件，最低版本為0.2.0
訪問k8s API
使用命令行工具kubectl： 查看pod：kubectl get pod 查看具體pod：kubectl describe pod pod名 --namespace=* 創建資源：kubectl create –f res.yaml 更新資源：kubectl apply –f res.yaml 刪除資源：kubectl delete pod pod名 回滾到某個版本 kubectl rollout undo deployment/nginx-deployment --to-revision=2 擴容 kubectl scale deployment nginx-deployment --replicas 10 自動擴容 kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80 暫停Deployment kubectl rollout pause deployment/nginx-deployment 恢復Deployment kubectl rollout resume deploy nginx PS：Deployment的rollout當且僅當Deployment的pod template（例如.spec.template）中的label 更新或者鏡像更改時被觸發。其他更新，例如擴容Deployment不會觸發rollout。
helm管理軟件包
Helm之於Kubernetes好比yum之於RHEL。Helm是由helm CLI和Tiller組成，是典型的C/S應用。helm運行與客戶端，提供命令行界面，而Tiller應用運行在Kubernetes內部。Helm管理的kubernetes資源包稱之為Chart
Endpoints
創建Service的同時，會自動創建跟Service同名的Endpoints
三種ip
Node IP：Node節點的IP地址。 節點物理網卡ip
Pod IP：Pod的IP地址。 Docker Engine根據docker0網橋的IP地址段進行分配的，通常是一個虛擬的二層網絡
Cluster IP：Service的IP地址。 屬於Kubernetes集群內部的地址，無法在集群外部直接使用這個地址
端口
Yaml配置文件中的幾種port如下： targetPort ：是pod上的端口 containport：容器的port port：service的port 將Service的端口號映射到物理機 方式一：nodeport：service的 port，kube-proxy開通宿主機的端口 默認端口范圍30000-32768 實現集群外訪問內容應用，但是這種方式無法解決負載均衡問題。可以使用經過反向代理kube-proxy流入后端pod的targetport，能實現負載均衡 方式二： 通過設置LoadBalancer映射到雲服務商提供的LoadBalancer地址, 被提供的負載均衡器的信息將會通過 Service 的 status.loadBalancer 字段被發布出去。
訪問多集群
將當前上下文更改為 exp-scratch：
kubectl config --kubeconfig=config-demo use-context exp-scratch
安全性
訪問api驗證授權具體步驟 1、 認證 認證模塊包括客戶端證書，密碼，明文token，初始token，和JWT token（用於服務賬號）。可以同時指定多個認證模塊，對於這種情況，會按照指定的順序一個個嘗試認證，直到有一個認證成功為。
2、 授權 一個請求必須包含請求者的用戶名，請求的動作，影響動作的對象。如果有存在的策略聲明這個用戶有權限完成這個動作，那么該請求就會被授權。當配置多個授權模塊時，按順序檢查每個模塊，如果有任何模塊授權請求，則可以繼續執行該請求。如果所有模塊拒絕請求，則拒絕該請求(HTTP狀態代碼403)。
3、 准入控制 如果准入控制插件序列中任何一個拒絕了該請求，則整個請求將立即被拒絕並且返回一個錯誤給終端用戶。 用戶賬號 vs 服務賬號（Service account） 1、 用戶賬號是給人使用的。服務賬號是給 pod 中運行的進程使用的 2、 用戶賬號為全局設計的。命名必須在一個集群的所有命名空間中唯一，未來的用戶資源不會被設計到命名空間中。 服務賬號是在命名空間里的。
服務賬號自動化
服務賬號的自動化由三個獨立的組件共同配合實現： 一、 服務賬號准入控制器（Service account admission controller） 在pod被創建或者更改時，它會做如下操作： 1、 如果pod沒有配置ServiceAccount，它會將ServiceAccount設置為default。 2、 確保被pod關聯的ServiceAccount是存在的，否則就拒絕請求。 3、 如果pod沒有包含任何的ImagePullSecrets，那么Serviceaccount的 ImagePullSecrets就會被添加到pod。 4、 它會把volume添加給pod，該pod包含有一個用於API訪問的令牌。 5、 它會把volumeSource 添加到pod的每個容器，掛載到/var/run/secrets/kubernetes.io/serviceaccount。 二、令牌控制器（Token controller） 三、 服務賬號控制器（Service account controller）
DaemonSet
DaemonSet能夠讓所有（或者一些特定）的Node節點運行同一個pod。當節點加入到kubernetes集群中，pod會被（DaemonSet）調度到該節點上運行，當節點從kubernetes集群中被移除，被（DaemonSet）調度的pod會被移除，如果刪除DaemonSet，
所有跟這個DaemonSet相關的pods都會被刪除。
例如如下場景：
每個Node上運行一個分布式存儲的守護進程，例如glusterd，ceph
每個Node上運行日志采集器，例如fluentd，logstash
每個Node上運行監控的采集端，例如Prometheus Node Exporter, collectd等
Taints和Tolerations
Taints定義在Node節點上，聲明污點及標准行為
Tolerations定義在Pod，聲明可接受得污點
具有 taint 的 node 和 pod 是互斥關系 annotations: scheduler.alpha.kubernetes.io/taints:'[{"key":"dedicated","value":"master","effect":"NoSchedule"}]'
親和性和反親和性
親和性：應用A與應用B兩個應用頻繁交互，所以有必要利用親和性讓兩個應用的盡可能的靠近，甚至在一個node上，以減少因網絡通信而帶來的性能損耗。
反親和性：當應用的采用多副本部署時，有必要采用反親和性讓各個應用實例打散分布在各個node上，以提高HA。
NodeName和NodeSelector
Pod.spec.nodeName用於強制約束將Pod放到到指定的Node名字節點上
Pod.spec.nodeSelector是通kubernete的label-selector機制進行節點選擇，由scheduler調度策略MatchNodeSelector進行label匹配，調度pod到目標節點，該匹配規則是強制約束。
四、 通過yaml文件創建資源
比如創建RC資源
RC通過spec.selector關聯pod的label,
RS和RC通spec.template設置Pod。
RS比RC的區別：RS使用基於集合的標簽選擇器
五、 kubectl常用命令
查看部署狀態
kubectl rollout status deployment/email
更新鏡像
kubectl set image deployment/email email=10.15.37.119/hic/email:tag4 busybox=busybox 將部署的email容器鏡像設置為'email:tag4'，其busybox容器映像設置為'busybox'。 PS：如果本地制作鏡像，啟動或更新pod時，對應node上必須有鏡像才行
回滾上一次版本
kubectl rollout undo deployment/email #查看pod運行在那個節點 kubectl get po -o wide