Operator是指一類基於Kubernetes自定義資源對象(CRD)和控制器(Controller)的雲原生拓展服務，其中CRD定義了每個operator所創建和管理的自定義資源對象，Controller則包含了管理這些對象所相關的運維邏輯代碼。

對於普通用戶來說，如果要在k8s集群中部署一個高可用的etcd集群，那麼不僅要了解其相關的配置，同時又需要特定的etcd專業知識才能完成維護仲裁，重新配置集群成員，創建備份，處理災難恢復等等繁瑣的事件。

而在operator這一類拓展服務的協助下，我們就可以使用簡單易懂的YAML文件(同理參考Deployment)來聲明式的配置，創建和管理我們的etcd集群，下面我們就來一同了解下etcd-operator這個服務的架構以及它所包含的一些功能。

目 標

1. 了解etcd-operator的架構與CRD資源對象

2. 部署etcd-operator

3. 使用etcd-operator創建etcd cluster

4. 基於etcd-operator備份和恢復etcd cluster

服務架構

etcd-operator的設計是基於k8s的API Extension機制來進行拓展的，它為用戶設計了一個類似於Deployment的Controller，只不過這個Controller是用來專門管理etcd這一服務的。

用戶默認還是通過kubectl或UI來與k8s的API進行交互，只不過在這個k8s集群中多了一個用戶自定義的控制器（custom controller），operator controller的服務是以Pod的方式運行在k8s集群中的，同時這個服務也需要配置所需的RBAC權限（比如對Pod,Deployment,Volume等使用到的資源進行增刪改查的操作），下面我們用一個簡單的架構圖來進行闡述：

etcd-operator的自定義資源對象（CRD）

在k8s中，所有自定義的Controller和其自定義的資源對象（CRD）都必須滿足k8s API的規範（參考下圖）:

• apiVersion描述了當前自定義資源對象的版本號

• Kind表示自定義資源對象的名稱，用戶可通過執行kubectl get $KIND_NAME來獲取所創建的CRD對象

• Metadata繼承了原生k8s的metadata，用於添加標籤，Annotations等元數據

• Spec是用戶可自定義設計的服務配置參數，如鏡像版本號，節點數量，資源配置等等..

• Status包含了當前資源的的相關狀態，每個operator controller可自定義status所包含的信息,一般會選擇添加如conditions，updateTime和message等一類的信息。

下面先我們來了解一下etcd-operator所包含的幾個自定義資源對象(CRDs):

1、EtcdCluster: etcdcluster用來描述用戶自定義的etcd集群，可一鍵式部署和配置一個相關的etcd集群。

apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: etcd-cluster
spec:
  size: 3
  version: 3.2.25

2、EtcdBackup: etcdbackup用來描述和管理一個etcd集群的備份，當前支持定期備份到雲端存儲，如AWS s3, Aliyun oss(oss當前需使用quay.io/coreos/etcd-operator:dev鏡像)。

apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdBackup
metadata:
  name: etcd-backup
spec:
  etcdEndpoints: [<etcd-cluster-endpoints>]
  storageType: OSS #options are S3/ABS/GCS/OSS
  backupPolicy:
    backupIntervalInSecond: 125
    maxBackups: 4
  oss:
    #"<oss-bucket-name>/<path-to-backup-file>"
    path: <full-oss-path>
    ossSecret: <oss-secret>
    # Details about regions and endpoints, see https://www.alibabacloud.com/help/doc-detail/31837.htm
    endpoint: <endpoint> 

3、EtcdRestore:etcdrestore用來幫助將etcdbackup服務所創建的備份恢復到一個指定的etcd的集群。

apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdRestore
metadata:
  # name must be same to the spec.etcdCluster.name
  name: example-etcd-cluster
spec:
  etcdCluster:
    name: example-etcd-cluster
  backupStorageType: OSS
  oss:
    path: <full-oss-path> 
    ossSecret: <oss-secret>
    endpoint: <endpoint>

如何部署和使用etcd-operator

1、部署etcd-operator

在Rancher最新的stable v2.3.2 的版本中，用戶可通過應用商店（Catalog）來一鍵式部署 etcd-operator v0.9.0版本，同時原生k8s也可下載rancher/charts到本地后通過helm install的方式進行部署。

1）（可選）部署etcd-operator時可選擇同時創建一個etcd集群（此集群在etcd-operator被刪除時會被一同移除），當然用戶也可待etcd-operator部署完成通過kubectl apply -f myetcd.yaml來創建一個新的etcd集群。

2）部署時，如果用戶選擇啟動Enable Clusterwide of etcd Operator這個選項，那麼這個etcd-operator將作為集群層級對象來使用（否則為namespaced隔離），如果enable這個選項，那麼在創建etcd集群時需添加以下註釋才能創建創建:

kind: EtcdCluster
metadata:
  name: etcd-cluster
  # add this annotation when the clusterWide is enabled
  annotations:
    etcd.database.coreos.com/scope: clusterwide

2、創建etcd集群

接下來我們就可以使用上述的CRD自定義資源對象對來創建和管理我們的etcd集群了。

2.1 手動創建etcd集群

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: "etcd-cluster"
spec:
  size: 3 # 默認etcd節點數
  version: "3.2.25" # etcd版本號
EOF

2.2 部署后可通過CRD對象來查看我們創建的etcd集群和pod狀態

$ kubectl get etcdcluster
NAME            AGE
etcd-cluster    2m

