将Coolstore微服务引入服务网格：第1部分 - 探索自动注入

随着业界走向云端原生微服务的幻灭之谷，我们最终明白分布式架构会带来更多的复杂性（奇怪吧？），服务网格可以帮助软化着陆，将一些复杂性从我们的应用程序中移出，并将它放置在应用程序的操作层中。

在红帽，我们致力于（并积极参与）上游Istio项目（服务网格概念的最新实现项目），并努力将其集成到Kubernetes（一个开源的容器集群管理系统）和Red Hat OpenShift（红帽公司的云计算服务平台）中，以将服务网格的好处带给我们的客户和涉及的更广泛的社区。如果你想参与Istio，请参阅learn.Openshift.com上的服务网格教程。如果您想安装它，请按照Istio Kubernetes快速入门说明将其安装到Red Hat OpenShift 3.7或更高版本（如果您想使用自动注入，则将其安装到3.9版本）。

现有的应用程序作为服务网格

您可能在去年看到了在红帽生态系统中出现的新的Coolstore微服务演示；这是一个极好的工具，可以展示Red Hat为现代应用程序带来的独特价值，并展示了使用Red Hat栈进行现代应用程序开发和集成的关键用例。如果我们可以使用Istio和Red Hat OpenShift将现有的应用(如Coolstore)部署为服务网格，岂不是很棒？毕竟，Istio的一个目标就是透明地为现有的应用程序带来新的价值，而不让他们知道。它可以减少或消除应用程序本身中处理重试、断路器、TLS（安全传输层协议）等大量代码的需求。

让我们开始学习Istio-ify Coolstore吧。我们假设您已经安装了Red Hat OpenShift 3.9。我使用的是Red Hat OpenShift Origin 3.9.0.alpha3; 截至发稿时，红帽OpenShift容器平台3.9尚未发布。我们进一步假设您已经按照Kubernetes 的 Istio快速启动安装了Istio 0.6.0或更高版本。克隆Coolstore回购，然后一起开始：

% git clone https://github.com/jbossdemocentral/coolstore-microservice

并确保您以集群管理员身份登录或具有集群管理权限，因为这将需要您稍后进行一些策略和权限更改。

自动注入边车

通过边车自动注入，您的应用程序的窗格将自动与Envoy代理进行挂接，甚至不需更改应用程序的部署。这依赖于Kubernetes的MutatingAdmissionWebhook，它在Kubernetes 1.9中是新的（也就是红帽OpenShift 3.9）新。要在红帽OpenShift中启用它，你需要编辑你的主配置文件（master-config.yaml）来添加MutatingAdmissionWebhook：

MutatingAdmissionWebhook:
admissionConfig:
  pluginConfig:
    MutatingAdmissionWebhook:
      configuration:
        apiVersion: v1
        disable: false
        kind: DefaultAdmissionConfig

并且启用Kubernetes证书签名API，以便使用Kubernetes签署Webhook证书（自动边车注入安装过程的一部分）：

kubernetesMasterConfig:
  controllerArguments:
    cluster-signing-cert-file: [ ca.crt ]
    cluster-signing-key-file: [ ca.key ]

通过这些更改，重新启动您的主站，然后执行自动边车注入安装过程。

请注意，与开箱即用的Kubernetes相比，Red Hat OpenShift拥有更多受限的默认安全策略，因此您必须允许注入器webhook以更高的权限运行，因为它将尝试在其网荚中绑定到443端口。Istio项目意识到关于它需要太多特权的抱怨，并且正在努力应用最小特权原则：

% oc adm policy add-scc-to-user anyuid -z istio-sidecar-injector-service-account -n istio-system
% oc adm policy add-scc-to-user privileged -z istio-sidecar-injector-service-account -n istio-system

然后重新启动注射器webhook网荚。当创建新的网荚以运行应用程序容器时，将会咨询MutatingAdmissionWebhook并给予机会更改容器的内容。它将添加必要的“sidecar”容器，以透明地拦截所有网络流量和所有入站/出站应用流量。

接下来，让我们创建一个包含示例应用程序的测试项目。赋予代理容器权限，让它们发挥神奇的作用，并与有特权的用户一起运行，以便我们以后可以进入：

% oc new-project coolstore-test
% oc adm policy add-scc-to-user privileged -z default,deployer
% oc adm policy add-scc-to-user anyuid -z default,deployer

要在红帽OpenShift项目上启用自动注入功能，只需标记项目（又名命名空间）即可：

% oc label namespace $(oc project -q) istio-injection=enabled

从那时起，在该项目中创建的任何网荚都将获得一个额外的容器注入其中。让我们通过创建一个运行基本Apache HTTPD服务器的测试网荚来快速测试它：

% oc new-app httpd

并检查出网荚：

% oc get pods
NAME           READY STATUS RESTARTS AGE
httpd-1-deploy 1/2   Error  0        6s

看到下面的1/2READY了吗？它说明2个容器中有1个已准备就绪。这两个容器一个是执行部署的容器，一个用于自动注入边车。在一个网荚内放置多个容器一直是可能的，但迄今为止，它还没有在其他地方被广泛看到。假设它已经渗透到各种开发工具中，这些工具需要修改才能在已确定的宇宙中顺利运行。

