Kubernetes：数据卷（Volume）管理（PV/PVC等）；公共数据管理（Secret & Configmap）；Helm；Dashboard；集群监控工具；日志管理工具

k8s数据卷（Volume）管理

数据管理Kubernetes Volume;emptyDir Volume；hostPath Volume；外部 Storage Provider；实验1：emptyDir Volume；ASW云硬盘配置；Ceph硬盘配置
==============================================================================================================================
数据管理

Volume 的生命周期独立于容器，Pod 中的容器可能被销毁和重建，但 Volume 会被保留。

Kubernetes Volume 是一个目录，这一点与 Docker Volume 类似。当 Volume 被 mount 到 Pod，Pod 中的所有容器都可以访问这个 Volume。
Kubernetes Volume 也支持多种 backend 类型:
    包括 emptyDir、hostPath、GCE Persistent Disk、AWS Elastic Block Store、NFS、Ceph 等

Volume 提供了对各种 backend 的抽象，容器在使用 Volume 读写数据的时候不需要关心数据到底是存放在本地节点的文件系统中呢还是云硬盘上。对它来说，所有类型的 Volume 都只是一个目录。


--------------------------------------------------------------------------------------------------------
emptyDir Volume
emptyDir（emptyDir Volume 的生命周期与 Pod 一致）
    emptyDir 是最基础的 Volume 类型。正如其名字所示，一个 emptyDir Volume 是 Host 上的一个空目录。
    emptyDir Volume 对于容器来说是持久的，对于 Pod 则不是。当 Pod 从节点删除时，Volume 的内容也会被删除。但如果只是容器被销毁而 Pod 还在，则 Volume 不受影响。

hostPath Volume
    hostPath Volume 的作用是将 Docker Host 文件系统中已经存在的目录 mount 给 Pod 的容器。
    大部分应用都不会使用 hostPath Volume，因为这实际上增加了 Pod 与节点的耦合，限制了 Pod 的使用。
    不过那些需要访问 Kubernetes 或 Docker 内部数据（配置文件和二进制库）的应用则需要使用 hostPath。

    如果 Pod 被销毁了，hostPath 对应的目录也还会被保留，从这点看，hostPath 的持久性比 emptyDir 强。不过一旦 Host 崩溃，hostPath 也就没法访问了。


外部 Storage Provider
    1.云硬盘：
        如果 Kubernetes 部署在诸如 AWS、GCE、Azure 等公有云上，可以直接使用云硬盘作为 Volume
    2.分布式存储：
        Kubernetes Volume 也可以使用主流的分布式存，比如 Ceph、GlusterFS 等，

    外部 Storage Provider 相对于 emptyDir 和 hostPath，这些 Volume 类型的最大特点就是不依赖 Kubernetes。Volume 的底层基础设施由独立的存储系统管理，与 Kubernetes 集群是分离的。数据被持久化后，即使整个 Kubernetes 崩溃也不会受损。
--------------------------------------------------------------------------------------------------------
实验1：emptyDir Volume
[root@centos7 k8s_yml2]# cat empty_dir.yml
apiVersion: v1
kind: Pod
metadata:
  name: producer-consumer
spec:
  containers:
  - name: producer
    image: busybox
    volumeMounts:
    - mountPath: /producer_dir                                #producer 容器将 shared-volume mount 到 /producer_dir 目录。
      name: shared-volume
    args:
    - /bin/sh
    - -c
    - echo "hello world"> /producer_dir/hello;sleep 30000    #producer 通过 echo 将数据写到文件 hello 里

  - name: consumer
    image: busybox
    volumeMounts:
    - mountPath: /consumer_dir                                # consumer 容器将 shared-volume mount 到 /consumer_dir 目录。
      name: shared-volume
    args:
    - /bin/sh
    - -c
    - cat /consumer_dir/hello;sleep 30000                    #consumer 通过 cat 从文件 hello 读数据。

  volumes:                                                    #volumes 定义了一个 emptyDir 类型的 Volume shared-volume。
  - name: shared-volume
    emptyDir: {}


[root@centos7 k8s_yml2]# kubectl apply -f empty_dir.yml
pod "producer-consumer" created
[root@centos7 k8s_yml2]# kubectl get pod producer-consumer
NAME                READY     STATUS    RESTARTS   AGE
producer-consumer   2/2       Running   0          34s

