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

相关文章

来自专栏乐享123

Docker中的网络

1876
来自专栏jessetalks

Gitlab CI 自动部署 asp.net core web api 到Docker容器

为什么要写这个? 在一个系统长大的过程中会经历不断重构升级来满足商业的需求,而一个严谨的商业系统需要高效、稳定、可扩展,有时候还不得不考虑成本的问题。我希望能找...

4936
来自专栏郭耀华‘s Blog

onSaveInstanceState和onRestoreInstanceState触发的时机

先看Application Fundamentals上的一段话:  Android calls onSaveInstanceState() before t...

3077
来自专栏大魏分享(微信公众号:david-share)

厉害了word哥 | 从两张图看红帽最高深的武功 |OpenShift

世上的高手 世上高手大约有两种: 第一种如下图这为老先生,一辈子纵横江湖数十载,所学武功实用有效,招数简明而力道雄厚,善于“简单粗暴”迅速解决问题。在老爷子的心...

4517
来自专栏北京马哥教育

Docker的典型应用场景

相对于VM,docker在其轻量、配置复杂度以及资源利用率方面有着明显的优势。 随着docker技术的不断成熟,越来越多的企业开始考虑通过docker来改进自己...

2367
来自专栏互联网杂技

Docker在PHP项目开发环境中的应用

环境部署是所有团队都必须面对的问题,随着系统越来越大,依赖的服务也越来越多,比如我们目前的一个项目就会用到: - Web服务器:Nginx - Web程序:P...

36010
来自专栏运维前线

使用Helm将应用程序部署到IBM Cloud上的Kubernetes上

Helm是Kubernetes的包管理员。借助Helm,我们可以非常方便地将应用程序,工具和数据库(如MongoDB,PostgreSQL,WordPress和...

2055
来自专栏容器化

容器化分布式日志组件ExceptionLess的Angular前端UI

2304
来自专栏云计算

​在 OS X 系统上快速上手 Docker 技术 (对 Docker 还不够熟悉? 从这里开始吧!)

原文地址:https://dzone.com/articles/dockerosx-quickstart-not

2178
来自专栏JadePeng的技术博客

google gcr.io、k8s.gcr.io 国内镜像

https://github.com/anjia0532/gcr.io_mirror

1.2K3

扫码关注云+社区