请注意，该httpd-1-deploy窗格未运行该应用程序，这是运行Red Hat OpenShift部署的窗格，该部署试图部署运行该应用程序的窗格（通常称为“部署者窗格”）。正如你所看到的，部署的状态是ERROR。部署者窗格日志文件显示：

% oc logs -c deployment httpd-1-deploy
error: couldn't get deployment httpd-1: Get https://172.30.0.1:443/api/v1/namespaces/coolstore-test/replicationcontrollers/httpd-1: dial tcp 172.30.0.1:443: getsockopt: connection refused

这是由于Istio / Envoy中的一个错误。作为一种解决方法，让我们来修改它以增加一些休眠时间，以允许边车代理有额外的时间在实际部署发生之前初始化：

% oc patch dc/httpd -p '{ "spec": { "strategy": { "customParams": { "command": ["/bin/sh", "-c", "sleep 5; echo slept for 5; /usr/bin/openshift-deploy"]}}}}'
deploymentconfig "httpd" patched

通常，当您修补部署时，它会立即触发新的部署。这给我们带来了下一个问题：以前的部署从未“完成”。问题是附加在部署人员窗格的边车代理没有退出（为什么会这样？）。因此，该窗格会继续运行，并且在此窗格完成并且其容器退出之前，部署将永远不会被认为是完整的（直到它在6小时后超时，此时整个部署将被回滚）。天呐！

所以让我们取消当前正在运行（但失败）的部署：

% oc rollout cancel dc/httpd
deploymentconfig "httpd" cancelling

等待窗格被终止，然后再次触发部署：

% oc rollout latest httpd
deploymentconfig "httpd" rolled out

现在，这个应用程序应该可以运行了，因为睡眠5个小时会让部署者有一段时间等待Istio网络来完成它的工作。尽管和以前一样，部署人员窗格永远不会退出。过一会儿你会看到：

% oc get pods
NAME           READY STATUS    RESTARTS AGE
httpd-2-deploy 1/2   Completed 0        56s
httpd-2-rbwdq  2/2   Running   0        47s

过一段时间，您可以看到实际的HTTPD应用程序在httpd-2-rbwdq容器的容器中运行，并且由于与部署器容器关联的代理永远不会退出，因此部署器容器（httpd-2-deploypkill）将处于闲置状态。让我们关闭与部署者窗格关联的代理，以便部署完成。我们将通过rsh进入部署者窗格（指定代理容器运行istio-proxy）来完成此操作，并使用它来终止Istio代理进程：

~ % oc rsh -c istio-proxy httpd-2-deploy pkill -f istio
command terminated with exit code 137

然后，您可以运行oc get pods和oc get dc/httpd，以观察应用程序使用边车容器是否正常运行：

~ % oc get pods
NAME          READY STATUS  RESTARTS AGE
httpd-2-m29d9 2/2   Running 0        1m
~ % oc get dc
NAME  REVISION DESIRED CURRENT TRIGGERED BY
httpd 2        1       1       config,image(httpd:2.4)

总结和观察

Istio代理的自动注入是一项引人注目的新功能，可为您的红帽OpenShift项目注入新的活力。然而，红帽OpenShift需要进行一些微调，以便在整个红帽OpenShift的应用程序生命周期功能中充分利用它来构建和部署应用程序。其他观察：

• 作为代理初始化的一部分出现的网络魔法似乎暂时中断了来自红帽OpenShift网络的窗格， 我们用真正的睡眠破解工具解决了这个问题，但需要更好的解决方案。
• 需要更详细的机制来指定哪些窗格被自动注入。目前，它是在具有标签的项目（Kubernetes命名空间）级别完成的，这意味着在命名空间中创建的每一个窗格将会注入一个代理。您还可以选择使用sidecar.istio.io/inject: "true"部署上的注释禁用每个应用程序的注入。然而，目前尚不清楚这将如何影响在红帽OpenShift中构建或部署的应用程序创建的特殊构建器和部署器窗格。这个解决方案应该在Red Hat OpenShift 3.10中实现。
• 使用自动注入时，部分应用程序的部署可能会失败并出现奇怪的错误reflect.Value.Addr of unaddressable value。这是Go语言级错误，已在Kubernetes中解决，并将出现在Red Hat OpenShift的下一个版本中。目前，除了使用手动注入之外，没有任何解决方法，我们将在本系列文章的下一部分介绍。
• 自动注入非常适合演示，并且可以快速获取现有应用程序并在网格中运行。但是，在生产场景中，我不确定我想要信任自动注入机制。手动注入允许您执行相同的任务，但是然后需要将结果提交给源代码管理系统，而不依赖于自动注入。我可能采取的另一种方法是在独立的集群和名称空间中构建，而不进行任何自动注入。将注入留给我的生产集群/命名空间中发生的部署。

现在让我们暂时关闭自动注入：

% oc label namespace $(oc project -q) istio-injection-

末尾的连字符（-）表示“删除标签”。

在本系列的下一部分中，我们将向您展示如何进行手动注入（Istio 0.6.0支持OpenShift DeploymentConfig对象），我们将把它应用于整个Coolstore项目，以获得一些真正的乐趣。

敬请关注！