參考：
https://zhuanlan.zhihu.com/p/43266412
https://zhuanlan.zhihu.com/p/292081941

k8s的作用和解決什么問題

由于docker并不具備分布式集群部署，自動擴容縮容，負(fù)載均衡的能力，并且沒有解決故障自愈和集群內(nèi)服務(wù)間的通信問題。k8s的出現(xiàn)就很好的彌補了docker的這些缺點，并且k8s自身也有非常出色的容器技術(shù)，不一定非得使用docker配合k8s，在最新的k8s版本中已經(jīng)移除對docker容器的支持。簡而言之k8s就是容器技術(shù)的分布式架構(gòu)系統(tǒng)

作用：

• 自動化服務(wù)

  • 1、自動快速的垂直擴容縮容和水平擴容縮容、更新部署：
    • a、垂直擴容和縮容：服務(wù)器能夠輕易的增加和刪除
    • b、水平擴容和縮容：容器能輕松增加和移除
  • 2、自動為擴容的pod實例提供負(fù)載均衡
  • 3、自動的提供健康檢查和自愈能力
  • 4、根據(jù)指令做到任務(wù)的自動統(tǒng)一調(diào)度

k8s架構(gòu)

K8S是屬于主從設(shè)備模型（Master-Slave架構(gòu)），即有Master節(jié)點負(fù)責(zé)核心的調(diào)度、管理和運維，Slave節(jié)點則在執(zhí)行用戶的程序。但是在K8S中，主節(jié)點一般被稱為Master Node或者Head Node或Master Node，而從節(jié)點則被稱為Worker Node或者Node。Master Node和Worker Node組成了K8S集群，同一個集群可能存在多個Master Node和Worker Node

Master Node

• ETCD:K8S的存儲服務(wù)。ETCD保存了集群中Master Node和Worker Node中各個組件的狀態(tài)，同時也存儲了K8S的關(guān)鍵配置和用戶配置，k8s架構(gòu)所有需要持久化的數(shù)據(jù)都會存儲在ETCD中。K8S中僅API Server才具備讀寫權(quán)限，其他組件必須通過API Server的接口才能讀寫數(shù)據(jù);
• Controller Manager：Worker Node的監(jiān)控器，Controller Manager有很多不同類型的Controller，主要負(fù)責(zé)維護集群的狀態(tài)，比如故障檢測、自動擴展、滾動更新等；
• Scheduler：負(fù)責(zé)資源的調(diào)度，按照預(yù)定的調(diào)度策略將 Pod 調(diào)度到相應(yīng)的Node節(jié)點上；
• API Server:API Server負(fù)責(zé)接收K8S所有請求,是k8s資源操作的唯一入口,并提供認(rèn)證、授權(quán)、訪問控制、API 注冊和發(fā)現(xiàn)等機制。API Server根據(jù)的具體請求，去通知其他組件干活。

Worker Node

• Kubelet。Worker Node的監(jiān)視器。每個節(jié)點上都運行一個 kubelet 服務(wù)進程，默認(rèn)監(jiān)聽 10250 端口，接收并執(zhí)行 master 發(fā)來的指令，管理 Pod 及 Pod 中的容器。每個 kubelet 進程會在 API Server 上注冊節(jié)點自身信息，定期向 master 節(jié)點匯報節(jié)點的資源使用情況，并監(jiān)控節(jié)點和容器的資源，維護node節(jié)點上Pod的生命周期。
• Kube-Proxy：K8S的網(wǎng)絡(luò)代理。Kube-Proxy負(fù)責(zé)Node在K8S的網(wǎng)絡(luò)通訊、以及對外部網(wǎng)絡(luò)流量的負(fù)載均衡。
• Container Runtime：Worker Node的運行環(huán)境。容器運行時（Container Runtime）是 Kubernetes 最重要的組件之一，負(fù)責(zé)真正管理鏡像和容器的生命周期。Kubelet 通過 Container Runtime Interface (CRI) 與容器運行時交互，以管理鏡像和容器。

其他組件：

kube-dns：負(fù)責(zé)為整個集群提供 DNS 服務(wù)
Ingress Controller：為服務(wù)提供外網(wǎng)入口
Heapster：提供資源監(jiān)控
Dashboard：提供 GUI
Federation：提供跨可用區(qū)的集群
Fluentd-elasticsearch：提供集群日志采集、存儲與查詢

K8S重要概念

