Kubernetes的Web UI网页管理工具kubernetes-dashboard可提供部署应用、资源对象管理、容器日志查询、系统监控等常用的集群管理功能。为了在页面上显示系统资源的使用情况，要求部署Metrics Server
可通过https://rawgit.com/kubernetes/dashboard/ master/src/deploy/kubernetes-dashboard.yaml页面下载部署kubernetes-dashboard的YAML配置文件。该配置文件的内容如下，其中包含Deployment和Service的定义：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
2kind: Deployment
3apiVersion: extensions/v1beta1
4metadata:
5 labels:
6 app: kubernetes-dashboard
7 name: kubernetes-dashboard
8 namespace: kube-system
9spec:
10 replicas: 1
11 revisionHistoryLimit: 10
12 selector:
13 matchLabels:
14 app: kubernetes-dashboard
15 template:
16 metadata:
17 labels:
18 app: kubernetes-dashboard
19 annotations:
20 scheduler.alpha.kubernetes.io/tolerations: |
21 [
22 {
23 "key": "dedicated",
24 "operator": "Equal",
25 "value": "master",
26 "effect": "NoSchedule"
27 }
28 ]
29 spec:
30 containers:
31 - name: kubernetes-dashboard
32 image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.0
33 imagePullPolicy: Always
34 ports:
35 - containerPort: 9090
36 protocol: TCP
37 args:
38 livenessProbe:
39 httpGet:
40 path: /
41 port: 9090
42 initialDelaySeconds: 30
43 timeoutSeconds: 30
44
45---
46kind: Service
47apiVersion: v1
48metadata:
49 labels:
50 app: kubernetes-dashboard
51 name: kubernetes-dashboard
52 namespace: kube-system
53spec:
54 type: NodePort
55 ports:
56 - port: 80
57 targetPort: 9090
58 nodePort: 9090
59 selector:
60 app: kubernetes-dashboard
61
详细部署过程可以参考第2篇。
Helm: Kubernetes应用包管理工具
随着容器技术逐渐被企业接受，在Kubernetes上已经能便捷地部署简单的应用了。但对于复杂的应用中间件，在Kubernetes上进行容器化部署并非易事，通常需要先研究Docker镜像的运行需求、环境变量等内容，并能为这些容器定制存储、网络等设置，最后设计和编写Deployment、ConfigMap、Service及Ingress等相关YAML配置文件，再提交给Kubernetes部署。这些复杂的过程将逐步被Helm应用包管理工具实现。
Helm概述
Helm是一个由CNCF孵化和管理的项目，用于对需要在Kubernetes上部署的复杂应用进行定义、安装和更新。Helm以Chart的方式对应用软件进行描述，可以方便地创建、版本化、共享和发布复杂的应用软件。
Helm的主要概念
Helm的主要概念如下。
◎ Chart：一个Helm包，其中包含运行一个应用所需要的工具和资源定义，还可能包含Kubernetes集群中的服务定义，类似于Homebrew中的formula、APT中的dpkg或者Yum中的RPM文件。
◎ Release：在Kubernetes集群上运行的一个Chart实例。在同一个集群上，一个Chart可以被安装多次。例如有一个MySQL Chart，如果想在服务器上运行两个MySQL数据库，就可以基于这个Chart安装两次。每次安装都会生成新的Release，会有独立的Release名称。
◎ Repository：用于存放和共享Chart仓库。
简单来说，Helm整个系统的主要任务就是，在仓库中查找需要的Chart，然后将Chart以Release的形式安装到Kubernetes集群中。
安装Helm
Helm由HelmClient和TillerServer两个组件组成，下面讲解这两个组件。
HelmClient
HelmClient是一个客户端，拥有对Repository、Chart、Release等对象的管理能力，可以通过二进制文件或脚本进行安装。
通过二进制文件安装时，从https://github.com/kubernetes/helm/releases下载二进制文件，将其解压并复制到执行目录即可。
通过脚本安装的代码如下：
2
3
4
5
2
3# chmod 700 get_helm.sh
4# ./get_helm.sh
5
TilerServer
TillerServer负责客户端指令和Kubernetes集群之间的交互，根据Chart定义，生成和管理各种Kubernetes的资源对象。
对TillerServer的安装可以使用helm init命令进行（官方推荐），这一命令会在kubectl当前context指定集群内的kube-system命名空间创建一个Deployment和一个Service，运行TillerServer服务。
在Deployment中使用的镜像是gcr.io/kubernetes-helm/tiller:v[helm-version]，可以通过helm version命令获得其Helm版本。如果无法连接互联网获取该镜像，则可以先通过一台能够联网的服务器下载这个镜像并保存到镜像私库，利用helm init子命令的–tiller-image参数来指定私库中的镜像执行初始化过程。
安装结束之后，用helm version命令验证安装情况，一切正常的话，会分别显示Tiller和Helm的版本信息。一个常见的问题是，Tiller部分显示一个错误信息“uid:unable to do port forwarding: socat not found”，这是因为所在节点没有socat，无法进行端口转发，这时在主机上安装socat软件即可。
对TillerServer的安装还可以在本地进行，在服务器本地直接运行Tiller，这种安装方式需要让Helm指定要连接的服务地址，有以下两种方法。
◎ 使用–host指定Tiller运行的监听地址。
◎ 设置HELM_HOST环境变量。
需要注意的是，Tiller仍会使用kubectl配置中的context连接Kubernetes集群。
Helm的常见用法
下面介绍Helm的常见用法，包括搜索Chart、安装Chart、自定义Chart配置、更新或回滚Release、删除Release、创建自定义Chart、搭建私有仓库等。
1.helm search：搜索可用的Chart
Helm在初始化完成之后，默认配置为使用官方的Kubernetes Chart仓库。官方仓库包含大量的经过组织和持续维护的Chart，这个仓库通常被命名为stable。
在没有过滤的情况下，通过helm search命令会显示所有可用的Chart，可以使用参数进行过滤：
为什么在列表中会有MariaDB？因为在MariaDB的描述信息中包含了mysql关键字。可以通过helm inspect <chart_name>命令查看Chart的详细信息：
在找到需要安装的Chart之后，就可以进行安装了。
2.helm install：安装Chart
使用helm install命令安装应用，最简单的参数是Chart的名称。以MariaDB为例：
至此，MariaDB就安装完成了。可以看到系统创建了一个新的名为falling-lightningbug的Release对象，可以在helm install命令中使用–name参数修改其名称。
在安装过程中，Helm客户端会输出一些有用的信息，例如Release的状态及额外的配置步骤等。
Helm不会等待所有创建过程的完成，这是因为有些Chart的Docker镜像较大，会消耗很长的时间进行下载和创建。
在helm install命令的执行过程中，可以使用helm status命令跟踪Release的状态：
在成功安装Chart后，系统会在kube-system命名空间内创建一个ConfigMap用于保存Release对象的数据：
3.自定义Chart的配置
前面介绍的安装过程使用的是Chart的默认配置。然而在很多情况下，我们希望使用自定义的配置部署应用。
首先，通过helm inspect命令查看Chart的可配置内容：
用户可以编写一个YAML配置文件来覆盖上面这些设置，然后利用这一文件来给安装过程提供配置。例如，我们可以自定义额外的两个配置文件config.yaml和config2.yaml，用于在执行helm install命令安装MariaDB之后，在MariaDB启动时自动创建名为firstdb和seconddb的数据库，并且设置root用户的密码：
在安装完成之后，可以登录MariaDB Pod查看数据库是否创建成功。
自定义Chart的配置有两种方法。
◎ –values或者-f：使用YAML配置文件进行参数配置，可以设置多个文件，最后一个优先生效。多个文件中的重复value会进行覆盖操作，不同的value会叠加生效。上面的例子使用的就是这种方式。
◎ –set：在命令行中直接设置参数。
如果同时使用两个参数，则–set会以高优先级合并到–values中。
–set的格式和限制
–set参数可以使用0个或多个名称/值的组合，最简单的方式是–set name=value，YAML配置文件中的等效描述是：
2
2
多个值可以使用逗号进行分隔，例如–set a=b,c=d的YAML配置等效于下面的描述：
2
3
2c: d
3
还可以用来表达多层结构的变量–set outer.inner=value：
2
3
2 inner: value
3
大括号（{}）可以用来表达列表数据，例如–set name={a,b,c}会被翻译成：
2
3
4
5
2 - a
3 - b
4 - c
5
有时需要在–set时使用一些特殊字符，这里可以使用斜线进行转义，比如–set name=value1,value2。类似地，可以对点符号“.”进行转义，这样Chart使用toYaml函数解析注解、标签或者node selector时就很方便了，例如：–set nodeSelector."kubernetes.io/role"=master。
尽管如此，–set语法的表达能力依然无法和YAML语言相提并论，尤其是在处理集合时。目前没有方法能够实现“把列表中第3个元素设置为XXX”这样的语法。
更多的安装方法
使用helm install命令时，可以通过多种安装源进行安装。
◎ 上面用到的Chart仓库。
◎ 本地的Chart压缩包（helm install foo-0.1.1.tgz）。
◎ 一个Chart目录（helm install path/to/foo）。
◎ 一个完整的URL（helm install https://example.com/charts/foo-1.2.3.tgz）。
helm upgrade和helm rollback：应用的更新或回滚
当一个Chart发布新版本或者需要修改一个Release的配置时，就需要使用helm upgrade命令了。
helm upgrade命令会利用用户提供的更新信息来对Release进行更新。因为Kubernetes Chart可能会有很大的规模或者相对复杂的关系，所以Helm会尝试进行最小影响范围的更新，只更新相对于上一个Release来说发生变化的内容。
例如，我们要更新一个Release的资源限制，则可以创建config3.yaml配置文件，内容如下：
2
3
4
5
2 requests:
3 memory: 256Mi
4 cpu: 500m
5
使用upgrade命令完成更新：
2
2
看到更新提示之后，我们可以用Helm的list指令查看Release的信息，会发现revision一列发生了变化。接下来通过kubectl的get pods，deploy指令可以看到Pod已经更新；通过kubectl describe deploy指令还会看到Deployment的更新过程和一系列的ScalingReplicaSet事件。
如果对更新后的Release不满意，则可以使用helm rollback命令对Release进行回滚，例如：
2
2
这个命令将把名为nomadic-terrier的Release回滚到版本2。
在执行命令之后，同样可以使用前面提到的几个查询指令，会看到类似的结果。
最后，可以使用helm history <release_name>命令查看一个Release的变更历史。
helm install/upgrade/rollback命令的常用参数
Helm 有很多参数可以帮助用户指导命令的行为。本节介绍一些常用参数，用户可以使用helm <command> help命令获取所有参数的列表。
◎ –timeout：等待Kubernetes命令完成的时间，单位是s，默认值为300，也就是5min。
◎ –wait：等待Pod，直到其状态变为ready，PVC才完成绑定。Deployment完成其最低就绪要求的Pod创建，并且服务有了IP地址，才认为Release创建成功。这一等待过程会一直持续到超过–timeout，超时后这一Release被标记为FAILED（注意：当Deployment的replicas被设置为1，同时滚动更新策略的maxUnavailable不为0时，–wait才会因为最小就绪Pod数量达成而返回ready状态）。
◎ –no-hooks：该命令会跳过Hook执行。
◎ –recreate-pods：会引起所有Pod的重建（Deployment所属的Pod除外）。
helm delete: 删除一个Release
通过helm delete命令可以删除一个Release，例如通过helm delete happy-panda命令可以从集群中删除名为happy-panda的Release。
可以通过helm list命令列出在集群中部署的Release。如果给list加上–deleted参数，则会列出所有删除的Release；–all参数会列出所有的Release，包含删除的、现存的及失败的Release。
正因为Helm会保存所有被删除Release的信息，所以Release的名字是不可复用的（如果坚持复用，则可以使用–replace参数，这一操作不建议在生产环境中使用），这样被删除的Release也可以被回滚，甚至重新激活。
helm repo： 仓库的使用
我们在前面使用的Chart来自stable仓库。我们也可以对Helm进行配置，让其使用其他仓库。Helm在helm repo命令中提供了很多仓库相关的工具。
◎ helm repo list：列出所有仓库。
◎ helm repo add：添加仓库，例如从repo_url中添加名为dev的仓库helm repo add dev http://<repo_url>/dev-charts。
◎ helm repo update：更新仓库中的Chart信息。
自定义Chart
用户可以将自己的应用定义为Chart并进行打包部署，本节对其进行简单介绍，详细的开发指南参见https://docs.helm.sh/developing-charts。
自定义Chart时需要使用符合Helm规范的一组目录和配置文件来完成。
对Chart目录结构和配置文件的说明
Chart是一个包含一系列文件的目录。目录的名称就是Chart的名称（不包含版本信息），例如一个WordPress的Chart就被会存储在wordpress目录下。
该目录的文件结构如下：
charts/子目录和requirements.yaml的区别在于，前者需要提供整个Chart文件，后者仅需要注明依赖Chart的仓库信息，例如一个requirements.yaml可以被定义为：
2
3
4
5
6
7
8
2 - name: apache
3 version: 1.2.3
4 repository: http://example.com/charts
5 - name: mysql
6 version: 3.2.1
7 repository: http://another.example.com/charts
8
对Chart.yaml文件的说明
Chart.yaml文件（注意首字母大写）是个必要文件，包含如下内容。
◎ name：Chart的名称，必选。
◎ version：SemVer 2规范的版本号，必选。
◎ description：项目的描述，可选。
◎ keywords：一个用于描述项目的关键字列表，可选。
◎ home：项目的主页，可选。
◎ sources：一个URL列表，说明项目的源代码位置，可选。
◎ maintainers：维护者列表，可选。
◎ name：管理员的名字，必选。
◎ email：管理员的邮件，必选。
◎ engine：模板引擎的名称，默认是gotpl，可选。
◎ icon：一个指向svg或png图像的URL，作为Chart的图标，可选。
◎ appVersion：在Chart中包含的应用的版本，无须遵循SemVer规范，可选。
◎ deprecated：布尔值，该Chart是否标注为“弃用”，可选。
◎ tillerVersion：可选，该Chart所需的Tiller版本。取值应该是一个SemVer的范围，例如“>2.0.0”。
快速制作自定义的Chart
同其他软件开发过程一样，快速制作一个简单Chart的方法，就是从其他项目中复制并修改。例如，我们要简单地改写前面MariaDB的Chart，令其使用本地的私有镜像仓库，就可以按照如下步骤进行。
◎ 下载Chart：使用helm fetch stable/mariadb命令下载这一Chart的压缩包。
◎ 编辑Chart。
◎ 利用tar解压之后，我们将目录重新命名为mymariadb。
◎ 修改templates中的deployment.yaml，简单地将其中的image字段硬编码为需要的镜像（当然不推荐这种用法，可以继续以变量的方式在values中进行设置）。
◎ 将Chart.yaml中的版本号修改为0.1.1，name为mymariadb。
◎ 使用helm package mymariadb打包Chart，会生成一个名为mymariadb-0.1.1.tgz的压缩包。
◎ 安装Chart：通过helm install mymariadb-0.1.1.tgz命令即可将我们“新”生成的Chart安装到集群中。
搭建是有Repository
在自建Chart之后自然需要搭建私有仓库。下面使用Apache搭建一个简单的Chart私有仓库，并将刚才新建的mymariadb Chart保存到私有仓库中，详情可参考https://docs.helm.sh/ developing-charts/#chart-repo-guide。
Chart仓库主要由前面提到的Chart压缩包和索引文件构成，通过HTTP/HTTPS对外提供服务。这里使用一个Apache应用来提供仓库服务。Apache的设置如下。
◎ Apache使用/var/web/repo目录进行仓库的存储。
◎ 使用http://127.0.0.1/repo网址提供访问服务。
将前面生成的mymariadb-0.1.1.tgz文件复制到仓库的/var/web/repo目录下。
接下来使用helm repo index /var/web/repo –url http://127.0.0.1/repo命令，Helm将自动根据目录下的内容创建索引。在命令执行完毕后，可以看到在目录下多出一个index.yaml文件。
最后启动Web Server。
为了能够使用这个私有仓库，需要将这个新的仓库地址加入Helm配置中：
2
2
再次运行helm search mysql命令，会看到在Chart列表中多出localhost/mymariadb项目，也就是我们的新仓库中的Chart。
现在可以通过helm install localhost/mymariadb命令安装私有仓库中的Chart了。
小结：
到这里我们k8s里面涉及到的大部分概念，以及一些组件都讲解完了。
相信大家看到这里，对k8的一些概念也比较清楚了，接下来我们会深入，甚至重复的来讲解这些内容。
感谢大家这段时间的支持！
