使用kubectl部署应用

部署一个简单的Demo网站

我们可以通过创建kubernetes Deployment对象来运行应用程序。我们需要编写一个yaml文件来定义Deployment对象。

1. 编写Deployment对象的配置文件

   apiVersion: apps/v1 #API对象版本，可通过“kubectl api-versions”命令查看
   kind: Deployment #资源类型，区分大小写，可通过“kubectl api-resources”命令查看，这里使用Deployment对象
   metadata: #标准的元数据
     name: demo-deployment  #当前Deployment对象名称，同一个命名空间下必须唯一
   spec: #部署规范（目标），Deployment控制器会根据此模板调整当前Pod到最终的期望状态
     replicas: 5  # Pod数量，这里指运行5个Pod
     selector: #选择器，其定义了Deployment控制器如何找到要管理的Pod
       matchLabels:  #匹配标签
         app: demo   #待匹配的标签键值对
     template:   # Pod模板定义
       metadata: #标准的元数据
         labels: #Pod标签
           app: demo #定义Pod标签，由键值对组成
       spec: #Pod规范
         containers: #容器列表，Pod中至少有一个容器
         - name: demo  #容器名称
           image: microsoft/dotnet-samples:aspnetapp #镜像地址
           ports:  #端口列表
           - containerPort: 80 #设置容器端口
   

   • 如上面的配置所示，部署名称为“demo-deployment”。
   • 此部署对象将创建5个复制的Pod，由replicas字段决定。
   • selector字段定义了Deployment控制器如何找到要管理的Pod，所以标签的键值对一定不能出错。
   • template字段定义了Pod模板，其子字段labels定义了Pod的标签，spec字段定义了容器。
   • 通常推荐使用“kubectl apply”命令代替“kubectl create”，因为“kubectl apply”既能创建k8s资源，也能对现象资源进行更新。
     如上所示，定义了一个简单的部署示例。它将创建一个RS对象，以利用复制控制器创建5个Pod来运行“dotnet-samples”

2. 使用“kubectl create” 执行资源创建

   kubectl create -f deployment-demo.yaml
   

   

   执行创建部署之后，我们可以通过命令“kubectl get Deployment demo-deployment”来检查部署对象是否已经创建、部署是否已经完成。
   

   • READY：代表是否已就绪，左侧数字表示当前已运行的副本数，右侧表示所需的副本数。

   • UP-TO-DATE：表示已更新实现预期状态的副本数。

   • AVAILABLE：表示用户可以使用的应用程序副本数。

   • AGE：表示应用已运行的时间。

     通常可以运行以下命令来查看副本集（ReplicaSet）对象
     

因此，我们创建Deployment对象的过程实际上就是生成对应的副本集对象（ReplicaSet）并完成Pod副本的创建过程。

应用伸缩和回滚

所谓伸缩，是指在线实时增加或减少Pod的副本数量。虽然我们可以通过修改Deployment的YAML文件的“replicas”字段来进行伸缩，但是不够方便，而且无法做到自动伸缩。

• 使用“kubectl scale”命令来伸缩应用
  

• 使用“kubectl autoscale”命令来自动伸缩应用
  

• 使用“kubectl run”命令快速运行应用
  
  

• 使用“kubectl set”命令更新应用
  
  
  

• 使用“kubectl rollout”命令回滚应用
  
  
  

通过Service访问应用

• 通过Pod IP 访问应用
  
  通过Pod IP访问应用有个缺点就是当Pod被删除，那么Pod重建时的ip会改变。而且如果节点实在不同的云服务商上也是不能访问的，例如：master节点在腾讯云服务器上，而node节点在阿里云服务器上，那么master节点无法访问阿里云服务器上节点ip。
  

• 通过ClusterIP Service在集群内部访问
  为了让应用能够稳定地输出，service应运而生。
  Service为k8s中是一个抽象概念，定义了一组逻辑上地Pod和一个访问它们地策略（通常称之为微服务）。Service通过标签选择器来绑定一组Pod和EndPoints(端点)对象，当Pod的IP发生变化时，EndPoints也随之变化。当Service接到请求时，就能通过EndPoints找到请求转发的目标Pod地址。也就是说，通常情况下，Service定义了集群IP和端口，EndPoints则维护了一组Pod IP和端口。
  
  通过Service，我们便可以在集群内部的所有节点访问。

• 通过NodePort Service在外部访问集群应用
  NodePort服务类型允许在每个节点的IP（任意节点IP）上使用静态端口公开服务，我们可以在集群之外通过请求<NodeIP>:<NodePort>来访问服务。
  YAML定义如下：

  kind: Service #资源类型
  apiVersion: v1
  metadata: #标准元数据
    name: nodeport-service  #服务名称
  spec:  #规范定义
    type: NodePort #服务类型，这里是节点端口
    ports:  #端口列表
      - port: 80  #Pod端口
        nodePort: 31001 #节点端口，注意默认的端口范围为“30000-32767”，注意不要冲突
    selector: #标签选择器
      app: demo
  

  
  这样，我们可以在集群通过访问任意节点的公网ip来访问k8s上的服务。
  虽然，我们可以在外部访问集群中的应用，但是也可以看到该方案由不少不足之处：

  1. 每个端口仅能支持一个服务。不能冲突
  2. 端口范围必须为“30000-32767”，非常不友好
  3. 如果节点IP发生变化，服务也将无法访问

• 使用Ingress负载分发微服务
  NodePort Service存在太多缺陷，不适合生产环境，LoadBlancer Service则不太灵活，例如针对微服务架构，那么不同服务是否需要多个负载均衡服务呢？
  Ingress将集群外部的HTTP和HTTPS路由暴露给集群中的Service，相当于集群的入口，而入口规则则由Ingress定义的规则来控制。
  具体内容，大家可以参考下面这篇博客：k8s部署ingress-nginx的方法步骤

Docker与持续集成和持续部署

一般情况下，Docker的CI、CD流程如下图所示：

相关步骤说明如下：

• 开发者提交代码
  开发者提交代码时作为流程的开始，这里代码的版本管理推荐使用Git。

• 触发镜像构建
  可以使用Git仓库的WebHook来触发，也可以利用相关工具进行代码监控。当发现存在变更时，自动拉取目标分支代码镜像构建（核心命令为“docker build”）

• 构建镜像上传至私有仓库
  镜像构建完成后，需要将镜像推送到相关私有的镜像仓库，建议在构建时根据代码分支来写入相应的标签前缀，这样就可以根据标签前缀来选择对应环境执行自动部署了，比如开发环境、测试环境和生产环境的自动部署，这样只要控制好分支权限即可。这一步，需要使用“docker login”命令来登录私有仓库，使用“docker push”命令来推送镜像。

• 镜像下载至执行机器
  镜像推送到私有仓库之后，可以使用CD工具来自动拉取镜像以执行部署，也可以利用云端k8s集群的镜像触发器来触发部署更新。镜像拉取的核心命令为“docker pull”。

• 镜像运行
  镜像拉取完成之后，可以简单粗暴地使用“docker run”命令让镜像运行起来，但是一般情况下推荐将镜像运行在k8s集群中。