$ kubectl get pod
NAME                     READY   STATUS  RESTARTS AGE
etcd-cluster-g28f552vvx  1/1   Running    0      2m
etcd-cluster-lpftgqngl8  1/1   Running    0      2m
etcd-cluster-sdpcfrtv99  1/1   Running    0      2m

2.3 可以往etcd集群任意的寫入幾條數據驗證etcd集群是正常工作的（後續也可用來驗證集群的備份和恢復功能）

$ kubectl get svc
NAME                  TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)             AGE
etcd-cluster          ClusterIP   None           <none>        2379/TCP,2380/TCP   17h
etcd-cluster-client   ClusterIP   10.43.130.71   <none>        2379/TCP            17h
## write data
$ kubectl exec -it any-etcd-pod -- env "ETCDCTL_API=3" etcdctl --endpoints http://etcd-cluster-client:2379 put foo "Hello World"
## get data
$ kubectl exec -it any-etcd-pod -- env "ETCDCTL_API=3" etcdctl --endpoints http://etcd-cluster-client:2379 get foo
foo
Hello World

3、基於operator備份etcd cluster

3.1 確認了etcd集群正常運行后，作為devops後面要考慮的就是如何創建etcd集群的自動化備份，下面以阿里雲的OSS舉例：

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdBackup
metadata:
  name: example-etcd-cluster-periodic-backup