• Pod：Pod是可以在 Kubernetes 中創(chuàng)建和管理的、最小的可部署的計算單元。Pod可以被理解成一群可以共享網(wǎng)絡(luò)、存儲和計算資源的容器化服務(wù)的集合。同一個Pod之間的Container可以通過localhost互相訪問，并且可以掛載Pod內(nèi)所有的數(shù)據(jù)卷；但是不同的Pod之間的Container不能用localhost訪問，也不能掛載其他Pod的數(shù)據(jù)卷。每個Pod中都運行著一個特殊的被稱為Pause的容器，其他容器則為業(yè)務(wù)容器，這些業(yè)務(wù)容器共享Pause容器的網(wǎng)絡(luò)棧和Volume掛載卷，因此它們之間的通信和數(shù)據(jù)交換更為高效，在設(shè)計時我們可以充分利用這一特性將一組密切相關(guān)的服務(wù)進程放入同一個Pod中，每當(dāng)啟動一個pod的時候,pause容器也會隨之啟動
• Deployment：Deployment的作用是管理和控制Pod和ReplicaSet，管控它們運行在用戶期望的狀態(tài)中，確保每時每刻有用戶要求數(shù)量的Pod在工作。如果一旦發(fā)現(xiàn)某Pod不行了，就從其他的node上啟動一個新的pod替換掉。
• ReplicaSet ：ReplicaSet 的目的是維護一組Pod在任何時候都處于穩(wěn)定運行的狀態(tài)。 因此，它通常用來保證給定數(shù)量的、完全相同的 Pod 的可用性。ReplicaSet受控制于Deployment
• Service：Service屏蔽了服務(wù)細(xì)節(jié)，統(tǒng)一對外暴露服務(wù)接口。舉個例子，我們的一個服務(wù)A，部署了3個備份，也就是3個Pod；對于用戶來說，只需要關(guān)注一個Service的入口就可以，而不需要操心究竟應(yīng)該請求哪一個Pod。一方面外部用戶不需要感知因為Pod上服務(wù)的意外崩潰、K8S重新拉起Pod而造成的IP變更，外部用戶也不需要感知因升級、變更服務(wù)帶來的Pod替換而造成的IP變化，另一方面，Service還可以做流量負(fù)載均衡。
• Ingress：Ingress是整個K8S集群的接入層，負(fù)責(zé)集群內(nèi)外通訊，類似springcloud的zuul網(wǎng)關(guān)的作用
• Label：Label是為使Deployment識別調(diào)度范圍內(nèi)的Pod是哪些，從而使service知道給哪些Pod進行負(fù)載均衡。比如我有2個業(yè)務(wù)A和B，通過標(biāo)簽，DeploymentA和DeploymentB可以識別調(diào)度的Pod在哪里，Label不僅可以貼到pod上，它還可以貼到任何的資源上，例如：Namespace和node都可以貼標(biāo)簽
• Namespace:在一個Kubernetes集群中可以使用namespace創(chuàng)建多個“虛擬集群”，這些namespace之間可以完全隔離,資源名稱在同一個命名空間內(nèi)需保持唯一，但是兩個不同的命名空間可以包含同名的資源。例如service訪問pod時，如果service的命名空間不指定正確，那么就無法通過標(biāo)簽關(guān)聯(lián)到pod。但是可以通過某種方式，讓一個namespace中的service可以訪問到其他的namespace中的pod。也就是說命名空間不會隔離不同空間下的Pod 之間的網(wǎng)絡(luò)通訊，除非針對命名空間加了相應(yīng)的安全策略。

通過實例理解概念：

參考：https://zhuanlan.zhihu.com/p/265997618

以搭建Nginx為例：
創(chuàng)建命名空間

vim nginx-namespace.yaml

apiVersion: v1 #類型為Namespace
kind: Namespace  #類型為Namespace
metadata:
  name: ns-test  #命名空間名稱

#創(chuàng)建
kubectl create -f nginx-namespace.yaml
#查詢
kubectl get namespace

在Namespace下創(chuàng)建資源,通過controller來創(chuàng)建pod。deployment為其中一種controller
deployment創(chuàng)建pod

vim nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: ns-test
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

#創(chuàng)建
kubectl create -f nginx-deployment.yaml
#查詢
kubectl get deployment
#或
kubectl get pods -n ns-test

創(chuàng)建service
使用隨機生產(chǎn)ip:

vim nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

kubectl create -f nginx-service.yaml
//查看生成的ip
kubectl get svc nginx-service -o wide

創(chuàng)建service
使用本機ip:

vim nginx-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 8000

kubectl create -f nginx-service.yaml