使用Helm将ASP.NET Core应用程序部署到Kubernetes容器集群

在《容器化单页面应用中RESTful API的访问》以及《容器化单页面应用中Nginx反向代理与Kubernetes部署》两篇文章中，我介绍了一套容器化ASP.NET Core应用程序的方案，并对于Nginx反向代理的使用进行了介绍。在《使用Rancher在Microsoft Azure上搭建Kubernetes集群》一文中，我介绍了一种基于Rancher搭建Kubernetes容器集群的方案，大家会发现，使用Rancher来部署和管理Kubernetes容器集群非常方便。今天，我将结合这三篇文章的内容，将案例程序name-list封装成Helm Chart，然后部署到Kubernetes容器集群中。

Helm的安装

要使用Helm来部署我们的案例程序，首先就是要安装Helm。Helm安装分两个步骤，先安装客户端，然后安装它的服务端部件Tiller。Tiller是运行在Kubernetes集群中的，有关Helm和Tiller的基础知识和基本概念，请参考官方文档，本文不会做过多介绍。

安装Helm客户端非常简单，官网上提供了多种安装方式。最简单的方式就是直接到Helm的Github repo，找到所需的版本下载后解压，然后将路径添加到系统的PATH环境变量，即可使用Helm客户端。之后，我们可以使用下面的命令验证客户端是否安装成功：

$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller

注意：在使用该命令之前，请先确保已经成功部署了Kubernetes，并且~/.kube/config文件中设置了正确的context。有关Kubernetes的部署，请参考《使用Rancher在Microsoft Azure上搭建Kubernetes集群》一文。

上面的命令用于检查Helm的版本，包括客户端版本和服务端Tiller的版本。由于我们还没有安装服务端，因此，提示“Error: could not find tiller”的错误信息。

使用下面的命令创建一个名为tiller的Service Account，然后将其赋予cluster-admin的角色，最后使用该Service Account安装Tiller：

$ kubectl -n kube-system create serviceaccount tiller
 
$ kubectl create clusterrolebinding tiller 
  --clusterrole=cluster-admin 
  --serviceaccount=kube-system:tiller
 
$ helm init --service-account tiller

待安装成功后，再次运行helm version，可以看到类似如下的信息，表示Helm以及Tiller安装成功。

$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}

为案例程序创建Helm Chart

Helm中有几个比较关键的概念，Helm Chart指的是一套应用程序部署的定义，比如一次Helm部署包含哪些Kubernetes的deployment以及service等等；Helm Release则表示一次应用程序的部署。在之前介绍name-list案例的文章中，我使用了docker-compose来组织各个所需的服务及其之间的依赖关系，并使用docker-compose命令行工具来实现整个应用程序的编译、容器化以及容器运行等任务。现在，我们仍然依赖这个docker-compose.yml文件来创建Helm Chart。

首先，到Kubernetes Kompose官方Github repo下载Kompose命令行工具，然后，在docker-compose.yml文件所在的目录中，运行：

$ kompose convert -c -o helm

此时，会在docker-compose.yml文件所在目录中，出现一个helm的子目录，然后，在该目录中，会包含Helm Chart相关的目录和文件。以name-list案例为例：

• helm：包含了两个文件和一个子目录：templates
• Chart.yaml：Helm Chart的定义文件，里面可以指定Helm Chart的名称、描述等
• README.md：说明文件，可以无视
• templates目录：该目录下包含了应用程序部署的deployment、service以及ingress的描述文件，也是Helm Chart的主要部分

此外，helm目录下还可以有values.yaml文件，用来定义一些用户可以修改的变量，例如，可以在values.yaml中，使用“serviceTcpPort: 8080”来指定服务的端口号为8080，然后，在template中使用{{ .Values.serviceTcpPort }}来表示需要从values.yaml中读取服务的端口号。在name-list案例中，没有用到values.yaml。

默认情况下，Kompose会将基本的template文件都创建好，然后，还需要根据应用程序的情况进行一些手工调整，比如，将Helm Release的名称作为每个生成的deployment和service的名称前缀就是一个不错的习惯，这就需要手工地对生成的template文件进行调整。比如，在name-list案例中，前端应用的service定义如下：

apiVersion: v1
kind: Service
metadata:
  annotations:
    kompose.cmd: kompose convert -o k8s.deployment.yaml
    kompose.version: 1.18.0 (06a2e56)
  creationTimestamp: null
  labels:
    io.kompose.service: {{ .Release.Name }}-namelist-client
  name: {{ .Release.Name }}-namelist-client
spec:
  ports:
  - name: "80"
    port: 80
    targetPort: 80
  selector:
    io.kompose.service: {{ .Release.Name }}-namelist-client
status:
  loadBalancer: {}

在高亮的几行，使用{{ .Release.Name }}来表示当前Helm Release的名称。因此，对于name-list的前端应用而言，在部署到Kubernetes之后，该前端服务的名称就是{{ .Release.Name }}-namelist-client，虽然在Kubernetes集群中，可以通过这个前缀来区分不同的Helm Release，但对于Nginx来说，它将无法找到这个前端服务，因为目前我们的Nginx配置如下：

events {
    worker_connections 1024;
}

http {

    server {
      listen        80;
      server_name   localhost;

      resolver 127.0.0.11 ipv6=off;
 
      include  /etc/nginx/mime.types;

      location / {
        proxy_pass http://namelistcli/;
      }

      location ~ ^/name-service/(.*)$ {
       rewrite ^ $request_uri;
       rewrite ^/name-service/(.*)$ $1 break;
       return 400;
       proxy_pass http://namelistsvc/$1;
      }
    }

    upstream namelistsvc {
     server namelist-service:5000;
    }

    upstream namelistcli {
     server namelist-client:80;
    }
}

可以看到，在Nginx配置中，前端服务的主机地址被写死成namelist-client了，而在我们的Helm Release中，应该是{{ .Release.Name }}-namelist-client。下面我们来解决这个问题。

dockerize的使用

解决Nginx中主机名称的问题，可以使用dockerize工具，它的官方Github repo是：https://github.com/jwilder/dockerize。dockerize可以在容器启动的时候，实现模板替换，将容器环境变量的值替换到指定模板文件中。比如，对于Nginx的配置而言，我们可以首先定义一个nginx.conf.tmpl的文件，在其中使用一些模板变量，然后使用dockerize，使其在容器启动时，使用环境变量来替换这些模板变量，于是，容器运行时所使用的nginx.conf文件就是dockerize最终生成的文件。

仍然以name-list为例，首先，定义一个nginx.conf.tmpl文件，内容如下：

server {
  listen        80;
  server_name   localhost;

  include  /etc/nginx/mime.types;

  location / {
    proxy_pass http://namelistcli/;
  }

  location ~ ^/name-service/(.*)$ {
    rewrite ^ $request_uri;
    rewrite ^/name-service/(.*)$ $1 break;
    return 400;
    proxy_pass http://namelistsvc/$1;
  }
}

upstream namelistsvc {
  server {{ .Env.RELEASE_NAME }}-namelist-service:5000;
}

upstream namelistcli {
  server {{ .Env.RELEASE_NAME }}-namelist-client:80;
}

其中{{ .Env.RELEASE_NAME }}表示使用RELEASE_NAME环境变量来替换当前位置的值。然后，修改Nginx所在容器的Dockerfile，内容如下：

FROM ubuntu:14.04
ENV DOCKERIZE_VERSION=v0.6.1
# Install Nginx.
RUN echo "deb http://ppa.launchpad.net/nginx/stable/ubuntu trusty main" > /etc/apt/sources.list.d/nginx-stable-trusty.list
RUN echo "deb-src http://ppa.launchpad.net/nginx/stable/ubuntu trusty main" >> /etc/apt/sources.list.d/nginx-stable-trusty.list
# RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys C300EE8C
RUN apt-get update
RUN apt-get install -y wget nginx

RUN echo "daemon off;" >> /etc/nginx/nginx.conf

RUN wget https://github.com/jwilder/dockerize/releases/download/$DOCKERIZE_VERSION/dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz
RUN tar -C /usr/local/bin -xvzf dockerize-linux-amd64-$DOCKERIZE_VERSION.tar.gz

ADD nginx.conf.tmpl /etc/nginx/sites-available/default.tmpl

EXPOSE 80

CMD dockerize -template /etc/nginx/sites-available/default.tmpl:/etc/nginx/sites-available/default -stdout /var/log/nginx/access.log -stderr /var/log/nginx/error.log nginx

这个Dockerfile的关键部分就是最后一行，它会调用dockerize命令，将之前编入容器的/etc/nginx/sites-available/default.tmpl文件替换并输出为/etc/nginx/sites-available/default文件。

再看看Nginx的deployment.yaml中，是如何设置这个RELEASE_NAME环境变量的：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose convert -c -o helm
    kompose.version: 1.18.0 (06a2e56)
  creationTimestamp: null
  labels:
    io.kompose.service: {{ .Release.Name }}-namelist-nginx
  name: {{ .Release.Name }}-namelist-nginx
spec:
  replicas: 1
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        io.kompose.service: {{ .Release.Name }}-namelist-nginx
    spec:
      containers:
      - image: daxnet/namelist-nginx
        name: namelist-nginx
        env:
        - name: RELEASE_NAME
          value: {{ .Release.Name | quote }}
        ports:
        - containerPort: 80
        resources: {}
      restartPolicy: Always
status: {}

由此可见，Helm Release的名称，也就是{{ .Release.Name }}的值，被作为环境变量RELEASE_NAME的值，注入到daxnet/namelist-nginx容器中。

部署与运行

在Chart.yaml所在目录，运行下面的命令，将name-list部署到Kubernetes集群，我们将这次部署命名为myapp：

$ helm upgrade --install myapp .

运行结果如下：

使用kubectl get pods命令查看所有pod是否正常运行：

使用kubectl exec查看Nginx是否正确配置：

使用helm list命令，查看我们的Helm Releases：

在Microsoft Azure中，找到由Rancher创建的Kubernetes节点虚机，确保80端口已在安全组中打开，然后访问该虚拟机的IP地址，可以看到，我们的name-list案例已经成功运行在Kubernetes集群中：

总结

本文主要介绍了使用Helm将ASP.NET Core应用程序部署到Kubernetes容器集群的方法，并对其中遇到的问题进行了概括性描述。事实上，本文所使用的name-list案例是一套集前端、后端以及Nginx于一体的完整案例，代码完全免费开源，地址是：https://github.com/daxnet/name-list。有需要的读者欢迎查阅。