spec:
  etcdEndpoints: [http://etcd-cluster-client:2379] #內網可使用svc地址，外網可用NodePort或LB代理地址
  storageType: OSS
  backupPolicy:
    backupIntervalInSecond: 120 #備份時間間隔
    maxBackups: 4 #最大備份數
  oss:
    path: my-bucket/etcd.backup
    ossSecret: oss-secret #需預先創建oss secret
    endpoint: oss-cn-hangzhou.aliyuncs.com
EOF

3.2 若OSS Secret不存在，用戶可先手動創建，具體配置可參考如下：

cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
  name: oss-secret
type: Opaque
stringData:
  accessKeyID: myAccessKey
  accessKeySecret: mySecret
EOF

3.3 待etcdbackup創建成功后，用戶可以通過kubectl describe etcdbackup或查看etcd-backup controller日誌來查看備份狀態，如狀態显示為Succeeded: true，可以前往oss查看具體的備份內容。

4、基於operator恢復etcd cluster

最後，假設我們要將etcd集群A的備份數據恢復到另一個新的etcd集群B，那麼我們先手動創建一個名為etcd-cluster2的新集群(oss備份/恢復當前需使用quay.io/coreos/etcd-operator:dev鏡像)。

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdCluster
metadata:
  name: "etcd-cluster2"
spec:
  size: 3
  version: "3.2.25"
EOF

然後通過創建etcdresotre將備份數據恢復到etcd-cluster2集群

cat <<EOF | kubectl apply -f -
apiVersion: etcd.database.coreos.com/v1beta2
kind: EtcdRestore
metadata:
  # name必須與下面的spec.etcdCluster.name保持一致
  name: etcd-cluster2
spec:
  etcdCluster:
    name: etcd-cluster2
  backupStorageType: OSS
  oss:
    path: my-bucket/etcd.backup_v1_2019-08-07-06:44:17
    ossSecret: oss-secret
    endpoint: oss-cn-hangzhou.aliyuncs.com
EOF

待etcdresotre對象創建成功后，可以查看etcd-operator-restore的日誌，大致內容如下：

$ kubectl logs -f etcd-operator-restore
...
time="2019-08-07T06:50:26Z" level=info msg="listening on 0.0.0.0:19999"
time="2019-08-07T06:50:26Z" level=info msg="starting restore controller" pkg=controller
time="2019-08-07T06:56:25Z" level=info msg="serving backup for restore CR etcd-cluster2"

通過kubectl查看pod我們可以看到etcd-cluster2集群的etcd節點被刪除重建：

NAME                       READY   STATUS    RESTARTS   AGE
etcd-cluster2-5tq2d5bvpf    0/1     Terminating   0      93s
etcd-cluster2-kfgvc692pp    1/1     Terminating   0      101s
etcd-cluster2-xqkgz8chb8    0/1     Init:1/3      0      6s
etcd-cluster2-pf2qxgtg9d    1/1     Running       0      48s
etcd-cluster2-x92l9vpx97    1/1     Running       0      40s

最後可通過etcdctl來驗證之前的數據是否存在（需設置ETCDCTL_API=3）：

$ kubectl exec -it etcd-pod -- env "ETCDCTL_API=3" etcdctl --endpoints http://etcd-cluster2-client:2379 get foo
foo
Hello World

小 結

Etcd作為當前非常流行的key-value分佈式文件存儲，它本身的強一致性和較優的性能可以為許多分佈式計算解決分佈式存儲的需求，如果你的微服務和應用需要用到此類的數據庫，不妨來試試Rancher Catalog應用中的etcd-operator吧，Just do it!

相關資料：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!

一 Pod定義詳解

1.1 完整Pod定義文件

  1 apiVersion: v1			#必選，版本號，例如v1,版本號必須可以用 kubectl api-versions 查詢到
  2 kind: Pod				#必選，Pod
  3 metadata:				#必選，元數據
  4   name: string			#必選，Pod名稱，需符合RFC 1035規範
  5   namespace: string			#必選，Pod所屬的命名空間，默認為"default"
  6   labels:				#自定義標籤
  7     - name: string			#自定義標籤名字
  8   annotations:			#自定義註釋列表
  9     - name: string
 10 spec:				#必選，Pod中容器的詳細定義
 11   containers:			#必選，Pod中容器列表
 12   - name: string			#必選，容器名稱，需符合RFC 1035規範
 13     image: string			#必選，容器的鏡像名稱
 14     imagePullPolicy: [ Always|Never|IfNotPresent ]	#獲取鏡像的策略，Alawys表示每次都嘗試下載鏡像，IfnotPresent表示優先使用本地鏡像,否則下載鏡像，Nerver表示僅使用本地鏡像
 15     command: [string]		#容器的啟動命令列表，如不指定，使用打包時使用的啟動命令
 16     args: [string]			#容器的啟動命令參數列表
 17     workingDir: string		#容器的工作目錄
 18     volumeMounts:			#掛載到容器內部的存儲卷配置
 19     - name: string			#引用pod定義的共享存儲卷的名稱，需用volumes[]部分定義的的卷名
 20       mountPath: string		#存儲卷在容器內mount的絕對路徑，應少於512字符
 21       readOnly: boolean		#是否為只讀模式，默認為讀寫模式
 22     ports:				#需要暴露的端口庫號列表
 23     - name: string			#端口的名稱
 24       containerPort: int		#容器需要監聽的端口號
 25       hostPort: int		        #容器所在主機需要監聽的端口號，默認與Container相同
 26       protocol: string		#端口協議，支持TCP和UDP，默認TCP
 27     env:				#容器運行前需設置的環境變量列表
 28     - name: string			#環境變量名稱
 29       value: string		        #環境變量的值
 30     resources:			#資源限制和請求的設置
 31       limits:			#資源限制的設置
 32         cpu: string		        #CPU的限制，單位為core數，將用於docker run --cpu-shares參數
 33         memory: string		#內存限制，單位可以為Mib/Gib，將用於docker run --memory參數
 34       requests:			#資源請求的設置
 35         cpu: string		        #CPU請求，容器啟動的初始可用數量
 36         memory: string		#內存請求,容器啟動的初始可用數量
 37     livenessProbe:			#對Pod內各容器健康檢查的設置，當探測無響應幾次后將自動重啟該容器，檢查方法有exec、httpGet和tcpSocket，對一個容器只需設置其中一種方法即可
 38       exec:			        #對Pod容器內檢查方式設置為exec方式
 39         command: [string]		#exec方式需要制定的命令或腳本
 40       httpGet:			#對Pod內個容器健康檢查方法設置為HttpGet，需要制定Path、port
 41         path: string
 42         port: number
 43         host: string
 44         scheme: string
 45         HttpHeaders:
 46         - name: string
 47           value: string
 48       tcpSocket:			#對Pod內個容器健康檢查方式設置為tcpSocket方式
 49          port: number
 50        initialDelaySeconds: 0	#容器啟動完成后首次探測的時間，單位為秒
 51        timeoutSeconds: 0		#對容器健康檢查探測等待響應的超時時間，單位秒，默認1秒
 52        periodSeconds: 0		#對容器監控檢查的定期探測時間設置，單位秒，默認10秒一次
 53        successThreshold: 0
 54        failureThreshold: 0
 55        securityContext:
 56          privileged: false
 57     restartPolicy: [Always | Never | OnFailure]	#Pod的重啟策略，Always表示一旦不管以何種方式終止運行，kubelet都將重啟，OnFailure表示只有Pod以非0退出碼退出才重啟，Nerver表示不再重啟該Pod
 58     nodeSelector: obeject		#設置NodeSelector表示將該Pod調度到包含這個label的node上，以key：value的格式指定
 59     imagePullSecrets:		#Pull鏡像時使用的secret名稱，以key：secretkey格式指定
 60     - name: string
 61     hostNetwork: false		#是否使用主機網絡模式，默認為false，如果設置為true，表示使用宿主機網絡
 62     volumes:			#在該pod上定義共享存儲卷列表
 63     - name: string			#共享存儲卷名稱 （volumes類型有很多種）
 64       emptyDir: {}			#類型為emtyDir的存儲卷，與Pod同生命周期的一個臨時目錄。為空值
 65       hostPath: string		#類型為hostPath的存儲卷，表示掛載Pod所在宿主機的目錄
 66         path: string		#Pod所在宿主機的目錄，將被用於同期中mount的目錄
 67       secret:			#類型為secret的存儲卷，掛載集群與定義的secre對象到容器內部
 68         scretname: string
 69         items:
 70         - key: string
 71           path: string
 72       configMap:			#類型為configMap的存儲卷，掛載預定義的configMap對象到容器內部
 73         name: string
 74         items:
 75         - key: string
 76           path: string

二 Pod的基本用法

2.1 創建Pod

Pod可以由1個或多個容器組合而成，通常對於緊耦合的兩個應用，應該組合成一個整體對外提供服務，則應該將這兩個打包為一個pod。

屬於一個Pod的多個容器應用之間相互訪問只需要通過localhost即可通信，這一組容器被綁定在一個環境中。

  1 [root@k8smaster01 study]# vi frontend-localredis-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: redis-php
  6   label:
  7     name: redis-php
  8 spec:
  9   containers:
 10   - name: frontend
 11     image: kubeguide/guestbook-php-frontend:localredis
 12     ports:
 13     - containersPort: 80
 14   - name: redis-php
 15     image: kubeguide/redis-master
 16     ports:
 17     - containersPort: 6379
 18 
 19 [root@k8smaster01 study]# kubectl create -f frontend-localredis-pod.yaml
 20 

2.2 查看Pod

  1 [root@k8smaster01 study]# kubectl get pods	                #READY為2/2，表示此Pod中運行了yaml定義的兩個容器
  2 NAME        READY   STATUS    RESTARTS   AGE
  3 redis-php   2/2     Running   0          7m45s
  4 [root@k8smaster01 study]# kubectl describe pod redis-php	#查看詳細信息
  5 

三 靜態Pod

3.1 靜態Pod概述

靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上，他們不能通過API Server進行管理，無法與ReplicationController、Deployment或者DaemonSet進行關聯，並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行創建，並且總是在kubelet所在的Node上運行。

創建靜態Pod有兩種方式：配置文件或者HTTP方式。

3.2 配置文件方式創建

  1 [root@k8snode01 ~]# mkdir -p /etc/kubelet.d
  2 [root@k8snode01 ~]# vi /etc/kubelet.d/static-web.yaml
  3 apiVersion: v1
  4 kind: Pod
  5 metadata:
  6   name: static-web
  7   label:
  8     name: static-web
  9 spec:
 10   containers:
 11   - name: static-web
 12     image: nginx
 13     ports:
 14     - name: web
 15       containersPort: 80
 16 
 17 [root@k8snode01 ~]# vi /etc/systemd/system/kubelet.service
 18 ……
 19   --config=/etc/kubelet.d/ \·				#加入此參數
 20 ……
 21 [root@k8snode01 ~]# systemctl daemon-reload
 22 [root@k8snode01 ~]# systemctl restart kubelet.service	#重啟kubelet
 23 [root@k8snode01 ~]# docker ps				#查看創建的pod

提示：由於靜態pod不能通過API Server進行管理，因此在Master節點執行刪除操作後會變為Pending狀態，且無法刪除。刪除該pod只能在其運行的node上，將定義POD的yaml刪除。

3.3 HTTP方式

通過設置kubelet的啟動參數–mainfest-url，會定期從該URL下載Pod的定義文件，並以.yaml或.json文件的格式進行解析，從而創建Pod。

四 Pod容器共享Volume

4.1 共享Volume

在同一個Pod中的多個容器能夠共享Pod級別的存儲就Volume。Volume可以被定義為各種類型，多個容器各自進行掛載操作，將一個Volume掛載為容器內部需要的目錄。


示例1：

Pod級別設置Volume “app-logs”，同時Pod包含兩個容器，Tomcat向該Volume寫日誌，busybox讀取日誌文件。

  1 [root@k8smaster01 study]# vi pod-volume-applogs.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: volume-pod
  6 spec:
  7   containers:
  8   - name: tomcat
  9     image: tomcat
 10     ports:
 11     - containerPort: 8080
 12     volumeMounts:
 13     - name: app-logs
 14       mountPath: /usr/local/tomcat/logs
 15   - name: logreader
 16     image: busybox
 17     command: ["sh","-c","tail -f /logs/catalina*.log"]
 18     volumeMounts:
 19     - name: app-logs
 20       mountPath: /logs
 21   volumes:
 22   - name: app-logs
 23     emptyDir: {}

解釋：

Volume名：app-logs；

emptyDir：為Pod分配到Node的時候創建。無需指定宿主機的目錄文件，為Kubernetes自動分配的目錄。

  1 [root@k8smaster01 study]# kubectl create -f pod-volume-applogs.yaml	#創建
  2 [root@k8smaster01 study]# kubectl get pods				#查看
  3 [root@k8smaster01 study]# kubectl logs volume-pod -c busybox	#讀取log

  1 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- ls /usr/local/tomcat/logs
  2 catalina.2019-06-29.log      localhost_access_log.2019-06-29.txt
  3 host-manager.2019-06-29.log  manager.2019-06-29.log
  4 localhost.2019-06-29.log
  5 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- tail /usr/local/tomcat/logs/catalina.2019-06-29.log

提示：通過tomcat容器可查看日誌，對比busybox通過共享Volume查看的日誌是否一致。

五 Pod配置管理

5.1 Pod配置概述

應用部署的一個最佳實踐是將應用所需的配置信息與程序進行分離，使程序更加靈活。將相應的應用打包為鏡像，可以通過環境變量或者外掛volume的方式在創建容器的時候進行配置注入，從而實現更好的復用。

Kubernetes提供一種統一的應用配置管理方案：ConfigMap。

5.2 ConfigMap概述

ConfigMap供容器使用的主要場景：

• 生成容器內部的環境變量；
• 設置容器的啟動命令的參數（需設置為環境變量）；
• 以volume的形式掛載為容器內部的文件或者目錄。

ConfigMap以一個或多個key:value的形式定義。value可以是string也可以是一個文件內容，可以通過yaml配置文件或者通過kubectl create configmap 的方式創建configMap。

5.3 創建ConfigMap資源對象——yaml方式

  1 [root@k8smaster01 study]# vi cm-appvars.yaml
  2 apiVersion: v1
  3 kind: ConfigMap
  4 metadata:
  5   name: cm-appvars
  6 data:
  7   apploglevel: info
  8   appdatadir: /var/data
  9 
 10 [root@k8smaster01 study]# kubectl create -f cm-appvars.yaml
 11 configmap/cm-appvars created
 12 [root@k8smaster01 study]# kubectl get configmaps
 13 NAME         DATA   AGE
 14 cm-appvars   2      8s
 15 [root@k8smaster01 study]# kubectl describe configmaps cm-appvars

  1 [root@k8smaster01 study]# kubectl get configmaps cm-appvars -o yaml

5.4 創建ConfigMap資源對象——命令行方式

語法1

  1 # kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source

解釋：通過–from-file參數從文件中創建，可以指定key名稱，也可以制定多個key。

語法2

  1 # kubectl create configmap NAME --from-file=config-files-dir

解釋：通過–from-file參數從目錄中創建，該目錄下的每個配置文件名都被設置為key，文件的內容被設置為value。

語法3

  1 # kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2

解釋：通過–from-literal參數從文本中創建，直接將指定的key#=value#創建為ConfigMap的內容。

5.5 Pod使用ConfigMap

容器應用使用ConfigMap有兩種方式：

• 通過環境變量獲取ConfigMap中的內容；
• 通過Volume掛載的方式將ConfigMap中的內容掛載為容器內容的文件或目錄。

  1 [root@k8smaster01 study]# vi cm-test-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: cm-test-pod
  6 spec:
  7   containers:
  8   - name: cm-test
  9     image: busybox
 10     command: ["/bin/sh","-c","env|grep APP"]	#容器里執行查看環境變量的命令
 11     env:
 12     - name: APPLOGLEVEL				#定義容器環境變量名稱
 13       valueFrom:
 14         configMapKeyRef:			#環境變量的值來自ConfigMap
 15           name: cm-appvars			#指定來自cm-appvars的ConfigMap
 16           key: apploglevel			#key為apploglevel
 17     - name: APPDATADIR
 18       valueFrom:
 19         configMapKeyRef:
 20           name: cm-appvars
 21           key: appdatadir
 22 
 23 [root@k8smaster01 study]# kubectl create -f cm-test-pod.yaml
 24 [root@k8smaster01 study]# kubectl get pods
 25 NAME          READY   STATUS      RESTARTS   AGE
 26 cm-test-pod   0/1     Completed   2          24s

【掛載形式-待補充】

5.6 ConfigMap限制

• Configmap必須在pod創建之間創建；
• ConfigMap受到namespace的限制，只有同一個命名空間下才能引用；
• ConfigMap暫時無法配置配額；
• 靜態的pod無法使用ConfigMap；
• 在使用volumeMount掛載的時候，configMap基於items創建的文件會整體的將掛載數據卷的容器的目錄下的文件全部覆蓋。

六 Pod獲取自身信息

6.1 Downward API

pod擁有唯一的名字、IP地址，並且處於某個Namespace中。pod的容器內獲取pod的信息科通過Downward API實現。具體有以下兩種方式：

• 環境變量：用於單個變量，可以將pod信息和container信息注入容器內部；
• volume掛載：將數組類信息生成為文件，掛載至容器內部。

舉例1：通過Downward API將Pod的IP、名稱和所在的Namespace注入容器的環境變量。

  1 [root@k8smaster01 study]# vi dapi-test-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod
  6 spec:
  7   containers:
  8     - name: test-container
  9       image: busybox
 10       command: [ "/bin/sh", "-c", "env" ]
 11       env:
 12         - name: MY_POD_NAME
 13           valueFrom:
 14             fieldRef:
 15               fieldPath: metadata.name
 16         - name: MY_POD_NAMESPACE
 17           valueFrom:
 18             fieldRef:
 19               fieldPath: metadata.namespace
 20         - name: MY_POD_IP
 21           valueFrom:
 22             fieldRef:
 23               fieldPath: status.podIP
 24   restartPolicy: Never

提示：Downward API提供如下變量：

metadata.name：Pod的名稱，當Pod通過RC生成時，其名稱是RC隨機產生的唯一名稱；

status.podIP：Pod的IP地址，POd的IP屬於狀態數據，而非元數據；

metadata.namespace：Pod所在的namespace。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod | grep MY_POD
  3 MY_POD_NAMESPACE=default
  4 MY_POD_IP=172.30.240.4
  5 MY_POD_NAME=dapi-test-pod
  6 

舉例2：通過Downward API將Container的自願請求和限制信息注入容器的環境變量。

  1 [root@k8smaster01 study]# vi dapi-test-pod-container-vars.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod-container-vars
  6 spec:
  7   containers:
  8     - name: test-container
  9       image: busybox
 10       imagePullPolicy: Never
 11       command: [ "/bin/sh", "-c" ]
 12       args:
 13       - while true; do
 14           echo -en '\n';
 15           printenv MY_CPU_REQUEST MY_CPU_LIMIT;
 16           printenv MY_MEM_REQUEST MY_MEM_LIMIT;
 17           sleep 3600;
 18         done;
 19       resources:
 20         requests:
 21           memory: "32Mi"
 22           cpu: "125m"
 23         limits:
 24           memory: "64Mi"
 25           cpu: "250m"
 26       env:
 27         - name: MY_CPU_REQUEST
 28           valueFrom:
 29             resourceFieldRef:
 30               containerName: test-container
 31               resource: requests.cpu
 32         - name: MY_CPU_LIMIT
 33           valueFrom:
 34             resourceFieldRef:
 35               containerName: test-container
 36               resource: limits.cpu
 37         - name: MY_MEM_REQUEST
 38           valueFrom:
 39             resourceFieldRef:
 40               containerName: test-container
 41               resource: requests.memory
 42         - name: MY_MEM_LIMIT
 43           valueFrom:
 44             resourceFieldRef:
 45               containerName: test-container
 46               resource: limits.memory
 47   restartPolicy: Never

提示：Downward API提供如下變量：

requests.cpu：容器的CPU請求值；

limits.cpu：容器的CPU限制值；

requests.memory：容器的內存請求值；

limits.memory：容器的內存限制值。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-container-vars.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-container-vars
  3 1
  4 1
  5 33554432
  6 67108864

舉例3：通過Downward API將Pod的Label、Annotation列表通過Volume掛載為容器內的一個文件。

  1 [root@k8smaster01 study]# vi dapi-test-pod-volume.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod-volume
  6   labels:
  7     zone: us-est-coast
  8     cluster: test-cluster1
  9     rack: rack-22
 10   annotations:
 11     build: two
 12     builder: john-doe
 13 spec:
 14   containers:
 15     - name: test-container
 16       image: busybox
 17       imagePullPolicy: Never
 18       command: [ "/bin/sh", "-c" ]
 19       args:
 20       - while true; do
 21           if [[ -e /etc/labels ]]; then
 22             echo -en '\n\n'; cat /etc/labels; fi;
 23           if [[ -e /etc/annotations ]]; then
 24             echo -en '\n\n'; cat /etc/annotations; fi;
 25           sleep 3600;
 26         done;
 27       volumeMounts:
 28         - name: podinfo
 29           mountPath: /etc
 30           readOnly: false
 31   volumes:
 32     - name: podinfo
 33       downwardAPI:
 34         items:
 35           - path: "labels"
 36             fieldRef:
 37               fieldPath: metadata.labels
 38           - path: "annotations"
 39             fieldRef:
 40               fieldPath: metadata.annotations

注意：Volume中的ddownwardAPI的items語法，將會以path的名稱生成文件。如上所示，會在容器內生產/etc/labels和/etc/annotations兩個文件，分別包含metadata.labels和metadata.annotations的全部Label。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-volume.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-volume
  3 

提示：DownwardAPI意義：

在某些集群中，集群中的每個節點需要將自身的標識（ID）及進程綁定的IP地址等信息事先寫入配置文件中，進程啟動時讀取此類信息，然後發布到某個類似註冊服務中心。此時可通過DowanwardAPI，將一個預啟動腳本或Init Container，通過環境變量或文件方式獲取Pod自身的信息，然後寫入主程序配置文件中，最後啟動主程序。本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!

古往今來最難的學的武功(javascript)算其一。

欲練此功必先自宮，願少俠習的此功，笑傲江湖。

你將了解

• 執行棧（Execution stack）
• 執行上下文（Execution Context）
• 作用域鏈（scope chains）
• 變量提升（hoisting）
• 閉包（closures）
• this 綁定

執行棧

又叫調用棧，具有 LIFO（last in first out 後進先出）結構，用於存儲在代碼執行期間創建的所有執行上下文。

當 JavaScript 引擎首次讀取你的腳本時，它會創建一個全局執行上下文並將其推入當前的執行棧。每當發生一個函數調用，引擎都會為該函數創建一個新的執行上下文並將其推到當前執行棧的頂端。
引擎會運行執行上下文在執行棧頂端的函數，當此函數運行完成后，其對應的執行上下文將會從執行棧中彈出，上下文控制權將移到當前執行棧的下一個執行上下文。

我們通過下面的示例來說明一下

function one() {
  console.log('one')
  two()
}
function two() {
  console.log('two')
}
one()

當程序（代碼）開始執行時 javscript 引擎創建 GobalExecutionContext （全局執行上下文）推入當前的執行棧，此時 GobalExecutionContext 處於棧頂會立刻執行全局執行上下文 然後遇到 one() 引擎都會為該函數創建一個新的執行上下文 oneFunctionExecutionContext 並將其推到當前執行棧的頂端並執行，然後遇到two() twoFunctionExecutionContext 入棧並執行至出棧，回到 oneFunctionExecutionContext 繼續執行至出棧 ,最後剩餘一個 GobalExecutionContext 它會在程序關閉的時候出棧。

然後調用棧如下圖：

如果是這樣的代碼

function foo() {
  foo()
}
foo()

如下

當一個遞歸沒有結束點的時候就會出現棧溢出

什麼是執行上下文

了解 JavaScript 的執行上下文，有助於你理解更高級的內容比如變量提升、作用域鏈和閉包。既然如此，那到底什麼是“執行上下文”呢？

執行上下文是當前 JavaScript 代碼被解析和執行時所在環境的抽象概念。

Javascript 中代碼的執行上下文分為以下三種：

1. 全局執行上下文（Global Execution Context）- 這個是默認的代碼運行環境，一旦代碼被載入，引擎最先進入的就是這個環境。
2. 函數執行上下文（Function Execution Context） – 當執行一個函數時，運行函數體中的代碼。
3. Eval – 在 Eval 函數內運行的代碼。

javascript 是一個單線程語言，這意味着在瀏覽器中同時只能做一件事情。當 javascript 解釋器初始執行代碼，它首先默認進入全局上下文。每次調用一個函數將會創建一個新的執行上下文。

javascript執行棧中不同執行上下文之間的詞法環境有一種關聯關係，從棧頂到棧底（從局部直到全局）,這種關係被叫做作用域鏈。

簡單的說，每次你試圖訪問函數執行上下文中的變量時，進程總是從自己上下文環境中開始查找。如果在自己的上下文中沒發現要查找的變量，繼續搜索下一層上下文。它將檢查執行棧中每一個執行上下文環境，尋找和變量名稱匹配的值，直到找到為止，如果到全局都沒有則拋出錯誤。

執行上下文的創建過程

我們現在已經知道，每當調用一個函數時，一個新的執行上下文就會被創建出來。然而，在 javascript 引擎內部，這個上下文的創建過程具體分為兩個階段:

創建階段 > 執行階段

創建階段

執行上下文在創建階段創建。在創建階段發生以下事情：

1. LexicalEnvironment 組件已創建。
2. VariableEnvironment 組件已創建。

因此，執行上下文可以在概念上表示如下：

ExecutionContext = {
  LexicalEnvironment = <詞法環境>，
  VariableEnvironment = <變量環境>，
}

詞法環境（Lexical Environment）

文檔將詞法環境定義為：

詞法環境是一種規範類型，基於 ECMAScript 代碼的詞法嵌套結構來定義標識符與特定變量和函數的關聯關係。詞法環境由環境記錄（environment record）和可能為空引用（null）的外部詞法環境組成。

簡而言之，詞法環境是一個包含標識符變量映射的結構。（這裏的標識符表示變量/函數的名稱，變量是對實際對象【包括函數類型對象】或原始值的引用）

詞法環境有兩種類型

• 全局環境（在全局執行上下文中）是一個沒有外部環境的詞法環境。全局環境的外部環境引用為 null。它擁有一個全局對象（window 對象）及其關聯的方法和屬性（例如數組方法）以及任何用戶自定義的全局變量，this 的值指向這個全局對象。
• 函數環境，用戶在函數中定義的變量被存儲在環境記錄中。對外部環境的引用可以是全局環境，也可以是包含內部函數的外部函數環境。

每個詞彙環境都有三個組成部分：

1）環境記錄（environment record）

2）對外部環境的引用(outer)

3） 綁定 this

環境記錄 同樣有兩種類型（如下所示）：

• 聲明性環境記錄 存儲變量、函數和參數。一個函數環境包含聲明性環境記錄。
• 對象環境記錄 用於定義在全局執行上下文中出現的變量和函數的關聯。全局環境包含對象環境記錄

抽象地說，詞法環境在偽代碼中看起來像這樣：

詞法環境和環境記錄值是純粹的規範機制，ECMAScript 程序不能直接訪問或操縱這些值。

GlobalExectionContext = {
  // 詞法環境
  LexicalEnvironment:{
    // 功能環境記錄
    EnvironmentRecord:{
      Type:"Object",
      // Identifier bindings go here
     }
    outer:<null>,
    this:<global object>
  }
}
FunctionExectionContext = {
  LexicalEnvironment:{
    EnvironmentRecord:{
      Type:"Declarative",
      // Identifier bindings go here
     }
    outer:<Global or outer function environment reference>,
    this:<取決於函數的調用方式>
  }
}

變量環境:

它也是一個詞法環境，其 EnvironmentRecord 包含了由 VariableStatements 在此執行上下文創建的綁定。
如上所述，變量環境也是一個詞法環境，因此它具有上面定義的詞法環境的所有屬性。
在 ES6 中，LexicalEnvironment 組件和 VariableEnvironment 組件的區別在於前者用於存儲函數聲明和變量（ let 和 const ）綁定，而後者僅用於存儲變量（ var ）綁定。
讓我們結合一些代碼示例來理解上述概念：

let a = 20
const b = 30
var c

function multiply(e, f) {
  var g = 20
  return e * f * g
}

c = multiply(20, 30)

執行上下文如下所示：

GlobalExectionContext = {
  LexicalEnvironment:{
    EnvironmentRecord:{
      Type:"Object",
      // Identifier bindings go here
      a:<uninitialized>,
      b:<uninitialized>,
      multiply:<func>
    },
    outer:<null>,
    ThisBinding:<Global Object>
  },
  VariableEnvironment:{
    EnvironmentRecord:{
      Type:"Object",
      // Identifier bindings go here
      c:undefined,
    }
    outer:<null>,
    ThisBinding:<Global Object>
  }
}

在執行階段，完成變量賦值。因此，在執行階段，全局執行上下文將看起來像這樣。

// 執行
GlobalExectionContext = {
LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // Identifier bindings go here
      a: 20,
      b: 30,
      multiply: < func >
    }
    outer: <null>,
    ThisBinding: <Global Object>
  },
VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Object",
      // Identifier bindings go here
      c: undefined,
    }
    outer: <null>,
    ThisBinding: <Global Object>
  }
}

當 multiply(20, 30)遇到函數調用時，會創建一個新的函數執行上下文來執行函數代碼。因此，在創建階段，函數執行上下文將如下所示：

// multiply 創建
FunctionExectionContext = {
LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      Arguments: {0: 20, 1: 30, length: 2},
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>,
  },
VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      g: undefined
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>
  }
}

在此之後，執行上下文將執行執行階段，這意味着完成了對函數內部變量的賦值。因此，在執行階段，函數執行上下文將如下所示：

// multiply 執行
FunctionExectionContext = {
LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      Arguments: {0: 20, 1: 30, length: 2},
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object>,
  },
VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      g: 20
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>
  }
}

函數完成后，返回的值賦值給c。因此，全局詞法環境得到了更新。之後，全局代碼完成，程序結束。

注： 在執行階段，如果 Javascript 引擎在源代碼中聲明的實際位置找不到 let 變量的值，那麼將為其分配 undefined 值。

變量提升

在網上一直看到這樣的總結： 在函數中聲明的變量以及函數，其作用域提升到函數頂部，換句話說，就是一進入函數體，就可以訪問到其中聲明的變量以及函數。這是對的，但是知道其中的緣由嗎？相信你通過上述的解釋應該也有所明白了。不過在這邊再分析一下。

