第 4 章 第二天
4.1. 在 Red Hat OpenShift Service Mesh 上部署应用程序
当将应用程序部署到 Service Mesh 后,在 Istio 上游社区版本的应用程序的行为和在 Red Hat OpenShift Service Mesh 中的应用程序的行为有几个不同之处。
4.1.1. 创建 control plane 模板
您可以使用 ServiceMeshControlPlane
模板生成可重复使用的配置。用户可根据自己的配置对您所创建的模板进行扩展。模板也可以从其他模板继承配置信息。例如,您可以为财务团队创建一个财务 control plane,为市场团队创建一个市场 control plane。如果您创建了一个开发模板和一个产品模板,则市场团队成员和财务团队成员就可以根据自己团队的情况对开发模板和产品模板进行扩展。
当配置 control plane 模板(与 ServiceMeshControlPlane
语法相同)时,用户以分级方式继承设置。Operator 附带一个具有 Red Hat OpenShift Service Mesh 默认设置的 default
模板 。要添加自定义模板,您必须在 openshift-operators
项目中创建一个名为 smcp-templates
的 ConfigMap,并在 Operator 容器的 /usr/local/share/istio-operator/templates
中挂载 ConfigMap 。
4.1.1.1. 创建 ConfigMap
按照以下步骤创建 ConfigMap。
先决条件
- 已安装并验证的 Service Mesh Operator。
-
具有
cluster-admin
角色的帐户。 - Operator 部署的位置。
-
访问 OpenShift Container Platform 命令行界面 (CLI) 也称为
oc
。
流程
- 以集群管理员身份登录到 OpenShift Container Platform CLI。
在 CLI 中运行这个命令,在
openshift-operators
项目中创建名为smcp-templates
的 ConfigMap,并将<templates-directory>
替换成本地磁盘上的ServiceMeshControlPlane
文件的位置:$ oc create configmap --from-file=<templates-directory> smcp-templates -n openshift-operators
找到 Operator 集群服务版本名称。
$ oc get clusterserviceversion -n openshift-operators | grep 'Service Mesh' maistra.v1.0.0 Red Hat OpenShift Service Mesh 1.0.0 Succeeded
编辑 Operator 集群服务版本,指定 Operator 使用
smcp-templates
ConfigMap。$ oc edit clusterserviceversion -n openshift-operators maistra.v1.0.0
在 Operator 部署中添加卷挂载和卷。
deployments: - name: istio-operator spec: template: spec: containers: volumeMounts: - name: discovery-cache mountPath: /home/istio-operator/.kube/cache/discovery - name: smcp-templates mountPath: /usr/local/share/istio-operator/templates/ volumes: - name: discovery-cache emptyDir: medium: Memory - name: smcp-templates configMap: name: smcp-templates ...
- 保存更改并退出编辑器。
现在,您可以使用
ServiceMeshControlPlane
中的template
参数来指定模板。apiVersion: maistra.io/v1 kind: ServiceMeshControlPlane metadata: name: minimal-install spec: template: default
4.1.2. Red Hat OpenShift Service Mesh 的 sidecar 注入
Red Hat OpenShift Service Mesh 依靠应用程序 pod 中的 proxy sidecar 来为应用程序提供 Service Mesh 功能。您可以使用自动 sidecar 注入功能或手动管理它。红帽推荐通过注释使用自动注入功能,而不需要标记项目。这样可保证您的应用程序在部署时包含正确的 Service Mesh 配置。这个方法需要较少的权限,且不会与其他 OpenShift 功能冲突,比如 builder pod。
如果您已经标记了项目,Istio 的上游版本会默认注入 sidecar。Red Hat OpenShift Service Mesh 要求您选择为一个部署自动注入 sidecar,因此您不需要标记项目。这可避免在不需要的情况下(例如,在构建或部署 pod 中)注入 sidecar。
webhook 会检查部署到所有项目的 pod 的配置,看它们是否选择使用适当的注解注入。
4.1.2.1. 启用自动 sidecar 注入
在 Red Hat OpenShift Service Mesh 中部署应用程序时,需要为sidecar.istio.io/inject
注解指定一个 "true"
值来选择进行注入。这可以确保 sidecar 注入不会影响 OpenShift 的其他功能,如被 OpenShift 生态系统中的很多框架使用的 builder pod。
先决条件
- 识别要启用自动插入的部署。
- 找到应用程序的 YAML 配置文件。
流程
- 在编辑器中打开应用程序的配置 YAML 文件。
把值为
"true"
的sidecar.istio.io/inject
添加到配置 YAML 中,如下所示:休眠测试程序示例
apiVersion: extensions/v1 kind: Deployment metadata: name: sleep spec: replicas: 1 template: metadata: annotations: sidecar.istio.io/inject: "true" labels: app: sleep spec: containers: - name: sleep image: tutum/curl command: ["/bin/sleep","infinity"] imagePullPolicy: IfNotPresent
- 保存配置文件。
4.1.3. 更新 Mixer 策略强制功能
在之前的 Red Hat OpenShift Service Mesh 版本中,Mixer 的策略强制功能被默认启用。现在,Mixer 的策略强制功能被默认禁用。您需要在运行策略任务前启用它。
先决条件
-
访问 OpenShift Container Platform 命令行界面 (CLI) 也称为
oc
。
流程
- 登录 OpenShift Container Platform CLI。
运行这个命令检查当前的 Mixer 策略强制状态:
$ oc get cm -n istio-system istio -o jsonpath='{.data.mesh}' | grep disablePolicyChecks
如果为
disablePolicyChecks: true
,编辑 Service Mesh ConfigMap:$ oc edit cm -n istio-system istio
-
在 ConfigMap 中找到
disablePolicyChecks: true
,把它的值改为false
。 - 保存配置并退出编辑器。
-
重新检查 Mixer 策略强制状态以确保其已被设置为
false
。
4.1.4. 设置正确的网络策略
Service Mesh 在 control plane 和成员命名空间中创建网络策略,以便将它们间的流量列在白名单中。在部署前,请考虑以下条件,以确保之前通过 OpenShift Container Platform 路由公开的网格中的服务。
- 进入网格的流量必须总是通过 ingress 网关以使 Istio 可以正常工作。
- 在没有处于任何网格的单独命名空间中为网格部署服务。
-
需要在服务网格列出的命名空间中部署的非 mesh 服务应该标记其
maistra.io/expose-route: "true"
,这可以确保 OpenShift Container Platform 路由到这些服务仍可以正常工作。
后续步骤
- 在 Red Hat OpenShift Service Mesh 上部署 Bookinfo。