Helm 入门指南

  Helm 为Kubernetes的软件包管理工具,Helm有两部分组成:Helm客户端、Tiller服务端,Helm三个主要部件:Chart、仓库、Release;

Chart:为Kubernetes中应用程序所需要的资源的定义。
仓库:为存储Helm chart的仓库,可从仓库中下载chart直接使用
Release: Kubernetes中运行的chart实例,每个chart可多次安装,每次安装都是一个新版本;

Helm 常见指令:

  helm search 在仓库中查找chart
enter image description here
enter image description here

  helm inspect stable/mongodb 可查看该chart的介绍信息;
  helm install stable/mongodb 可直接下载该chart并安装该chart;

版本升级:
  helm upgrade releaseName .
enter image description here

  helm rollback releaseName 1 回滚到版本1

  从零开始通过helm发布Kubernetes项目:

一、结构介绍

初始化项目:

helm create nginx  

  执行完后创建名为nginx的chart,现在查看nginx目录中的文件:

enter image description here

charts:目录用于存放所依赖的子chart
chart.yaml:为当前chart的说明文件,也可在模板中访问该文件;
templates:目录为nginx项目的模板目录,通常会使用values.yaml配置内容进行填充,板引擎渲染此目录的文件后Tiller将渲染得到的结果 提交给Kubernetes创建响应的对象;
values.yaml:为值文件,定义模板中需要使用的值,在templates的模板文件中将访问改值;
enter image description here

  在templates目录中有可以看到deployment.yaml、ingress.yaml、service.yaml文件这些为定义Kubernetes deployment、ingress、service对象的模板文件;
NOTES.txt:为安装chart成功后的说明文件
_helpers.tpl:模板助手文件,定义的值可在模板中使用;

二、通过helm在Kubernetes中部署Nginx

1、helm 初步使用

  现在删除template目录中的所有文件、清空values.yaml文件中所有内容

enter image description here

  部署nginx需要一个deployment控制器与对外提供服务的service,现在我们分别手动创建这个两个文件并编写相关内容;

deployment.yaml :

 apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-deployment
   labels:
     app: nginx
 spec:
   replicas: 3
   selector:
     matchLabels:
       app: nginx
   template:
     metadata:
       labels:
         app: nginx
     spec:
       containers:
       - name: nginx
         image: nginx:1.7.9
         ports:
         - containerPort: 80      

service.yaml

 apiVersion: v1
 kind: Service
 metadata:
  name: nginx-service
 spec:
  selector:
    app: nginx
  type: NodePort
  ports:
  - port: 80
    nodePort: 30078

  此时我们在上级目录执行:helm install nginx 已经可以将nginx部署到Kubernetes中;

enter image description here

  但如果只是这样使用Helm,那它存在的意义也不大,既然说template目录是模板目录当然它里面的模板文件也不能只是这么使用,要让模板文件体现出它的模型性质;下面我们将使用Helm的模板等功能,让模板文件体现出他的模板性质;

2、helm 模板
  目前为止deployment.yaml与service.yaml虽然是放在模板目录下但是完全没有体现出他的模板性质,现在我们开始这两个文件的模板化;

模板语法基础:

  内置对象:helm中有这么这个常用内置对象:Release、Values、Chart、Files、Capabilities、Template;

Release:此对象描述当前release,内置有:Release.Name release名称、Release.Time 发布时间等等等对面;
Values:此对象为从values.yaml文件与用户提供的文件中传递到模板的对值对象;
Chart:此对象为chart.yaml文件所提供的数据对象;
Files:提供了对chart非特殊文件的访问;
Capabilities:这提供了Kubernetes集群信息的访问;
Template:正在执行的当前模板信息

  下面我们通过helm内置对象Values来实现deployment.yaml、service.yaml文件的模板化,Values对象的取值范围:
1、当前chart的values.yaml文件;
2、如当前为子chart,则来自父chart的values.yaml文件;
3、在helm install或helm update执行是通过-f参数传递的文件;
4、通过helm install 时通过 –set设置的值;

  如values.yaml文件中存在replicaCount: 1对象,则在模板文件中通过{{ .Values.replicaCount }}即可访问到values.yaml文件定义的对象值1;

  通过_helpers.tpl可定义命名模板,下面定义模板deploy.name

 {{- define "deploy.name" -}}
 demo-deploy-nginx
 {{- end }}

  其中:{{ – 表示删除左侧的空格 – }} 删除右侧的空格
  此时可在模板文件中通过{{ template “deploy.name” . }} 引用该命名模板;

实现模板化:

  提取需要模板化的数据,这里提取出deployment对象的name、labels、replicas、matchLabels、template的labels、template spec的name、image;service对象的name、selector labels、type、port、nodePort等配置;
  我们再从提取出来的配置中挑选出name类与labels类配置定义为命名模板存放在_helpers.tpl文件中,其他的配置项定义在Values.yaml文件中;

_helpers.tpl文件内容如下:存放了deploy名称、service名称、deploy的lables、deploy中pod的lables;

{{- define "deploy.name" -}}
 demo-deploy-nginx
{{- end }}

{{- define "service.name" -}}
demo-service-nginx
{{- end }}

{{- define "labels" -}}
demo: nginx
{{- end}}

{{- define "deploy.labels" -}}
deploy: nginx
{{- end}}

values.yaml 文件,此文件定义了副本数、镜像名称与版本、service类型、端口等:

# 定义模板默认值
replicaCount: 1
image:
  repository: nginx
  tag: 1.7.9

service:
  type: NodePort
  port: 80
  nodePort: 30078

  值文件定义好了此时需要在模板deployment、service文件中引用上述两个文件所定义的值,下面开始重构deployment.yaml与service.yaml文件:

