Kubernetes基本概念

1. 集群架構

1.1. Nodes（節點）

一個節點就是Kubernetes中的一個作業機器，一個節點可能是一臺虛擬機，也可能是一臺物理機，

每個節點都包含運行pods所需的服務，并由master組件管理，

節點上的服務包括container runtime、kubelet和kube-proxy，

1.1.1. 節點狀態

節點的狀態包含以下資訊：

• Addresses
• Conditions
• Capacity and Allocatable
• Info 

# 查看節點串列kubectl get nodes # 查看節點狀態kubectl describe node  <insert-node-name-here>

示例：

localhost-2:~ chengjiansheng$ kubectl get nodesNAME       STATUS   ROLES    AGE    VERSIONminikube   Ready    master   3d2h   v1.16.2localhost-2:~ chengjiansheng$ kubectl describe node minikubeName:               minikubeRoles:              masterLabels:             beta.kubernetes.io/arch=amd64                    beta.kubernetes.io/os=linux                    kubernetes.io/arch=amd64                    kubernetes.io/hostname=minikube                    kubernetes.io/os=linux                    node-role.kubernetes.io/master=Annotations:        kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock                    node.alpha.kubernetes.io/ttl: 0                    volumes.kubernetes.io/controller-managed-attach-detach: trueCreationTimestamp:  Sat, 16 Nov 2019 18:58:34 +0800Taints:             <none>Unschedulable:      falseConditions:  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message  ----             ------  -----------------                 ------------------                ------                       -------  MemoryPressure   False   Tue, 19 Nov 2019 21:21:27 +0800   Sat, 16 Nov 2019 18:58:30 +0800   KubeletHasSufficientMemory   kubelet has sufficient memory available  DiskPressure     False   Tue, 19 Nov 2019 21:21:27 +0800   Sat, 16 Nov 2019 18:58:30 +0800   KubeletHasNoDiskPressure     kubelet has no disk pressure  PIDPressure      False   Tue, 19 Nov 2019 21:21:27 +0800   Sat, 16 Nov 2019 18:58:30 +0800   KubeletHasSufficientPID      kubelet has sufficient PID available  Ready            True    Tue, 19 Nov 2019 21:21:27 +0800   Sat, 16 Nov 2019 18:58:30 +0800   KubeletReady                 kubelet is posting ready statusAddresses:  InternalIP:  192.168.99.111  Hostname:    minikubeCapacity: cpu:                2 ephemeral-storage:  17784772Ki hugepages-2Mi:      0 memory:             1985612Ki pods:               110Allocatable: cpu:                2 ephemeral-storage:  17784772Ki hugepages-2Mi:      0 memory:             1985612Ki pods:               110System Info: Machine ID:                 0ea5d1f0d9bc427f83fd59da99157a63 System UUID:                f2aed72a-64ac-4016-8cb4-eaa2ce6afea5 Boot ID:                    8c476881-65ed-419a-aee5-ccc4adaa7527 Kernel Version:             4.19.76 OS Image:                   Buildroot 2019.02.6 Operating System:           linux Architecture:               amd64 Container Runtime Version:  docker://18.9.9 Kubelet Version:            v1.16.2 Kube-Proxy Version:         v1.16.2Non-terminated Pods:         (12 in total)  Namespace                  Name                                          CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE  ---------                  ----                                          ------------  ----------  ---------------  -------------  ---  default                    hello-minikube-6cf65d8776-7lkkt               0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d14h  kube-system                coredns-67c766df46-hhxh8                      100m (5%)     0 (0%)      70Mi (3%)        170Mi (8%)     6d17h  kube-system                coredns-67c766df46-p2hh9                      100m (5%)     0 (0%)      70Mi (3%)        170Mi (8%)     6d17h  kube-system                etcd-minikube                                 0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d17h  kube-system                kube-addon-manager-minikube                   5m (0%)       0 (0%)      50Mi (2%)        0 (0%)         6d17h  kube-system                kube-apiserver-minikube                       250m (12%)    0 (0%)      0 (0%)           0 (0%)         6d17h  kube-system                kube-controller-manager-minikube              200m (10%)    0 (0%)      0 (0%)           0 (0%)         6d17h  kube-system                kube-proxy-8zzlz                              0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d17h  kube-system                kube-scheduler-minikube                       100m (5%)     0 (0%)      0 (0%)           0 (0%)         6d17h  kube-system                storage-provisioner                           0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d17h  kubernetes-dashboard       dashboard-metrics-scraper-76585494d8-2w8md    0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d11h  kubernetes-dashboard       kubernetes-dashboard-57f4cb4545-mqxxn         0 (0%)        0 (0%)      0 (0%)           0 (0%)         6d11hAllocated resources:  (Total limits may be over 100 percent, i.e., overcommitted.)  Resource           Requests    Limits  --------           --------    ------  cpu                755m (37%)  0 (0%)  memory             190Mi (9%)  340Mi (17%)  ephemeral-storage  0 (0%)      0 (0%)Events:              <none>

