书籍来源:cloudman《每天5分钟玩转Kubernetes》
一边学习一边整理老师的课程内容及试验笔记,并与大家分享,侵权即删,谢谢支持!
附上汇总贴:每天5分钟玩转Kubernetes | 汇总_COCOgsta的博客-CSDN博客
Helm到底解决了什么问题?为什么Kubernetes需要Helm?
答案是:Kubernetes能够很好地组织和编排容器,但它缺少一个更高层次的应用打包工具,而Helm就是来干这件事的。
先来看个例子。
比如对于一个MySQL服务,Kubernetes需要部署下面这些对象:
(1)Service,让外界能够访问到MySQL,如下所示。
[root@k8s-master ~]# cat mysql-service.yml
apiVersion: v1
kind: Service
metadata:
name: my-mysql
labels:
app: my-mysql
spec:
ports:
- name: mysql
port: 3306
targetPort: mysql
selector:
app: my-mysql
[root@k8s-master ~]#
(2)Secret,定义MySQL的密码,如下所示。
[root@k8s-master ~]# cat mysql-secret.yml
apiVersion: v1
kind: Secret
metadata:
name: my-mysql
labels:
app: my-mysql
type: Opaque
data:
mysql-root-password: "M0MzREhRQWRjeQ=="
mysql-password: "eGNXZkpMNmlkSw=="
[root@k8s-master ~]#
(3)PersistentVolumeClaim,为MySQL申请持久化存储空间,如下所示。
[root@k8s-master ~]# cat mysql-volume.yml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: my-mysql
labels:
app: my-mysql
spec:
accessModes:
- "ReadWriteOnce"
resources:
requests:
storage: "8Gi"
[root@k8s-master ~]#
(4)Deployment,部署MySQL Pod,并使用上面的这些支持对象,如下所示。
[root@k8s-master ~]# cat mysql-deployment.yml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: my-mysql
labels:
app: my-mysql
spec:
template:
metadata:
labels:
app: my-mysql
spec:
containers:
- name: my-mysql
image: "mysql:5.7.14"
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: my-mysql
key: mysql-root-password
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: my-mysql
key: mysql-password
- name: MYSQL_USER
value: ""
- name: MYSQL_DATABASE
value: ""
ports:
- name: mysql
containerPort: 3306
volumeMounts:
- name: data
mountPath: /var/lib/mysql
volumes:
- name: data
persistentVolumeClaim:
claimName: my-mysql
[root@k8s-master ~]#
我们可以将上面这些配置保存到对象各自的文件中,或者集中写进一个配置文件,然后通过kubectl apply -f部署。
到目前为止,Kubernetes对服务的部署支持得都挺好,如果应用只由一个或几个这样的服务组成,上面的部署方式完全足够了。
但是,如果我们开发的是微服务架构的应用,组成应用的服务可能多达十个甚至几十上百个,这种组织和管理应用的方式就不好使了:
(1)很难管理、编辑和维护如此多的服务。每个服务都有若干配置,缺乏一个更高层次的工具将这些配置组织起来。
(2)不容易将这些服务作为一个整体统一发布。部署人员需要首先理解应用都包含哪些服务,然后按照逻辑顺序依次执行kubectl apply,即缺少一种工具来定义应用与服务,以及服务与服务之间的依赖关系。
(3)不能高效地共享和重用服务。比如两个应用都要用到MySQL服务,但配置的参数不一样,这两个应用只能分别复制一套标准的MySQL配置文件,修改后通过kubectl apply部署。也就是说, 不支持参数化配置和多环境部署。
(4)不支持应用级别的版本管理。虽然可以通过kubectl rollout undo进行回滚,但这只能针对单个Deployment,不支持整个应用的回滚。
(5)不支持对部署的应用状态进行验证。比如是否能通过预定义的账号访问MySQL。虽然Kubernetes有健康检查,但那是针对单个容器,我们需要应用(服务)级别的健康检查。
Helm能够解决上面这些问题,Helm帮助Kubernetes成为微服务架构应用理想的部署平台。