[root@centos7 k8s_yml2]# kubectl logs producer-consumer producer
[root@centos7 k8s_yml2]# kubectl logs producer-consumer consumer
hello world


[root@centos7 k8s_yml2]# docker inspect 7f20dd77036f |grep "Mounts" -A4
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/var/lib/kubelet/pods/f0d67b83-78f3-11ec-927e-00163e1bae12/volumes/kubernetes.io~empty-dir/shared-volume",    #emptyDir 在host的真正路径
                "Destination": "/consumer_dir",                                                                                            #挂在到容器的/consumer_dir目录下
[root@centos7 k8s_yml2]#
[root@centos7 k8s_yml2]# docker inspect 06a46b3e5e92 |grep  "Mounts" -A4
        "Mounts": [
            {
                "Type": "bind",
                "Source": "/var/lib/kubelet/pods/f0d67b83-78f3-11ec-927e-00163e1bae12/volumes/kubernetes.io~empty-dir/shared-volume",    #emptyDir 在host的真正路径
                "Destination": "/producer_dir",                                                                                            #挂在到容器的/producer_dir目录下

----------------------------------------------------------------------------------------------------
ASW云硬盘配置
#AWS Elastic Block Store 的例子：
[root@centos7 k8s_yml2]# cat aws.yml
apiVersion: v1
kind: Pod
metadata:
  name: using-ebs
spec:
  containers:
  - name: using-ebs
    image: busybox
    volumeMounts:
    - mountPath: /test-ebs
      name: ebs-volume

  volumes:
  - name: ebs-volume
    awsElasticBlockStore:            #使用 ESB volume
      VolumeID: <volume-id>            #必须先在 AWS 中创建，然后通过 volume-id 引用
      fsType: ext4                    
    #其他云硬盘的使用方法可参考各公有云厂商的官方文档。
------------------------------------------------------------------------------------------------------
Ceph硬盘配置
下面是 Ceph 的例子：
[root@centos7 k8s_yml2]# cat ceph.yml
apiVersion: v1
kind: Pod
metadata:
  name: using-ceph
spec:
  containers:
  - name: using-ceph
    image: busybox
    volumeMounts:
    - mountPath: /test-ceph
      name: ceph-volume

  volumes:
  - name: ceph-volume
    cephfs:
      path: /some/path/in/side/cephfs        #使用Ceph 文件系统的 /some/path/in/side/cephfs 
      monitors: "10.16.154.78:6789"
      secretFile: "/etc/ceph/admin.secret"

Kubernetes Volume;emptyDir Volume；hostPath Volume；外部 Storage Provider；实验1：emptyDir Volume；ASW云硬盘配置；Ceph硬盘配置

PersistentVolume (PV) & PersistentVolumeClaim (PVC)；PV回收过程及机制；PV 动态供给；实验1：NFS静态PV实验；实验2：MySQL 使用 PV 和 PVC（故障模拟）
========================================================================================================
PersistentVolume & PersistentVolumeClaim

PersistentVolume (PV) 是外部存储系统中的一块存储空间，由管理员创建和维护。与 Volume 一样，PV 具有持久性，生命周期独立于 Pod。
PersistentVolumeClaim (PVC) 是对 PV 的申请 (Claim)。PVC 通常由普通用户创建和维护。需要为 Pod 分配存储资源时，用户可以创建一个 PVC，指明存储资源的容量大小和访问模式（比如只读）等信息，Kubernetes 会查找并提供满足条件的 PV。

Kubernetes 支持多种类型的 PersistentVolume，比如 AWS EBS、Ceph、NFS 等，完整列表请参考 https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes

emptyDir 和 hostPath 类型的 Volume 很方便，但可持久性不强，Kubernetes 支持多种外部存储系统的 Volume。
PV 和 PVC 分离了管理员和普通用户的职责，更适合生产环境。
----------------------------------------------------------------------------------------------------
PV回收过程及机制
PV回收过程：
    当 PV 不再需要时，可通过删除 PVC 回收。
    通过kubectl delete删除pvc后，k8s会启动一个新pod "recycler-for-mypv1";该Pod 的作用就是清除 PV mypv1 的数据。
        同时 PV mypv1 的状态为 Released，表示已经解除了与 mypvc1 的 Bound，正在清除数据，不过此时还不可用。
    等待数据清理完毕后，PV mypv1 的状态重新变为 Available，此时则可以被新的 PVC 申请。

PV回收机制：
    因为 PV 的回收策略设置为 Recycle，所以数据会被清除；如果我们希望保留数据，可以将策略设置为 Retain。
        pv数据会保留，但是pv状态一直处于 Released，不能被其他 PVC 申请。
        此时可以删除并重新创建 mypv1。删除操作只是删除了 PV 对象，存储空间中的数据并不会被删除。
        
    PV 还支持 Delete 的回收策略，会删除 PV 在 Storage Provider 上对应存储空间。NFS 的 PV 不支持 Delete，支持 Delete 的 Provider 有 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

----------------------------------------------------------------------------------------------------
PV 动态供给
动态供给（Dynamical Provision）：
    如果没有满足 PVC 条件的 PV，会动态创建 PV。相比静态供给，动态供给有明显的优势：不需要提前创建 PV，减少了管理员的工作量，效率高。
    动态供给是通过 StorageClass 实现的，StorageClass 定义了如何创建 PV。
    StorageClass 支持 Delete 和 Retain 两种 reclaimPolicy，默认是 Delete。

我的理解：不管是静态PV，还是动态PV，还是PVC都是以应用的形式存在，由k8s提供pod，部署应用的形式。
除了 AWS EBS，Kubernetes 支持其他多种动态供给 PV 的 Provisioner，完整列表请参考 https://kubernetes.io/docs/concepts/storage/storage-classes/#provisioner

----------------------------------------------------------------------------------------------------
支持的访问模式有：
    ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
    ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
    ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点。
    
支持的策略有：
    Retain – 需要管理员手工回收。
    Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
    Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

实验1：NFS静态PV实验：

1.部署nfs
    docker 部署nfs    https://www.cnblogs.com/pythonx/p/14641059.html
    docker pull erichough/nfs-server

    [root@k8s-master dir_yml]# lsmod |grep nfs      #确认，未加载nfs、nfsd模块
    [root@k8s-master dir_yml]# modprobe nfs
    [root@k8s-master dir_yml]# modprobe nfsd

     docker run --privileged -d                          \
      -v /home/ap/nas_a:/nas_a                        \
      -e NFS_EXPORT_0='/nas_a  *(rw,sync,no_root_squash,no_all_squash,no_subtree_check,nohide,crossmnt)'  \
      -p 2049:2049   -p 2049:2049/udp   \
      -p 111:111     -p 111:111/udp     \
      -p 32765:32765 -p 32765:32765/udp \
      -p 32767:32767 -p 32767:32767/udp \
      -it --name ai-nas-a \
      erichough/nfs-server
      
    [root@k8s-master ~]# docker exec -it 6132fd8f94be showmount -e
    Export list for 6132fd8f94be:
    /nas_a *

2.创建静态PV、PVC，并确认状态正常
    [root@k8s-master pv_pvc]# cat nfs-pv1.yml
    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: my-pv1
    spec:
      capacity:
        storage: 1Gi                            #指定 PV 的容量为 1G
      accessModes:
        - ReadWriteOnce                         #指定访问模式为 ReadWriteOnce
      persistentVolumeReclaimPolicy: Recycle    #指定当 PV 的回收策略为 Recycle
      storageClassName: nfs                     #指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。
      nfs:
        path: /nas_a                            #指定 PV 在 NFS 服务器上对应的目录。
        server: 192.168.1.81

    [root@k8s-master pv_pvc]# cat nfs-pvc1.yml
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: my-pvc1
    spec:
      accessModes:
        - ReadWriteOnce                         #指定访问模式
      resources:
        requests:
          storage: 1Gi                          #指定容量
      storageClassName: nfs                     #指定PV的名称

    --------------------------------
    [root@k8s-master pv_pvc]# kubectl apply -f nfs-pv1.yml --validate=false
    persistentvolume "my-pv1" created
    [root@k8s-master pv_pvc]# kubectl get pv
    NAME      CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     REASON    AGE
    my-pv1    1Gi        RWO           Recycle         Available                       31s          #PV创建成功


    [root@k8s-master pv_pvc]# kubectl apply -f nfs-pvc1.yml --validate=false
    persistentvolumeclaim "my-pvc1" created
    [root@k8s-master pv_pvc]# kubectl get pvc
    NAME      STATUS    VOLUME    CAPACITY   ACCESSMODES   AGE
    my-pvc1   Bound     my-pv1    1Gi        RWO           12s                                      #PVC创建成功
    [root@k8s-master pv_pvc]# kubectl get pv
    NAME      CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM             REASON    AGE
    my-pv1    1Gi        RWO           Recycle         Bound     default/my-pvc1             6m     #再次查看PV，确认PVC已经绑定到PV

3.创建pod，验证NFS PV的可用性

[root@k8s-master pv_pvc]# cat pod1.yml
apiVersion: v1
kind: Pod
metadata:
  name: mypod1
spec:
  containers:
    - name: mypod1
      image: busybox
      args:
      - /bin/sh
      - -c
      - sleep 30000
      volumeMounts:
      - mountPath: "/mydata"
        name: mydata
  volumes:
    - name: mydata
      persistentVolumeClaim:
        claimName: my-pvc1


[root@k8s-master pv_pvc]# kubectl apply -f pod1.yml
pod "mypod1" created

创建pod应用后，进行验证
kubectl exec mypod1 touch /mydata/hello        #使用该命令在容器中touch hello文件
kubectl exec mypod1 touch /mydata/hello0120
                        
[root@centos7 111]# docker exec 44f07be17efd ls /nas_a    #在容器目录下，确认了touch的新文件
hello
hello0120
[root@centos7 111]# ls /home/ap/nas_a                    #在host目录下，确认了touch的新文件
hello  hello0120


----------------------------------------------------------------------------------------------------
实验2：MySQL 使用 PV 和 PVC（故障模拟）
    1.创建 PV 和 PVC
    2.部署service和mysql
    3.向 MySQL 添加数据。
    4.模拟节点宕机故障，Kubernetes 将 MySQL 自动迁移到其他节点。
    5.验证数据一致性。

[root@centos7 mysql_pv]# cat mysql_pv.yml
apiVersion: v1
kind: persistentVolume
metadata:
  name: mysql-pv
spec:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs
  nfs:
    path: /nas_a 
    server: 172.17.22.136
[root@centos7 mysql_pv]# cat mysql_pvc.yml
apiVersion: v1
kind: persistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessMode:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs
  
  

[root@centos7 mysql_pv]# cat mysql_service.yml
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  ports:
  - port: 3306
  selector:
    app: mysql
[root@centos7 mysql_pv]# cat mysql_pod.yml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: mysql
spec:
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        presistentVolumeClaim:
          claimName: mysql-pvc


#起一个运行mysql客户端的容器，使用这个容器去访问mysql
kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h mysql -ppassword 

插入数据，模拟故障，验证数据一致性。

PersistentVolume (PV) & PersistentVolumeClaim (PVC)；PV回收过程及机制；PV 动态供给；实验1：NFS静态PV实验；实验2：MySQL 使用 PV 和 PVC（故障模拟）

k8s公共数据管理

Secret & Configmap；创建Secret的4种方法；pod使用Secret的2种形式；创建Configmap的4种方法；
======================================================================================================
Secret & Configmap

个人理解：k8s去管理一些公共信息or数据（键值对形式的数据，例如用户密码、环境变量），从而这些数据不需要直接写在容器中，而是容器去调用这些数据即可。
    Secret：密文的形式保存数据
    Configmap：明文的形式保存数据

pod使用Secret、Configmap有两种方式：
    1.Volume形式，数据在容器内以文件的形式存在
    2.环境变量形式，数据在容器内以环境变量的形式存在

--------------------------------------------------------------------------------------
Secret 会以密文的方式存储数据，避免了直接在配置文件中保存敏感信息。Secret 会以 Volume 的形式被 mount 到 Pod，容器可通过文件的方式使用 Secret 中的敏感数据；此外，容器也可以环境变量的方式使用这些数据。

有四种方法创建 Secret：
    1. 通过 --from-literal：
        kubectl create secret generic mysecret --from-literal=username=admin --from-literal=password=123456
        每个 --from-literal 对应一个信息条目。

    2. 通过 --from-file：
        echo -n admin > ./username
        echo -n 123456 > ./password
        kubectl create secret generic mysecret --from-file=./username --from-file=./password
        每个文件内容对应一个信息条目。

    3. 通过 --from-env-file：
        cat << EOF > env.txt
        username=admin
        password=123456
        EOF
        kubectl create secret generic mysecret --from-env-file=env.txt
        文件 env.txt 中每行 Key=Value 对应一个信息条目。

    4. 通过 YAML 配置文件：
        需要先把数据进行base64编码，然后再把编码结果填入yml文件
        [root@centos7 secret_Configmap]# echo -n admin |base64
        YWRtaW4=
        [root@centos7 secret_Configmap]# echo -n 123456 |base64
        MTIzNDU2
        [root@centos7 secret_Configmap]# cat secret.yml
        apiVersion: v1
        kind: Secret
        metadata:
          name: my_secret
        data:
          username: YWRtaW4=
          password: MTIzNDU2


    kubectl get secret                 #查看存在的 secret。
    kubectl describe secret         #查看条目的 Key
    kubectl edit secret mysecret    #查看 Value，可以看到数据是密文的形式保存，使用了base64编码

    kubectl get configmap                 #查看存在的 configmap。
    kubectl describe configmap             #查看条目的 Key
    kubectl edit configmap myconfigmap    #查看 Value，可以看到数据是明文的形式保存！



    [root@centos7 k8s_yml2]# echo -n MTIzNDU2 |base64 --decode
    123456                                                            #反编码
----------------------------------------------------------------------------------------------------
Pod 可以通过 Volume 或者环境变量的方式使用 Secret

volume 方式使用 Secret
[root@centos7 secret_Configmap]# cat secret_volume.yml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args:
      - /bin/sh
      - -c
      - sleep 10;touch /tmp/healthy;sleep 30000
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"                #将 foo mount 到容器路径 /etc/foo，可指定读写权限为 readOnly。
      readOnly: true
  volumes:
  - name: foo                            #定义 volume foo，来源为 secret mysecret。
    secret:
      secretName: mysecret

kubectl exec -it mypod sh    #进入容器后，查看/etc/foo
    可以看到，Kubernetes 会在指定的路径 /etc/foo 下为每条敏感数据创建一个文件，文件名就是数据条目的 Key，这里是 /etc/foo/username 和 /etc/foo/password，Value 则以明文存放在文件中。

--------------------
  volumes:
  - name: foo                            #定义 volume foo，来源为 secret mysecret。
    secret:
      secretName: mysecret
      items:                            #自定义存放路径
      - key: username
        path: my-group/my-username        #/etc/foo/my-group/my-username
      - key: password
        path: my-group/my-password        #/etc/foo/my-group/my-password 

以 Volume 方式使用的 Secret 支持动态更新：Secret 更新后，容器中的数据也会更新。

#更新password后，进入容器查看，可以观察到几秒钟之后，新的password会同步到容器。

----------------------------------------------------------------------------------------------------
环境变量方式使用 Secret

[root@centos7 secret_Configmap]# cat secret_env.yml
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: busybox
    args:
      - /bin/sh
      - -c
      - sleep 10;touch /tmp/healthy;sleep 30000
    env:
      - name: SECRET_USERNAME                    #环境变量的形式使用secret
        valueFrom: 
          secretKeyRef: 
            name: mysecret
            key: username
      - name: SECRET_PASSWORD
        valueFrom: 
          secretKeyRef: 
            name: mysecret
            key: password


需要注意的是，环境变量读取 Secret 很方便，但无法支撑 Secret 动态更新。

Secret 可以为 Pod 提供密码、Token、私钥等敏感数据；对于一些非敏感数据，比如应用的配置信息，则可以用 ConfigMap。


=======================================================================================================
ConfigMap 的创建和使用方式与 Secret 非常类似，主要的不同是数据以明文的形式存放。
与 Secret 一样，ConfigMap 也支持四种创建方式：
    1. 通过 --from-literal：
        kubectl create configmap myconfigmap --from-literal=config1=xxx --from-literal=config2=yyy
        每个 --from-literal 对应一个信息条目。

    2. 通过 --from-file：
        echo -n xxx > ./config1
        echo -n yyy > ./config2
        kubectl create configmap myconfigmap --from-file=./config1 --from-file=./config2
        每个文件内容对应一个信息条目。

    3. 通过 --from-env-file：
        cat << EOF > env.txt
        config1=xxx
        config2=yyy
        EOF
        kubectl create configmap myconfigmap --from-env-file=env.txt
        文件 env.txt 中每行 Key=Value 对应一个信息条目。

    4. 通过 YAML 配置文件：
        [root@centos7 ~]# cat configmap.yml
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: myconfigmap
        data:
          config1: xxxxx
          config2: yyyyy


使用的方式也和secret一样，支持volume或env形式
volumes:
- name: foo                            #volume形式
configMap:
  secretName: myconfigmap
---------------
env:
  - name: CONFIG_1            #env形式
    valueFrom: 
      configMapKeyRef: 
        name: myconfigmap
        key: config1
  - name: CONFIG_2
    valueFrom: 
      configMapKeyRef: 
        name: myconfigmap
        key: config2

大多数情况下，配置信息都以文件形式提供，所以在创建 ConfigMap 时通常采用 --from-file 或 YAML 方式，读取 ConfigMap 时通常采用 Volume 方式。

Secret & Configmap；创建Secret的4种方法；pod使用Secret的2种形式；创建Configmap的4种方法；

Helm

包管理工具Helm概述
=================================================================================================
根据之前所学知道，kubernetes搭建一个MySQL服务，需要部署以下对象：
    1.部署service        
    2.部署secret
    3.部署PV/PVC
    4.部署MySQL pod

在面对微服务架构的应用，组成应用的服务可能多达十个甚至几十上百个，这种组织和管理应用的方式就不好使了：
    1.很难管理、编辑和维护如此多的服务。每个服务都有若干配置，缺乏一个更高层次的工具将这些配置组织起来。
    2.不容易将这些服务作为一个整体统一发布。部署人员需要首先理解应用都包含哪些服务，然后按照逻辑顺序依次执行 kubectl apply。即缺少一种工具来定义应用与服务，以及服务与服务之间的依赖关系。
    3.不能高效地共享和重用服务。比如两个应用都要用到 MySQL 服务，但配置的参数不一样，这两个应用只能分别拷贝一套标准的 MySQL 配置文件，修改后通过 kubectl apply 部署。也就是说不支持参数化配置和多环境部署。
    4.不支持应用级别的版本管理。虽然可以通过 kubectl rollout undo 进行回滚，但这只能针对单个 Deployment，不支持整个应用的回滚。
    5.不支持对部署的应用状态进行验证。比如是否能通过预定义的账号访问 MySQL。虽然 Kubernetes 有健康检查，但那是针对单个容器，我们需要应用（服务）级别的健康检查
--------------------------------------------
Kubernetes 能够很好地组织和编排容器；Helm则是一个更高层次的应用打包工具

chart 是创建一个应用的信息集合，包括各种 Kubernetes 对象的配置模板、参数定义、依赖关系、文档说明等。chart 是应用部署的自包含逻辑单元。可以将 chart 想象成 apt、yum 中的软件安装包。

release 是 chart 的运行实例，代表了一个正在运行的应用。当 chart 被安装到 Kubernetes 集群，就生成一个 release。chart 能够多次安装到同一个集群，每次安装都是一个 release。



Helm 是包管理工具，这里的包就是指的 chart。Helm 能够：
    1.从零创建新 chart。
    2.与存储 chart 的仓库交互，拉取、保存和更新 chart。
    3.在 Kubernetes 集群中安装和卸载 release。
    4.更新、回滚和测试 release。

Helm 包含两个组件：Helm 客户端 和 Tiller 服务器。

Helm 客户端是终端用户使用的命令行工具，用户可以：
    1.在本地开发 chart。
    2.管理 chart 仓库。
    3.与 Tiller 服务器交互。
    4.在远程 Kubernetes 集群上安装 chart。
    5.查看 release 信息。
    6.升级或卸载已有的 release。

Tiller 服务器运行在 Kubernetes 集群中，它会处理 Helm 客户端的请求，与 Kubernetes API Server 交互。Tiller 服务器负责：
    1.监听来自 Helm 客户端的请求。
    2.通过 chart 构建 release。
    3.在 Kubernetes 中安装 chart，并跟踪 release 的状态。
    4.通过 API Server 升级或卸载已有的 release。


简单的讲：Helm 客户端负责管理 chart；Tiller 服务器负责管理 release。