你可能已經注意到了在創建階段 let 和 const 定義的變量沒有任何與之關聯的值，但 var 定義的變量設置為 undefined。
這是因為在創建階段，代碼會被掃描並解析變量和函數聲明，其中函數聲明存儲在環境中，而變量會被設置為 undefined（在 var 聲明變量的情況下）或保持未初始化（在 let 和const 聲明變量的情況下）。
這就是為什麼你可以在聲明之前訪問var 定義的變量（儘管是 undefined ），但如果在聲明之前訪問let 和const 定義的變量就會提示引用錯誤的原因。
這就是我們所謂的變量提升。

思考題：

console.log('step1:',a)
var a = 'artiely'
console.log('step2:',a)
function bar (a){
  console.log('step3:',a)
  a = 'TJ'
  console.log('step4:',a)
  function a(){
  }
}
bar(a)
console.log('step5:',a)

對外部環境的引用

上面代碼如果我們改用調用方式如下：

let a = 20
const b = 30
var c

function multiply() {
  var g = 20
  return a * b * g
}

c = multiply()

其實你會發現結果是一樣的
但是 multiply 的執行上下文卻發生一些變化

// 創建
FunctionExectionContext = {
LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      Arguments: { length: 0},
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>,
  },
VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // Identifier bindings go here
      g: undefined
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>
  }
}

