mirror of https://github.com/istio/istio.io.git
zh-translation: trade winds 2020 (#6745)
sync some file with en for lint
This commit is contained in:
2BFL
GitHub
parent
8689aa7b8d
commit
701814896c
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 170 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 608 KiB |
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
title: Istio 2020——为了商用
|
||||
subtitle: Istio 2020 的目标是更快的速度，更简单的用法
|
||||
description: Istio 在 2020 年的愿景声明及路线图。
|
||||
publishdate: 2020-03-03
|
||||
attribution: Istio Team
|
||||
keywords: [roadmap,security,performance,operator]
|
||||
---
|
||||
|
||||
Istio 解决了人们在运行微服务时遇到的实际问题。甚至[早期的预发行版本](https://kubernetespodcast.com/episode/016-descartes-labs/)就已经可以帮助用户诊断其体系架构中的延迟，提高服务的可靠性以及透明地保护防火墙后的流量。
|
||||
|
||||
去年，Istio 项目成长巨大。经过 9 个月的酝酿，在 2019 年第一季度发行 1.1 之前，我们设定了一个季度发布节奏的目标。我们知道，持续且可预测地交付非常重要。我们计划连续三个季度发布三个版本，并且我们为实现了这一目标感到自豪。
|
||||
|
||||
过去一年，我们改进了构建和测试基础架构，从而提高了质量并简化了发布周期。我们将用户体验提高了一倍，添加了许多命令使网格的操作和调试变得更加简单。我们还看到为 Istio 做出贡献的开发人员和公司数量急剧增长，最终，我们成为了 [GitHub 增长最快的十大项目中排名第 4 名](https://octoverse.github.com/#fastest-growing-oss-projects-by-contributors)！
|
||||
|
||||
2020 年，Istio 有宏伟的目标，并且我们正在努力中。与此同时，我们坚信良好的基础设施应该“无聊”。在生产中使用 Istio 应该是无缝的体验；性能不应该成为问题，升级应该是非事件性的，复杂的任务应自动化。随着我们对更强大的可扩展性的投入，我们认为 Istio 在专注于现在成就的同时，可以加快服务网格领域的创新步伐。以下是我们在 2020 年主要工作的详情。
|
||||
|
||||
## 更快、更简单{#sleeker-smoother-and-faster}
|
||||
|
||||
从第一天起，Istio 就通过 Mixer 组件提供了可扩展性支持。Mixer 是一个平台，允许使用自定义[适配器](/zh/docs/reference/config/policy-and-telemetry/mixer-overview/#adapters)充当数据平面与策略及遥测后端之间的中介。Mixer 必定会增加请求的开销，因为它必须扩展到进程之外。因此，我们正在向一种可以直接在代理中进行扩展的模型转变。
|
||||
|
||||
Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权](/zh/docs/concepts/security/#authorization)策略已经涵盖了 Mixer 用于策略执行的大多数用例，这些策略使您可以直接在代理中控制 workload 到 workload 以及终端用户到 workload 的授权。常见的监控用例也已经转移到代理中，我们[引入了代理内支持](/zh/docs/ops/configuration/telemetry/in-proxy-service-telemetry/)，以便将遥测发送到 Prometheus 和 Stackdriver。
|
||||
|
||||
我们的基准测试表明，新的遥测模型可显著减少延迟，并可提供行业领先的性能，同时降低 50％ 的延迟和 CPU 消耗。
|
||||
|
||||
## 新的 Istio 可扩展性模型{#a-new-model-for-Istio-extensibility}
|
||||
|
||||
新的 Mixer 模型使用 Envoy 中的扩展来提供更多功能。Istio 社区正在领导 Envoy 的 [WebAssembly](https://webassembly.org/)（Wasm）运行时的实现，Wasm 让我们可以使用[超过 20 种的语言](https://github.com/appcypher/awesome-wasm-langs)来开发模块化、沙盒化的扩展。可以在代理继续提供流量的同时动态加载、重载扩展。Wasm 扩展程序还可以通过 Mixer 无法做到的方式来扩展平台。它们可以充当自定义协议处理程序，并在通过 Envoy 时转换有效负载，简而言之，它们可以执行与 Envoy 中内置的模块相同的操作。
|
||||
|
||||
我们正在与 Envoy 社区一起研究发现和分发这些扩展的方法。我们希望使 WebAssembly 扩展像容器一样易于安装和运行。我们的许多合作伙伴已经编写了 Mixer 适配器，并与我们一起将其移植到 Wasm。如何编写自己的扩展并进行自定义集成？我们正在开发相关的指南和代码实验室。
|
||||
|
||||
更换扩展模型后，我们还可以删除数十个 CRD。与 Istio 集成的每个软件都不再需要唯一 CRD。
|
||||
|
||||
通过 `preview` 配置文件安装 Istio 1.5 不会再安装 Mixer。安全起见，如果您是从以前的版本升级，或通过 `default` 配置文件安装，我们仍会保留 Mixer。当使用 Prometheus 或 Stackdriver 进行度量时，建议您尝试新模式并查看性能提高了多少。
|
||||
|
||||
如果有需要，您可以保持安装并启用 Mixer。最终，Mixer 将成为 Istio 单独的发行组件，成为 [istio-ecosystem](https://github.com/istio-ecosystem/)的一部分。
|
||||
|
||||
## 减少移动部分{#fewer-moving-parts}
|
||||
|
||||
我们还将简化其余控制平面的 deployment。为此，我们将几个控制平面组件合并为一个组件：Istiod。该二进制文件包括 Pilot、Citadel、Galley 和 Sidecar 注入器的功能。这种方法从许多方面改善了 Istio 的安装和管理，降低了安装和配置的复杂性、维护工作量以及问题诊断时间，同时提高了响应速度。
|
||||
关于 Istiod 的更多内容请查看 [Christian Posta 的这篇博客](https://blog.christianposta.com/microservices/istio-as-an-example-of-when-not-to-do-microservices/)。
|
||||
|
||||
我们将 istiod 作为 1.5 中所有配置文件的默认配置。
|
||||
|
||||
为了减少每个节点的占用空间，我们放弃了用于分发证书的节点代理，并将其功能迁移至已经在每个 Pod 中运行的 istio-agent 中。从图片来看，我们正在从这里：
|
||||
|
||||
{{< image width="75%"
|
||||
link="./architecture-pre-istiod.svg"
|
||||
alt="基于 Pilot、Mixer、Citadel、Sidecar 注入器的 Istio 架构"
|
||||
caption="Istio 目前的架构"
|
||||
>}}
|
||||
|
||||
迁移到这里：
|
||||
|
||||
{{< image width="75%"
|
||||
link="./architecture-post-istiod.svg"
|
||||
alt="基于 istiod 的 Istio 架构"
|
||||
caption="Istio 2020 年的架构"
|
||||
>}}
|
||||
|
||||
2020年，我们将继续专注于普及，实现默认 `零配置` 的目标，该默认设置不需要您更改应用程序的任何配置即可使用 Istio 的大多数功能。
|
||||
|
||||
## 改进生命周期管理{#improved-lifecycle-management}
|
||||
|
||||
为了改进 Istio 的生命周期管理，我们使用了基于 [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) 的安装方式。这里介绍 **[Istio Operator CRD 的两种安装模式](/zh/docs/setup/install/istioctl/)**：
|
||||
|
||||
- 人为触发：使用 istioctl 将设置应用至集群。
|
||||
- 机器触发：使用一个控制器，实时观察 CRD 的改动并使其生效。
|
||||
|
||||
在 2020 年，升级 Istio 也将变得更加容易。我们将添加对 Istio 控制平面新版本的"金丝雀"支持，这使您可以同时运行现有版本的和新版本，并将数据平面逐渐切换至新版本。
|
||||
|
||||
## 默认安全{#secure-by-default}
|
||||
|
||||
Istio 已经为强大的服务安全性提供了基础：可靠的 workload 身份、强大的访问策略、全面的审核日志记录。我们正在为这些功能提供稳定的 API；许多 Alpha API 都将在 1.5 版中过渡为 Beta 版，我们希望到 2020 年底它们都将成为 v1 版本。要了解有关 API 状态的更多信息，请参见我们的[功能页面](/zh/about/feature-stages/#istio-features)。
|
||||
|
||||
默认情况下，网络流量也变得更加安全。继许多用户可以在评估时启用它之后，[自动双向 TLS](/zh/docs/tasks/security/authentication/auto-mtls/) 已成为 Istio 1.5 中的推荐做法。
|
||||
|
||||
此外，我们将让 Istio 所需的权限更少，并简化其依赖性，从而使 Istio 成为更强大的系统。在以前，您必须使用 Kubernetes Secrets 将证书安装到 Envoy，这些证书作为文件挂载至每个代理中。而现在，通过[密钥发现服务（SDS）](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret) ，我们可以安全地分发这些证书，而不必担心它们会被计算机上的其他 workload 拦截。该模式将成为 1.5 中的默认模式。
|
||||
|
||||
摆脱节点代理，不仅简化了部署，而且消除了对整个集群范围内 `PodSecurityPolicy` 的要求，从而进一步改善了集群的安全性。
|
||||
|
||||
## 其它功能{#other-features}
|
||||
|
||||
这是 Istio 在 2020 年一些值得期待的、令人兴奋的事情：
|
||||
|
||||
- 与更多托管的 Kubernetes 环境集成，目前已有 15 个供应商提供了 Istio 服务网格，这些公司包括：Google、IBM、Red Hat、VMware、Alibaba 以及 Huawei。
|
||||
- 更多的关注 `istioctl` 及其帮助诊断问题的能力。
|
||||
- 将基于 VM 的 workload 更好地集成到网格中。
|
||||
- 继续努力使多群集和多网络网格更易于配置、维护和运行。
|
||||
- 与更多的服务发现系统集成，包括 Functions-as-a-Service。
|
||||
- 实现新的 [Kubernetes service API](https://kubernetes-sigs.github.io/service-apis/)（目前正在开发中）。
|
||||
- [增强存储库](https://github.com/istio/enhancements/)，以便开发追踪功能。
|
||||
- 让没有 Kubernetes 的 Istio 可以更轻松地运行！
|
||||
|
||||
从大海到[天空](https://www.youtube.com/watch?v=YjZ4AZ7hRM0)，Istio 期待您的加入！
|
||||
|
|
@ -1,53 +0,0 @@
|
|||
---
|
||||
title: Bookinfo 应用 - 多集群
|
||||
description: 跨多集群网格部署示例应用程序。
|
||||
weight: 11
|
||||
keywords: [multicluster]
|
||||
---
|
||||
|
||||
{{< boilerplate experimental-feature-warning >}}
|
||||
|
||||
本示例是对[简化版多集群设置过程](/zh/docs/setup/install/multicluster/simplified)的补充。
|
||||
它向您展示了如何跨多集群网格部署 Istio 的经典 [Bookinfo](/zh/docs/examples/bookinfo) 示例应用。
|
||||
|
||||
## 让它运行起来{#getting-it-running}
|
||||
|
||||
1. 请先从[这些说明](/zh/docs/setup/install/multicluster/simplified)开始，它将向您展示如何配置一个 3 集群的网格。
|
||||
|
||||
1. 下载 [`setup-bookinfo.sh` 脚本]({{< github_file >}}/samples/multicluster/setup-bookinfo.sh)并保存至上一步中创建的工作目录中。
|
||||
|
||||
1. 运行下载的脚本：
|
||||
|
||||
{{< text bash >}}
|
||||
$ ./setup-bookinfo.sh install
|
||||
{{< /text >}}
|
||||
|
||||
这将会把 Bookinfo 部署到网格的所有集群中。
|
||||
|
||||
## 观察它能否正常工作{#showing-that-its-working}
|
||||
|
||||
现在 Bookinfo 已经部署到所有的集群中了，我们可以禁用掉它的某些集群中的某些服务，然后观察整个应用继续保持响应状态，表明流量可以根据需要在群集之间透明地流动。
|
||||
|
||||
让我们禁用掉一些服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ for DEPLOYMENT in details-v1 productpage-v1 reviews-v2 reviews-v3; do
|
||||
$ kubectl --context=context-east-1 scale deployment ${DEPLOYMENT} --replicas=0
|
||||
$ done
|
||||
$ for DEPLOYMENT in details-v1 reviews-v2 reviews-v3 ratings-v1; do
|
||||
$ kubectl --context=context-east-2 scale deployment ${DEPLOYMENT} --replicas=0
|
||||
$ done
|
||||
$ for DEPLOYMENT in productpage-v1 reviews-v2 reviews-v1 ratings-v1; do
|
||||
$ kubectl --context=context-west-1 scale deployment ${DEPLOYMENT} --replicas=0
|
||||
$ done
|
||||
{{< /text >}}
|
||||
|
||||
现在请参考 [常规的 Bookinfo](/zh/docs/examples/bookinfo) 来证明多集群部署是可以正常运行的。
|
||||
|
||||
## 清理{#clean-up}
|
||||
|
||||
您可以使用以下命令从所有集群中删除 Bookinfo：
|
||||
|
||||
{{< text bash >}}
|
||||
$ ./setup-bookinfo.sh uninstall
|
||||
{{< /text >}}
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
---
|
||||
title: 特定平台的示例（已弃用）
|
||||
description: Istio 特定平台安装的示例。
|
||||
weight: 110
|
||||
keywords: [multicluster]
|
||||
---
|
||||
|
||||
{{< warning >}}
|
||||
这些示例是有关特定平台的，已被弃用。这些示例将在下一个 Istio 版本中被删除。
|
||||
{{< /warning >}}
|
||||
|
|
@ -1,95 +0,0 @@
|
|||
---
|
||||
title: 在 Google Cloud Endpoints 服务上安装 Istio
|
||||
description: 如何将 Istio 手动集成至 Google Cloud Endpoints 服务的说明。
|
||||
weight: 10
|
||||
aliases:
|
||||
- /zh/docs/guides/endpoints/index.html
|
||||
- /zh/docs/examples/endpoints/
|
||||
---
|
||||
|
||||
该文档展示了如何将 Istio 手动集成至现成的 Google Cloud Endpoints 服务中。
|
||||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
如果您还没有 Endpoints 服务并想尝试一下，请按照[这个说明](https://cloud.google.com/endpoints/docs/openapi/get-started-kubernetes-engine)在 GKE 上设置一个 Endpoints 服务。
|
||||
设置完成后，您会得到一个 API key，将它存为 `ENDPOINTS_KEY` 环境变量，然后将 external IP 地址存为 `EXTERNAL_IP`。
|
||||
您可以使用以下命令测试该服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ curl --request POST --header "content-type:application/json" --data '{"message":"hello world"}' "http://${EXTERNAL_IP}/echo?key=${ENDPOINTS_KEY}"
|
||||
{{< /text >}}
|
||||
|
||||
按照[使用 Google Kubernetes Engine 快速开始](/zh/docs/setup/platform-setup/gke)的说明为 GKE 安装 Istio。
|
||||
|
||||
## HTTP endpoints 服务{#HTTP-endpoints-service}
|
||||
|
||||
1. 按照[这篇说明](/zh/docs/tasks/traffic-management/egress/egress-control/#direct-access-to-external-services)使用 `--includeIPRanges` 将 service 和 deployment 注入到网格中，以让 Egress 可以直接调用外部服务。
|
||||
否则，ESP 将无法访问 Google cloud service control。
|
||||
|
||||
1. 注入后，使用上面同样的测试命令以确保访问 ESP 依然有效。
|
||||
|
||||
1. 如果您希望通过 Istio ingress 访问该服务，请创建如下网络定义：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: Gateway
|
||||
metadata:
|
||||
name: echo-gateway
|
||||
spec:
|
||||
selector:
|
||||
istio: ingressgateway # use Istio default gateway implementation
|
||||
servers:
|
||||
- port:
|
||||
number: 80
|
||||
name: http
|
||||
protocol: HTTP
|
||||
hosts:
|
||||
- "*"
|
||||
---
|
||||
apiVersion: networking.istio.io/v1alpha3
|
||||
kind: VirtualService
|
||||
metadata:
|
||||
name: echo
|
||||
spec:
|
||||
hosts:
|
||||
- "*"
|
||||
gateways:
|
||||
- echo-gateway
|
||||
http:
|
||||
- match:
|
||||
- uri:
|
||||
prefix: /echo
|
||||
route:
|
||||
- destination:
|
||||
port:
|
||||
number: 80
|
||||
host: esp-echo
|
||||
---
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 按照[这篇说明](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)获取 ingress 网关的 IP 和端口。
|
||||
您可以使用以下命令检查一下通过 Istio ingress 访问 Endpoints 服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ curl --request POST --header "content-type:application/json" --data '{"message":"hello world"}' "http://${INGRESS_HOST}:${INGRESS_PORT}/echo?key=${ENDPOINTS_KEY}"
|
||||
{{< /text >}}
|
||||
|
||||
## 使用安全 Ingress 的 HTTPS endpoints 服务{#HTTPS-endpoints-service-using-secured-Ingress}
|
||||
|
||||
安全地访问网格 Endpoints 服务的推荐方式是通过一个配置了 TLS 的 ingress。
|
||||
|
||||
1. 在启用严格双向 TLS 的情况下安装 Istio。确认下列命令的输出是 `STRICT` 还是空的：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get meshpolicy default -n istio-system -o=jsonpath='{.spec.peers[0].mtls.mode}'
|
||||
{{< /text >}}
|
||||
|
||||
1. 按照[这篇说明](/zh/docs/tasks/traffic-management/egress/egress-control/#direct-access-to-external-services)使用 `--includeIPRanges` 将 service 和 deployment 注入到网格中，以让 Egress 可以直接调用外部服务。
|
||||
否则，ESP 将无法访问 Google cloud service control。
|
||||
|
||||
1. 然后，您将发现，`ENDPOINTS_IP` 已经无法访问了，因为 Istio 代理只接受安全的网格连接。
|
||||
通过 Istio ingress 访问依然有效，因为 ingress 代理创建了与网格的双向 TLS 连接。
|
||||
|
||||
1. 按照[这篇说明](/zh/docs/tasks/traffic-management/ingress/secure-ingress-mount/)以让 ingress 上的访问更加安全。
|
||||
|
|
@ -1,276 +0,0 @@
|
|||
---
|
||||
title: Google Kubernetes Engine
|
||||
description: 在两个 GKE 集群上设置多集群网格。
|
||||
weight: 65
|
||||
keywords: [kubernetes,multicluster]
|
||||
aliases:
|
||||
- /zh/docs/tasks/multicluster/gke/
|
||||
- /zh/docs/examples/multicluster/gke/
|
||||
---
|
||||
|
||||
此示例展示在两个 [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) 集群上使用[单网络 deployment](/zh/docs/ops/deployment/deployment-models/#single-network) 配置多集群网格。
|
||||
|
||||
## 开始之前{#before-you-begin}
|
||||
|
||||
除了为安装 Istio 准备环境，该示例还需要以下设置：
|
||||
|
||||
* 该示例需要一个有效并开启计费功能的 Google Cloud Platform project。如果您
|
||||
还不是 GCP 用户，您或许可以注册并获得 $300 美元的[免费使用](https://cloud.google.com/free/) 信用额度。
|
||||
|
||||
* [创建一个 Google Cloud Project](https://cloud.google.com/resource-manager/docs/creating-managing-projects) 来
|
||||
托管您的 GKE 集群。
|
||||
|
||||
* 安装并初始化 [Google Cloud SDK](https://cloud.google.com/sdk/install)
|
||||
|
||||
## 创建 GKE 集群
|
||||
|
||||
1. 为 `gcloud` 设置默认的项目，并执行以下操作：
|
||||
|
||||
{{< text bash >}}
|
||||
$ gcloud config set project myProject
|
||||
$ proj=$(gcloud config list --format='value(core.project)')
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建 2 GKE 集群来使用多集群的特性。 _注意：_ `--enable-ip-alias` 需要允许集群中 pod 之间的直接通信。该 `zone` 值必须是
|
||||
[GCP zones](https://cloud.google.com/compute/docs/regions-zones/) 其中之一。
|
||||
|
||||
{{< text bash >}}
|
||||
$ zone="us-east1-b"
|
||||
$ cluster="cluster-1"
|
||||
$ gcloud container clusters create $cluster --zone $zone --username "admin" \
|
||||
--machine-type "n1-standard-2" --image-type "COS" --disk-size "100" \
|
||||
--scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_only",\
|
||||
"https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring",\
|
||||
"https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly",\
|
||||
"https://www.googleapis.com/auth/trace.append" \
|
||||
--num-nodes "4" --network "default" --enable-cloud-logging --enable-cloud-monitoring --enable-ip-alias --async
|
||||
$ cluster="cluster-2"
|
||||
$ gcloud container clusters create $cluster --zone $zone --username "admin" \
|
||||
--machine-type "n1-standard-2" --image-type "COS" --disk-size "100" \
|
||||
--scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_only",\
|
||||
"https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring",\
|
||||
"https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly",\
|
||||
"https://www.googleapis.com/auth/trace.append" \
|
||||
--num-nodes "4" --network "default" --enable-cloud-logging --enable-cloud-monitoring --enable-ip-alias --async
|
||||
{{< /text >}}
|
||||
|
||||
1. 通过以下命令轮询集群的状态，以等待集群转换为 `RUNNING` 状态：
|
||||
|
||||
{{< text bash >}}
|
||||
$ gcloud container clusters list
|
||||
{{< /text >}}
|
||||
|
||||
1. 获取集群证书的 ([详细命令](https://cloud.google.com/sdk/gcloud/reference/container/clusters/get-credentials))：
|
||||
|
||||
{{< text bash >}}
|
||||
$ gcloud container clusters get-credentials cluster-1 --zone $zone
|
||||
$ gcloud container clusters get-credentials cluster-2 --zone $zone
|
||||
{{< /text >}}
|
||||
|
||||
1. 验证 `kubectl` 是否能访问每一个集群，并创建一个 `cluster-admin` 集群角色，使其与 GCP 用户关联的 Kubernetes 证书绑定。
|
||||
|
||||
1. 对于 cluster-1：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-1"
|
||||
$ kubectl get pods --all-namespaces
|
||||
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user="$(gcloud config get-value core/account)"
|
||||
{{< /text >}}
|
||||
|
||||
1. 对于 cluster-2：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-2"
|
||||
$ kubectl get pods --all-namespaces
|
||||
$ kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user="$(gcloud config get-value core/account)"
|
||||
{{< /text >}}
|
||||
|
||||
## 创建 Google Cloud 防火墙规则{#create-a-google-cloud-firewall-rule}
|
||||
|
||||
为了允许 pod 在每个集群中直接通信，创建以下规则：
|
||||
|
||||
{{< text bash >}}
|
||||
$ function join_by { local IFS="$1"; shift; echo "$*"; }
|
||||
$ ALL_CLUSTER_CIDRS=$(gcloud container clusters list --format='value(clusterIpv4Cidr)' | sort | uniq)
|
||||
$ ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
|
||||
$ ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --format='value(tags.items.[0])' | sort | uniq)
|
||||
$ ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
|
||||
$ gcloud compute firewall-rules create istio-multicluster-test-pods \
|
||||
--allow=tcp,udp,icmp,esp,ah,sctp \
|
||||
--direction=INGRESS \
|
||||
--priority=900 \
|
||||
--source-ranges="${ALL_CLUSTER_CIDRS}" \
|
||||
--target-tags="${ALL_CLUSTER_NETTAGS}" --quiet
|
||||
{{< /text >}}
|
||||
|
||||
## 安装 Istio 控制平面{#install-the-Istio-control-plane}
|
||||
|
||||
以下命令生成 Istio 安装清单，使其安装，并在 `default` 命名空间开启 sidecar 自动注入：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-1"
|
||||
$ helm template install/kubernetes/helm/istio --name istio --namespace istio-system > $HOME/istio_master.yaml
|
||||
$ kubectl create ns istio-system
|
||||
$ helm template install/kubernetes/helm/istio-init --name istio-init --namespace istio-system | kubectl apply -f -
|
||||
$ kubectl apply -f $HOME/istio_master.yaml
|
||||
$ kubectl label namespace default istio-injection=enabled
|
||||
{{< /text >}}
|
||||
|
||||
通过以下命令轮询其状态，以等待 pod 创建完成：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get pods -n istio-system
|
||||
{{< /text >}}
|
||||
|
||||
## 生成远程集群清单{#generate-remote-cluster-manifest}
|
||||
|
||||
1. 获取控制平面 pod 的 IP：
|
||||
|
||||
{{< text bash >}}
|
||||
$ export PILOT_POD_IP=$(kubectl -n istio-system get pod -l istio=pilot -o jsonpath='{.items[0].status.podIP}')
|
||||
$ export POLICY_POD_IP=$(kubectl -n istio-system get pod -l istio=mixer -o jsonpath='{.items[0].status.podIP}')
|
||||
$ export TELEMETRY_POD_IP=$(kubectl -n istio-system get pod -l istio-mixer-type=telemetry -o jsonpath='{.items[0].status.podIP}')
|
||||
{{< /text >}}
|
||||
|
||||
1. 生成远程集群清单；
|
||||
|
||||
{{< text bash >}}
|
||||
$ helm template install/kubernetes/helm/istio \
|
||||
--namespace istio-system --name istio-remote \
|
||||
--values @manifests/UPDATING-CHARTS.md@ \
|
||||
--set global.remotePilotAddress=${PILOT_POD_IP} \
|
||||
--set global.remotePolicyAddress=${POLICY_POD_IP} \
|
||||
--set global.remoteTelemetryAddress=${TELEMETRY_POD_IP} > $HOME/istio-remote.yaml
|
||||
{{< /text >}}
|
||||
|
||||
## 安装远程集群清单中的配置{#install-remote-cluster-manifest}
|
||||
|
||||
以下命令将安装 Istio 最低配置所需的组件， 并在远程集群上的 `default` 命名空间开启 sidecar 自动注入：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-2"
|
||||
$ kubectl create ns istio-system
|
||||
$ kubectl apply -f $HOME/istio-remote.yaml
|
||||
$ kubectl label namespace default istio-injection=enabled
|
||||
{{< /text >}}
|
||||
|
||||
## 为 Istio Pilot 创建远程集群的 kubeconfig{#create-remote-cluster's-kubeconfig-for-Istio-pilot}
|
||||
|
||||
The `istio-remote` Helm 图表创建了一个具有最少访问权限的服务帐户，供 Istio Pilot 发现使用。
|
||||
|
||||
1. 准备环境变量为服务账户 `istio-multi` 创建 `kubeconfig` 文件：
|
||||
|
||||
{{< text bash >}}
|
||||
$ export WORK_DIR=$(pwd)
|
||||
$ CLUSTER_NAME=$(kubectl config view --minify=true -o jsonpath='{.clusters[].name}')
|
||||
$ CLUSTER_NAME="${CLUSTER_NAME##*_}"
|
||||
$ export KUBECFG_FILE=${WORK_DIR}/${CLUSTER_NAME}
|
||||
$ SERVER=$(kubectl config view --minify=true -o jsonpath='{.clusters[].cluster.server}')
|
||||
$ NAMESPACE=istio-system
|
||||
$ SERVICE_ACCOUNT=istio-multi
|
||||
$ SECRET_NAME=$(kubectl get sa ${SERVICE_ACCOUNT} -n ${NAMESPACE} -o jsonpath='{.secrets[].name}')
|
||||
$ CA_DATA=$(kubectl get secret ${SECRET_NAME} -n ${NAMESPACE} -o jsonpath="{.data['ca\.crt']}")
|
||||
$ TOKEN=$(kubectl get secret ${SECRET_NAME} -n ${NAMESPACE} -o jsonpath="{.data['token']}" | base64 --decode)
|
||||
{{< /text >}}
|
||||
|
||||
{{< tip >}}
|
||||
在许多系统中，`openssl enc -d -base64 -A` 是 `base64 --decode` 是的一种替代方式。
|
||||
{{< /tip >}}
|
||||
|
||||
1. 在工作目录中为服务账户 `istio-multi` 创建一个 `kubeconfig` 文件：
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF > ${KUBECFG_FILE}
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
certificate-authority-data: ${CA_DATA}
|
||||
server: ${SERVER}
|
||||
name: ${CLUSTER_NAME}
|
||||
contexts:
|
||||
- context:
|
||||
cluster: ${CLUSTER_NAME}
|
||||
user: ${CLUSTER_NAME}
|
||||
name: ${CLUSTER_NAME}
|
||||
current-context: ${CLUSTER_NAME}
|
||||
kind: Config
|
||||
preferences: {}
|
||||
users:
|
||||
- name: ${CLUSTER_NAME}
|
||||
user:
|
||||
token: ${TOKEN}
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
至此，远程集群的 `kubeconfig` 文件已被创建在 `${WORK_DIR}` 目录中。
|
||||
集群的文件名与原始的 `kubeconfig` 集群名字相同。
|
||||
|
||||
## 配置 Istio 控制平面来发现远程集群{#configure-Istio-control-plane-to-discover-the-remote-cluster}
|
||||
|
||||
创建 secret 并为每一个远程集群标记：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-1"
|
||||
$ kubectl create secret generic ${CLUSTER_NAME} --from-file ${KUBECFG_FILE} -n ${NAMESPACE}
|
||||
$ kubectl label secret ${CLUSTER_NAME} istio/multiCluster=true -n ${NAMESPACE}
|
||||
{{< /text >}}
|
||||
|
||||
## 跨集群部署 Bookinfo 示例{#deploy-the-Bookinfo-example-across-clusters}
|
||||
|
||||
1. 在第一个集群上安装 Bookinfo。移除 `reviews-v3` deployment 来部署在远程上：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-1"
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@
|
||||
$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
|
||||
$ kubectl delete deployment reviews-v3
|
||||
{{< /text >}}
|
||||
|
||||
1. 在远程集群上安装 `reviews-v3` deployment。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-2"
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@ -l service=ratings
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@ -l service=reviews
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@ -l account=reviews
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@ -l app=reviews,version=v3
|
||||
{{< /text >}}
|
||||
|
||||
_注意：_ 该 `ratings` 服务定义被添加到远程集群，因为 `reviews-v3` 是
|
||||
`ratings` 的一个客户端，并创建服务对象以创建 DNS 条目。
|
||||
在 DNS 查询被解析为服务地址后，在 `reviews-v3` pod 中的 Istio sidecar 将确定正确的 `ratings` endpoint。
|
||||
如果额外设置了多集群的 DNS 解决方案，例如联邦 Kubernetes 环境，则上面的步骤是没必要的。
|
||||
|
||||
1. 获取 `istio-ingressgateway` 服务的外部 IP 访问 `bookinfo` 页面以验证 Istio 是否
|
||||
在 review 版本的负载均衡中包括远程的 `reviews-v3` 实例：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl config use-context "gke_${proj}_${zone}_cluster-1"
|
||||
$ kubectl get svc istio-ingressgateway -n istio-system
|
||||
{{< /text >}}
|
||||
|
||||
重复访问 `http://<GATEWAY_IP>/productpage` 并且每个 review 的版本均应负载均衡，
|
||||
包含远程集群（红色星星）中的 `reviews-v3`。或许需要几次（数十次）操作才能演示 `reviews` 版本之间的负载均衡。
|
||||
|
||||
## 卸载 {#uninstalling}
|
||||
|
||||
除了卸载 Istio 之外，还应执行
|
||||
[基于 VPN 的多集群卸载部分](/zh/docs/setup/install/multicluster/shared-vpn/) 中的操作：
|
||||
|
||||
1. 删除 Google Cloud 防火墙规则：
|
||||
|
||||
{{< text bash >}}
|
||||
$ gcloud compute firewall-rules delete istio-multicluster-test-pods --quiet
|
||||
{{< /text >}}
|
||||
|
||||
1. 从不再用于 Istio 的每个集群中删除 `cluster-admin` 集群角色绑定：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl delete clusterrolebinding gke-cluster-admin-binding
|
||||
{{< /text >}}
|
||||
|
||||
1. 删除不再使用的所有 GKE 集群。以下是删除 `cluster-2` 远程集群的命令示例：
|
||||
|
||||
{{< text bash >}}
|
||||
$ gcloud container clusters delete cluster-2 --zone $zone
|
||||
{{< /text >}}
|
||||
|
|
@ -1,233 +0,0 @@
|
|||
---
|
||||
title: IBM Cloud Private
|
||||
description: 跨两个 IBM Cloud Private 集群的多集群网格示例。
|
||||
weight: 70
|
||||
keywords: [kubernetes,multicluster]
|
||||
aliases:
|
||||
- /zh/docs/tasks/multicluster/icp/
|
||||
- /zh/docs/examples/multicluster/icp/
|
||||
---
|
||||
|
||||
本例演示了如何在两个 [IBM Cloud Private](https://www.ibm.com/cloud/private) 集群之间设置网络连接并使用[单网络部署](/zh/docs/ops/deployment/deployment-models/#single-network)以将它们组成一个多集群网格。
|
||||
|
||||
## 创建 IBM Cloud Private 集群{#create-the-IBM-Cloud-Private-clusters}
|
||||
|
||||
1. [安装两个 IBM Cloud Private 集群](https://www.ibm.com/support/knowledgecenter/zh/SSBS6K_3.2.0/installing/install.html).
|
||||
|
||||
{{< warning >}}
|
||||
确保每个集群的 Pod CIDR 范围和服务 CIDR 范围都是唯一的，并且在多集群环境中不会重叠。
|
||||
这可以通过 `cluster/config.yaml` 文件中的 `network_cidr` 和 `service_cluster_ip_range` 来配置。
|
||||
{{< /warning >}}
|
||||
|
||||
{{< text plain >}}
|
||||
# Default IPv4 CIDR is 10.1.0.0/16
|
||||
# Default IPv6 CIDR is fd03::0/112
|
||||
network_cidr: 10.1.0.0/16
|
||||
|
||||
## Kubernetes Settings
|
||||
# Default IPv4 Service Cluster Range is 10.0.0.0/16
|
||||
# Default IPv6 Service Cluster Range is fd02::0/112
|
||||
service_cluster_ip_range: 10.0.0.0/16
|
||||
{{< /text >}}
|
||||
|
||||
1. 在 IBM Cloud Private 集群安装完成后，验证 `kubectl` 可以访问这些集群。在本例中，我们将两个集群命名为 `cluster-1` 和 `cluster-2`。
|
||||
|
||||
1. [使用 `kubectl` 配置 `cluster-1`](https://www.ibm.com/support/knowledgecenter/zh/SSBS6K_3.2.0/manage_cluster/install_kubectl.html)。
|
||||
|
||||
1. 检查集群状态：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl get nodes
|
||||
$ kubectl get pods --all-namespaces
|
||||
{{< /text >}}
|
||||
|
||||
1. 重复以上两步来验证 `cluster-2`。
|
||||
|
||||
## 配置 pod 通过 IBM Cloud Private 集群通信{#configure-pod-communication-across-IBM-Cloud-Private-clusters}
|
||||
|
||||
IBM Cloud Private 默认使用 Calico Node-to-Node Mesh 来管理容器网络。
|
||||
每个节点上的 BGP 客户端会将 IP 路由信息分发到所有节点。
|
||||
|
||||
为了确保 pods 可以跨不同集群通信，您需要在两个集群的所有节点上都配置 IP 路由。
|
||||
综上所述，您需要以下两步以配置 pod 跨两个 IBM Cloud Private 集群通信：
|
||||
|
||||
1. 添加从 `cluster-1` 到 `cluster-2` 的 IP 路由。
|
||||
|
||||
1. 添加从 `cluster-2` 到 `cluster-1` 的 IP 路由。
|
||||
|
||||
{{< warning >}}
|
||||
只有多个 IBM Cloud Private 集群中的所有节点都位于同一子网中，这个方法才有效。
|
||||
直接为位于不同子网中的节点添加 BGP 路由器是行不通的，因为 IP 地址必须通过单跳就能访问。
|
||||
另外，您可以使用 VPN 实现 pod 跨集群通信。请参考[这篇文章](https://medium.com/ibm-cloud/setup-pop-to-pod-communication-across-ibm-cloud-private-clusters-add0b079ebf3)以获取更多细节。
|
||||
{{< /warning >}}
|
||||
|
||||
您可以检查如何添加从 `cluster-1` 到 `cluster-2` 的 IP 路由以验证 pod 之间的跨集群通信。
|
||||
在 Node-to-Node Mesh 模式下，每个节点都将具有连接到群集中对等节点的 IP 路由。
|
||||
在本例中，每个集群有三个节点。
|
||||
|
||||
`cluster-1` 的 `hosts` 文件：
|
||||
|
||||
{{< text plain >}}
|
||||
172.16.160.23 micpnode1
|
||||
172.16.160.27 micpnode2
|
||||
172.16.160.29 micpnode3
|
||||
{{< /text >}}
|
||||
|
||||
`cluster-2` 的 `hosts` 文件：
|
||||
|
||||
{{< text plain >}}
|
||||
172.16.187.14 nicpnode1
|
||||
172.16.187.16 nicpnode2
|
||||
172.16.187.18 nicpnode3
|
||||
{{< /text >}}
|
||||
|
||||
1. 在 `cluster-1` 的所有节点上使用命令 `ip route | grep bird` 获取路由信息。
|
||||
|
||||
{{< text bash >}}
|
||||
$ ip route | grep bird
|
||||
blackhole 10.1.103.128/26 proto bird
|
||||
10.1.176.64/26 via 172.16.160.29 dev tunl0 proto bird onlink
|
||||
10.1.192.0/26 via 172.16.160.27 dev tunl0 proto bird onlink
|
||||
{{< /text >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ ip route | grep bird
|
||||
10.1.103.128/26 via 172.16.160.23 dev tunl0 proto bird onlink
|
||||
10.1.176.64/26 via 172.16.160.29 dev tunl0 proto bird onlink
|
||||
blackhole 10.1.192.0/26 proto bird
|
||||
{{< /text >}}
|
||||
|
||||
{{< text bash >}}
|
||||
$ ip route | grep bird
|
||||
10.1.103.128/26 via 172.16.160.23 dev tunl0 proto bird onlink
|
||||
blackhole 10.1.176.64/26 proto bird
|
||||
10.1.192.0/26 via 172.16.160.27 dev tunl0 proto bird onlink
|
||||
{{< /text >}}
|
||||
|
||||
1. `cluster-1` 中的这三个节点一共有三个 IP 路由。
|
||||
|
||||
{{< text plain >}}
|
||||
10.1.176.64/26 via 172.16.160.29 dev tunl0 proto bird onlink
|
||||
10.1.103.128/26 via 172.16.160.23 dev tunl0 proto bird onlink
|
||||
10.1.192.0/26 via 172.16.160.27 dev tunl0 proto bird onlink
|
||||
{{< /text >}}
|
||||
|
||||
1. 使用以下命令将这三个 IP 路由添加到 `cluster-2` 的所有节点：
|
||||
|
||||
{{< text bash >}}
|
||||
$ ip route add 10.1.176.64/26 via 172.16.160.29
|
||||
$ ip route add 10.1.103.128/26 via 172.16.160.23
|
||||
$ ip route add 10.1.192.0/26 via 172.16.160.27
|
||||
{{< /text >}}
|
||||
|
||||
1. 您可以使用相同的步骤以添加从 `cluster-2` 到 `cluster-1` 的所有 IP 路由。配置完成后，这两个不同集群中的所有 pods 都可以互相通信了。
|
||||
|
||||
1. 从 `cluster-1` ping `cluster-2` 中的 pod IP 以验证 pod 之间的通信。下面是一个 `cluster-2` 中的 pod，其 IP 为 `20.1.58.247`。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl -n kube-system get pod -owide | grep dns
|
||||
kube-dns-ksmq6 1/1 Running 2 28d 20.1.58.247 172.16.187.14 <none>
|
||||
{{< /text >}}
|
||||
|
||||
1. 从 `cluster-1` 的一个节点上 ping 该 pod IP，应该会成功。
|
||||
|
||||
{{< text bash >}}
|
||||
$ ping 20.1.58.247
|
||||
PING 20.1.58.247 (20.1.58.247) 56(84) bytes of data.
|
||||
64 bytes from 20.1.58.247: icmp_seq=1 ttl=63 time=1.73 ms
|
||||
{{< /text >}}
|
||||
|
||||
本节中的这些步骤，通过在两个 IBM Cloud Private 集群中的所有节点之间配置完整的 IP 路由网格，使得 pod 可以在两个集群之间通信。
|
||||
|
||||
## 为多集群安装 Istio{#install-Istio-for-multicluster}
|
||||
|
||||
按照[单网络共享控制平面说明](/zh/docs/setup/install/multicluster/shared-vpn/)在 `cluster-1` 和 `cluster-2` 上安装并配置本地 Istio 控制平面和远程 Istio。
|
||||
|
||||
在本指南中，假定本地 Istio 控制平面部署在 `cluster-1`，远程 Istio 部署在 `cluster-2`。
|
||||
|
||||
## 跨集群部署 Bookinfo 示例{#deploy-the-Bookinfo-example-across-clusters}
|
||||
|
||||
下面的例子启用了[自动注入 sidecar](/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection)。
|
||||
|
||||
1. 在集群 `cluster-1` 上安装 `bookinfo`。删掉 `reviews-v3` deployment，它将在接下来的步骤中被部署到集群 `cluster-2` 上：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f @samples/bookinfo/platform/kube/bookinfo.yaml@
|
||||
$ kubectl apply -f @samples/bookinfo/networking/bookinfo-gateway.yaml@
|
||||
$ kubectl delete deployment reviews-v3
|
||||
{{< /text >}}
|
||||
|
||||
1. 在远程 `cluster-2` 集群上部署 `reviews-v3` 服务以及其它相关服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ cat <<EOF | kubectl apply -f -
|
||||
---
|
||||
##################################################################################################
|
||||
# Ratings service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: ratings
|
||||
labels:
|
||||
app: ratings
|
||||
service: ratings
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
---
|
||||
##################################################################################################
|
||||
# Reviews service
|
||||
##################################################################################################
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: reviews
|
||||
labels:
|
||||
app: reviews
|
||||
service: reviews
|
||||
spec:
|
||||
ports:
|
||||
- port: 9080
|
||||
name: http
|
||||
selector:
|
||||
app: reviews
|
||||
---
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: reviews-v3
|
||||
labels:
|
||||
app: reviews
|
||||
version: v3
|
||||
spec:
|
||||
replicas: 1
|
||||
selector:
|
||||
matchLabels:
|
||||
app: reviews
|
||||
version: v3
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: reviews
|
||||
version: v3
|
||||
spec:
|
||||
containers:
|
||||
- name: reviews
|
||||
image: istio/examples-bookinfo-reviews-v3:1.12.0
|
||||
imagePullPolicy: IfNotPresent
|
||||
ports:
|
||||
- containerPort: 9080
|
||||
---
|
||||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
_请注意：_ `ratings` 服务定义也添加到远程集群是因为 `reviews-v3` 是 `ratings` 服务的客户端，因此 `reviews-v3` 需要 `ratings` 服务的 DNS 条目。
|
||||
`reviews-v3` pod 里的 Istio sidecar 将在 DNS 解析为服务地址后确定适当的 `ratings` 端点。
|
||||
如果另外设置了多群集 DNS 解决方案，例如在联邦 Kubernetes 环境中，这些就不是必须的了。
|
||||
|
||||
1. 为 `istio-ingressgateway` [确定它的 IP 和端口](/zh/docs/tasks/traffic-management/ingress/ingress-control/#determining-the-ingress-i-p-and-ports)为 `INGRESS_HOST` 和 `INGRESS_PORT` 变量以访问网关。
|
||||
|
||||
重复访问 `http://<INGRESS_HOST>:<INGRESS_PORT>/productpage`，每个版本的 `reviews` 都应负载均衡，包括远程集群上的 `reviews-v3`（红色星级）。
|
||||
可能需要几次访问（数十次）才能证明 `reviews` 版本之间是负载均衡的。
|
||||
Loading…
Reference in New Issue