diff --git a/content/zh/docs/setup/install/operator/index.md b/content/zh/docs/setup/install/operator/index.md index 4f172d909e..209920665d 100644 --- a/content/zh/docs/setup/install/operator/index.md +++ b/content/zh/docs/setup/install/operator/index.md @@ -53,7 +53,7 @@ $ istioctl operator init 此命令运行 Operator 在 `istio-operator` 命名空间中创建以下资源： - Operator 自定义资源定义（CRD） -- Operator 控制器的 deployment 对象 +- Operator 控制器的 Deployment 对象 - 一个用来访问 Operator 指标的服务 - Istio Operator 运行必须的 RBAC 规则 @@ -69,13 +69,13 @@ $ istioctl operator init --watchedNamespaces=istio-namespace1,istio-namespace2 {{< tip >}} 您也可以使用 Helm 部署 Operator： -1. 创建 `istio-operator` 命名空间. +1. 创建 `istio-operator` 命名空间。 {{< text syntax=bash snip_id=create_ns_istio_operator >}} $ kubectl create namespace istio-operator {{< /text >}} -1. 使用 Helm 安装 operator. +1. 使用 Helm 安装 Operator。 {{< text syntax=bash snip_id=deploy_istio_operator_helm >}} $ helm install istio-operator manifests/charts/istio-operator \ @@ -83,14 +83,14 @@ $ istioctl operator init --watchedNamespaces=istio-namespace1,istio-namespace2 -n istio-operator {{< /text >}} -注意：为了运行上面的命令您需要 [下载 Istio 的发行版本](/zh/docs/setup/getting-started/#download)。 +注意：为了运行上面的命令，您需要[下载 Istio 的发行版本](/zh/docs/setup/getting-started/#download)。 {{< /tip >}} {{< warning >}} -在 Istio 1.10.0 之前，需要在安装 operator 之前创建命名空间 `istio-system`。 +在 Istio 1.10.0 之前，需要在安装 Operator 之前创建命名空间 `istio-system`。 从 Istio 1.10.0 开始，`istioctl operator init` 将创建 `istio-system` 命名空间。 -如果你使用的不是 `istioctl operator init`，那么 `istio-system` 命名空间需要手动创建。 +如果您使用的不是 `istioctl operator init`，那么 `istio-system` 命名空间需要被手动创建。 {{< /warning >}} ### 使用 operator 安装 Istio {#install-Istio-with-the-operator} @@ -118,7 +118,7 @@ EOF {{< /warning >}} 默认情况下，Istio 控制平面（istiod）将安装在 `istio-system` 命名空间中。 -要将其安装到其他命名空间，请使用 `values.global.istioNamespace` 字段，如下： +要将其安装到其他命名空间，请如下使用 `values.global.istioNamespace` 字段： {{< text syntax=yaml snip_id=none >}} apiVersion: install.istio.io/v1alpha1 @@ -132,7 +132,7 @@ spec: {{< /text >}} {{< tip >}} -Istio Operator 控制器在创建 `IstioOperator` 资源的 90 秒内启动 Istio 的安装。 +Istio Operator 控制器在创建 `IstioOperator` 资源的 90 秒内开始安装 Istio。 Istio 安装过程将在 120 秒内完成。 {{< /tip >}} @@ -154,10 +154,10 @@ istio-ingressgateway-86cb4b6795-9jlrk 1/1 Running 0 68s istiod-b47586647-sf6sw 1/1 Running 0 74s {{< /text >}} -## 更新{#update} +## 更新 {#update} -现在，控制器已经运行起来，您可以通过编辑或替换 `IstioOperator` 来改变 Istio 配置。 -控制器将检测到改变，继而用相应配置更新 Istio 的安装内容。 +现在，控制器已经运行起来，您可以通过编辑或替换 `IstioOperator` 资源来改变 Istio 配置。 +控制器将检测到改变，继而用相应配置更新安装的 Istio。 例如，使用以下命令将安装切换到 `default` 配置： @@ -174,7 +174,7 @@ EOF {{< /text >}} 您还可以启用或禁用组件、修改资源设置。 -例如，启用 `istio-egressgateway` 组件并增加 pilot 的内存要求： +例如，启用 `istio-egressgateway` 组件并增加 pilot 的内存请求： {{< text syntax=bash snip_id=update_to_default_profile_egress >}} $ kubectl apply -f - <}} -## 金丝雀升级{#canary-upgrade} +## 金丝雀升级 {#canary-upgrade} 金丝雀升级的过程类似于 [`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_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 {{< /text >}} -安装 Istio 控制面 demo 配置文件： +安装 Istio 控制平面 demo 配置文件： {{< text syntax=bash snip_id=install_istio_previous_version >}} $ kubectl apply -f - <}} -运行该命令后，您将看到两组并排运行的控制平面 Deployments 和 Services： +运行该命令后，您将看到两组并排运行的控制平面 Deployment 和 Service： {{< text syntax=bash snip_id=get_pods_istio_system >}} $ kubectl get pod -n istio-system -l app=istiod @@ -327,7 +327,7 @@ istiod-{{< istio_full_version_revision >}} ClusterIP 10.111.17.49 要完成升级，请给工作负载的命名空间打这个标签：`istio.io/rev=1-8-1`，并重新启动工作负载， 就如[数据平面升级](/zh/docs/setup/upgrade/canary/#data-plane)文档的描述。 -## 卸载{#uninstall} +## 卸载 {#uninstall} 如果您使用 Operator 完成了控制平面的金丝雀升级，请运行以下命令卸载旧版本的控件平面，并保留新版本： diff --git a/content/zh/docs/setup/platform-setup/ibm/index.md b/content/zh/docs/setup/platform-setup/ibm/index.md index f5fbace090..d98fc7e120 100644 --- a/content/zh/docs/setup/platform-setup/ibm/index.md +++ b/content/zh/docs/setup/platform-setup/ibm/index.md @@ -17,14 +17,13 @@ test: no {{< tip >}} IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plane{{< /gloss >}} 插件， -您可以使用它代替手动安装 Istio。 -请参阅 [Istio on IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-istio) -有关详细信息和说明。 +您可以使用它代替手动安装 Istio。有关详细信息和说明， +请参阅 [Istio on IBM Cloud Kubernetes Service](https://cloud.ibm.com/docs/containers?topic=containers-istio)。 {{< /tip >}} -要在手动安装 Istio 之前准备群集，请按照下列步骤操作： +要在手动安装 Istio 之前准备集群，请按照下列步骤操作： -1. [安装 IBM Cloud CLI，IBM Cloud Kubernetes Service 插件和 Kubernetes CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_install)。 +1. [安装 IBM Cloud CLI、IBM Cloud Kubernetes Service 插件和 Kubernetes CLI](https://cloud.ibm.com/docs/containers?topic=containers-cs_cli_install)。 1. 使用以下命令创建标准的 Kubernetes 集群。 将 `` 替换为您的集群使用的名称，将 `` 替换为可用区。 @@ -32,11 +31,11 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan {{< tip >}} 您可以通过运行 `ibmcloud ks zones` 来显示可用区。 IBM Cloud Kubernetes Service [位置参考指南](https://cloud.ibm.com/docs/containers?topic=containers-regions-and-zones) - 介绍可用区域以及如何指定它们。 + 介绍可用区以及如何指定它们。 {{< /tip >}} {{< text bash >}} - $ ibmcloud ks cluster-create --zone --machine-type b3c.4x16 \ + $ ibmcloud ks cluster create classic --zone --machine-type b3c.4x16 \ --workers 3 --name {{< /text >}} @@ -48,7 +47,7 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan 1. 运行以下命令下载您的 `kubectl` 集群配置，然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。 {{< text bash >}} - $ ibmcloud ks cluster-config + $ ibmcloud ks cluster config --cluster {{< /text >}} {{< warning >}} diff --git a/content/zh/docs/setup/upgrade/canary/index.md b/content/zh/docs/setup/upgrade/canary/index.md index ca236e5faf..1bf7ad5874 100644 --- a/content/zh/docs/setup/upgrade/canary/index.md +++ b/content/zh/docs/setup/upgrade/canary/index.md @@ -83,8 +83,8 @@ istiod-canary-6956db645c-vwhsk 但是，仅安装新版本不会对现有的 Sidecar 代理产生影响。要升级它们，必须将它们配置为指向新的 `istiod-canary` 控制平面。这是在基于命名空间标签的 Sidecar 注入期间控制的 `istio.io/rev`。 -要升级名称空间 `test-ns`，请删除 `istio-injection` 标签，然后添加 `istio.io/rev` 标签以指向 -`canary` 修订版本。`istio-injection` 标签必须移除，因为它的优先级高于 `istio.io/rev`，此标签用于向后兼容性。 +要升级命名空间 `test-ns`，请删除 `istio-injection` 标签，然后添加 `istio.io/rev` 标签以指向 +`canary` 修订版本。为了向后兼容性，`istio-injection` 标签必须移除，因为它的优先级高于 `istio.io/rev`。 {{< text bash >}} $ 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 {{< /text >}} -当 Pod 被重新注入时，它们将被配置为指向 `istiod-canary` 控制平面。你可以使用 `istioctl proxy-status` 来验证。 +当 Pod 被重新注入时，它们将被配置为指向 `istiod-canary` 控制平面。您可以使用 `istioctl proxy-status` 来验证。 {{< text bash >}} $ 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 {{< /text >}} -1. 在每个命名空间中部署一个休眠 pod 示例: +1. 在每个命名空间中部署一个休眠 Pod 示例: {{< text bash >}} $ 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} -升级控制平面和数据平面之后，您可以卸载旧的控制平面。例如，以下命令卸载修订版本的控制平面 `{{< istio_previous_version_revision >}}-1`： +升级控制平面和数据平面之后，您可以卸载旧的控制平面。例如， +以下命令卸载修订版本的控制平面 `{{< istio_previous_version_revision >}}-1`： {{< text bash >}} $ 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 {{< /text >}} -请注意，以上说明仅删除了用于指定控制平面修订版的资源，而未删除与其他控制平面共享的群集作用域资源。 +请注意，以上说明仅删除了用于指定控制平面修订版的资源，而未删除与其他控制平面共享的集群作用域资源。 要完全卸载 Istio，请参阅[卸载指南](/zh/docs/setup/install/istioctl/#uninstall-istio)。 ## 卸载金丝雀控制平面 {#uninstall-canary-control-plane} @@ -228,10 +229,11 @@ $ istioctl uninstall --revision=canary -y 但是，在这种情况下，您必须首先手动重新安装先前版本的网关，因为卸载命令不会自动还原先前原地升级的网关。 {{< tip >}} -确保使用与 `istioctl` 旧控制平面相对应的版本来重新安装旧网关，并且为避免停机，请确保旧网关已启动并正在运行，然后再进行金丝雀卸载。 +确保使用与 `istioctl` 旧控制平面相对应的版本来重新安装旧网关，并且为避免停机， +请确保旧网关已启动并正在运行，然后再进行金丝雀卸载。 {{< /tip >}} -## 清理{#cleanup} +## 清理 {#cleanup} 1. 清理用于金丝雀升级的命名空间与修订标签的例子： @@ -239,7 +241,7 @@ $ istioctl uninstall --revision=canary -y $ kubectl delete ns istio-system test-ns {{< /text >}} -1. 清理用于金丝雀升级的命名空间与修订版本标签的例子： +1. 清理用于金丝雀升级的命名空间与修订版本的例子： {{< text bash >}} $ kubectl delete ns istio-system app-ns-1 app-ns-2 app-ns-3 diff --git a/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md b/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md index b211197cd2..8cf94e2686 100644 --- a/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md +++ b/content/zh/docs/tasks/traffic-management/egress/egress-gateway/index.md @@ -15,44 +15,44 @@ test: yes [控制 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-control)任务展示了如何配置 Istio 以允许网格内部的应用程序访问外部 HTTP 和 HTTPS 服务，但那个任务实际上是通过 -Sidecar 直接调用的外部服务。而这个示例会展示如何配置 Istio 以通过专用的 **egress gateway** +Sidecar 直接调用的外部服务。而这个示例会展示如何配置 Istio 以通过专用的 **Egress Gateway** 服务间接调用外部服务。 -Istio 使用 [Ingress and Egress gateway](/zh/docs/reference/config/networking/gateway/) -配置运行在服务网格边缘的负载均衡。Ingress gateway 允许您定义网格所有入站流量的入口。 -Egress gateway 是一个与 Ingress gateway 对称的概念，它定义了网格的出口。 -Egress gateway 允许您将 Istio 的功能（例如，监视和路由规则）应用于网格的出站流量。 +Istio 使用 [Ingress 和 Egress Gateway](/zh/docs/reference/config/networking/gateway/) +配置运行在服务网格边缘的负载均衡。Ingress Gateway 允许您定义网格所有入站流量的入口。 +Egress Gateway 是一个与 Ingress Gateway 对称的概念，它定义了网格的出口。 +Egress Gateway 允许您将 Istio 的功能（例如，监视和路由规则）应用于网格的出站流量。 ## 使用场景{#use-case} 设想一个对安全有严格要求的组织，要求服务网格所有的出站流量必须经过一组专用节点。 专用节点运行在专门的机器上，与集群中运行应用程序的其他节点隔离。 -这些专用节点用于实施 egress 流量的策略，并且受到比其余节点更严密地监控。 +这些专用节点用于实施 Egress 流量的策略，并且受到比其余节点更严密地监控。 另一个使用场景是集群中的应用节点没有公有 IP，所以在该节点上运行的网格 -Service 无法访问互联网。通过定义 egress gateway，将公有 IP 分配给 -egress gateway 节点，用它引导所有的出站流量，可以使应用节点以受控的方式访问外部服务。 +Service 无法访问互联网。通过定义 Egress gateway，将公有 IP 分配给 +Egress Gateway 节点，用它引导所有的出站流量，可以使应用节点以受控的方式访问外部服务。 {{< boilerplate before-you-begin-egress >}} * [启用 Envoy 访问日志](/zh/docs/tasks/observability/logs/access-log/#enable-envoy-s-access-logging) {{< warning >}} -此任务中的指令在 `default` 命名空间中为出口网关创建目标规则。 +此任务中的指令在 `default` 命名空间中为 Egress gateway 创建目标规则。 并假设客户端 `SOURCE_POD` 也在 `default` 名称空间中运行。如果没有， 目标规则则不会在[目标规则查找路径](/zh/docs/ops/best-practices/traffic-management/#cross-namespace-configuration)上找到， 并且客户端请求将失败。 {{< /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 >}} $ kubectl get pod -l istio=egressgateway -n istio-system {{< /text >}} - 如果没有 Pod 返回，通过接下来的步骤来部署 Istio egress gateway。 + 如果没有 Pod 返回，通过接下来的步骤来部署 Istio Egress Gateway。 1. 如果您使用 `IstioOperator` CR 安装 Istio，请在配置中添加以下字段： @@ -122,14 +122,14 @@ egress gateway 节点，用它引导所有的出站流量，可以使应用节 ... {{< /text >}} - 输出结果应该与 [发起 TLS 的 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中示例中的输出结果相同， + 输出结果应该与[发起 TLS 的 Egress 流量](/zh/docs/tasks/traffic-management/egress/egress-tls-origination/)中示例中的输出结果相同， 都还没有发起 TLS。 1. 为 `edition.cnn.com` 端口 80 创建 egress `Gateway`。并为指向 - egress gateway 的流量创建一个 destination rule。 + Egress Gateway 的流量创建一个 destination rule。 {{< tip >}} - 要通过 egress gateway 引导多个主机，您可以在 `Gateway` 中包含主机列表， + 要通过 Egress Gateway 引导多个主机，您可以在 `Gateway` 中包含主机列表， 或使用 `*` 匹配所有主机。应该将 `DestinationRule` 中的 `subset` 字段用于其他主机。 {{< /tip >}} @@ -216,7 +216,7 @@ egress gateway 节点，用它引导所有的出站流量，可以使应用节 ... {{< /text >}} - The output should be the same as in the step 2. + 输出应与第 2 步中的输出相同。 1. 检查 `istio-egressgateway` Pod 的日志，并查看与我们的请求对应的行。 如果 Istio 部署在 `istio-system` 命名空间中，则打印日志的命令是： @@ -225,13 +225,13 @@ egress gateway 节点，用它引导所有的出站流量，可以使应用节 $ kubectl logs -l istio=egressgateway -c istio-proxy -n istio-system | tail {{< /text >}} - 你应该会看到一行类似于下面这样的内容： + 您应该会看到一行类似于下面这样的内容： {{< 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 - {{< /text >}} - 请注意，您只是将流量从 80 端口重定向到出口网关。到端口 443 的 HTTPS + 请注意，您只是将流量从 80 端口重定向到 Egress Gateway。到端口 443 的 HTTPS 流量直接进入 **edition.cnn.com**。 ### 清理 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 请求（TLS 由应用程序发起）。 -您需要在相应的 `ServiceEntry`、egress `Gateway` 和 `VirtualService` +您需要在相应的 `ServiceEntry`、Egress `Gateway` 和 `VirtualService` 中指定 `TLS` 协议的端口 443。 1. 为 `edition.cnn.com` 定义 `ServiceEntry`： @@ -281,8 +281,8 @@ $ kubectl delete destinationrule egressgateway-for-cnn ... {{< /text >}} -1. 为 `edition.cnn.com` 创建一个 egress `Gateway`。除此之外还需要创建一个 - destination rule 和一个 virtual service，用来引导流量通过 Egress Gateway， +1. 为 `edition.cnn.com` 创建一个 Egress `Gateway`。除此之外还需要创建一个 + 目标规则和一个虚拟服务，用来引导流量通过 Egress Gateway， 并通过 Egress Gateway 与外部服务通信。 {{< tip >}} @@ -333,7 +333,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn - gateways: - mesh port: 443 - sni_hosts: + sniHosts: - edition.cnn.com route: - destination: @@ -345,7 +345,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn - gateways: - istio-egressgateway port: 443 - sni_hosts: + sniHosts: - edition.cnn.com route: - destination: @@ -374,13 +374,13 @@ $ kubectl delete destinationrule egressgateway-for-cnn $ kubectl logs -l istio=egressgateway -n istio-system {{< /text >}} - 你应该会看到类似于下面的内容： + 您应该会看到类似于下面的内容： {{< 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 {{< /text >}} -### 清理 HTTPS gateway{#cleanup-https-gateway} +### 清理 HTTPS Gateway {#cleanup-https-gateway} {{< text bash >}} $ kubectl delete serviceentry cnn @@ -389,28 +389,28 @@ $ kubectl delete virtualservice direct-cnn-through-egress-gateway $ kubectl delete destinationrule egressgateway-for-cnn {{< /text >}} -## 其他安全注意事项{#additional-security-considerations} +## 其他安全注意事项 {#additional-security-considerations} 注意，Istio 中定义的 egress `Gateway` 本身并没有为其所在的节点提供任何特殊处理。 -集群管理员或云提供商可以在专用节点上部署 egress gateway，并引入额外的安全措施， +集群管理员或云提供商可以在专用节点上部署 Egress Gateway，并引入额外的安全措施， 从而使这些节点比网格中的其他节点更安全。 -另外要注意的是，Istio **无法强制**让所有出站流量都经过 egress gateway， -Istio 只是通过 sidecar 代理实现了这种流向。攻击者只要绕过 sidecar 代理， -就可以不经 egress gateway 直接与网格外的服务进行通信，从而避开了 Istio 的控制和监控。 -出于安全考虑，集群管理员和云供应商必须确保网格所有的出站流量都要经过 egress gateway。 +另外要注意的是，Istio **无法强制**让所有出站流量都经过 Egress Gateway， +Istio 只是通过 Sidecar 代理实现了这种流向。攻击者只要绕过 Sidecar 代理， +就可以不经 Egress Gateway 直接与网格外的服务进行通信，从而避开了 Istio 的控制和监控。 +出于安全考虑，集群管理员和云供应商必须确保网格所有的出站流量都要经过 Egress Gateway。 这需要通过 Istio 之外的机制来满足这一要求。例如，集群管理员可以配置防火墙， -拒绝 egress gateway 以外的所有流量。 +拒绝 Egress Gateway 以外的所有流量。 [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 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/) 来阻止绕过 -egress gateway 的出站流量。为了测试网络策略，首先创建一个 `test-egress` 命名空间， +Egress Gateway 的出站流量。为了测试网络策略，首先创建一个 `test-egress` 命名空间， 并在其中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用， 然后尝试发送一个会通过安全网关的外部服务请求。 @@ -444,7 +444,7 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` 200 {{< /text >}} -1. 给 Istio 组件（控制平面和 gateway）所在的命名空间打上标签。例如，你的 Istio +1. 给 Istio 组件（控制平面和 gateway）所在的命名空间打上标签。例如，您的 Istio 组件部署在 `istio-system` 命名空间中，则命令是： {{< text bash >}} @@ -487,8 +487,8 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` {{< /text >}} {{< warning >}} - [网络政策](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 由您的 - Kubernetes 集群中的网络插件实现。根据您的测试群集，以下情况可能不会阻止下面的步骤。 + [网络政策](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/)由您的 + Kubernetes 集群中的网络插件实现。根据您的测试集群，以下情况可能不会阻止下面的步骤。 {{< /warning >}} 1. 重新发送前面的 HTTPS 请求到 [https://edition.cnn.com/politics](https://edition.cnn.com/politics)。 @@ -497,7 +497,7 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` 才能完成。这种配置表明，即使一些恶意的 Pod 绕过了 Sidecar，也会被网络策略拦截，而无法访问到外部站点。 {{< 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 Trying 151.101.65.67... Trying 2a04:4e42:200::323... @@ -528,12 +528,12 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` 1. 检查生成的 Pod，其中应该有了两个容器，其中包含了注入的 sidecar（`istio-proxy`）： {{< 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 {{< /text >}} -1. 在 `default` 命名空间中创建一个与 `sleep` pod 类似的目标规则，用来引导 - `test-egress` 命名空间内的流量经过 egress 网关： +1. 在 `default` 命名空间中创建一个与 `sleep` Pod 类似的目标规则，用来引导 + `test-egress` 命名空间内的流量经过 Egress Gateway： {{< text bash >}} $ kubectl apply -n test-egress -f - <}} - $ 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 {{< /text >}} @@ -564,7 +564,7 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` $ kubectl logs -l istio=egressgateway -n istio-system {{< /text >}} - 你应该会看到一行类似于下面这样的内容： + 您应该会看到一行类似于下面这样的内容： {{< 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 - @@ -583,15 +583,15 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` $ kubectl delete namespace test-egress {{< /text >}} -1. 请参考[清理 HTTPS gateway](#cleanup-https-gateway)一节的内容。 +1. 请参考[清理 HTTPS Gateway](#cleanup-https-gateway) 一节的内容。 ## 故障排除 {#troubleshooting} 1. 如果启用了[双向 TLS 认证](/zh/docs/tasks/security/authentication/authn-policy/#auto-mutual-TLS)， - 请验证 egress gateway 证书的正确性： + 请验证 Egress Gateway 证书的正确性： {{< 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: URI:spiffe://cluster.local/ns/istio-system/sa/istio-egressgateway-service-account {{< /text >}} @@ -600,7 +600,7 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` `openssl` 的 `-servername` 选项可以用来设置 SNI： {{< 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) ... Certificate chain @@ -614,11 +614,11 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 ` ... {{< /text >}} - 如果在上面命令的输出中看到了类似的证书信息，就表明路由是正确的。接下来检查 egress gateway 的代理， + 如果在上面命令的输出中看到了类似的证书信息，就表明路由是正确的。接下来检查 Egress Gateway 的代理， 查找对应请求的计数器（由 `openssl` 和 `curl` 发送，目标是 `edition.cnn.com`）： {{< 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 {{< /text >}}