// 執行
FunctionExectionContext = {
LexicalEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      Arguments: { length: 0},
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>,
  },
VariableEnvironment: {
    EnvironmentRecord: {
      Type: "Declarative",
      // Identifier bindings go here
      g: 20
    },
    outer: <GlobalLexicalEnvironment>,
    ThisBinding: <Global Object or undefined>
  }
}

multiply() 執行的時候會直接在 outer: <GlobalLexicalEnvironment>,中查找a,b

對外部環境的引用意味着它可以訪問其外部詞法環境。這意味着如果在當前詞法環境中找不到它們，JavaScript 引擎可以在外部環境中查找變量。這就是之前說的 作用域鏈

閉包

MDN 解釋 閉包是由函數以及創建該函數的詞法環境組合而成。這個環境包含了這個閉包創建時所能訪問的所有局部變量

這是我認為對閉包最合理的解釋了，就看你怎麼理解閉包的機制了。
其實閉包與作用域鏈有着密切的關係。

首先我們來看看什麼樣的代碼會產生閉包。

function foo() {
  var name = 'artiely'
  function bar() {
    console.log(`hello `)
  }
  bar()
}
foo()

以上代碼是有閉包嗎？沒有~

function foo() {
  var name = 'artiely'
  function bar() {
    console.log(`hello ${name}`)
  }
  bar()
}
foo()