service.yaml文件:

apiVersion: v1
kind: Service
metadata: 
 name: {{ template "service.name" . }}
spec: 
 selector:
  {{ template "labels" . }}
 type: {{ .Values.service.type }}
 ports: 
 - port: {{ .Values.service.port }}
   nodePort: {{ .Values.service.nodePort }}

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata: 
  name: {{ template "deploy.name" . }}
  labels: 
    {{ template "deploy.labels" .}}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
   matchLabels:
      {{ template "labels" . }}
 template: 
    metadata:
      labels:
        {{ template "labels" . }}
    spec:
      containers:
      - name: {{ .Chart.Name}}
        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}
        ports:
        - containerPort: 80

  模板文件编写好后可以再重新使用Helm install部署nginx试试,执行前先执行helm delete running-chipmunk卸载掉之前安装的;

enter image description here

参考资料: https://docs.helm.sh/

Kubernetes中的RBAC

  Kubernetes中,授权有ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。需要在kube-apiserver设置–authorization-mode=RBAC参数,启用RABC模式,下面的操作版本为v1.10.1;
  当应用没有指定serviceAccountName,它将使用default服务帐户。

  在RABC API中,通过如下的步骤进行授权:
  1)定义角色:定义角色时会指定此角色对于资源的访问控制的规则;
  2)定义主体:用户、组和服务帐户
  3)绑定角色:将主体与角色进行绑定,对主体进行访问授权。

        enter image description here
                    RBAC API中的对象关系图

  Kubernetes中角色包含代表权限集合的规则,权限只有被授予,没有被拒绝的设置。
  在Kubernetes中有两类角色:普通角色和集群角色。
可以通过Role定义在一个命名空间中的角色,或是使用ClusterRole定义集群范围的角色。

普通角色只能被授予访问单一命令空间中的资源。
集群角色(ClusterRole)能够被授予资源权限有:集群范围资源(Node、NameSpace)、非资源端点(/healthz)、集群所有命名空间资源(跨名称空间);

角色绑定和集群角色绑定
  角色绑定用于将角色与一个主体进行绑定,从而实现将对主体授权的目的,主体分为用户、组和服务帐户。
角色绑定分为:普通角色绑定和集群角色绑定

角色绑定中不同主体定义有:
名称为 demo 用户:

 subjects:
 - kind:User
   name:"demo"
   apiGroup:rbac.authorization.k8s.io

名称为 demo 组:

 subjects:
 - kind:Group
   name:"demo-group"
   apiGroup:rbac.authorization.k8s.io

kube-system命名空间中,名称为default的服务帐户

 subjects:
 - kind:ServiceAccount
   name:default
   namespace:kube-system

so命名空间中,所有的服务帐户:

 subjects:
 - kind:Group
   name:system:serviceaccounts:so
   apiGroup:rbac.authorization.k8s.io

所有的服务帐户:

 subjects:
 - kind:Group
   name:system:serviceaccounts
   apiGroup:rbac.authorization.k8s.io

所有用户:

 subjects:
 - kind:Group
   name:system:authenticated    #授权用户
   apiGroup:rbac.authorization.k8s.io
 - kind:Group
   name:system:unauthenticated  #未授权用户
   apiGroup:rbac.authorization.k8s.io

授予cluster-admin集群角色给admin用户:

 kubectl create clusterrolebinding admin-cluster-admin-binding --clusterrole=cluster-admin --user=admin  

授予cluster-admin集群角色给so名称空间中的app服务帐户:

 kubectl create clusterrolebinding app-admin-binding --clusterrole=cluster-admin --serviceaccount=so:app  

  RBAC实例demo下面创建solinx-service-account.yml文件包含以下内容:

 # 服务账号
 apiVersion: v1
 kind: ServiceAccount   
 metadata:
   name: solinx
 # 角色
 ---
 kind: Role
 apiVersion: rbac.authorization.k8s.io/v1beta1
 metadata:
   name: solinx
 rules:                #规则
 - apiGroups: [""]       # 所有核心api
   resources: ["pods"]   # 资源
   verbs: ["create","delete","get","list","patch","update","watch"]  #操作
 - apiGroups: [""]
   resources: ["namespaces"]
   verbs: ["create","delete","get","list","patch","update","watch"]
 # 角色绑定
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: RoleBinding
 metadata:
   name: solinx
 roleRef:     # 上面定义的角色
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: solinx
 subjects:   # 上面定义的服务账户
 - kind: ServiceAccount
   name: solinx
   namespace: default

  上面定义了一个服务账户solinx、普通角色solinx,并将该服务账户与角色进行绑定,该角色定义了对了pod的增删查改等操作,所以该服务账户也具备了该权限;
  这里使用solinx服务账户对资源进行操作:

 kubectl get po --as system:serviceaccount:default:solinx

enter image description here

由于只授予了pod的操作权限,当访问service资源时被拒绝:

 kubectl get svc --as system:serviceaccount:default:solinx

 Error from server (Forbidden): services is forbidden: User "system:serviceaccount:default:solinx" cannot list services in the namespace "default"

enter image description here

该角色为普通角色Role,当访问集群资源NameSpace时同样被拒绝:

 kubectl get ns --as system:serviceaccount:default:solinx

 Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount:default:solinx" cannot list namespaces at the cluster scope

enter image description here

  此时把角色改为集群角色:ClusterRole,并重新绑定服务账户:
enter image description here

  此时该服务账户已经具备集群角色权限,访问集群资源:NameSpace

 kubectl get ns --as system:serviceaccount:default:solinx

enter image description here

参考资料: https://kubernetes.io/docs/reference/access-authn-authz/rbac/