conditions欄位描述所有Running節點的狀態， 

如果Ready條件的狀態在長時間內保持Unknown或為False，并且持續時間超過pod-eviction-timeout所指定的時間的話，那么會向kube-controller-manager傳遞一個引數，節點控制器將調度節點上的所有pod進行洗掉，默認的清除超時時間是5分鐘，在某些情況下，當節點不可用時，apiserver無法與節點上的kubelet通信，在與apiserver重新建立通信之前，不能將洗掉無法與kubelet通信pods的決定傳達給kubelet，與此同時，計劃洗掉的pods可以繼續在磁區節點上運行，

在1.5及更高版本中，節點控制器不會強制洗掉pod，直到確認它們已停止在集群中運行，你可以看到在一個不可到達的節點上運行的pod一直處于Terminating或Unknown狀態，在Kubernetes無法從底層基礎設施推斷出某個節點是否永久離開了集群的情況下，集群管理員可能需要手工洗掉節點物件，從Kubernetes中洗掉節點物件將導致在該節點上運行的所有Pod物件從apiserver中洗掉，并釋放它們的名稱，

Capacity 和 Allocatable 欄位，描述節點上可用的資源：CPU、記憶體和可以在節點上調度的最大pods數，

Capacity塊中的欄位表示節點擁有的資源總量，

Allocatable塊表示一個節點上可供普通Pods使用的資源數量，

1.1.1. 節點管理

與pods和services不同，node不是由Kubernetes創建的：它是由諸如谷歌計算引擎之類的云提供商在外部創建的，或者它存在于一組物理或虛擬機中，因此，當Kubernetes創建一個節點時，它創建一個表示該節點的物件，創建之后，Kubernetes檢查節點是否有效，

Kubernetes在內部創建一個節點物件來表示，并通過基于metada.name欄位的健康檢查來驗證節點，如果節點是有效的，也就是說，如果所有必需的服務都在運行，那么它就有資格運行pod，否則，對于任何集群活動都將忽略它，直到它變得有效為止， 

目前，有三個組件與Kubernetes節點介面互動：node controller、kubelet和kubectl，

Node Controller

節點控制器是管理節點各個方面的Kubernetes master組件， 

第一個是在節點注冊時為其分配CIDR塊（如果打開了CIDR分配），

第二個是使節點控制器的內部節點串列與云提供商的可用機器串列保持最新，在云環境中運行時，每當某個節點不健康時，節點控制器就會詢問云提供商該節點的VM是否仍然可用，否則，節點控制器將從節點串列中洗掉節點，

第三是監控節點的健康狀況，節點控制器每隔--node-monitor-period秒檢查每個節點的狀態， 

1.2. Master-Node Communication（主節點通信）

1.2.1. Cluster to Master

從集群到主服務器的所有通信路徑都終止于apiserver（其他的主組件都不是為了公開遠程服務而設計的），在典型的部署中，apiserver被配置為偵聽安全HTTPS埠(443)上的遠程連接，并且啟用了一種或多種形式的客戶端身份驗證，

希望連接到apiserver的pod可以通過利用服務帳戶來實作安全連接，以便Kubernetes在pod實體化時自動將公共根證書和有效的承載令牌注入到pod中，kubernetes服務(在所有名稱空間中)配置了一個虛擬IP地址，該地址(通過kube-proxy)重定向到apiserver上的HTTPS端點，

因此，默認情況下，從集群（節點和在節點上運行的pod）到主服務器的連接的默認操作模式是安全的，可以在不可信的和/或公共網路上運行， 

1.2.2. Master to Cluster

從master（apiserver）到cluster有兩條主要通信路徑，第一個是從apiserver到kubelet行程，它在集群中的每個節點上運行，第二種是通過apiserver的代理功能從apiserver到任何節點、pod或服務，