我們只做了微小的調整，現在就有閉包了,我們只是在bar中加入了name得引用
上面的代碼還可以寫成這樣

// 或者
function foo() {
  var name = 'artiely'
  return function bar() {
    console.log(`hello ${name}`)
  }
}
foo()()

對於閉包的形成我進行了如下的幾點歸納

1. A 函數內必須有 B 函數的聲明；
2. B 函數必須引用 A 函數的變量；
3. B 函數被調用（當然前提是 A 函數被調用）

以上 3 點缺一不可

我們來分析一下上面代碼的執行上下文

// 創建
fooFunctionExectionContext = {
LexicalEnvironment: {
  EnvironmentRecord: {
    Type: "Declarative",
    Arguments: { length: 0},
    bar: < func >,
  },
  outer: <GlobalLexicalEnvironment>,
  ThisBinding: <Global Object or undefined>,
},
VariableEnvironment: {
  EnvironmentRecord: {
    Type: "Declarative",
    name: undefined
  },
  outer: <GlobalLexicalEnvironment>,
  ThisBinding: <Global Object or undefined>
  }
}
// 執行 略

// 創建
barFunctionExectionContext = {
LexicalEnvironment: {
  EnvironmentRecord: {
    Type: "Declarative",
    Arguments: { length: 0},
  },
  outer: <fooLexicalEnvironment>,
  ThisBinding: <Global Object or undefined>,
},
VariableEnvironment: {
  EnvironmentRecord: {
    Type: "Declarative",
  },
  outer: <fooLexicalEnvironment>,
  ThisBinding: <Global Object or undefined>
  }
}
// 執行 略

