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

相关文章

来自专栏FreeBuf

Arp欺骗原理及Android环境下的检测方法

测试环境说明 网关: IP:172.20.150.1 mac:24050FCE53 靶机(手机): IP:172.20.150.20 mac:000822...

26810
来自专栏容器化

详解k8s一个完整的监控方案(Heapster+Grafana+InfluxDB) - kubernetes

3232
来自专栏张戈的专栏

Nginx发布1.9.0版本,新增支持TCP代理和负载均衡的stream模块

昨天在公司微信群,CTO 分享了这个消息,对运维来说以后基于 TCP 协议的后端业务的高可用又多了一个新的选择,实在是棒极了! 一直以来,Nginx 并不支持 ...

2755
来自专栏计算机视觉与深度学习基础

计算机视觉与图像处理学习笔记(二)win32+mingw+opencv搭建

本来是想接着第二章学习的,但是感觉理论性有点强,了解基本概念后还是从Opencv来,遇到问题再切换。 关于opencv的下载与配置参考: http://open...

1929
来自专栏KaliArch

Python重启深信服设备

为防止隧道检测脚本异常,另外编写监控监测脚本的脚本配合定时任务来定时监控,如果异常,重新拉起。

5006
来自专栏yw的数据分析

安卓手机免root实现对其他软件最高管理(sandbox思想)

  root之后的安卓系统并不稳定,root后有时候会出现一些系统的错误,如果实在忍受不了的话,这时候只能恢复出厂设置了。因此不root是最优的选择,但是不ro...

35011
来自专栏bboysoul

使用树莓派来挖xmr门罗币

作为一个要把所有算力用来挖矿的人来说,树莓派肯定不能放着吃灰啊,但是树莓派用来挖矿是我觉得是有点鸡肋的,不管怎么说,挖起。

762
来自专栏VMCloud

【腾讯云的1001种玩法】构建企业级应用环境之数据层面优化(一)

本系列为两年前 VMCloud 云平台的进阶篇,本次借助 QCloud 的《1001种玩法》活动来继续完成进阶篇,主要以在 QCloud 上搭建一个完整的应用环...

1K0
来自专栏FreeBuf

关于C/S架构系统的安全监测

由于工作需求,需要对一大批C/S架构的系统进行测试,所以这几天一直在摸索怎么个套路法,踩过的坑就不发了,直接奔我个人的套路: C/S架构的系统,说最直白一点就是...

3568
来自专栏静晴轩

Npm vs Yarn 之备忘大全

有则笑话,如此讲到:“老丈人爱吃核桃,昨天买了二斤陪妻子送去,老丈人年轻时练过武,用手一拍核桃就碎了,笑着对我说:你还用锤子,你看我用手就成。我嘴一抽,来了句:...

2459

扫码关注云+社区