apiserver to kubelet

從apiserver到kubelet的連接用于：

• 獲取pods的日志
• 連接（通過kubectl）正在運行的pods
• 提供kubelet的埠轉發功能 

默認情況下，apiserver不驗證kubelet的服務證書，這使得連接容易受到中間人攻擊，在不可信的和/或公共網路上運行不安全，為了校驗此連接，請使用--kubelet-certificate-authority標志為apiserver提供一個根證書包，用于驗證kubelet的服務證書， 

apiserver to nodes, pods, and services 

從apiserver到節點、pod或服務的連接默認為純HTTP連接，因此既不進行身份驗證，也不進行加密，他們可以運行在一個安全的HTTPS連接通過加前綴HTTPS，但他們不會驗證證書提供的HTTPS端點也提供客戶端憑證所以當連接將被加密，它不會提供任何擔保的完整性，這些連接目前在不可信和/或公共網路上運行是不安全的， 

1.3. Controllers

在Kubernetes中，控制器是監視集群狀態的控制回路，然后根據需要進行或請求更改，每個控制器都試圖將當前集群狀態移動到更接近期望的狀態， 

2. Containers（容器）

2.1. Images（鏡像）

為了在Kubernetes pod中參考鏡像，你必須首先創建Docker鏡像，并推送至鏡像倉庫，容器的image屬性支持與docker命令相同的語法 ，

2.1.1. 更新鏡像

默認的拉取策略是IfNotPresent，它會導致Kubelet跳過拉取一個已經存在的鏡像，

如果你希望總是強制拉取，可以采用以下任意一種方式：

• 將容器的imagePullPolicy設定為Always
• 省略imagePullPolicy并使用:latest作為要使用的鏡像的tag
• 省略imagePullPolicy和要使用的鏡像的tag
• 啟用AlwaysPullImages控制器 

2.1.2. 使用私有倉庫

https://cr.console.aliyun.com/cn-hangzhou/new

3. Workloads

3.1. Pods

Pod是Kubernetes應用程式的基本執行單元，創建或部署的Kubernetes物件模型中最小、最簡單的單元，Pod代表在集群上運行的行程，

一個Pod封裝了一個應用程式的容器（在某些情況下是多個容器）、存盤資源、一個唯一的網路IP和控制容器如何運行的選項，

一個Pod代表一個部署單元：Kubernetes中的應用程式的一個單個實體，它可能由單個容器或少量緊密耦合且共享資源的容器組成， 

Docker是Kubernetes Pod中最常用的容器運行時，但是Pods也支持其他容器運行時，

Pods在Kubernetes集群中主要有兩種使用方式：

• Pods that run a single container. The “one-container-per-Pod” model is the most common Kubernetes use case; in this case, you can think of a Pod as a wrapper around a single container, and Kubernetes manages the Pods rather than the containers directly.
• Pods that run multiple containers that need to work together. A Pod might encapsulate an application composed of multiple co-located containers that are tightly coupled and need to share resources. These co-located containers might form a single cohesive unit of service–one container serving files from a shared volume to the public, while a separate “sidecar” container refreshes or updates those files. The Pod wraps these containers and storage resources together as a single manageable entity. 

Each Pod is meant to run a single instance of a given application. If you want to scale your application horizontally (e.g., run multiple instances), you should use multiple Pods, one for each instance. In Kubernetes, this is generally referred to as replication. Replicated Pods are usually created and managed as a group by an abstraction called a Controller.

每個Pod代表運行一個給定應用的一個單個實體，如果你想要水平擴展你的應用（例如，運行多個實體），你應該用多個Pods，每個實體一個Pod，在Kubernetes中，通常稱之為副本，副本Pods通常作為一個組被一個控制器創建和管理，

Pods如何管理多個容器 

Pods被設計成支持多個協作流程（作為容器），形成一個內聚的服務單元，Pod中的容器會自動在集群中的同一物理或虛擬機上同時定位和調度，容器可以共享資源和依賴項，彼此通信，以及協調何時以及如何終止它們，

請注意，在單個Pod中分組多個共存和共同管理的容器是一個相對高級的用例，你應該僅在容器緊密耦合的特定實體中使用此模式，例如，可能有一個容器充當共享卷中的檔案的web服務器，還有一個單獨的“sidecar”容器，用于從遠程源更新這些檔案，如下圖所示：