這裏因為bar的創建存在着對fooLexicalEnvironment里變量的引用，雖然foo可能執行已結束但變量不會被回收。這種機制被叫做閉包

閉包是由函數以及創建該函數的詞法環境組合而成。這個環境包含了這個閉包創建時所能訪問的所有局部變量

我們結合上面例子重新分解一下這句話

閉包是由函數bar以及創建該函數foo的詞法環境組合而成。這個環境包含了這個閉包創建時所能訪問的所有局部變量name

但是從chrome的理解，閉包並沒有包含所能訪問的所有局部變量，僅僅包含所被引用的變量。

this 綁定

在全局執行上下文中，值是 this 指全局對象。（在瀏覽器中，this 指的是 Window 對象）。

在函數執行上下文中，值 this 取決於函數的調用方式。如果它由對象引用調用，則將值 this 設置為該對象，否則，將值 this 設置為全局對象或 undefined（在嚴格模式下）。例如：

let person = {
  name: 'peter',
  birthYear: 1994,
  calcAge: function() {
    console.log(2018 - this.birthYear)
  }
}

person.calcAge()
// 'this' 指向 'person', 因為 'calcAge' 是被 'person' 對象引用調用的。

let calculateAge = person.calcAge
calculateAge()
// 'this' 指向全局 window 對象,因為沒有給出任何對象引用

注意所有的()()自調用的函數 this 都是指向Global Object的既瀏覽器中的window

最後

如果本文對你有幫助或覺得不錯請幫忙點贊，如有疑問請留言。

其他參考：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR  ?

※自行創業 缺乏曝光? 下一步”網站設計“幫您第一時間規劃公司的門面形象

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，網站設計公司幫您達到更多曝光效益

※試算大陸海運運費!