kubernetes入門（04）kubernetes的核心概念（1）

時間 2019-12-08

標籤 kubernetes 入門核心概念简体版

原文原文鏈接

1、ReplicationController/ReplicaSet

在Kubernetes集羣中，ReplicationController可以確保在任意時刻，指定數量的Pod副本正在運行。若是Pod副本的數量過多，則ReplicationController會Kill掉部分使其數量與預期保持一致，若是Pod數量過少，則會自動建立新的Pod副本以與預期數量相同。下面是一個ReplicationController的配置示例，以下所示：html

ReplicaSet是ReplicationController的下一代實現，它們之間沒有本質的區別，除了ReplicaSet支持在selector中經過集合的方式進行配置。在新版本的Kubernetes中支持並建議使用ReplicaSet，並且咱們應該儘可能使用Deployment來管理一個ReplicaSet。下面定義一個ReplicaSet，對應的配置示例以下所示：前端

2、Volume

默認狀況下容器的數據都是非持久化的，在容器銷燬之後數據也會丟失，因此Docker提供了Volume機制來實現數據的持久化存儲。一樣，Kubernetes提供了更強大的Volume機制和豐富的插件，實現了容器數據的持久化，以及在容器之間共享數據。
Kubernetes Volume具備顯式的生命週期，它與Pod的生命週期是相同的，因此只要Pod還處於運行狀態，則該Pod內部的全部容器都可以訪問該Volume，即便該Pod中的某個容器失敗，數據也不會丟失。
Kubernetes支持多種類型的Volume，以下所示：node

emptyDir
hostPath
gcePersistentDisk
awsElasticBlockStore
nfs
iscsi
fc (fibre channel)
flocker
glusterfs
rbd
cephfs
gitRepo
secret
persistentVolumeClaim
downwardAPI
projected
azureFileVolume
azureDisk
vsphereVolume
Quobyte
PortworxVolume
ScaleIO
StorageOS
local

上面各類類型的說明和示例，能夠參考官方文檔。Volume是與Pod有關的，因此這裏咱們給出一個Pod定義的配置示例，使用了hostPath類型的Volume，以下所示：nginx

上面定義中，指定了Pod中容器使用的Node節點上的data存儲路徑。git

3、Deployment

Deployment提供了聲明式的方法，對Pod和ReplicaSet進行更新，咱們只須要在Deployment對象中設置好預期的狀態，而後Deployment就可以控制將實際的狀態保持與預期狀態一致。使用Deployment的典型場景，有以下幾個：github

建立ReplicaSet，進而經過ReplicaSet啓動Pod，Deployment會檢查啓動狀態是否成功
滾動升級或回滾應用
應用擴容或縮容
暫停（好比修改Pod模板）及恢復Deployment的運行
根據Deployment的運行狀態，能夠判斷對應的應用是否hang住
清除掉再也不使用的ReplicaSet

定義一個Deployment，示例以下所示：web

上述配置建立一個ReplicaSet，進而啓動3個Nginx Pod。數據庫

4、DaemonSet

DaemonSet可以保證Kubernetes集羣中某些Node，或者所有Node上都運行一個Pod副本，當集羣中某個Node被移除時，該Node上的Pod副本也會被清理掉。刪除一個DaemonSet，也會把對應的Pod都刪除掉。
一般，DaemonSet會被用於以下場景（在Kubernetes集羣中每一個Node上）：安全

運行一個存儲Daemon，如glusterd、ceph等
運行一個日誌收集Daemon，如fluentd、logstash等
運行一個監控Daemon，如collectd、gmond等

定義一個DaemonSet，示例以下所示：網絡

上面例子，建立了一個基於fluentd的日誌收集DaemonSet。

5、StatefulSet

StatefulSet是Kubernetes v1.5版本新增的，在v1.5以前的版本叫作PetSet（使用v1.4版本可使用，具體能夠查看官方文檔，這裏再也不累述），是爲了解決有狀態服務的問題（對應無狀態服務的Kubernetes對象：Deployment和ReplicaSet），其應用場景包括：