有些pod有init容器和app容器，Init容器在應用程式容器啟動之前運行并完成，

Pods為組成它的容器們提供兩種共享資源：網路和存盤，

網路

每個Pod被分配一個唯一的IP地址，Pod中的每個容器共享網路命名空間，包括IP地址和網路埠，Pod中的容器可以使用localhost彼此通信，當Pod中的容器與Pod外的物體通信時，它們必須協調如何使用共享的網路資源（如埠），

存盤

一個Pod可以指定一組共享存盤卷，Pod中的所有容器都可以訪問共享卷，從而允許這些容器共享資料，卷還允許在Pod中保存持久資料，以防需要重新啟動其中一個容器，

3.1.1. Pods and Controllers

通常，很少直接在kubernetes中創建單獨的Pods，這是因為Pod被設計成相對短暫的一次性物體，當Pod被創建時（直接創建，或間接由控制器創建)），它將被調度到在集群中的節點上運行，Pod將一直在該節點上，直到行程終止、洗掉Pod物件、由于缺乏資源而驅逐Pod或節點失敗，

Pods無法自愈（自動恢復），如果將Pod調度到失敗的節點，或者調度操作本身失敗，則Pod將被洗掉，同樣，如果由于缺乏資源或節點維護，Pod也將被洗掉，Kubernetes使用一個更高層次的抽象，稱為控制器，它處理管理相對可丟棄的Pod實體的作業，因此，雖然可以直接操作Pod，但在Kubernetes中使用控制器來管理Pod要常見得多，

一個Controller可以為你創建和管理多個Pods，并處理副本和rollout，以及集群范圍內提供自修復功能，例如，如果一個節點失敗，控制器可能通過在不同的節點上調度相同的副本來自動替換Pod，

控制器使用Pod模板來制作實際的Pod，下面是一個例子：

 apiVersion: v1 kind: Pod metadata:   name: myapp-pod   labels:     app: myapp spec:   containers:   - name: myapp-container     image: busybox     command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

3.2. Pod是什么

一個Pod（就像一個豌豆莢）是一個組，這個組中包含一個或多個容器（比如，Docker容器），具有共享存盤/網路，以及如何運行容器的規范，Pod的內容總是同時定位和同時調度，并在共享背景關系中運行，Pod為特定于應用程式的“邏輯主機”建立模型，它包含一個或多個相對緊密耦合的應用程式容器，在容器之前的世界中，在相同的物理或虛擬機上執行意味著在相同的邏輯主機上執行，

Docker是最常見的容器運行時，

Pod中的容器共享一個IP地址和埠空間，并且可以通過localhost相互查找，它們還可以使用SystemV信號量或POSIX共享記憶體等標準行程間通信進行通信，不同Pods中的容器有不同的IP地址，沒有特殊配置的情況下是不能通過IPC進行通信的，這些容器通常通過Pod IP地址彼此通信，

Pod中的應用程式也可以訪問共享volumes，這些共享volumes被定義為Pod的一部分，可以安裝到每個應用程式的檔案系統中，

在Docker構造方面，Pod被建模為一組Docker容器，它們具有共享的名稱空間和共享的檔案系統volumes，

與單個應用程式容器一樣，Pods被認為是相對短暫的（而不是持久的）物體，正如在pod生命周期中所討論的，創建pod，分配惟一ID (UID)，并將其調度到節點，直到終止（根據重啟策略）或洗掉，如果一個節點死亡，那么在超時之后，該節點的Pods將被洗掉，給定的Pod（由UID定義）不會“重新調度”到一個新節點；相反，它可以被一個相同的Pod替換，如果需要，甚至可以使用相同的名稱，但是要使用一個新的UID，

如果Pod被洗掉，那么與之相關聯的資源都會被銷毀，并在必要的時候重新創建，

3.2.1. Pods的動機

Pods是一個模型，這種模型就是將多個協作流程內聚成一個服務，它們通過提供比其組成應用程式集更高級別的抽象來簡化應用程式部署和管理，Pods可以作為部署、水平擴展和副本的單元，在Pods中，托管（協同調度）、共享命運（例如終止）、協調副本、資源共享和依賴項管理都是自動處理的，

Pods使得資料共享和成員之間的通信成為可能，

