[zh] sync 4 files in setup (#13351)

This commit is contained in:
Michael 2023-06-14 14:52:10 +08:00 committed by GitHub
parent 52b96e4461
commit f7b2fd3873
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
4 changed files with 87 additions and 86 deletions

View File

@ -53,7 +53,7 @@ $ istioctl operator init
此命令运行 Operator 在 `istio-operator` 命名空间中创建以下资源: 此命令运行 Operator 在 `istio-operator` 命名空间中创建以下资源:
- Operator 自定义资源定义CRD - Operator 自定义资源定义CRD
- Operator 控制器的 deployment 对象 - Operator 控制器的 Deployment 对象
- 一个用来访问 Operator 指标的服务 - 一个用来访问 Operator 指标的服务
- Istio Operator 运行必须的 RBAC 规则 - Istio Operator 运行必须的 RBAC 规则
@ -69,13 +69,13 @@ $ istioctl operator init --watchedNamespaces=istio-namespace1,istio-namespace2
{{< tip >}} {{< tip >}}
您也可以使用 Helm 部署 Operator 您也可以使用 Helm 部署 Operator
1. 创建 `istio-operator` 命名空间. 1. 创建 `istio-operator` 命名空间
{{< text syntax=bash snip_id=create_ns_istio_operator >}} {{< text syntax=bash snip_id=create_ns_istio_operator >}}
$ kubectl create namespace istio-operator $ kubectl create namespace istio-operator
{{< /text >}} {{< /text >}}
1. 使用 Helm 安装 operator. 1. 使用 Helm 安装 Operator。
{{< text syntax=bash snip_id=deploy_istio_operator_helm >}} {{< text syntax=bash snip_id=deploy_istio_operator_helm >}}
$ helm install istio-operator manifests/charts/istio-operator \ $ helm install istio-operator manifests/charts/istio-operator \
@ -83,14 +83,14 @@ $ istioctl operator init --watchedNamespaces=istio-namespace1,istio-namespace2
-n istio-operator -n istio-operator
{{< /text >}} {{< /text >}}
注意:为了运行上面的命令您需要 [下载 Istio 的发行版本](/zh/docs/setup/getting-started/#download)。 注意:为了运行上面的命令您需要[下载 Istio 的发行版本](/zh/docs/setup/getting-started/#download)。
{{< /tip >}} {{< /tip >}}
{{< warning >}} {{< warning >}}
在 Istio 1.10.0 之前,需要在安装 operator 之前创建命名空间 `istio-system` 在 Istio 1.10.0 之前,需要在安装 Operator 之前创建命名空间 `istio-system`
从 Istio 1.10.0 开始,`istioctl operator init` 将创建 `istio-system` 命名空间。 从 Istio 1.10.0 开始,`istioctl operator init` 将创建 `istio-system` 命名空间。
如果使用的不是 `istioctl operator init`,那么 `istio-system` 命名空间需要手动创建。 如果使用的不是 `istioctl operator init`,那么 `istio-system` 命名空间需要手动创建。
{{< /warning >}} {{< /warning >}}
### 使用 operator 安装 Istio {#install-Istio-with-the-operator} ### 使用 operator 安装 Istio {#install-Istio-with-the-operator}
@ -118,7 +118,7 @@ EOF
{{< /warning >}} {{< /warning >}}
默认情况下Istio 控制平面istiod将安装在 `istio-system` 命名空间中。 默认情况下Istio 控制平面istiod将安装在 `istio-system` 命名空间中。
要将其安装到其他命名空间,请使用 `values.global.istioNamespace` 字段,如下 要将其安装到其他命名空间,请如下使用 `values.global.istioNamespace` 字段:
{{< text syntax=yaml snip_id=none >}} {{< text syntax=yaml snip_id=none >}}
apiVersion: install.istio.io/v1alpha1 apiVersion: install.istio.io/v1alpha1
@ -132,7 +132,7 @@ spec:
{{< /text >}} {{< /text >}}
{{< tip >}} {{< tip >}}
Istio Operator 控制器在创建 `IstioOperator` 资源的 90 秒内启动 Istio 的安装 Istio Operator 控制器在创建 `IstioOperator` 资源的 90 秒内开始安装 Istio
Istio 安装过程将在 120 秒内完成。 Istio 安装过程将在 120 秒内完成。
{{< /tip >}} {{< /tip >}}
@ -154,10 +154,10 @@ istio-ingressgateway-86cb4b6795-9jlrk 1/1 Running 0 68s
istiod-b47586647-sf6sw 1/1 Running 0 74s istiod-b47586647-sf6sw 1/1 Running 0 74s
{{< /text >}} {{< /text >}}
## 更新{#update} ## 更新 {#update}
现在,控制器已经运行起来,您可以通过编辑或替换 `IstioOperator` 来改变 Istio 配置。 现在,控制器已经运行起来,您可以通过编辑或替换 `IstioOperator` 资源来改变 Istio 配置。
控制器将检测到改变,继而用相应配置更新 Istio 的安装内容 控制器将检测到改变,继而用相应配置更新安装的 Istio。
例如,使用以下命令将安装切换到 `default` 配置: 例如,使用以下命令将安装切换到 `default` 配置:
@ -174,7 +174,7 @@ EOF
{{< /text >}} {{< /text >}}
您还可以启用或禁用组件、修改资源设置。 您还可以启用或禁用组件、修改资源设置。
例如,启用 `istio-egressgateway` 组件并增加 pilot 的内存求: 例如,启用 `istio-egressgateway` 组件并增加 pilot 的内存求:
{{< text syntax=bash snip_id=update_to_default_profile_egress >}} {{< text syntax=bash snip_id=update_to_default_profile_egress >}}
$ kubectl apply -f - <<EOF $ kubectl apply -f - <<EOF
@ -206,7 +206,7 @@ $ kubectl logs -f -n istio-operator "$(kubectl get pods -n istio-operator -lname
参阅 [`IstioOperator` API](/zh/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec) 参阅 [`IstioOperator` API](/zh/docs/reference/config/istio.operator.v1alpha1/#IstioOperatorSpec)
获取完整的配置设置。 获取完整的配置设置。
## 就地升级{#in-place-upgrade} ## 就地升级 {#in-place-upgrade}
下载并提取希望升级到的 Istio 版本对应的 `istioctl` 下载并提取希望升级到的 Istio 版本对应的 `istioctl`
在目标 Istio 版本的目录中,重新安装 Operator 在目标 Istio 版本的目录中,重新安装 Operator
@ -229,12 +229,12 @@ $ kubectl get pods --namespace istio-system \
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{"\n"}{end}' -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{range .spec.containers[*]}{.image}{", "}{end}{"\n"}{end}'
{{< /text >}} {{< /text >}}
## 金丝雀升级{#canary-upgrade} ## 金丝雀升级 {#canary-upgrade}
金丝雀升级的过程类似于 金丝雀升级的过程类似于
[`istioctl` 版本的金丝雀升级](/zh/docs/setup/upgrade/#canary-upgrades)。 [`istioctl` 版本的金丝雀升级](/zh/docs/setup/upgrade/#canary-upgrades)。
例如,要升级上一节中安装的 Istio 修订版本,首先验证集中名为 `example-istiocontrolplane``IstioOperator` CR 是否存在: 例如,要升级上一节中安装的 Istio 修订版本,首先验证集中名为 `example-istiocontrolplane``IstioOperator` CR 是否存在:
例如要升级 Istio {{< istio_previous_version >}}.0 到 {{< istio_full_version >}} 例如要升级 Istio {{< istio_previous_version >}}.0 到 {{< istio_full_version >}}
首先安装 {{< istio_previous_version >}}.0 首先安装 {{< istio_previous_version >}}.0
@ -249,7 +249,7 @@ $ curl -L https://istio.io/downloadIstio | ISTIO_VERSION={{< istio_previous_vers
$ istio-{{< istio_previous_version >}}.0/bin/istioctl operator init $ istio-{{< istio_previous_version >}}.0/bin/istioctl operator init
{{< /text >}} {{< /text >}}
安装 Istio 控制面 demo 配置文件: 安装 Istio 控制面 demo 配置文件:
{{< text syntax=bash snip_id=install_istio_previous_version >}} {{< text syntax=bash snip_id=install_istio_previous_version >}}
$ kubectl apply -f - <<EOF $ kubectl apply -f - <<EOF
@ -308,7 +308,7 @@ spec:
profile: default profile: default
{{< /text >}} {{< /text >}}
运行该命令后,您将看到两组并排运行的控制平面 Deployments 和 Services 运行该命令后,您将看到两组并排运行的控制平面 Deployment 和 Service
{{< text syntax=bash snip_id=get_pods_istio_system >}} {{< text syntax=bash snip_id=get_pods_istio_system >}}
$ kubectl get pod -n istio-system -l app=istiod $ kubectl get pod -n istio-system -l app=istiod
@ -327,7 +327,7 @@ istiod-{{< istio_full_version_revision >}} ClusterIP 10.111.17.49 <none>
要完成升级,请给工作负载的命名空间打这个标签:`istio.io/rev=1-8-1`,并重新启动工作负载, 要完成升级,请给工作负载的命名空间打这个标签:`istio.io/rev=1-8-1`,并重新启动工作负载,
就如[数据平面升级](/zh/docs/setup/upgrade/canary/#data-plane)文档的描述。 就如[数据平面升级](/zh/docs/setup/upgrade/canary/#data-plane)文档的描述。
## 卸载{#uninstall} ## 卸载 {#uninstall}
如果您使用 Operator 完成了控制平面的金丝雀升级,请运行以下命令卸载旧版本的控件平面,并保留新版本: 如果您使用 Operator 完成了控制平面的金丝雀升级,请运行以下命令卸载旧版本的控件平面,并保留新版本:

View File

@ -17,14 +17,13 @@ test: no
{{< tip >}} {{< tip >}}
IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plane{{< /gloss >}} 插件, IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plane{{< /gloss >}} 插件,
您可以使用它代替手动安装 Istio。 您可以使用它代替手动安装 Istio。有关详细信息和说明
请参阅 [Istio on IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-istio) 请参阅 [Istio on IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-istio)。
有关详细信息和说明。
{{< /tip >}} {{< /tip >}}
要在手动安装 Istio 之前准备集,请按照下列步骤操作: 要在手动安装 Istio 之前准备集,请按照下列步骤操作:
1. [安装 IBM Cloud CLIIBM Cloud Kubernetes Service 插件和 Kubernetes CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_install)。 1. [安装 IBM Cloud CLIIBM Cloud Kubernetes Service 插件和 Kubernetes CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_install)。
1. 使用以下命令创建标准的 Kubernetes 集群。 1. 使用以下命令创建标准的 Kubernetes 集群。
`<cluster-name>` 替换为您的集群使用的名称,将 `<zone-name>` 替换为可用区。 `<cluster-name>` 替换为您的集群使用的名称,将 `<zone-name>` 替换为可用区。
@ -32,11 +31,11 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan
{{< tip >}} {{< tip >}}
您可以通过运行 `ibmcloud ks zones` 来显示可用区。 您可以通过运行 `ibmcloud ks zones` 来显示可用区。
IBM Cloud Kubernetes Service [位置参考指南](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones) IBM Cloud Kubernetes Service [位置参考指南](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones)
介绍可用区以及如何指定它们。 介绍可用区以及如何指定它们。
{{< /tip >}} {{< /tip >}}
{{< text bash >}} {{< text bash >}}
$ ibmcloud ks cluster-create --zone <zone-name> --machine-type b3c.4x16 \ $ ibmcloud ks cluster create classic --zone <zone-name> --machine-type b3c.4x16 \
--workers 3 --name <cluster-name> --workers 3 --name <cluster-name>
{{< /text >}} {{< /text >}}
@ -48,7 +47,7 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan
1. 运行以下命令下载您的 `kubectl` 集群配置,然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。 1. 运行以下命令下载您的 `kubectl` 集群配置,然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。
{{< text bash >}} {{< text bash >}}
$ ibmcloud ks cluster-config <cluster-name> $ ibmcloud ks cluster config --cluster <cluster-name>
{{< /text >}} {{< /text >}}
{{< warning >}} {{< warning >}}

View File

@ -83,8 +83,8 @@ istiod-canary-6956db645c-vwhsk
但是,仅安装新版本不会对现有的 Sidecar 代理产生影响。要升级它们,必须将它们配置为指向新的 但是,仅安装新版本不会对现有的 Sidecar 代理产生影响。要升级它们,必须将它们配置为指向新的
`istiod-canary` 控制平面。这是在基于命名空间标签的 Sidecar 注入期间控制的 `istio.io/rev` `istiod-canary` 控制平面。这是在基于命名空间标签的 Sidecar 注入期间控制的 `istio.io/rev`
要升级名空间 `test-ns`,请删除 `istio-injection` 标签,然后添加 `istio.io/rev` 标签以指向 要升级名空间 `test-ns`,请删除 `istio-injection` 标签,然后添加 `istio.io/rev` 标签以指向
`canary` 修订版本。`istio-injection` 标签必须移除,因为它的优先级高于 `istio.io/rev`,此标签用于向后兼容性 `canary` 修订版本。为了向后兼容性,`istio-injection` 标签必须移除,因为它的优先级高于 `istio.io/rev`
{{< text bash >}} {{< text bash >}}
$ kubectl label namespace test-ns istio-injection- istio.io/rev=canary $ kubectl label namespace test-ns istio-injection- istio.io/rev=canary
@ -96,7 +96,7 @@ $ kubectl label namespace test-ns istio-injection- istio.io/rev=canary
$ kubectl rollout restart deployment -n test-ns $ kubectl rollout restart deployment -n test-ns
{{< /text >}} {{< /text >}}
当 Pod 被重新注入时,它们将被配置为指向 `istiod-canary` 控制平面。可以使用 `istioctl proxy-status` 来验证。 当 Pod 被重新注入时,它们将被配置为指向 `istiod-canary` 控制平面。可以使用 `istioctl proxy-status` 来验证。
{{< text bash >}} {{< text bash >}}
$ istioctl proxy-status | grep "\.test-ns " $ istioctl proxy-status | grep "\.test-ns "
@ -141,7 +141,7 @@ $ istioctl proxy-status | grep "\.test-ns "
$ kubectl label ns app-ns-3 istio.io/rev=prod-canary $ kubectl label ns app-ns-3 istio.io/rev=prod-canary
{{< /text >}} {{< /text >}}
1. 在每个命名空间中部署一个休眠 pod 示例: 1. 在每个命名空间中部署一个休眠 Pod 示例:
{{< text bash >}} {{< text bash >}}
$ kubectl apply -n app-ns-1 -f samples/sleep/sleep.yaml $ kubectl apply -n app-ns-1 -f samples/sleep/sleep.yaml
@ -194,7 +194,8 @@ $ istioctl tag set default --revision {{< istio_full_version_revision >}}
## 卸载旧的控制平面 {#uninstall-old-control-plane} ## 卸载旧的控制平面 {#uninstall-old-control-plane}
升级控制平面和数据平面之后,您可以卸载旧的控制平面。例如,以下命令卸载修订版本的控制平面 `{{< istio_previous_version_revision >}}-1` 升级控制平面和数据平面之后,您可以卸载旧的控制平面。例如,
以下命令卸载修订版本的控制平面 `{{< istio_previous_version_revision >}}-1`
{{< text bash >}} {{< text bash >}}
$ istioctl uninstall --revision {{< istio_previous_version_revision >}}-1 -y $ istioctl uninstall --revision {{< istio_previous_version_revision >}}-1 -y
@ -214,7 +215,7 @@ NAME READY STATUS RESTARTS AGE
istiod-canary-55887f699c-t8bh8 1/1 Running 0 27m istiod-canary-55887f699c-t8bh8 1/1 Running 0 27m
{{< /text >}} {{< /text >}}
请注意,以上说明仅删除了用于指定控制平面修订版的资源,而未删除与其他控制平面共享的集作用域资源。 请注意,以上说明仅删除了用于指定控制平面修订版的资源,而未删除与其他控制平面共享的集作用域资源。
要完全卸载 Istio请参阅[卸载指南](/zh/docs/setup/install/istioctl/#uninstall-istio)。 要完全卸载 Istio请参阅[卸载指南](/zh/docs/setup/install/istioctl/#uninstall-istio)。
## 卸载金丝雀控制平面 {#uninstall-canary-control-plane} ## 卸载金丝雀控制平面 {#uninstall-canary-control-plane}
@ -228,10 +229,11 @@ $ istioctl uninstall --revision=canary -y
但是,在这种情况下,您必须首先手动重新安装先前版本的网关,因为卸载命令不会自动还原先前原地升级的网关。 但是,在这种情况下,您必须首先手动重新安装先前版本的网关,因为卸载命令不会自动还原先前原地升级的网关。
{{< tip >}} {{< tip >}}
确保使用与 `istioctl` 旧控制平面相对应的版本来重新安装旧网关,并且为避免停机,请确保旧网关已启动并正在运行,然后再进行金丝雀卸载。 确保使用与 `istioctl` 旧控制平面相对应的版本来重新安装旧网关,并且为避免停机,
请确保旧网关已启动并正在运行,然后再进行金丝雀卸载。
{{< /tip >}} {{< /tip >}}
## 清理{#cleanup} ## 清理 {#cleanup}
1. 清理用于金丝雀升级的命名空间与修订标签的例子: 1. 清理用于金丝雀升级的命名空间与修订标签的例子:
@ -239,7 +241,7 @@ $ istioctl uninstall --revision=canary -y
$ kubectl delete ns istio-system test-ns $ kubectl delete ns istio-system test-ns
{{< /text >}} {{< /text >}}
1. 清理用于金丝雀升级的命名空间与修订版本标签的例子: 1. 清理用于金丝雀升级的命名空间与修订版本的例子:
{{< text bash >}} {{< text bash >}}
$ kubectl delete ns istio-system app-ns-1 app-ns-2 app-ns-3 $ kubectl delete ns istio-system app-ns-1 app-ns-2 app-ns-3

View File

@ -15,44 +15,44 @@ test: yes
[控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-control)任务展示了如何配置 [控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-control)任务展示了如何配置
Istio 以允许网格内部的应用程序访问外部 HTTP 和 HTTPS 服务,但那个任务实际上是通过 Istio 以允许网格内部的应用程序访问外部 HTTP 和 HTTPS 服务,但那个任务实际上是通过
Sidecar 直接调用的外部服务。而这个示例会展示如何配置 Istio 以通过专用的 **egress gateway** Sidecar 直接调用的外部服务。而这个示例会展示如何配置 Istio 以通过专用的 **Egress Gateway**
服务间接调用外部服务。 服务间接调用外部服务。
Istio 使用 [Ingress and Egress gateway](/zh/docs/reference/config/networking/gateway/) Istio 使用 [Ingress 和 Egress Gateway](/zh/docs/reference/config/networking/gateway/)
配置运行在服务网格边缘的负载均衡。Ingress gateway 允许您定义网格所有入站流量的入口。 配置运行在服务网格边缘的负载均衡。Ingress Gateway 允许您定义网格所有入站流量的入口。
Egress gateway 是一个与 Ingress gateway 对称的概念,它定义了网格的出口。 Egress Gateway 是一个与 Ingress Gateway 对称的概念,它定义了网格的出口。
Egress gateway 允许您将 Istio 的功能(例如,监视和路由规则)应用于网格的出站流量。 Egress Gateway 允许您将 Istio 的功能(例如,监视和路由规则)应用于网格的出站流量。
## 使用场景{#use-case} ## 使用场景{#use-case}
设想一个对安全有严格要求的组织,要求服务网格所有的出站流量必须经过一组专用节点。 设想一个对安全有严格要求的组织,要求服务网格所有的出站流量必须经过一组专用节点。
专用节点运行在专门的机器上,与集群中运行应用程序的其他节点隔离。 专用节点运行在专门的机器上,与集群中运行应用程序的其他节点隔离。
这些专用节点用于实施 egress 流量的策略,并且受到比其余节点更严密地监控。 这些专用节点用于实施 Egress 流量的策略,并且受到比其余节点更严密地监控。
另一个使用场景是集群中的应用节点没有公有 IP所以在该节点上运行的网格 另一个使用场景是集群中的应用节点没有公有 IP所以在该节点上运行的网格
Service 无法访问互联网。通过定义 egress gateway将公有 IP 分配给 Service 无法访问互联网。通过定义 Egress gateway将公有 IP 分配给
egress gateway 节点,用它引导所有的出站流量,可以使应用节点以受控的方式访问外部服务。 Egress Gateway 节点,用它引导所有的出站流量,可以使应用节点以受控的方式访问外部服务。
{{< boilerplate before-you-begin-egress >}} {{< boilerplate before-you-begin-egress >}}
* [启用 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging) * [启用 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging)
{{< warning >}} {{< warning >}}
此任务中的指令在 `default` 命名空间中为出口网关创建目标规则。 此任务中的指令在 `default` 命名空间中为 Egress gateway 创建目标规则。
并假设客户端 `SOURCE_POD` 也在 `default` 名称空间中运行。如果没有, 并假设客户端 `SOURCE_POD` 也在 `default` 名称空间中运行。如果没有,
目标规则则不会在[目标规则查找路径](/zh/docs/ops/best-practices/traffic-management/#cross-namespace-configuration)上找到, 目标规则则不会在[目标规则查找路径](/zh/docs/ops/best-practices/traffic-management/#cross-namespace-configuration)上找到,
并且客户端请求将失败。 并且客户端请求将失败。
{{< /warning >}} {{< /warning >}}
## 部署 Istio egress gateway {#deploy-Istio-egress-gateway} ## 部署 Istio Egress Gateway {#deploy-Istio-egress-gateway}
1. 检查 Istio egress gateway 是否已布署: 1. 检查 Istio Egress Gateway 是否已布署:
{{< text bash >}} {{< text bash >}}
$ kubectl get pod -l istio=egressgateway -n istio-system $ kubectl get pod -l istio=egressgateway -n istio-system
{{< /text >}} {{< /text >}}
如果没有 Pod 返回,通过接下来的步骤来部署 Istio egress gateway。 如果没有 Pod 返回,通过接下来的步骤来部署 Istio Egress Gateway。
1. 如果您使用 `IstioOperator` CR 安装 Istio请在配置中添加以下字段 1. 如果您使用 `IstioOperator` CR 安装 Istio请在配置中添加以下字段
@ -122,14 +122,14 @@ egress gateway 节点,用它引导所有的出站流量,可以使应用节
... ...
{{< /text >}} {{< /text >}}
输出结果应该与 [发起 TLS 的 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中示例中的输出结果相同, 输出结果应该与[发起 TLS 的 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中示例中的输出结果相同,
都还没有发起 TLS。 都还没有发起 TLS。
1. 为 `edition.cnn.com` 端口 80 创建 egress `Gateway`。并为指向 1. 为 `edition.cnn.com` 端口 80 创建 egress `Gateway`。并为指向
egress gateway 的流量创建一个 destination rule。 Egress Gateway 的流量创建一个 destination rule。
{{< tip >}} {{< tip >}}
要通过 egress gateway 引导多个主机,您可以在 `Gateway` 中包含主机列表, 要通过 Egress Gateway 引导多个主机,您可以在 `Gateway` 中包含主机列表,
或使用 `*` 匹配所有主机。应该将 `DestinationRule` 中的 `subset` 字段用于其他主机。 或使用 `*` 匹配所有主机。应该将 `DestinationRule` 中的 `subset` 字段用于其他主机。
{{< /tip >}} {{< /tip >}}
@ -216,7 +216,7 @@ egress gateway 节点,用它引导所有的出站流量,可以使应用节
... ...
{{< /text >}} {{< /text >}}
The output should be the same as in the step 2. 输出应与第 2 步中的输出相同。
1. 检查 `istio-egressgateway` Pod 的日志,并查看与我们的请求对应的行。 1. 检查 `istio-egressgateway` Pod 的日志,并查看与我们的请求对应的行。
如果 Istio 部署在 `istio-system` 命名空间中,则打印日志的命令是: 如果 Istio 部署在 `istio-system` 命名空间中,则打印日志的命令是:
@ -225,13 +225,13 @@ egress gateway 节点,用它引导所有的出站流量,可以使应用节
$ kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail $ kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail
{{< /text >}} {{< /text >}}
应该会看到一行类似于下面这样的内容: 应该会看到一行类似于下面这样的内容:
{{< text plain >}} {{< text plain >}}
[2019-09-03T20:57:49.103Z] "GET /politics HTTP/2" 301 - "-" "-" 0 0 90 89 "10.244.2.10" "curl/7.64.0" "ea379962-9b5c-4431-ab66-f01994f5a5a5" "edition.cnn.com" "151.101.65.67:80" outbound|80||edition.cnn.com - 10.244.1.5:80 10.244.2.10:50482 edition.cnn.com - [2019-09-03T20:57:49.103Z] "GET /politics HTTP/2" 301 - "-" "-" 0 0 90 89 "10.244.2.10" "curl/7.64.0" "ea379962-9b5c-4431-ab66-f01994f5a5a5" "edition.cnn.com" "151.101.65.67:80" outbound|80||edition.cnn.com - 10.244.1.5:80 10.244.2.10:50482 edition.cnn.com -
{{< /text >}} {{< /text >}}
请注意,您只是将流量从 80 端口重定向到出口网关。到端口 443 的 HTTPS 请注意,您只是将流量从 80 端口重定向到 Egress Gateway。到端口 443 的 HTTPS
流量直接进入 **edition.cnn.com** 流量直接进入 **edition.cnn.com**
### 清理 HTTP gateway {#cleanup-http-gateway} ### 清理 HTTP gateway {#cleanup-http-gateway}
@ -248,7 +248,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
## 用 Egress gateway 发起 HTTPS 请求 {#egress-gateway-for-https-traffic} ## 用 Egress gateway 发起 HTTPS 请求 {#egress-gateway-for-https-traffic}
接下来尝试使用 Egress Gateway 发起 HTTPS 请求TLS 由应用程序发起)。 接下来尝试使用 Egress Gateway 发起 HTTPS 请求TLS 由应用程序发起)。
您需要在相应的 `ServiceEntry`egress `Gateway``VirtualService` 您需要在相应的 `ServiceEntry`Egress `Gateway``VirtualService`
中指定 `TLS` 协议的端口 443。 中指定 `TLS` 协议的端口 443。
1. 为 `edition.cnn.com` 定义 `ServiceEntry` 1. 为 `edition.cnn.com` 定义 `ServiceEntry`
@ -281,8 +281,8 @@ $ kubectl delete destinationrule egressgateway-for-cnn
... ...
{{< /text >}} {{< /text >}}
1. 为 `edition.cnn.com` 创建一个 egress `Gateway`。除此之外还需要创建一个 1. 为 `edition.cnn.com` 创建一个 Egress `Gateway`。除此之外还需要创建一个
destination rule 和一个 virtual service,用来引导流量通过 Egress Gateway 目标规则和一个虚拟服务,用来引导流量通过 Egress Gateway
并通过 Egress Gateway 与外部服务通信。 并通过 Egress Gateway 与外部服务通信。
{{< tip >}} {{< tip >}}
@ -333,7 +333,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
- gateways: - gateways:
- mesh - mesh
port: 443 port: 443
sni_hosts: sniHosts:
- edition.cnn.com - edition.cnn.com
route: route:
- destination: - destination:
@ -345,7 +345,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
- gateways: - gateways:
- istio-egressgateway - istio-egressgateway
port: 443 port: 443
sni_hosts: sniHosts:
- edition.cnn.com - edition.cnn.com
route: route:
- destination: - destination:
@ -374,13 +374,13 @@ $ kubectl delete destinationrule egressgateway-for-cnn
$ kubectl logs -l istio=egressgateway -n istio-system $ kubectl logs -l istio=egressgateway -n istio-system
{{< /text >}} {{< /text >}}
应该会看到类似于下面的内容: 应该会看到类似于下面的内容:
{{< text plain >}} {{< text plain >}}
[2019-01-02T11:46:46.981Z] "- - -" 0 - 627 1879689 44 - "-" "-" "-" "-" "151.101.129.67:443" outbound|443||edition.cnn.com 172.30.109.80:41122 172.30.109.80:443 172.30.109.112:59970 edition.cnn.com [2019-01-02T11:46:46.981Z] "- - -" 0 - 627 1879689 44 - "-" "-" "-" "-" "151.101.129.67:443" outbound|443||edition.cnn.com 172.30.109.80:41122 172.30.109.80:443 172.30.109.112:59970 edition.cnn.com
{{< /text >}} {{< /text >}}
### 清理 HTTPS gateway{#cleanup-https-gateway} ### 清理 HTTPS Gateway {#cleanup-https-gateway}
{{< text bash >}} {{< text bash >}}
$ kubectl delete serviceentry cnn $ kubectl delete serviceentry cnn
@ -389,28 +389,28 @@ $ kubectl delete virtualservice direct-cnn-through-egress-gateway
$ kubectl delete destinationrule egressgateway-for-cnn $ kubectl delete destinationrule egressgateway-for-cnn
{{< /text >}} {{< /text >}}
## 其他安全注意事项{#additional-security-considerations} ## 其他安全注意事项 {#additional-security-considerations}
注意Istio 中定义的 egress `Gateway` 本身并没有为其所在的节点提供任何特殊处理。 注意Istio 中定义的 egress `Gateway` 本身并没有为其所在的节点提供任何特殊处理。
集群管理员或云提供商可以在专用节点上部署 egress gateway并引入额外的安全措施 集群管理员或云提供商可以在专用节点上部署 Egress Gateway并引入额外的安全措施
从而使这些节点比网格中的其他节点更安全。 从而使这些节点比网格中的其他节点更安全。
另外要注意的是Istio **无法强制**让所有出站流量都经过 egress gateway 另外要注意的是Istio **无法强制**让所有出站流量都经过 Egress Gateway
Istio 只是通过 sidecar 代理实现了这种流向。攻击者只要绕过 sidecar 代理, Istio 只是通过 Sidecar 代理实现了这种流向。攻击者只要绕过 Sidecar 代理,
就可以不经 egress gateway 直接与网格外的服务进行通信,从而避开了 Istio 的控制和监控。 就可以不经 Egress Gateway 直接与网格外的服务进行通信,从而避开了 Istio 的控制和监控。
出于安全考虑,集群管理员和云供应商必须确保网格所有的出站流量都要经过 egress gateway。 出于安全考虑,集群管理员和云供应商必须确保网格所有的出站流量都要经过 Egress Gateway。
这需要通过 Istio 之外的机制来满足这一要求。例如,集群管理员可以配置防火墙, 这需要通过 Istio 之外的机制来满足这一要求。例如,集群管理员可以配置防火墙,
拒绝 egress gateway 以外的所有流量。 拒绝 Egress Gateway 以外的所有流量。
[Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 也能禁止所有不是从 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 也能禁止所有不是从
egress gateway 发起的出站流量([下一节](#apply-Kubernetes-network-policies)有一个这样的例子)。 Egress Gateway 发起的出站流量([下一节](#apply-Kubernetes-network-policies)有一个这样的例子)。
此外,集群管理员和云供应商还可以对网络进行限制,让运行应用的节点只能通过 gateway 来访问外部网络。 此外,集群管理员和云供应商还可以对网络进行限制,让运行应用的节点只能通过 gateway 来访问外部网络。
要实现这一限制,可以只给 gateway Pod 分配公网 IP并且可以配置 NAT 设备, 要实现这一限制,可以只给 gateway Pod 分配公网 IP并且可以配置 NAT 设备,
丢弃来自 egress gateway Pod 之外的所有流量。 丢弃来自 Egress Gateway Pod 之外的所有流量。
## 应用 Kubernetes 网络策略{#apply-Kubernetes-network-policies} ## 应用 Kubernetes 网络策略 {#apply-Kubernetes-network-policies}
本节中展示了如何创建 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 来阻止绕过 本节中展示了如何创建 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 来阻止绕过
egress gateway 的出站流量。为了测试网络策略,首先创建一个 `test-egress` 命名空间, Egress Gateway 的出站流量。为了测试网络策略,首先创建一个 `test-egress` 命名空间,
并在其中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用, 并在其中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用,
然后尝试发送一个会通过安全网关的外部服务请求。 然后尝试发送一个会通过安全网关的外部服务请求。
@ -444,7 +444,7 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
200 200
{{< /text >}} {{< /text >}}
1. 给 Istio 组件(控制平面和 gateway所在的命名空间打上标签。例如的 Istio 1. 给 Istio 组件(控制平面和 gateway所在的命名空间打上标签。例如的 Istio
组件部署在 `istio-system` 命名空间中,则命令是: 组件部署在 `istio-system` 命名空间中,则命令是:
{{< text bash >}} {{< text bash >}}
@ -487,8 +487,8 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
{{< /text >}} {{< /text >}}
{{< warning >}} {{< warning >}}
[网络政策](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 由您的 [网络政策](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/)由您的
Kubernetes 集群中的网络插件实现。根据您的测试集,以下情况可能不会阻止下面的步骤。 Kubernetes 集群中的网络插件实现。根据您的测试集,以下情况可能不会阻止下面的步骤。
{{< /warning >}} {{< /warning >}}
1. 重新发送前面的 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。 1. 重新发送前面的 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。
@ -497,7 +497,7 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
才能完成。这种配置表明,即使一些恶意的 Pod 绕过了 Sidecar也会被网络策略拦截而无法访问到外部站点。 才能完成。这种配置表明,即使一些恶意的 Pod 绕过了 Sidecar也会被网络策略拦截而无法访问到外部站点。
{{< text bash >}} {{< text bash >}}
$ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -c sleep -- curl -v https://edition.cnn.com/politics $ kubectl exec "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -c sleep -- curl -v -sS https://edition.cnn.com/politics
Hostname was NOT found in DNS cache Hostname was NOT found in DNS cache
Trying 151.101.65.67... Trying 151.101.65.67...
Trying 2a04:4e42:200::323... Trying 2a04:4e42:200::323...
@ -528,12 +528,12 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
1. 检查生成的 Pod其中应该有了两个容器其中包含了注入的 sidecar`istio-proxy` 1. 检查生成的 Pod其中应该有了两个容器其中包含了注入的 sidecar`istio-proxy`
{{< text bash >}} {{< text bash >}}
$ kubectl get pod $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -o jsonpath='{.spec.containers[*].name}' $ kubectl get pod "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -o jsonpath='{.spec.containers[*].name}'
sleep istio-proxy sleep istio-proxy
{{< /text >}} {{< /text >}}
1. 在 `default` 命名空间中创建一个与 `sleep` pod 类似的目标规则,用来引导 1. 在 `default` 命名空间中创建一个与 `sleep` Pod 类似的目标规则,用来引导
`test-egress` 命名空间内的流量经过 egress 网关 `test-egress` 命名空间内的流量经过 Egress Gateway
{{< text bash >}} {{< text bash >}}
$ kubectl apply -n test-egress -f - <<EOF $ kubectl apply -n test-egress -f - <<EOF
@ -553,7 +553,7 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
`istio-egressgateway`。`istio-egressgateway` 最终把流量转发到 `edition.cnn.com` `istio-egressgateway`。`istio-egressgateway` 最终把流量转发到 `edition.cnn.com`
{{< text bash >}} {{< text bash >}}
$ kubectl exec -it $(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name}) -n test-egress -c sleep -- curl -s -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics $ kubectl exec "$(kubectl get pod -n test-egress -l app=sleep -o jsonpath={.items..metadata.name})" -n test-egress -c sleep -- curl -sS -o /dev/null -w "%{http_code}\n" https://edition.cnn.com/politics
200 200
{{< /text >}} {{< /text >}}
@ -564,7 +564,7 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
$ kubectl logs -l istio=egressgateway -n istio-system $ kubectl logs -l istio=egressgateway -n istio-system
{{< /text >}} {{< /text >}}
应该会看到一行类似于下面这样的内容: 应该会看到一行类似于下面这样的内容:
{{< text plain >}} {{< text plain >}}
[2020-03-06T18:12:33.101Z] "- - -" 0 - "-" "-" 906 1352475 35 - "-" "-" "-" "-" "151.101.193.67:443" outbound|443||edition.cnn.com 172.30.223.53:39460 172.30.223.53:443 172.30.223.58:38138 edition.cnn.com - [2020-03-06T18:12:33.101Z] "- - -" 0 - "-" "-" 906 1352475 35 - "-" "-" "-" "-" "151.101.193.67:443" outbound|443||edition.cnn.com 172.30.223.53:39460 172.30.223.53:443 172.30.223.58:38138 edition.cnn.com -
@ -583,15 +583,15 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
$ kubectl delete namespace test-egress $ kubectl delete namespace test-egress
{{< /text >}} {{< /text >}}
1. 请参考[清理 HTTPS gateway](#cleanup-https-gateway)一节的内容。 1. 请参考[清理 HTTPS Gateway](#cleanup-https-gateway) 一节的内容。
## 故障排除 {#troubleshooting} ## 故障排除 {#troubleshooting}
1. 如果启用了[双向 TLS 认证](/zh/docs/tasks/security/authentication/authn-policy/#auto-mutual-TLS) 1. 如果启用了[双向 TLS 认证](/zh/docs/tasks/security/authentication/authn-policy/#auto-mutual-TLS)
请验证 egress gateway 证书的正确性: 请验证 Egress Gateway 证书的正确性:
{{< text bash >}} {{< text bash >}}
$ kubectl exec -i -n istio-system $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -- cat /etc/certs/cert-chain.pem | openssl x509 -text -noout | grep 'Subject Alternative Name' -A 1 $ kubectl exec -i -n istio-system "$(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}')" -- cat /etc/certs/cert-chain.pem | openssl x509 -text -noout | grep 'Subject Alternative Name' -A 1
X509v3 Subject Alternative Name: X509v3 Subject Alternative Name:
URI:spiffe://cluster.local/ns/istio-system/sa/istio-egressgateway-service-account URI:spiffe://cluster.local/ns/istio-system/sa/istio-egressgateway-service-account
{{< /text >}} {{< /text >}}
@ -600,7 +600,7 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
`openssl``-servername` 选项可以用来设置 SNI `openssl``-servername` 选项可以用来设置 SNI
{{< text bash >}} {{< text bash >}}
$ kubectl exec -it $SOURCE_POD -c sleep -- openssl s_client -connect edition.cnn.com:443 -servername edition.cnn.com $ kubectl exec "$SOURCE_POD" -c sleep -- openssl s_client -connect edition.cnn.com:443 -servername edition.cnn.com
CONNECTED(00000003) CONNECTED(00000003)
... ...
Certificate chain Certificate chain
@ -614,11 +614,11 @@ egress gateway 的出站流量。为了测试网络策略,首先创建一个 `
... ...
{{< /text >}} {{< /text >}}
如果在上面命令的输出中看到了类似的证书信息,就表明路由是正确的。接下来检查 egress gateway 的代理, 如果在上面命令的输出中看到了类似的证书信息,就表明路由是正确的。接下来检查 Egress Gateway 的代理,
查找对应请求的计数器(由 `openssl``curl` 发送,目标是 `edition.cnn.com` 查找对应请求的计数器(由 `openssl``curl` 发送,目标是 `edition.cnn.com`
{{< text bash >}} {{< text bash >}}
$ kubectl exec $(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}') -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total $ kubectl exec "$(kubectl get pod -l istio=egressgateway -n istio-system -o jsonpath='{.items[0].metadata.name}')" -c istio-proxy -n istio-system -- pilot-agent request GET stats | grep edition.cnn.com.upstream_cx_total
cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2 cluster.outbound|443||edition.cnn.com.upstream_cx_total: 2
{{< /text >}} {{< /text >}}