摘要：京東云集群最佳實踐容器是的基石，它們之間的關系不言而喻。因此我們今天的文章將會和大家分享關于京東云集群的部分最佳實踐。京東云集群采用管理節點全托管的方式，為用戶提供簡單易用高可靠功能強大的容器管理服務。

容器是Cloud Native的基石，它們之間的關系不言而喻。了解容器對于學習Cloud Native也是十分重要的。近期，京東云Cloud Native的“在線公開課”從理論和實踐兩個層面為大家分享了Cloud Native相關的技術知識。在本周的周日，我們還將迎來”Cloud Native時代的應用之路與開源創新“專場技術沙龍。

因此我們今天的文章將會和大家分享關于京東云Kubernetes集群的部分最佳實踐。感興趣的小伙伴也可以跟著文檔自己動手進行創建。

京東云Kubernetes集群采用管理節點全托管的方式，為用戶提供簡單易用、高可靠、功能強大的容器管理服務。該產品完全兼容標準Kubernetes API ，集成京東云網絡、存儲等插件。Kubernetes集群服務簡化了Kubernetes部署、管理，降低了Kubernetes使用門檻，增強應用的可靠性，提升開發的效率，同時，也能更好地幫助用戶減少資源投入的成本。

最佳實踐——部署應用

京東云Kubernetes集群服務集成了京東云云硬盤，您可以在集群中使用京東云云硬盤作為持久化存儲；

使用京東云云盤定義靜態存儲

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-static
  labels:
    type: jdcloud-ebs
spec:
  capacity:
    storage: 30Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  jdcloudElasticBlockStore:
    volumeID: vol-ogcbkdjg7x
    fsType: xfs

參數說明：

1、如您需要在京東云Kubernetes集群服務中使用京東云云硬盤作為持久化存儲，請在PersistentVolume定義時，指定插件jdcloudElasticBlockStore；

2、VolumeID：指定同地域下為Kubernetes集群服務提供持久化存儲的云硬盤ID；

3、Fstype：指定文件系統類型；目前僅支持ext4和xfs兩種；

4、Capacity：PV 將具有特定的存儲容量。這是使用 PV 的容量屬性設置的；

5、PersistentVolume 可以以資源提供者支持的任何方式掛載到主機上。

京東云云硬盤目前只支持一種模式ReadWriteOnce——該卷可以被單個節點以讀/寫模式掛載；

訪問模式包括：
ReadWriteOnce——該卷可以被單個節點以讀/寫模式掛載

在命令行中，訪問模式縮寫為：
RWO - ReadWriteOnce
京東云為PersistentVolume提供了插件，插件類型為：jdcloudElasticBlockStore

注：

由于云硬盤限制一個云硬盤只能同時掛載一個云主機,在使用基于PVC的Pod時，建議使用replicas=1來創建一個部署集。StatefulSet可解決多副本問題。

Pod遷移，PVC遷移(卸載舊實例/掛載新實例)默認35秒。

通過Deployment部署，刪除Deployment之后，可重新掛載原有PVC到新的Pod里面。

聲明可以指定一個標簽選擇器來進一步過濾該組卷。只有標簽與選擇器匹配的卷可以綁定到聲明。選擇器由兩個字段組成：

所有來自 MatchLabels 和 MatchExpressions 的要求都被“與”在一起——它們必須全部滿足才能匹配。

本例使用MatchLabels作為過濾條件，將匹配的PersistentVolume綁定到Persistent Volume Claim。

MatchLabels：Volume 必須有具有該值的標簽

matchExpressions：這是一個要求列表，通過指定關鍵字，值列表以及與關鍵字和值相關的運算符組成。有效的運算符包括 In、NotIn、Exists 和 DoesNotExist。

訪問模式包括：ReadWriteOnce——該卷可以被單個節點以讀/寫模式掛載。

在命令行中，訪問模式縮寫為：RWO - ReadWriteOnce

京東云為Persistent Volume提供了插件，插件類型為：jdcloudElasticBlockStore

注：副本數只能指定1。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pv-static-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ""
  resources:
    requests:
      storage: 30Gi
  selector:
    matchLabels:
      type: jdcloud-ebs

創建Pod

kind: Pod

   apiVersion: v1
   metadata:
     name: pod-static
   spec:
     volumes:
       - name: pv-static
         persistentVolumeClaim:
           claimName: pv-static-pvc

  containers:
    - name: busybox-static
      image: busybox
      command:
         - sleep
         - "600"
      imagePullPolicy: Always
      volumeMounts:
        - mountPath: "/usr/share/mybusybox/"
          name: pv-static

