Kubernetes之蓝绿部署

【编者的话】毋庸置疑，Kubernetes目前已成为业内最炙手可热的容器编排框架。本文主要讲讲怎么用Kubernetes进行蓝绿部署以及如何自动化实现蓝绿部署。更多Kubernetes知识请关注DockOne其他文章。

对于那些有更多热情想投入其中的朋友，我已经在GitHub上上传了一个教程和一些示例清单。请访问https://github.com/IanLewis/ku … orial。

Kubernetes有一个非常棒的内置功能即部署（Deployments）。当您将应用程序更新到一个新版本时，部署功能能够帮您对容器进行滚动更新。滚动更新是更新应用程序的一种很好的方法，因为您的应用程序在更新期间使用的资源数量，基本和不更新时所使用的资源相同，而且滚动更新过程中对性能和可用性影响最小。

尽管如此，仍然有许多老式的应用程序在滚动更新中不能很好地运行。一些应用程序只需要部署一个新版本，并需要立即切到这个版本。因此，我们需要执行蓝/绿部署。在进行蓝/绿部署时，应用程序的一个新副本（绿）将与现有版本（蓝）一起部署。然后更新应用程序的入口/路由器以切换到新版本（绿）。然后，您需要等待旧（蓝）版本来完成所有发送给它的请求，但是大多数情况下，应用程序的流量将一次更改为新版本。

Kubernetes不支持内置的蓝/绿部署。目前最好的方式是创建新的部署，然后更新应用程序的服务以指向新的部署。接下来让我们来看看这是啥意思。

蓝部署

Kubernetes部署指定一个应用程序的一组实例。在幕后，它创建一个副本，该副本负责保持指定数量的实例运行。

我们可以通过将以下yaml保存到blue.yaml文件中来创建我们的“蓝色”部署。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-1.10
spec:
replicas: 3
template:
metadata:
  labels:
    name: nginx
    version: "1.10"
spec:
  containers: 
    - name: nginx
      image: nginx:1.10
      ports:
        - name: http
          containerPort: 80

然后可以使用kubectl命令创建部署。

$ kubectl apply -f blue.yaml

一旦我们进行了部署，我们可以通过创建一个服务来提供访问部署实例的方法。服务与部署分离，这意味着您不必在部署时明确指向服务。您需要做的是指定一个标签选择器，它的主要作用是列出构成服务的pods。当你使用部署时，通常会将其设置为与部署的pods相匹配。

在这种情况下，我们有两个标签，name=nginx和version=1.10。我们将这些设置为下面的服务的标签选择器。将下面的内容保存到service.yaml。

apiVersion: v1
kind: Service
metadata: 
name: nginx
labels: 
name: nginx
spec:
ports:
- name: http
  port: 80
  targetPort: 80
selector: 
name: nginx
version: "1.10"
type: LoadBalancer

创建服务将创建一个可在集群外访问的负载均衡器。

$ kubectl apply -f service.yaml

现在我们看看已经部署的服务，如下图。

您可以测试该服务是否可访问并获取该版本。

$ EXTERNAL_IP = $（ kubectl get svc nginx -o jsonpath = “{.status.loadBalancer.ingress [*]。ip}” ） 
$ curl -s http：// $ EXTERNAL_IP / version | grep nginx 

创建绿部署

对于“绿”部署，我们将部署“蓝”部署并行的新部署。如果以下是

green.yaml……
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-1.11
spec:
replicas: 3
template:
metadata:
  labels:
    name: nginx
    version: "1.11"
spec:
  containers: 
    - name: nginx
      image: nginx:1.11
      ports:
        - name: http
          containerPort: 80

……我可以像这样创建新的部署。

$ kubectl apply -f green.yaml

现在我有两个部署，但服务仍然指向“蓝”部署。接下来我们要怎么做呢？

更新应用程序

要切换到“绿”部署，我们将更新服务的选择器。编辑service.yaml并将选择器版本更改为“1.11”。这将使它与“绿”部署中的pods匹配。

apiVersion: v1
kind: Service
metadata: 
name: nginx
labels: 
name: nginx
spec:
ports:
- name: http
  port: 80
  targetPort: 80
selector: 
name: nginx
version: "1.11"
type: LoadBalancer

执行下面的命令将更新现有的nginx服务。

$ kubectl apply -f service.yaml

现在我们再看看已经部署的，如下图。

更新服务的选择器将立即被应用，因此您应该看到新版本的nginx正在提供服务。

$ EXTERNAL_IP = $（ kubectl get svc nginx -o jsonpath = “{.status.loadBalancer.ingress [*]。ip}” ） 
$ curl -s http：// $ EXTERNAL_IP / version | grep nginx

自动化

您可以通过一些脚本来自动化跑您的蓝/绿部署。以下脚本将使用服务的名称，要部署的版本以及绿色部署的yaml文件的路径，并使用kubectl运行完整的蓝/绿部署，以从API中输出原始JSON，并使用jq进行解析。通过status.conditions在更新服务定义之前检查部署对象，等待绿部署准备就绪。

脚本为简单起见做出了一些假设，例如期望部署的名称为形式 – 并且存在用于选择器的name和version标签。kubectl是超级灵活的，你可以用它写你自己需要的任何东东。

#!/bin/bash
bg-deploy.sh <servicename> <version> <green-deployment.yaml>

Deployment name should be <service>-<version>

DEPLOYMENTNAME=$1-$2
SERVICE=$1
VERSION=$2
DEPLOYMENTFILE=$3

kubectl apply -f $DEPLOYMENTFILE
Wait until the Deployment is ready by checking the MinimumReplicasAvailable condition.

READY=$(kubectl get deploy $DEPLOYMENTNAME -o json | jq '.status.conditions[] | select(.reason == "MinimumReplicasAvailable") | .status' | tr -d '"')
while [[ "$READY" != "True" ]]; do
READY=$(kubectl get deploy $DEPLOYMENTNAME -o json | jq '.status.conditions[] | select(.reason == "MinimumReplicasAvailable") | .status' | tr -d '"')
sleep 5
done
Update the service selector with the new version

kubectl patch svc $SERVICE -p "{\"spec\":{\"selector\": {\"name\": \"${SERVICE}\", \"version\":\"${VERSION}\"\}\}\}"
echo "Done."

最后，真心希望Kubernetes可以原生支持蓝/绿部署，但这美好时刻来临之前，您可以通过上面的方式来实现自动化。如需要联系那些关心Kubernetes应用程序部署的童鞋，请查看Kubernetes Slack中的#sig-apps频道 。