穩定的持久化存儲，即Pod從新調度後仍是能訪問到相同的持久化數據，基於PVC來實現
穩定的網絡標誌，即Pod從新調度後其PodName和HostName不變，基於Headless Service（即沒有Cluster IP的Service）來實現
有序部署，有序擴展，即Pod是有順序的，在部署或者擴展的時候要依據定義的順序依次進行，基於init containers來實現
有序縮容，有序刪除

爲了說明StatefulSet，咱們先定義一個名稱爲nginx的Headless Service，以下所示：

再定義一個名稱爲web的StatefulSet，定義了要在3個獨立的Pod中分別建立3個nginx容器，示例以下所示：

上面示例，在Service中引用了名稱爲web的StatefulSet，該Service對應的存儲信息是有狀態的，經過StatefulSet可以保證Service中的Pod失敗也不會丟失存儲的數據，它經過PersistentVolume來提供穩定存儲的。

6、ConfigMap

應用程序會從配置文件、命令行參數或環境變量中讀取配置信息，若是將這些配置信息直接寫在Docker鏡像中，會很是不靈活，每次修改配置信息都要從新建立一個Docker鏡像。ConfigMap的出現，可以使配置信息與Docker鏡像解耦，更加方便和靈活。

在定義一個Pod的時候，可使用ConfigMap對象中的配置數據，有不少種方式，以下所示：

從一個ConfigMap中讀取鍵值對配置數據
從多個ConfigMap中讀取鍵值對配置數據
從一個ConfigMap中讀取所有的鍵值對配置數據
將一個ConfigMap中的配置數據加入到一個Volume中

下面給出其中2種使用方式：

定義一個環境變量，該變量值映射到一個ConfigMap對象中的配置值

建立一個名稱爲special-config的ConfigMap對象，執行以下命令：

kubectl create configmap special-config --from-literal=special.how=very

在上述ConfigMap對象special-config中建立了一個鍵special.how，它對應的值爲very。
而後，咱們定義一個Pod，將ConfigMap中的鍵special.how對應的值，賦值給環境變量SPECIAL_LEVEL_KEY，Pod定義文件內容，以下所示：

這時，Pod建立之後，就能夠獲取到對應的環境變量的值：SPECIAL_LEVEL_KEY=very。

建立多個ConfigMap對象，Pod從多個ConfigMap對象中讀取到對應的配置值

首先，建立第一個ConfigMap對象special-config，該對象定義了配置數據special.how=very，以下所示：

而後，建立第二個ConfigMap對象env-config，該對象定義了配置數據log_level=INFO，以下所示：

最後，就能夠在Pod中定義環境變量，以下所示：

在Pod建立後，能夠分別從special-config、env-config中讀取環境變量的值：SPECIAL_LEVEL_KEY=very、LOG_LEVEL=INFO。

7、Secret

Secret對象用來保存一些敏感信息，好比密碼、OAuth令牌、ssh祕鑰等，雖然這些敏感信息能夠放到Pod定義中，或者Docker鏡像中，可是放到Secret對象中更加安全和靈活。
使用Secret對象時，能夠在Pod中引用建立的Secret對象，主要有以下兩種方式：

掛載到一個或多個容器的Volume中的文件裏面
當爲一個Pod拉取鏡像時，被kubectl使用

能夠經過將Secret掛載到Volume中，或者以環境變量的形式導出，來被一個Pod中的容器使用。下面是一個示例，在一個Pod中的Volume上掛載一個Secret，以下所示：

經過導出環境變量，使用Secret，示例以下所示：

8、Job

一個Job會建立一個或多個Pod，並確保指定數目的Pod可以運行成功。Job會跟蹤每一個Pod的運行，直到其運行成功，若是該Job跟蹤的多個Pod都運行成功，則該Job就變爲完成狀態。刪除一個Job，該Job建立的Pod都會被清理掉。
定義一個Job，示例以下所示：

9、CronJob

Crontab用來管理定時Job，主要使用場景以下：

在一個給定的時間點，調度Job運行
建立一個週期性運行的Job，例如數據庫備份、發送郵件等等

定義一個CronJob，示例配置內容以下所示：

10、Ingress

一般狀況下，Service和Pod僅可在集羣內部網絡中經過IP地址訪問。全部到達Edge router的流量或被丟棄或被轉發到其它地方。一個Ingress是一組規則的集合，這些規則容許外部請求（公網訪問）直接鏈接到Kubernetes集羣內部的Service，