使用京東云云盤定義動態存儲

當集群中的靜態 PV 都不匹配新建的 Persistent Volume Claim 時，集群可能會嘗試動態地為 PVC 創建卷。

關于京東云云硬盤規格：

創建PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: jdcloud-ssd
  resources:
    requests:
      storage: 20Gi

查看集群的PVC

kubectl get pvc

輸出

NAME                                         STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc1                                         Bound     pvc-73d8538b-ebd6-11e8-a857-fa163eeab14b   20Gi       RWO            jdcloud-ssd    18s

查看集群的PV

kubectl get pv

輸出

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-73d8538b-ebd6-11e8-a857-fa163eeab14b 20Gi RWO Delete Bound default/pvc1 jdcloud-ssd 2m

基于Storage Class jdcloud-ssd，為PVC創建了卷。一旦 PV 和 PVC 綁定后，Persistent Volume Claim 綁定是排他性的，不管它們是如何綁定的。 PVC 跟 PV 綁定是一對一的映射。

Kubernetes Service

Kubernetes Service定義了這樣一種抽象：一個 Pod 的邏輯分組，一種可以訪問它們的策略-通常稱為微服務。這一組 Pod 能夠被 Service 訪問到，通常是通過 Label Selector（查看下面了解，為什么可能需要沒有 Selector 的 Service）實現的。一個 Service 在 Kubernetes 中是一個REST對象，和Pod類似.像所有的 REST 對象一樣， Service 定義可以基于 POST 方式，請求 API Server 創建新的實例。

京東云Kubernetes集成負載均衡服務，支持創建Load Balance類型的Service，為應用提供安全、可靠的網絡。

創建的負載均衡會占用本地域的負載均衡配額，需要保證有足夠配額。

1、創建支持Load Balance類型的Service，命名為myservice.yaml文件定義如下：

kind: Service
apiVersion: v1
metadata:
  name: servicetest
  labels:
    run: myapp
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30062
  type: LoadBalancer
  selector:
     run: myapp

2、執行Kubectl創建命令，創建一個Service；其中使用相應的YAML文件名稱替換：

kubectl create -f myservice.yaml

3、創建一組Nginx Pod，mynginx.yaml文件定義如下：

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: myapp
  replicas: 2
  template:
    metadata:
      labels:
        run: myapp
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

4、執行Kubectl創建命令，創建一個Deployment；其中使用相應的YAML文件名稱替換

kubectl create -f mynginx.yaml

5、查看已創建成功的Deployment，執行以下命令：

kubectl get pods -l run=myapp -o wide

返回結果如下：

NAME       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
my-nginx   2         2         2            2           4m

6、查看相應的Pod運行狀態，

kubectl get pods -l run=myapp -o wide

返回結果如下：

NAME                        READY     STATUS    RESTARTS   AGE       IP            NODE
my-nginx-864b5bfdc7-6297s   1/1       Running   0          23m       172.16.0.10   k8s-node-vmtwjb-0vy9nuo0ym
my-nginx-864b5bfdc7-lr7gq   1/1       Running   0          23m       172.16.0.42   k8s-node-vm25q1-0vy9nuo0ym

7、查看Service詳情：

kubectl describe service servicetest
可以查看綁定到Service的Endpoints:

Name:                     servicetest
Namespace:                default
Labels:                   run=myapp
Annotations:              
Selector:                 run=myapp
Type:                     LoadBalancer
IP:                       172.16.61.58
LoadBalancer Ingress:     114.67.227.25
Port:                       80/TCP
TargetPort:               80/TCP
NodePort:                   30062/TCP
Endpoints:                172.16.0.10:80,172.16.0.42:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type     Reason                      Age                From                Message
  ----     ------                      ----               ----                -------
  Normal   EnsuringLoadBalancer        11m (x9 over 26m)  service-controller  Ensuring load balancer
  Normal   EnsuredLoadBalancer         10m                service-controller  Ensured load balancer

注：Load Balancer Ingress:114.67.227.25為外部公網IP

8、執行如下命令查詢綁定到service的enpoints列表：

kubectl get ep servicetest
返回

NAME          ENDPOINTS                       AGE
servicetest   172.16.0.10:80,172.16.0.42:80   28m

9、在瀏覽器中輸入與Service關聯的Load Balance公網IP及端口，看到如下頁面，即表明Nginx服務正常。

·END·