专栏首页将Coolstore微服务引入服务网格:第1部分 - 探索自动注入

将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 条评论
登录 后参与评论

相关文章

  • 比较服务网格体系结构

    如果你正在围绕微服务构建您的软件和团队,那么你应该正在寻找更快迭代和灵活扩展的方法。服务网格可以帮助你在保持(或增强)可见性和控制的同时实现这一点。在这篇博客中...

    Aaroncang
  • Go微服务,第10部分:集中式日志记录

    在Go微服务博客系列的这一部分中,我们将介绍基于Logrus,Docker Gelf日志驱动程序和“作为服务的日志记录” Loggly服务的Go微服务的日志记录...

    Aaroncang
  • 组织微服务

    微服务可能是我的开发伙伴朋友中最受欢迎的热门话题之一,我确实喜欢灵活,敏捷以及拥有更多选择的概念。但作为一名在软件集成领域工作多年的人,我开始看到一些类似于以前...

    Aaroncang
  • React / Vue 项目时为什么要在列表组件中写 key,其作用是什么?

    在交叉对比中,当新节点跟旧节点头尾交叉对比没有结果时,会根据新节点的key去对比旧节点数组中的key,从而找到相应旧节点(这里对应的是一个key => inde...

    Javanx
  • 容器时代的DevOps部署

    本文目录: 一、企业应用的部署发展 二、普元容器云与DevOps的部署设计 三、面向微服务的部署设计 四、容器组装化部署 五、容器云集成之路 六、结语 一、企业...

    yuanyi928
  • 「技术架构」TOGAF建模:处理图/部署图

    处理图着重于可部署的代码/配置单元,以及如何将它们部署到技术平台上。部署单元表示业务功能、服务或应用程序组件的分组。处理图解决了以下问题:

    首席架构师智库
  • 管理conda environments

    environments作为conda的核心组件,用于封装相互独立的软件环境。通过在不同的environment中安装packages,来实现不同软件的相互独立...

    生信修炼手册
  • spring的定时任务,超级简单好用

    @EnableScheduling 注解的作用是发现注解@Scheduled的任务并后台执行。@Scheduled用于标注这个方法是一个定时任务的方法cro...

    Java深度编程
  • 一个小知识点-Hive行转列实现Pivot

    传统关系型数据库中,无论是Oracle(11g之后)还是SQLserver(2005之后),都自带了Pivot函数实现行转列功能,本文主要讲述在Hive中实现行...

    大数据技术与架构
  • Synchronized锁性能优化偏向锁轻量级锁升级 多线程中篇(五)

    不止一次的提到过,synchronized是Java内置的机制,是JVM层面的,而Lock则是接口,是JDK层面的

    noteless

扫码关注云+社区

领取腾讯云代金券