以下圖所示：

咱們能夠配置Ingress，爲它提供外部（公網）可訪問給定Service的規則，如Service URL、負載均衡、SSL、基於名稱的虛擬主機等。用戶想要基於POST方式請求Ingress資源，須要經過訪問Kubernetes API Server來操做Ingress資源。
Ingress Controller是一個daemon進程，它是經過Kubernetes Pod來進行部署的。它負責實現Ingress，一般使用負載均衡器，還能夠配置Edge router和其餘前端（frontends），以高可用（HA）的方式來處理請求。爲了可以使Ingress工做，Kubernetes集羣中必需要有個一個Ingress Controller在運行，不一樣於kube-controller-manager所管理的Controller，咱們必需要選擇一個適合咱們Kubernetes集羣的Ingress Controller實現，若是沒有合適的就須要開發實現一個。
定義一個Ingress，示例以下所示：

上面rules配置了Ingress的規則列表，目前只支持HTTP規則，該示例使用了HTTP的paths規則，所請求URL可以匹配上paths指定的testpath，都會被轉發到backend指定的Service上。
Ingress有以下5種類型：

單Service Ingress
簡單扇出（fanout）
基於名稱的虛擬主機
TLS
負載均衡

11、Horizontal Pod Autoscaler （彈性伸縮）

應用運行在容器中，它所依賴的資源的使用率一般並不均衡，資源使用量有時可能達到峯值，有時使用的又不多，爲了提升Kubernetes集羣的總體資源利用率，咱們須要Service中的Pod的個數可以根據實際資源使用量來自動調整。

這時咱們就可使用HPA（Horizontal Pod Autoscaling），它和Pod、Deployment等都是Kubernetes API資源，能實現Kubernetes集羣內Service中Pod的水平伸縮。

HPA的工做原理，以下圖所示：

經過下面命令，能夠對HPA進行各類操做（建立HPA、列出全部HPA、獲取HPA詳細描述信息、刪除HPA）：

另外，還能夠經過kubectl autoscale 命令來建立HPA，例如，執行以下命令：

kubectl autoscale rc foo --min=2 --max=5 --cpu-percent=80

上面示例的命令，要爲名稱爲foo的ReplicationController建立一個HPA對象，使得目標CPU利率用爲80%，而且副本的數量保持在2到5之間。

12、kubectl CLI

kubectl是一個命令行接口，經過它能夠執行命令與Kubernetes集羣交互。kubectl命令的語法格式，以下所示：

kubectl [command] [TYPE] [NAME] [flags]

上面命令說明中：
command：須要在一種或多種資源上執行的操做，好比：create、get、describe、delete等等，更詳細能夠參考官網文檔。
TYPE：指定資源類型，大小寫敏感，當前支持以下這些類型的資源：certificatesigningrequests、clusters、clusterrolebindings、clusterroles、componentstatuses、configmaps、cronjobs、daemonsets、deployments、endpoints、events、horizontalpodautoscalers、ingresses、jobs、limitranges、namespaces、networkpolicies、nodes、persistentvolumeclaims、persistentvolumes、poddisruptionbudget、pods、podsecuritypolicies、podtemplates、replicasets、replicationcontrollers、resourcequotas、rolebindings、roles、secrets、serviceaccounts、services、statefulsets、storageclasses、thirdpartyresources。
NAME：指定資源的名稱，大小寫敏感。
flags：可選，指定選項標誌，好比：-s或-server表示Kubernetes API Server的IP地址和端口。
若是想要了解上述命令的詳細用法說明，能夠執行幫助命令：

kubectl help

另外，還能夠經過官方文檔，根據使用的Kubernetes的不一樣版本，來參考以下連接獲取幫助：

下面，舉個經常使用的命令行操做，須要經過YAML文件定義一個Service（詳見上文「基本概念」中給出的Service示例），建立一個Service，執行以下命令：

kubectl create -f ./my-k8s-service.yaml

定義任何Kubernetes對象，都是經過YAML文件去配置，使用相似上述命令進行建立。若是想要查看建立Kubernetes對象的結果，好比查看建立Service對象的結果，可經過以下命令查看：

kubectl get services

這樣，就能看到當前建立的Service對象的狀態。