在一個Pod中的所有應用程式都使用相同的網路名稱空間（即，相同的IP和埠），因此應用之間可以“找到”彼此并使用localhost進行通信，因此，Pod中的應用程式必須協調它們對埠的使用，每個Pod在平面共享網路空間中都有一個IP地址，可以通過網路與其它物理計算機和Pod進行完全通信，

除了定義在Pod中運行的應用程式容器外，Pod還指定一組共享存盤volumes，Volumes使資料能夠在容器重啟后繼續存在，并在Pod內的應用程式之間共享，

為什么不在一個（Docke）容器中運行多個應用程式呢？

1、透明度，使Pod中的容器對基礎設施可見使基礎設施能夠向這些容器提供服務，例如流程管理和資源監控，這為用戶提供了許多便利，
2、解耦軟體依賴關系，可以獨立地對各個容器進行版本控制、重新構建和重新部署，
3、易用性，用戶不需要運行自己的行程管理器，不需要擔心信號和輸出代碼傳播等問題
4、效率，因為基礎設施承擔了更多的責任，容器可以更輕量級，

3.2.2. Pods的持久性

Pods不打算被視為持久的物體，它們無法在調度失敗、節點失敗或其他驅逐（如由于缺乏資源或在節點維護的情況下）中幸存下來，
一般來說，用戶不需要直接創建Pods，他們幾乎總是應該使用控制器，即使對于單例也是如此，例如部署，控制器提供集群范圍的自修復，以及副本和滾動管理，

3.2.3. Pods終止

因為Pods表示集群中節點上正在運行的行程，所以允許這些行程在不再需要它們時優雅地終止是很重要的（PS：優雅指的是與使用終止信號被暴力殺死而沒有機會清理的情況相比），用戶應該能夠請求洗掉并知道行程何時終止，但也能夠確保洗掉最終完成，當用戶請求洗掉一個Pod時，系統記錄允許強制殺死Pod之前的寬限期（默認30秒），并向每個容器中的主行程發送TERM信號，寬限期一過，KILL信號就發送給這些行程，然后從API服務器洗掉Pod，如果在等待行程終止時重新啟動了Kubelet或容器管理器，則將在完整的寬限期內重試終止，

3.3. Controllers

3.3.1. ReplicaSet

ReplicaSet（副本集）的目的是維護一組穩定的副本Pods，以保證在任何給定時間都有可用的Pods，因此，它通常用于保證指定數量的相同Pods的可用性，

一個ReplicaSet是由一些欄位定義的，包括一個選擇器，它指定如何識別它可以獲得的pod，一個副本的數量指示它應該維護多少個pod，一個pod模板指定它應該創建的新pod的資料，以滿足replicas的數量標準，然后，一個復制集通過創建和洗掉Pods來實作它的目的，以達到所需的數量，當一個復制集需要創建新的Pod時，它使用它的Pod模板，

示例：

 apiVersion: apps/v1 kind: ReplicaSet metadata:   name: frontend   labels:     app: guestbook     tier: frontend spec:   # modify replicas according to your case   replicas: 3   selector:     matchLabels:       tier: frontend   template:     metadata:       labels:         tier: frontend     spec:       containers:       - name: php-redis         image: gcr.io/google_samples/gb-frontend:v3

保存這個manifest檔案為frontend.yaml，并提交到Kubernetes集群，這樣就創建了一個副本集定義， 

# 提交副本集定義	kubectl apply -f  frontend.yaml# 獲取當前副本集kubectl get rs# 查看副本集狀態kubectl describe  rs/frontend

3.3.2. ReplicationController

ReplicationController確保在任何時候都運行指定數量的pod副本，換句話說，一個ReplicationController確保一個pod或一組同類的pod總是處于可用狀態， 

如果有太多的pods，ReplicationController會終止額外的pods，如果數量太少，ReplicationController就會啟動更多的pods，與手動創建的pods不同，ReplicationController維護的pods在失敗、洗掉或終止時將自動替換，例如，在內核升級等破壞性維護之后，將在節點上重新創建pods，因此，即使應用程式只需要一個pod，也應該使用ReplicationController，ReplicationController類似于行程管理器，但是它不是管理單個節點上的單個行程，而是管理跨多個節點的多個pod，

下面這個示例ReplicationController配置運行三個nginx web服務器副本：

 apiVersion: v1 kind: ReplicationController metadata:   name: nginx spec:   replicas: 3   selector:     app: nginx   template:     metadata:       name: nginx       labels:         app: nginx     spec:       containers:       - name: nginx         image: nginx         ports:         - containerPort: 80

