mirror of https://github.com/istio/istio.io.git
[zh] sync 4 files in setup (#13351)
This commit is contained in:
Michael
GitHub
parent
52b96e4461
commit
f7b2fd3873
|
|
@ -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 - <<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)
|
||||
获取完整的配置设置。
|
||||
|
||||
## 就地升级{#in-place-upgrade}
|
||||
## 就地升级 {#in-place-upgrade}
|
||||
|
||||
下载并提取希望升级到的 Istio 版本对应的 `istioctl`。
|
||||
在目标 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}'
|
||||
{{< /text >}}
|
||||
|
||||
## 金丝雀升级{#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 - <<EOF
|
||||
|
|
@ -308,7 +308,7 @@ spec:
|
|||
profile: default
|
||||
{{< /text >}}
|
||||
|
||||
运行该命令后，您将看到两组并排运行的控制平面 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 <none>
|
|||
要完成升级，请给工作负载的命名空间打这个标签：`istio.io/rev=1-8-1`，并重新启动工作负载，
|
||||
就如[数据平面升级](/zh/docs/setup/upgrade/canary/#data-plane)文档的描述。
|
||||
|
||||
## 卸载{#uninstall}
|
||||
## 卸载 {#uninstall}
|
||||
|
||||
如果您使用 Operator 完成了控制平面的金丝雀升级，请运行以下命令卸载旧版本的控件平面，并保留新版本：
|
||||
|
||||
|
|
|
|||
|
|
@ -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 集群。
|
||||
将 `<cluster-name>` 替换为您的集群使用的名称，将 `<zone-name>` 替换为可用区。
|
||||
|
|
@ -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 <zone-name> --machine-type b3c.4x16 \
|
||||
$ ibmcloud ks cluster create classic --zone <zone-name> --machine-type b3c.4x16 \
|
||||
--workers 3 --name <cluster-name>
|
||||
{{< /text >}}
|
||||
|
||||
|
|
@ -48,7 +47,7 @@ IBM 为 IBM Cloud Kubernetes Service 提供了 {{< gloss >}}managed control plan
|
|||
1. 运行以下命令下载您的 `kubectl` 集群配置，然后按照命令输出的说明来设置 `KUBECONFIG` 环境变量。
|
||||
|
||||
{{< text bash >}}
|
||||
$ ibmcloud ks cluster-config <cluster-name>
|
||||
$ ibmcloud ks cluster config --cluster <cluster-name>
|
||||
{{< /text >}}
|
||||
|
||||
{{< warning >}}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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 - <<EOF
|
||||
|
|
@ -553,7 +553,7 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 `
|
|||
`istio-egressgateway`。`istio-egressgateway` 最终把流量转发到 `edition.cnn.com`。
|
||||
|
||||
{{< 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
|
||||
{{< /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 >}}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue