Janakiram MSV | 伪架构师

在 Kubernetes 和 Istio 环境下进行蓝绿部署

Sat, 20 Oct 2018 00:46:47 +0800

原文：Tutorial: Blue/Green Deployments with Kubernetes and Istio

作为一个服务网格系统，Istio 为服务间通信提供稳定性、透明性和安全性方面的保障。不论集群内外的服务，只要其访问目标是网格内的服务，就都会被 Istio 所拦截并进行处理。

Istio 有很多功能，例如服务间通信的加密、自动的指标记录、访问控制策略、频率限制以及配额等，这里我们仅着眼于最常用的流量管理能力。

Istio 让 DevOps 团队有能力为内部服务创建智能的路由规则。断路器、超时和重试之类的服务级属性非常容易配置，配置包含蓝绿部署及金丝雀发布的过程也很轻松。

本文教程用于帮助读者理解配置 Kubernetes + Istio 环境下的蓝绿部署过程。无需很多知识背景，只要理解一些在 Kubernetes 中部署 Pod 和服务的基础概念就好。我们会在 Minikube 和 Istio 中完成示例。

教程包含四个步骤：安装 Minikube、安装 Istio 并进行验证、安装一个应用的两个版本，最后配置服务的蓝绿部署。我们会使用两个简单的构建好了的镜像，分别作为蓝（v1）、绿（v2）两个版本。

步骤 1：安装 Minikube

为了降低依赖，我们会使用 Minikube 作为测试平台。因为需要自定义配置，所以要删除已经存在的配置，并使用额外参数重新启动集群：

minikube start --memory=8192 --cpus=4 --kubernetes-version=v1.10.0 \
--extra-config=controller-manager.cluster-signing-cert-file="/var/lib/localkube/certs/ca.crt" \
--extra-config=controller-manager.cluster-signing-key-file="/var/lib/localkube/certs/ca.key" \
--vm-driver=virtualbox

要在 Minikube 上运行 Istio，需要至少 8G 内存和 4 个 CPU 核心。等集群启动：

步骤 2：安装 Istio

Kubernetes 集群成功启动之后，就可以安装 Istio 了。用下面的步骤完成：

curl -L https://git.io/getLatestIstio | sh -

在运行上述命令的目录中会发现一个 istio-1.0.2 目录，可以把 istio-1.0.2/bin 目录加入 PATH 变量，方便后面的命令执行过程。

由于我们在 Minikube 环境下运行的 Istio，所以我们要在下一步进行之前，要把 Ingress Gateway 服务从 LoadBalancer 改为 NodePort。

打开文件 istio-1.0.2/install/kubernetes/istio-demo.yaml，查找并替换：

Istio 中包含了很多 CRD，可以帮用户来进行虚拟服务、规则、网关以及其他对象的管理。在部署服务网格之前首先要部署一下这些 CRD：

kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

最后，在 Kubernetes 中安装 Istio：

kubectl apply -f install/kubernetes/istio-demo.yaml

上面的步骤会创建新的命名空间（istio-system）：

会看到这里还有很多服务：

稍候片刻，会看到很多 Pod：

Istio 如果成功部署，所有这些 Pod 只能是 Running 或者 Completed 状态。

下一步就要准备用于蓝绿部署的应用了。

步骤 3：安装同一应用的两个版本

为了展示应用的不同版本，我构建了基于 Nginx 的简单镜像 - janakiramm/myapp:v1 和 janakiramm/myapp:v2。部署之后，会展示蓝色或者绿色的背景。

apiVersion: v1
kind: Service
metadata:
  name: myapp
  labels:
    app: myapp
spec:
  type: ClusterIP
  ports:
  - port: 80
    name: http
  selector:
    app: myapp
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        version: v1
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: myapp-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: myapp
        version: v2
    spec:
      containers:
      - name: myapp
        image: janakiramm/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

也可以在 Github 上看到这些代码。

接着就要创建 YAML 文件来定义 v1 和 v2 服务了。注意 Pod 标签的差异代表了不同的版本 —— app 保持一致，但 version 是不同的。这样一来，Istio 就会认为这是同一应用的不同版本。

而服务中的选择器定义只针对 app 标签进行设置，也就是说不同版本的 Pod 都会参与这一服务。

用 kubectl 创建 Service 和 Deployment。注意这个简单的应用对 Istio 一无所知。Istio 和应用的唯一可见的连接就是标签：

kubectl apply -f myapp.yaml

配置 Istio 路由之前，首先检查一下应用的版本。可以使用端口转发的方式来访问 Pod。

要访问应用的 v1 版本，可以运行下面的命令，然后访问 localhost:8080，验证完成之后，按 CTRL+C 结束端口映射命令。

kubectl port-forward deployment/myapp-v1 8080:80

要访问应用的 v2 版本，可以运行下面的命令，然后访问 localhost:8081，验证完成之后，按 CTRL+C 结束端口映射命令。

kubectl port-forward deployment/myapp-v2 8081:80

步骤 4：配置蓝绿部署

我们的目标是在不停机的情况下，让流量选择性的进入某一版本。为了完成这一目的，就需要告知 Istio 根据权重进行路由。完成这一任务需要三个对象：

Gateway

Istio Gateway 描述了网格边缘的负载均衡组件，用于 HTTP/TCP 连接的接收和发出。定义中包含一组要开放的端口、使用的协议、负载均衡的 SNI 等。下面的定义中我们将 Gateway 指向 Istio 部署过程中建立的缺省的 Ingress Gategeway。

用 Kubernetes 的方式创建 Gateway 对象：

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: app-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

目标规则

Istio DestinationRule 定义了在一个服务成为路由目标之后的行为。注意一下这一规则中是如何通过标签来对 Kubernetes 的原生 Deployment 进行区分的：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: myapp
spec:
  host: myapp
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

虚拟服务

虚拟服务中定义了一组流量路由规则，在其中的 host 被访问时就会触发。每个路由规则中都定义了对某一协议进行匹配的标准。如果流量匹配这一标准，那么就发送给对应的区分了版本的目标服务。

下面的定义中我们定义两个版本的服务权重都是 50，也就是说流量会在版本间进行平均分配：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - "*"
  gateways:
  - app-gateway
  http:
    - route:
      - destination:
          host: myapp
          subset: v1
        weight: 50
      - destination:
          host: myapp
          subset: v2
        weight: 50

所有这些都可以定义在同一个 YAML 文件中，然后用 kubectl 提交给集群，同样可以在 Gtihub 中获取这一文件。

kubectl apply -f app-gateway.yaml

接下来就可以尝试访问这一服务了。因为我们使用的是 NodePort 模式的服务，所以就需要首先判断一下 Ingress Gateway 所在的端口。

运行下面的命令来访问 MiniKube 的 Ingress 端口。

$ export INGRESS_HOST=$(minikube ip)

$ export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

从浏览器访问这个 URL，会看到流量被均等的在蓝色和绿色版本之间进行分配。

也可以在终端里面查看命令结果。运行下面的命令会看到 V1 和 V2 的响应：

while : ;do export GREP_COLOR='1;33';curl -s  192.168.99.100:31380 \
 |  grep --color=always "V1" ; export GREP_COLOR='1;36';\
 curl -s  192.168.99.100:31380 \
 | grep --color=always "vNext" ; sleep 1; done

上面的命令会循环运行，我们可以返回编辑 gateway.yaml，修改其中的权重分配。把 V1 的权重设置为 0，V2 的权重设置为 100.

把新的定义提交到 Istio。

$ istioctl replace -f app-gateway.yaml

更新权重之后，V2 的响应比例会提升到 100%。这一结果会体现在输出之中：

可以继续对权重进行修改，查看路由的动态变化过程。

流量管理只是 Istio 的一个功能，后续文章中尝试更多其他特性。

Kubernetes 如何走向统一调度之路

Tue, 18 Sep 2018 22:04:06 +0800

原文：How Kubernetes Is Transforming into a Universal Scheduler

作者：Janakiram MSV

计算机科学里，调度指的是一种能够为作业分配满足其执行所需资源的方法。IBM 在 60 年代的 S/360 中首次提出这一概念，可以说是年代久远了。

对所有存在资源需求的作业来说，调度都是至关重要的。在操作系统的上下文中，作业可能是个简单的程序，资源可能是 CPU 核心。类似的，操作系统中的调度器可能就只是一些用于操作线程或信号的代码。

分布式计算将调度器的疆土从内部的进程和线程扩展到了物理机集群之中。90 年代中，Corba、DCOM 以及 J2EE 等分布式平台应运而生，在应用服务器集群内发展了各自的调度组件。

再后来，出现了 Amazon EC2、Azure Fabric 以及 OpenStack Nova 这样的 IaaS 平台，这些平台的控制平面完成了对运行于物理机基础之上的虚拟机的调度工作。根据资源需求将虚拟机实例安置在合适的物理机上。

基于 Apache Hadoop 和 MapReduce 算法的大数据工作负载对调度算法非常依赖。Hadoop 的文件系统 HDFS 就用于保障集群上的节点能够访问到数据集。这一架构聚焦于资源的的稳定性和可用性保障。

Cloud Foundry 和 Heroku 这样的 PaaS 实现中包含了设计精密的调度逻辑，用来为服务提供隔离的环境。每个服务都被打包，部署在虚拟或物理服务器的执行环境之中。

横空出世的容器，强迫业界重新审视资源调度器的设计。新一代调度器的设计理念更加重视简单性和伸缩性。传统应用服务器面对的是少量服务器，而容器管理平台要管理的容器工作节点数量可能从几台到几千台。

Kubernetes 和 Mesosphere 是当代资源调度器的代表。它们的设计对底层基础设施进行了抽象，用透明的方式为用户提供调度服务。

Kubernetes 中的调度

Kubernetes 平台中，调度器是一个关键组件。它在主节点上运行，和 API Server 以及 Controller 紧密合作。调度器的核心任务就是对 Pod 和 Node 进行撮合。可以在 Kubernetes architecture 一文中透彻的了解其架构。

调度器会在多个方面对可用资源进行评估，从而为 Pod 分配合适的节点。另外还可以通过对节点亲和性的设置，为 Pod 分配指定特性的节点。例如一个一个高 IO 的数据库 Pod 可能需要调度到配有 SSD 存储的节点上。还有可能为了降低延迟，将一系列的 Pod 调度到同一节点上，这一操作称为 Pod 亲和性。Kubernetes 还支持自定义调度器，完全由第三方实现分配逻辑。

Kubernetes 调度器的最大亮点就是其简单性。前面描述的多数策略都能很轻松的实现。只要通过一点注解和标签，就能完成 Pod 和节点之间的亲和或排斥的定义。通过对 Pod 和节点的键值对设置就能够实现成熟的调度逻辑。

超越 Pod 和节点的 Kubernetes 调度器

Kubernetes 可能是目前最好的资源调度器之一。兼顾简单和扩展能力的调度器让用户能够解决很多传统分布式系统中的调度问题。

在高度分布的环境中，Kubernetes 正在成为首选的作业调度和管理工具。这些作业包括在物理服务器上部署虚拟机、在边缘设备上运行容器，甚至还具有将控制平面扩展到 Serverless 环境这样的其他调度器上的能力。

KuberVirt 就是一个 Kubernetes 上的虚拟机管理插件，它让用户能够像 Pod 一样在 Kubernetes 或 OpenShift 集群上运行虚拟机。这一系统用 CRD 的形式来进行虚拟机的设置，完成了对 Kubernetes 的扩展。KubeVirt 虚拟机运行在普通的 Kubernetes Pod 之内，从而具有了访问标准 Pod 网络和存储的能力，并且可以使用标准的 kubectl 或者类似的 Kubernetes 工具来进行管理。

来自 Mirantis 的 Virtlet 项目让虚拟机可以在 Kubernetes 集群中像普通 Pod 一样运行。运维人员可以用 kubectl 命令管理虚拟机，并且将虚拟机以一等公民的身份纳入集群网络。有了 Virtlet 就可以构建高级的 Kubernetes 对象，例如 Deployment、Statefulset 或者 DaemonSet。

微软的 Virtual Kubelet 是最有趣的一个调度器。Virtual Kubelet 是一个 Agent，运行在注册为 Kubernetes 集群节点的外部环境之中。这个 Agent 会通过 Kubernetes API 创建节点资源。通过对污染和隔离功能的使用，会通过本地 API 来进行外部环境中的 Pod 调度。

Virtual Kubelet 可以在 Azure Container Instance、Azure IoT Edge 以及 AWS Fargate 上运行。

另外，我还写过其他文章，介绍了 Virtual Kubelet 的架构和部署指南，可供读者参考。

更进一步——自定义调度器和 CRD

上面讨论的例子只是冰山一角。Kubernetes 正在成为当代基础设施的基础，正在迈入传统业务应用领域——例如 ERP 和 CRM。

应用提供商们将会越来越重的依赖 Kubernetes 的两个功能：自定义调度器和 CRD。

正如前文所说，Kubernetes 的自定义调度器让开发者可以实现自己的调度逻辑。Pod 的声明中就可以通知控制面跳过缺省调度器，转而采用自定义调度。这一机制能够保障集群内的 Pod 得到正确安置。

Portworx 是一个云原生生存储公司，它使用自定义调度器来创建 STORK（Kubernetes 存储编排运行时：STorage Orchestrator Runtime for Kubernetes）。从而保障它的 Stateful Pod 只会在安装了 Portworx 驱动和存储的节点上运行。这一功能对于运行其上的数据库负载的可用性保障很有帮助。

Kubernetes 中的 CRD 为自定义对象提供了简单且强大的生命周期支持。自定义资源是一种对象，对 Kubernetes API 进行了扩展，开发人员可以利用这一机制将自己的 API 引入 Kubernetes。CRD 文件声明了自定义对象的定义，让 API Server 能够处理整个生命周期。在 Kubernetes 中部署 CRD，就是让 Kubernetes API Server 开始支持某种自定义资源。

CRD 创建之后，运维人员可以使用 kubectl 或者第三方工具来进行管理，这一过程和 Pod 等内置对象并无二致。ISV 可以利用 CRD 的方式将自己的软件进行打包和部署。