另存為replication.yaml

# 提交副本定義kubectl apply -f replication.yaml# 查看副本狀態kubectl describe  replicationcontrollers/nginx

3.3.3. Deployments

一個Deployment（部署）為 Pods 和 ReplicaSets 提供宣告式更新，

你在部署中描述一個期望的狀態，而Deployment Controller以受控的速率將實際狀態更改為期望狀態，你可以定義部署來創建新的副本集，或者洗掉現有的部署， 

例如：

 apiVersion: apps/v1 kind: Deployment metadata:   name: nginx-deployment   labels:     app: nginx spec:   replicas: 3   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - name: nginx         image: nginx:1.7.9         ports:         - containerPort: 80

3.3.4. DaemonSet

DaemonSet確保所有（或部分）節點都運行一個Pod的副本，隨著節點被添加到集群中，pod也被添加到該節點上，當節點從集群中移除時，這些pods將被垃圾收集，洗掉DaemonSet將清理它創建的pods，

4. Services

一種將運行在一組pod上的應用程式公開為網路服務的抽象方法，

使用Kubernetes，你不需要修改應用程式來使用不熟悉的服務發現機制，Kubernetes為Pods提供它們自己的IP地址和單個DNS名稱，并且可以在它們之間實作負載均衡，

每個Pod都有自己的IP地址，但是在部署中，某個時刻運行的Pod集可能與稍后運行該應用程式的Pod集稍微有些不同，

在Kubernetes中，服務是一種抽象，它定義了一組邏輯Pods和訪問它們的策略（有時這種模式被稱為微服務），服務最終部署到哪個pods通常由選擇器決定
如果你在應用程式中使用Kubernetes API進行服務發現，則可以查詢API服務器的端點，并且在服務更新的時候這些端點也會得到更新，

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

4.1. 服務發現

Kubernetes支持兩種主要的模式：服務環境變數和DNS

當在節點上運行Pod時，kubelet為每個激活的服務添加一組環境變數，它既支持Docker links compatible 的變數，也支持更簡單的{SVCNAME}_SERVICE_HOST和{SVCNAME}_SERVICE_PORT變數，其中服務名采用大寫形式，破折號轉換為下劃線，

例如，有一個服務名字叫“redis-master”，IP和埠分別是10.0.0.11和6379，那么將會生成以下環境變數：

 REDIS_MASTER_SERVICE_HOST=10.0.0.11 REDIS_MASTER_SERVICE_PORT=6379 REDIS_MASTER_PORT=tcp://10.0.0.11:6379 REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379 REDIS_MASTER_PORT_6379_TCP_PROTO=tcp REDIS_MASTER_PORT_6379_TCP_PORT=6379 REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

4.2. 發布服務

Kubernetes ServiceTypes 允許你指定想要的服務型別，默認是ClusterIP，

Type可選值有：

• ClusterIP ： 在集群內部IP上公開服務，選擇此值將使服務只能從集群內訪問，這是默認的ServiceType，
• NodePort ： 在靜態埠上公開每個節點的IP上的服務，可以通過請求<NodeIP>:<NodePort>來訪問服務，
• LoadBalancer ： 使用云提供商的負載均衡器在外部公開服務，
• ExternalName ： 將服務映射到externalName欄位的內容（例如，foo.bar.example.com） 

4.3. Volumes

容器中的磁盤上的檔案是短暫的，這給在容器中運行的重要應用程式帶來了一些問題，首先，當容器崩潰時，kubelet將重新啟動它，但是檔案將丟失—容器將以一個干凈的狀態開始，其次，在一個Pod中一起運行容器時，常常需要在這些容器之間共享檔案，Kubernetes Volume抽象解決了這兩個問題，

Docker也有一個volumes（卷）的概念，在Docker中，卷就是磁盤上或另一個容器中的目錄，其生存期沒有管理， 

Kubernetes volume有一個明確的生命周期，它與包裹它的Pod一樣，因此，卷的生命周期比在Pod中運行的任何容器都長，并且跨容器重新啟動時保留資料，當然，當一個pod被洗掉的時候，volum也會被洗掉，更重要的是，Kubernetes支持多種型別的卷，一個Pod可以同時使用任意數量的卷，

標籤：其他

上一篇：讓微信推送Jenkins構建訊息

下一篇：k8s學習筆記