将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 podsoc 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项目,以获得一些真正的乐趣。

敬请关注!

本文的版权归 Aaroncang 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Ceph对象存储方案

Luminous版本PG 分布调优

Luminous版本开始新增的balancer模块在PG分布优化方面效果非常明显,操作也非常简便,强烈推荐各位在集群上线之前进行这一操作,能够极大的提升整个集群...

3145
来自专栏转载gongluck的CSDN博客

cocos2dx 打灰机

#include "GamePlane.h" #include "PlaneSprite.h" #include "BulletNode.h" #include...

5476
来自专栏C#

DotNet加密方式解析--非对称加密

    新年新气象,也希望新年可以挣大钱。不管今年年底会不会跟去年一样,满怀抱负却又壮志未酬。(不过没事,我已为各位卜上一卦,卦象显示各位都能挣钱...)...

4878
来自专栏闻道于事

js登录滑动验证,不滑动无法登陆

js的判断这里是根据滑块的位置进行判断,应该是用一个flag判断 <%@ page language="java" contentType="text/html...

6828
来自专栏Golang语言社区

【Golang语言社区】GO1.9 map并发安全测试

var m sync.Map //全局 func maintest() { // 第一个 YongHuomap := make(map[st...

4708
来自专栏java 成神之路

使用 NIO 实现 echo 服务器

4667
来自专栏我和未来有约会

Kit 3D 更新

Kit3D is a 3D graphics engine written for Microsoft Silverlight. Kit3D was inita...

2536
来自专栏pangguoming

Spring Boot集成JasperReports生成PDF文档

由于工作需要,要实现后端根据模板动态填充数据生成PDF文档,通过技术选型,使用Ireport5.6来设计模板,结合JasperReports5.6工具库来调用渲...

1.2K7
来自专栏大内老A

The .NET of Tomorrow

Ed Charbeneau(http://developer.telerik.com/featured/the-net-of-tomorrow/) Exciti...

31710
来自专栏张善友的专栏

Mix 10 上的asp.net mvc 2的相关Session

Beyond File | New Company: From Cheesy Sample to Social Platform Scott Hansel...

2577

扫码关注云+社区