在 Istio 上设置服务网格

Net catching 1s and 0s or data in the clouds

图片来源：

Opensource.com

服务网格和无服务器部署模型代表了微服务架构演进的下一阶段。服务网格使开发人员能够专注于业务功能开发，而不是管理非功能性微服务能力，例如监控、跟踪、容错和服务发现。

开源服务网格项目，包括 Istio、LinkerD 和 Kuma，使用 Sidecar（专用的基础架构层，直接构建到应用程序中）来实现服务网格功能。例如，开发人员可以使用 Jaeger 构建 Istio 服务网格，从而改进对分布式网络系统上云原生微服务的监控和跟踪。

图片来源：

^{CNCF 服务网格概览（来源： CNCF）}

在微服务中实施服务网格的下一阶段，开发人员可以使用事件驱动的执行模式来推进其无服务器开发。这不仅仅是一种全新的方法；它还试图将业务流程从 24x7x365 正常运行时间转变为按需扩展。开发人员可以通过使用以下显示的开源无服务器项目之一来利用无服务器部署的特性和优势。例如，Knative 是一种在 Kubernetes 平台上开发无服务器应用程序的更快、更简单的方法。

图片来源：

CNCF 无服务器概览（来源： CNCF）

想象一下，将服务网格和无服务器结合起来，以进行更高级的云原生微服务开发和部署。这种组合架构允许您配置额外的网络设置，例如自定义域、相互传输层安全 (mTLS) 证书和 JSON Web 令牌身份验证。

这是一个在 Istio 上设置服务网格，并在 Knative Serving 上实现无服务器的快速示例。

1. 添加带有 Sidecar 注入的 Istio

安装 Istio 服务网格时，需要设置 autoInject: enabled 配置以进行自动 Sidecar 注入

    global:
      proxy:
        autoInject: enabled

如果您想了解更多信息，请查阅 Knative 关于安装没有和带有 Sidecar 注入的 Istio的文档。

2. 为 mTLS 网络启用 Sidecar

要在 knative-serving 命名空间和您希望应用程序 Pod 运行的另一个命名空间之间使用 mTLS 网络通信，请启用 Sidecar 注入

$ kubectl label namespace knative-serving istio-injection=enabled

您还需要在 knative-serving namespace 中配置 PeerAuthentication

cat <<EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "knative-serving"
spec:
  mtls:
    mode: PERMISSIVE
EOF

如果您为 Istio 服务网格和 Knative 安装了本地网关，则 Knative 服务和应用程序部署的默认集群网关名称将是 knative-local-gateway。

3. 为 Knative 服务部署应用程序

创建一个 Knative 服务资源 YAML 文件（例如，myservice.yml）以启用 Knative 服务的 Sidecar 注入。

将 sidecar.istio.io/inject="true" 注释添加到服务资源

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: hello-example-1
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true" (1)
        sidecar.istio.io/rewriteAppHTTPProbers: "true" (2)
    spec:
      containers:
      - image: docker.io/sample_application (3)
        name: container

在上面的代码中

(1) 添加 Sidecar 注入注释。

(2) 启用 JSON Web 令牌 (JWT) 身份验证。

(3) 在外部容器注册表中（例如，DockerHub、Quay.io）将应用程序镜像替换为您自己的镜像。

应用上面的 Knative 服务资源