mirror of https://github.com/istio/istio.io.git
[zh] Update k8s doc site links to Chinese version for zh docs (#13138)
* Update k8s links to Chinese version for Chinese docs * Update content/zh/blog/2017/0.1-canary/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2017/0.1-canary/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2018/egress-monitoring-access-control/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2017/0.1-canary/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2017/0.1-canary/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2018/egress-tcp/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2019/egress-traffic-control-in-istio-part-1/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> * Update content/zh/blog/2019/egress-traffic-control-in-istio-part-2/index.md Co-authored-by: Michael <haifeng.yao@daocloud.io> --------- Co-authored-by: Michael <haifeng.yao@daocloud.io>
This commit is contained in:
Wilson Wu
GitHub
parent
e125dc3553
commit
6ef6a78357
|
|
@ -3,4 +3,8 @@ title: 如何验证流量是否使用双向 TLS 加密？
|
|||
weight: 25
|
||||
---
|
||||
|
||||
如果您使用 `values.global.proxy.privileged=true` 安装 Istio，您可以使用 `tcpdump` 来确定加密状态。同样在 Kubernetes 1.23 及以后的版本中，作为将 Istio 安装为特权用户的另一种选择，您可以使用 `kubectl debug` 在[ephemeral container](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)中运行 `tcpdump` 。有关说明，请参见 [Istio 双向 TLS 迁移](/zh/docs/tasks/security/authentication/mtls-migration)。
|
||||
如果您使用 `values.global.proxy.privileged=true` 安装 Istio，
|
||||
您可以使用 `tcpdump` 来确定加密状态。同样在 Kubernetes 1.23 及以后的版本中，
|
||||
作为将 Istio 安装为特权用户的另一种选择，
|
||||
您可以使用 `kubectl debug` 在 [ephemeral container](https://kubernetes.io/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container) 中运行 `tcpdump`。
|
||||
有关说明，请参见 [Istio 双向 TLS 迁移](/zh/docs/tasks/security/authentication/mtls-migration)。
|
||||
|
|
|
|||
|
|
@ -44,9 +44,10 @@ Istio Auth 基于双向 TLS 和 X.509 等行业标准。此外，Google 还积
|
|||
|
||||
### 强身份认证{#strong-identity}
|
||||
|
||||
Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)来识别服务运行的身份。身份用于建立信任和定义服务级别访问策略。身份在服务部署时分配，并在 X.509 证书的 SAN（主题备用名称）字段中进行编码。使用服务帐户作为身份具有以下优点：
|
||||
Istio Auth 使用了 [Kubernetes 服务帐户](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 来识别服务运行的身份。
|
||||
身份用于建立信任和定义服务级别访问策略。身份在服务部署时分配，并在 X.509 证书的 SAN（主题备用名称）字段中进行编码。使用服务帐户作为身份具有以下优点：
|
||||
|
||||
* 管理员可以使用 Kubernetes 1.6 中引入的 [RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) 功能配置谁有权访问服务帐户
|
||||
* 管理员可以使用 Kubernetes 1.6 中引入的 [RBAC](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/) 功能配置谁有权访问服务帐户
|
||||
|
||||
* 灵活地识别人类用户，服务或一组服务
|
||||
|
||||
|
|
@ -62,7 +63,7 @@ Istio Auth 为每个集群提供 CA（证书颁发机构），并可对密钥和
|
|||
|
||||
* 为每个服务帐户生成密钥和证书对。
|
||||
|
||||
* 使用 [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) 将密钥和证书分发到相应的 pod。
|
||||
* 使用 [Kubernetes Secrets](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) 将密钥和证书分发到相应的 pod。
|
||||
|
||||
* 定期轮换密钥和证书。
|
||||
|
||||
|
|
|
|||
|
|
@ -15,13 +15,26 @@ aliases:
|
|||
|
||||
采用 [Istio](/zh/) 项目的一大好处就是为服务金丝雀方式部署提供了控制便利。金丝雀部署（或上线）背后的想法是通过让一小部分用户流量引入的新版本进行测试，如果一切顺利，则可以增加（可能逐渐增加）百分比，逐步替换旧版本。如在过程中出现任何问题，则可以中止并回滚到旧版本。最简单的方式，是随机选择百分比请求到金丝雀版本，但在更复杂的方案下，则可以基于请求的区域，用户或其他属性。
|
||||
|
||||
基于领域的专业水平，您可能想知道为什么需要 Istio 来支持金丝雀部署，因为像 Kubernetes 这样的平台已经提供了进行[版本上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)和[金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方法。问题解决了吗 ？不完全是。虽然以这种方式进行部署可以在简单的情况下工作，但功能非常有限，特别是在大规模自动缩放的云环境中大流量的情况下。
|
||||
基于领域的专业水平，您可能想知道为什么需要 Istio 来支持金丝雀部署，因为像 Kubernetes
|
||||
这样的平台已经提供了进行 [版本上线](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)
|
||||
和[金丝雀部署](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) 的方法。
|
||||
问题解决了吗 ？不完全是。虽然以这种方式进行部署可以在简单的情况下工作，但功能非常有限，特别是在大规模自动缩放的云环境中大流量的情况下。
|
||||
|
||||
## Kubernetes 中的金丝雀部署{#canary-deployment-in-Kubernetes}
|
||||
|
||||
假设我们有一个已部署的 **helloworld** 服务 **v1** 版本，我们想要测试（或简单上线）新版本 **v2**。使用 Kubernetes，您可以通过简单地更新服务的 [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) 中的镜像并自动进行部署来[上线](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#updating-a-deployment)新版本的 **helloworld** 服务。如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment)上线时有足够的 **v1** 副本运行，则能够保持金丝雀发布对系统的影响非常小。后续我们可以观察效果，或在必要时进行[回滚](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment)。最好，我们也能够对 Deployment 设置 [HPA](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment)，在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。
|
||||
假设我们有一个已部署的 **helloworld** 服务 **v1** 版本，我们想要测试（或简单上线）新版本 **v2**。
|
||||
使用 Kubernetes，您可以通过简单地更新服务的 [Deployment](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/)
|
||||
中的镜像并自动进行部署来 [上线](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 新版本的 **helloworld** 服务。
|
||||
如果我们特能够小心保证在启动并且在仅启动一个或两个 v2 副本[暂停](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/#pausing-and-resuming-a-deployment)
|
||||
上线时有足够的 **v1** 副本运行，则能够保持金丝雀发布对系统的影响非常小。
|
||||
后续我们可以观察效果，或在必要时进行 [回滚](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/#rolling-back-a-deployment)。
|
||||
最好，我们也能够对 Deployment 设置 [HPA](https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/#scaling-a-deployment)，
|
||||
在上线过程中减少或增加副本以处理流量负载时，也能够保持副本比例一致。
|
||||
|
||||
尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），Kubernetes 中的金丝雀部署将使用具有[公共 pod 标签](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)的两个 Deployment 来完成。在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。
|
||||
尽管这种机制能够很好工作，但这种方式只适用于部署的经过适当测试的版本，也就是说，更多的是蓝/绿发布，又称红/黑发布，而不是 “蜻蜓点水“ 式的金丝雀部署。
|
||||
实际上，对于后者（例如，并没有完全准备好或者无意对外暴露的版本），
|
||||
Kubernetes 中的金丝雀部署将使用具有 [公共 pod 标签](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively) 的两个 Deployment 来完成。
|
||||
在这种情况下，我们不能再使用自动缩放器，因为是有由两个独立的自动缩放器来进行控制，不同负载情况下，副本比例（百分比）可能与所需的比例不同。
|
||||
|
||||
无论我们使用一个或者两个部署，使用 Docker，Mesos/Marathon 或 Kubernetes 等容器编排平台进行的金丝雀发布管理都存在一个根本问题：使用实例扩容来管理流量；版本流量分发和副本部署在上述平台中并独立。所有 pod 副本，无论版本如何，在 `kube-proxy` 循环池中都被一视同仁地对待，因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比维持金丝雀流量需要许多副本（例如，1％ 将需要至少 100 个副本）。即使我们可以忽略这个问题，部署方式功能仍然非常有限，因为它只支持简单（随机百分比）金丝雀部署。如果我们想根据某些特定规则将请求路由到金丝雀版本上，我们仍然需要另一种解决方案。
|
||||
|
||||
|
|
@ -29,7 +42,7 @@ aliases:
|
|||
|
||||
使用 Istio，流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩，与版本流量路由的控制完全正交。这在自动缩放的情况下能够更加简单地管理金丝雀版本。事实上，自动缩放管理器仍然独立运行，其在响应因流量路由导致的负载变化与其他原因导致负载变化的行为上没有区别。
|
||||
|
||||
Istio 的[路由规则](/zh/docs/concepts/traffic-management/#routing-rules)也带来了其他的便利；你可以轻松实现细粒度控制流量百分比（例如，路由 1％ 的流量而不需要 100 个 pod），当然也可以使用其他规则来控制流量（例如，将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 **helloworld** 服务的简单便捷。
|
||||
Istio 的[路由规则](/zh/docs/concepts/traffic-management/#routing-rules)也带来了其他的便利；您可以轻松实现细粒度控制流量百分比（例如路由 1％ 的流量而不需要 100 个 Pod），当然也可以使用其他规则来控制流量（例如将特定用户的流量路由到金丝雀版本）。作为展示，让我们看一下采用这种方式部署 **helloworld** 服务的简单便捷。
|
||||
|
||||
首先我们定义 **helloworld** 服务，和普通 **Kubernetes** 服务一样，如下所示：
|
||||
|
||||
|
|
@ -81,9 +94,9 @@ spec:
|
|||
...
|
||||
{{< /text >}}
|
||||
|
||||
需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％ 的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。
|
||||
需要注意的是，这与使用普通 Kubernetes 进行[金丝雀部署](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)的方式完全相同，但是在 Kubernetes 方式下控制流量分配需要调整每个 Deployment 的副本数目。例如，将 10％ 的流量发送到金丝雀版本（v2），v1 和 v2 的副本可以分别设置为 9 和 1。
|
||||
|
||||
但是在[启用 Istio](/zh/docs/setup/) 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本本，我们可以使用 `kubectl` 来设置以下的路由规则：
|
||||
但是在 [启用 Istio](/zh/docs/setup/) 的集群中，我们可以通过设置路由规则来控制流量分配。如将 10％ 的流量发送到金丝雀版本本，我们可以使用 `kubectl` 来设置以下的路由规则：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
@ -125,7 +138,7 @@ EOF
|
|||
|
||||
## 部署中的自动缩放{#autoscaling-the-deployments}
|
||||
|
||||
由于我们不再需要保持副本比例，所以我们可以安全地设置 Kubernetes [HPA](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) 来管理两个版本 Deployment 的副本：
|
||||
由于我们不再需要保持副本比例，所以我们可以安全地设置 Kubernetes [HPA](https://kubernetes.io/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 来管理两个版本 Deployment 的副本：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl autoscale deployment helloworld-v1 --cpu-percent=50 --min=1 --max=10
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Sidecar proxy 模式成就了很多奇迹。Sidecar 身处微服务的数据路
|
|||
|
||||
### 网络的去虚拟化{#network-devirtualization}
|
||||
|
||||
Kubernetes 为运行其上的微服务应用提供了简单的设计优良的网络结构。然而为了支持这些设计，也为下层网络强加了特定的[需求](https://kubernetes.io/docs/concepts/cluster-administration/networking/)。要符合这些需求并不简单。通常会通过另加一层的方式来满足要求。典型方案就是在下层网络和 Kubernetes 之间加入叠加层。应用产生的流量会在源头进行封包，在目的地进行解包，这一过程消耗的不仅是网络资源，还包括 CPU。
|
||||
Kubernetes 为运行其上的微服务应用提供了简单的设计优良的网络结构。然而为了支持这些设计，也为下层网络强加了特定的 [需求](https://kubernetes.io/zh-cn/docs/concepts/cluster-administration/networking/)。要符合这些需求并不简单。通常会通过另加一层的方式来满足要求。典型方案就是在下层网络和 Kubernetes 之间加入叠加层。应用产生的流量会在源头进行封包，在目的地进行解包，这一过程消耗的不仅是网络资源，还包括 CPU。
|
||||
|
||||
AppSwitch 会通过和平台之间的接触，来决定应用程序的可见范围。它会为应用程序提供一个关于下层网络的虚拟视图，这一视图类似于叠加层，但是不会在数据路径中引入额外的处理工作。和容器的情况类似，容器内部看起来也像是一个虚拟机，但是其基础实现不会干扰低级中断之类的高发事件的控制过程。
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ AppSwitch 能注入到标准的 Kubernetes 清单文件之中（和 Istio 注入
|
|||
|
||||
### 容器网络的组件{#artifacts-of-container-networking}
|
||||
|
||||
将网络从主机扩展到容器是一个[巨大挑战](https://kubernetes.io/blog/2016/01/why-kubernetes-doesnt-use-libnetwork/)。新的网络层应运而生。容器中的进程只是主机上的一个进程。然而应用所期待的网络抽象和容器网络命名空间之间存在一个[错位](http://appswitch.io/blog/kubernetes_istio_and_network_function_devirtualization_with_appswitch/)，进程无法直接访问主机网络。应用程序眼里的网络是 Socket 或者 Session，而网络命名空间暴露的是设备抽象。一旦进入网络命名空间，进程会失去所有连接。为此发明了 `veth-pair` 之类的工具用来弥合这一鸿沟。数据现在必须从主机接口进入虚拟交换机，然后通过 `veth-pair` 才能进入容器网络空间里面的虚拟网络接口。
|
||||
将网络从主机扩展到容器是一个 [巨大挑战](https://kubernetes.io/blog/2016/01/why-kubernetes-doesnt-use-libnetwork/)。新的网络层应运而生。容器中的进程只是主机上的一个进程。然而应用所期待的网络抽象和容器网络命名空间之间存在一个 [错位](http://appswitch.io/blog/kubernetes_istio_and_network_function_devirtualization_with_appswitch/)，进程无法直接访问主机网络。应用程序眼里的网络是 Socket 或者 Session，而网络命名空间暴露的是设备抽象。一旦进入网络命名空间，进程会失去所有连接。为此发明了 `veth-pair` 之类的工具用来弥合这一鸿沟。数据现在必须从主机接口进入虚拟交换机，然后通过 `veth-pair` 才能进入容器网络空间里面的虚拟网络接口。
|
||||
|
||||
AppSwitch 能够有效的移除连接两端的虚拟交换机和 `veth-pair` 层。运行在主机上的守护进程所用的主机网络既然已经就绪，就无需再使用网桥方式把主机网络桥接到容器了。主机上创建的 Socket 文件描述符被传递给运行在 Pod 网络命名空间中的应用程序。应用收到 FD 之后，控制路径的所有工作都已就绪，就可以使用 FD 进行实际 IO 了。
|
||||
|
||||
|
|
|
|||
|
|
@ -749,7 +749,7 @@ $ kubectl delete destinationrule egressgateway-for-mongo
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 来保存 Nginx SNI 代理的配置：
|
||||
1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 来保存 Nginx SNI 代理的配置：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create configmap egress-sni-proxy-configmap -n istio-system --from-file=nginx.conf=./sni-proxy.conf
|
||||
|
|
|
|||
|
|
@ -350,7 +350,9 @@ target_release: 1.1
|
|||
|
||||
### Mixer 策略检查访问控制，第二部分{#access-control-by-Mixer-policy-checks-part-2}
|
||||
|
||||
在我们用例中的组织设法配置日志和访问控制之后，它决定扩展它的访问策略，允许具有特殊[服务帐户](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)的应用程序访问 _cnn.com_ 的任何主题，而不受监控。您将看到如何在 Istio 中配置此需求。
|
||||
在我们用例中的组织设法配置日志和访问控制之后，它决定扩展它的访问策略，
|
||||
允许具有特殊[服务帐户](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)
|
||||
的应用程序访问 _cnn.com_ 的任何主题，而不受监控。您将看到如何在 Istio 中配置此需求。
|
||||
|
||||
1. 使用 `politics` 服务账户开启 [sleep]({{< github_tree >}}/samples/sleep) 示例程序。
|
||||
|
||||
|
|
|
|||
|
|
@ -158,7 +158,7 @@ target_release: 1.0
|
|||
value: password
|
||||
{{< /text >}}
|
||||
|
||||
替换上面代码段中的值，指定数据库主机，端口，用户和密码，请注意，在 Kubernetes 中使用容器环境变量中密码的正确方法是 [使用 secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)，仅对于此示例任务，你可能会在 deployment spec 中直接配置明文的密码，**切记！不要在真实环境中这样做**！我想你们应该也知道，`"password"` 这个值也不应该用作密码。
|
||||
替换上面代码段中的值，指定数据库主机，端口，用户和密码，请注意，在 Kubernetes 中使用容器环境变量中密码的正确方法是[使用 Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/#using-secrets-as-environment-variables)，仅对于此示例任务，您可能会在 deployment spec 中直接配置明文的密码，**切记！不要在真实环境中这样做**！我想大家应该也知道，`"password"` 这个值也不应该用作密码。
|
||||
|
||||
1. 应用修改后的 `spec` 来部署使用外部数据库的 _ratings_ 服务，_v2-mysql_ 的版本。
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ Istio 服务网格在逻辑上分为数据平面和控制平面。
|
|||
简单来说，Sidecar 注入会将额外容器的配置添加到 Pod 模板中。Istio 服务网格目前所需的容器有：
|
||||
|
||||
`istio-init`
|
||||
[init 容器](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/)用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：
|
||||
[init 容器](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/init-containers/) 用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：
|
||||
|
||||
- 它在启动应用容器之前运行，并一直运行直至完成。
|
||||
- 如果有多个初始化容器，则每个容器都应在启动下一个容器之前成功完成。
|
||||
|
|
@ -205,7 +205,7 @@ kube-system Active 40d <none>
|
|||
|
||||
但它是如何工作的呢？要深入了解这一点，我们需要理解 Kubernetes 准入控制器。
|
||||
|
||||
[来自 Kubernetes 文档：](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
|
||||
[来自 Kubernetes 文档：](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/)
|
||||
|
||||
{{< tip >}}
|
||||
准入控制器是一段代码，用于在对象持久化之前但请求已经过身份验证和授权之后，拦截对 Kubernetes API 服务器的请求。您可以定义两种类型的 Admission Webhook：Validating 和 Mutating。Validating 类型的 Webhook 可以根据自定义的准入策略决定是否拒绝请求；Mutating 类型的 Webhook 可以根据自定义配置来对请求进行编辑。
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ _1.3.4 不允许持卡人数据环境没有授权的出站流量进入互联网
|
|||
|
||||
## 出口流量管控要求 {#requirements-for-egress-traffic-control}
|
||||
|
||||
我的同事（在 IBM）和我从一些客户那里收集了一些出口流量安全管控的要求，并把它们和 [Kubernetes 网络特定兴趣小组的出口流量管控要求](https://docs.google.com/document/d/1-Cq_Y-yuyNklvdnaZF9Qngl3xe0NnArT7Xt_Wno9beg)做了整合。
|
||||
我的同事（在 IBM）和我从一些客户那里收集了一些出口流量安全管控的要求，并把它们和 [Kubernetes 网络特定兴趣小组的出口流量管控要求](https://docs.google.com/document/d/1-Cq_Y-yuyNklvdnaZF9Qngl3xe0NnArT7Xt_Wno9beg) 做了整合。
|
||||
|
||||
Istio 1.1 满足所有的收集要求：
|
||||
|
||||
|
|
@ -80,9 +80,9 @@ Istio 1.1 满足所有的收集要求：
|
|||
|
||||
注意如果是应用程序发起的 TLS，Istio 的 sidecar 代理就只能看到 TCP 流量和包含 SNI 的 TLS 握手。源 pod 的标签可以识别出流量来源，但是 pod 的服务账号或者其它源识标识符也可以用来识别流量。我们把出口流量管控系统的这个特性叫做 _Kubernetes 可感知_：这个系统必须理解 Kubernetes 组件，比如 pod 和服务账号。如果这个系统不是 Kubernetes 可感知的，那它只能监控 IP 地址，并把它作为源的标示。
|
||||
|
||||
第三个要求指出：Istio 运维人员必须能为整个集群所有的出口流量定规策略。策略指出集群中的 pod 可能会访问哪些外部服务。外部服务可以通过服务的[全域名](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) （比如 `www.ibm.com`）或者泛域名（比如：`*.ibm.com`）进行标示。只有指定的外部服务可以访问，其它所有的出口流量都要被阻止。
|
||||
第三个要求指出：Istio 运维人员必须能为整个集群所有的出口流量定规策略。策略指出集群中的 pod 可能会访问哪些外部服务。外部服务可以通过服务的 [全域名](https://en.wikipedia.org/wiki/Fully_qualified_domain_name)（比如 `www.ibm.com`）或者泛域名（比如：`*.ibm.com`）进行标示。只有指定的外部服务可以访问，其它所有的出口流量都要被阻止。
|
||||
|
||||
这个要求是为了阻止攻击者访问恶意站点而提出的，比如下载更新/操作他们的恶意软件。同样也想去限制攻击者可以访问和攻击的外部站点的数量。只允许集群内应用程序需要访问的外部站点并且阻止其它所拥有的服务访问，这样减少了[攻击面](https://en.wikipedia.org/wiki/Attack_surface)。当外部服务有了它们自己的安全机制，你想使用[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))并且使用多个安全层：除了外部系统的安全层外，集群内还有一个安全层。
|
||||
这个要求是为了阻止攻击者访问恶意站点而提出的，比如下载更新/操作他们的恶意软件。同样也想去限制攻击者可以访问和攻击的外部站点的数量。只允许集群内应用程序需要访问的外部站点并且阻止其它所拥有的服务访问，这样减少了[攻击面](https://en.wikipedia.org/wiki/Attack_surface)。当外部服务有了它们自己的安全机制，您想使用[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 并且使用多个安全层：除了外部系统的安全层外，集群内还有一个安全层。
|
||||
|
||||
这个要求意味着外部服务必须能用域名来标示。我们把出口管控系统的这个特性叫做 DNS 感知。如果系统不是 DNS 可感知的，外部服务必须用 IP 地址标示。
|
||||
使用 IP 地址不方便而且经常不灵活，因为服务的 IP 地址会变的。有时候服务的所有 IP 地址甚至都不知道，比如：[CDN](https://en.wikipedia.org/wiki/Content_delivery_network)。
|
||||
|
|
@ -98,4 +98,7 @@ Istio 1.1 满足所有的收集要求：
|
|||
|
||||
## 总结 {#summary}
|
||||
|
||||
希望您确信对于集群安全来说出口流量管控是非常重要的。在[这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/)我讲述了使用 Istio 实现出口流量安全管控的方法。在[这个系列文章的第三部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/)我和其它方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)以及已有的其它出口代理/防火墙方案。
|
||||
希望您确信对于集群安全来说出口流量管控是非常重要的。
|
||||
在 [这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/) 我讲述了使用 Istio 实现出口流量安全管控的方法。
|
||||
在 [这个系列文章的第三部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/) 我和其它方案进行了对比，
|
||||
比如 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 以及已有的其它出口代理/防火墙方案。
|
||||
|
|
|
|||
|
|
@ -22,11 +22,14 @@ target_release: 1.2
|
|||
|
||||
如果应用程序发送 HTTP 请求，并且由出口网关发起执行 TLS，你就可以监控 HTTP 信息，像 HTTP 方法、HTTP 头和 URL 路径。也可以根据上面说的 HTTP 信息来[定义策略](/zh/blog/2018/egress-monitoring-access-control)。如果是由应用程序发起执行 TLS，你就可以对源 pod 的 TLS 流量的 [SNI 和服务账号进行监控](/zh/docs/tasks/traffic-management/egress/egress_sni_monitoring_and_policies/)，并且基于 SNI 和服务账号定义策略。
|
||||
|
||||
你必须确保你集群到外部的流量不能绕过出口网关。Istio 不能给你确保这一点，所以你必需使用一些[附加的安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)或者 L3 防火墙。看一个 [Kubernetes 网络策略配置](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-Kubernetes-network-policies)的例子。
|
||||
根据[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))的概念，为同一个目标使用的安全机制越多越安全。
|
||||
您必须确保你集群到外部的流量不能绕过出口网关。Istio 不能给您确保这一点，
|
||||
所以您必须使用一些[附加的安全机制](/zh/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations)，
|
||||
比如 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 或者 L3 防火墙。
|
||||
看一个 [Kubernetes 网络策略配置](/zh/docs/tasks/traffic-management/egress/egress-gateway/#apply-Kubernetes-network-policies) 的例子。
|
||||
根据 [纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)) 的概念，为同一个目标使用的安全机制越多越安全。
|
||||
|
||||
你也必需也要确保 Istio 控制平面和出口网关不能被破坏。你的集群里面可能有成百上千的应用程序 pod，而只有十几个 Istio 控制平面 pod 和网关。
|
||||
你可以也应该聚焦在保护控制平面 pod 和网关，因为这比较容易（需要保护的 pod 数量很少），并且这对集群的安全性是最关键的。
|
||||
您也必需也要确保 Istio 控制平面和出口网关不能被破坏。您的集群里面可能有成百上千的应用程序 Pod，而只有十几个 Istio 控制平面 Pod 和网关。
|
||||
您可以也应该聚焦在保护控制平面 Pod 和网关，因为这比较容易（需要保护的 Pod 数量很少），并且这对集群的安全性是最关键的。
|
||||
如果攻击者破坏了控制平面和出口网关，他们可以违反任何策略。
|
||||
|
||||
根据环境的不同，你可能有多种工具来保护控制平面 pod。合理的安全策略如下：
|
||||
|
|
@ -77,4 +80,4 @@ target_release: 1.2
|
|||
|
||||
## 总结 {#summary}
|
||||
|
||||
希望我能说服你：Istio 在阻止相关出口流量攻击上是一个非常高效的工具。在[这个系列文章的下一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/)，我对 Istio 出口流量安全管控方案和其它的方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)和已有的出口代理/防火墙。
|
||||
希望我能说服您：Istio 在阻止相关出口流量攻击上是一个非常高效的工具。在[这个系列文章的下一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-3/)，我对 Istio 出口流量安全管控方案和其它的方案进行了对比，比如 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/)和已有的出口代理/防火墙。
|
||||
|
|
|
|||
|
|
@ -9,16 +9,16 @@ target_release: 1.2
|
|||
---
|
||||
|
||||
欢迎来看在 Istio 对出口流量进行安全管控系列文章的第 3 部分。
|
||||
在[这个系列文章的第一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-1/)，我提出了出口流量相关攻击和我们针对出口流量进行安全管控收集的要求点。
|
||||
在[这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/)，我展示了 Istio 的对安全出口流量方案，并且展示了使用 Istio 如何来阻止攻击。
|
||||
在 [这个系列文章的第一部分](/zh/blog/2019/egress-traffic-control-in-istio-part-1/)，我提出了出口流量相关攻击和我们针对出口流量进行安全管控收集的要求点。
|
||||
在 [这个系列文章的第二部分](/zh/blog/2019/egress-traffic-control-in-istio-part-2/)，我展示了 Istio 的对安全出口流量方案，并且展示了使用 Istio 如何来阻止攻击。
|
||||
|
||||
在这一期中，我对 Istio 出口流量安全管控方案和其它的方案进行了对比，比如使用 Kubernetes 网络策略和已有的出口代理和防火墙。最后我讲述了 Istio 中安全管控出口流量的性能因素。
|
||||
|
||||
## 出口流量管控的其它解决方案 {#alternative-solutions-for-egress-traffic-control}
|
||||
|
||||
首先，我们回想一下我们之前收集的[出口流量管控要求](/zh/blog/2019/egress-traffic-control-in-istio-part-1/#requirements-for-egress-traffic-control)：
|
||||
首先，我们回想一下我们之前收集的 [出口流量管控要求](/zh/blog/2019/egress-traffic-control-in-istio-part-1/#requirements-for-egress-traffic-control)：
|
||||
|
||||
1. 用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 或者用 [TLS 源](/zh/docs/reference/glossary/#tls-origination)来支持 [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security)。
|
||||
1. 用 [SNI](https://en.wikipedia.org/wiki/Server_Name_Indication) 或者用 [TLS 源](/zh/docs/reference/glossary/#tls-origination) 来支持 [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security)。
|
||||
1. **监控** SNI 和每个出口访问的 workload 源。
|
||||
1. 定义和执行 **每个集群的策略**。
|
||||
1. 定义和执行 **每个源的策略**，Kubernetes 可感知。
|
||||
|
|
@ -27,7 +27,7 @@ target_release: 1.2
|
|||
|
||||
接下来，将会介绍两种出口流量管控的备选方案：Kubernetes 网络策略和出口代理与防火墙。展示了上述要求中哪些是它们满足的，更重要的是那些要求是它们不能满足的。
|
||||
|
||||
Kubernetes 通过[网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)提供了一个流量管控的原生方案，特别是对出口流量管控。使用这些网络策略，集群运维人员可以配置那个 pod 可以访问指定的外部服务。
|
||||
Kubernetes 通过 [网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 提供了一个流量管控的原生方案，特别是对出口流量管控。使用这些网络策略，集群运维人员可以配置那个 pod 可以访问指定的外部服务。
|
||||
集群运维人员可以通过 pod 标签、命名空间标签或者 IP 范围来识别 pod。集群运维人员可以使用 IP 范围来明确外部服务，但是不能使用像 `cnn.com` 这样的域名来指定外部服务。因为 **Kubernetes 网络策略对 DNS 无感知**。
|
||||
网络策略可以满足第一个要求，因为它可以管控任何 TCP 流量。网络策略只能部分满足第三和第四点要求，因为集群运维人员可以针对每个集群或者每个 pod 制定策略，但是运维人员无法用域名来标示外部服务。
|
||||
只有当攻击者无法从恶意容器进入 Kubernetes 节点并干扰该节点内策略的执行时，网络策略才满足第五个要求。
|
||||
|
|
|
|||
|
|
@ -8,22 +8,24 @@ keywords: [install,configuration,istioctl,operator]
|
|||
target_release: 1.4
|
||||
---
|
||||
|
||||
Kubernetes [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) 提供了一种将人类运维知识编码到软件中的模式，是一种简化软件基础结构组件管理的流行方法。Istio 是自动 operator 的理想选择，因为它的管理具有挑战性。
|
||||
Kubernetes [Operator](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/) 提供了一种将人类运维知识编码到软件中的模式，是一种简化软件基础结构组件管理的流行方法。Istio 是自动 Operator 的理想选择，因为它的管理具有挑战性。
|
||||
|
||||
到目前为止，[Helm](https://github.com/helm/helm) 一直是安装和升级 Istio 的主要工具。Istio 1.4 引入了一种新的[使用{{< istioctl >}}安装](/zh/docs/setup/install/istioctl/)方法。这种新的安装方法建立在 Helm 的优势之上，并添加了以下内容:
|
||||
到目前为止，[Helm](https://github.com/helm/helm) 一直是安装和升级 Istio 的主要工具。Istio 1.4 引入了一种新的[使用{{< istioctl >}}安装](/zh/docs/setup/install/istioctl/) 方法。这种新的安装方法建立在 Helm 的优势之上，并添加了以下内容:
|
||||
|
||||
- 用户只需要安装一个工具：`istioctl`
|
||||
- 验证所有 API 字段
|
||||
- 不在 API 中的小型定制不需要更改 chart 或 API
|
||||
- 版本特定的升级 hook 可以很容易和稳健地实现
|
||||
|
||||
[Helm 安装](/zh/docs/setup/install/helm/)方法正在弃用中。从 Istio 1.4 升级到一个默认没有安装 Helm 的版本也会被一个新的 [{{< istioctl >}} 升级特性](/zh/docs/setup/upgrade/istioctl-upgrade/)所取代。
|
||||
[Helm 安装](/zh/docs/setup/install/helm/) 方法正在弃用中。从 Istio 1.4 升级到一个默认没有安装 Helm 的版本也会被一个新的 [{{< istioctl >}} 升级特性](/zh/docs/setup/upgrade/istioctl-upgrade/)所取代。
|
||||
|
||||
新的 `istioctl` 安装命令使用一个[自定义资源](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)来配置安装。自定义资源是新的 Istio operator 实现的一部分，该实现旨在简化安装、升级和复杂的 Istio 配置更改等常见管理任务。安装和升级的验证和检查与工具紧密集成，以防止常见错误并简化故障排除。
|
||||
新的 `istioctl` 安装命令使用一个 [自定义资源](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 来配置安装。
|
||||
自定义资源是新的 Istio Operator 实现的一部分，该实现旨在简化安装、升级和复杂的 Istio 配置更改等常见管理任务。
|
||||
安装和升级的验证和检查与工具紧密集成，以防止常见错误并简化故障排除。
|
||||
|
||||
## Operator API{#the-Operator-API}
|
||||
|
||||
每个 operator 实现都需要一个[自定义资源定义（CRD）](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) 来定义它的自定义资源，即它的 API。Istio 的 operator API 由 [`IstioControlPlane` CRD](/zh/docs/reference/config/istio.operator.v1alpha12.pb/) 定义，它是由一个 [`IstioControlPlane` 原型](https://github.com/istio/operator/blob/release-1.4/pkg/apis/istio/v1alpha2/istiocontrolplane_types.proto)生成的。API 支持所有 Istio 当前的[配置文件](/zh/docs/setup/additional-setup/config-profiles/) ，通过使用一个字段来选择 profile。例如，下面的 `IstioControlPlane` 资源使用 `demo` profile 配置 Istio：
|
||||
每个 Operator 实现都需要一个[自定义资源定义（CRD）](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions) 来定义它的自定义资源，即它的 API。Istio 的 Operator API 由 [`IstioControlPlane` CRD](/zh/docs/reference/config/istio.operator.v1alpha12.pb/) 定义，它是由一个 [`IstioControlPlane` 原型](https://github.com/istio/operator/blob/release-1.4/pkg/apis/istio/v1alpha2/istiocontrolplane_types.proto)生成的。API 支持所有 Istio 当前的[配置文件](/zh/docs/setup/additional-setup/config-profiles/) ，通过使用一个字段来选择 profile。例如，下面的 `IstioControlPlane` 资源使用 `demo` profile 配置 Istio：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: install.istio.io/v1alpha2
|
||||
|
|
@ -112,21 +114,23 @@ $ helm template ... --set global.mtls.enabled=true
|
|||
$ istioctl manifest generate ... --set values.global.mtls.enabled=true
|
||||
{{< /text >}}
|
||||
|
||||
你也可以在一个 `IstioControlPlane` 自定义资源中设置 Helm 配置值。参见[使用 Helm 自定义 Istio 设置](/zh/docs/setup/install/istioctl/#customize-Istio-settings-using-the-helm-API)。
|
||||
你也可以在一个 `IstioControlPlane` 自定义资源中设置 Helm 配置值。
|
||||
参见 [使用 Helm 自定义 Istio 设置](/zh/docs/setup/install/istioctl/#customize-Istio-settings-using-the-helm-API)。
|
||||
|
||||
另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。此命令可用于将 Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。
|
||||
另一个可以帮助从 Helm 迁移的特性是这个 alpha 命令：[{{< istioctl >}} manifest migrate](/zh/docs/reference/commands/istioctl/#istioctl-manifest-migrate)。
|
||||
此命令可用于将 Helm `values.yaml` 文件自动转换为相应的 `IstioControlPlane` 配置。
|
||||
|
||||
## 实现{#implementation}
|
||||
|
||||
已经创建了几个框架，通过为部分或所有组件生成存根来帮助实现 operator。Istio operator 是在 [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) 和 [operator framework](https://github.com/operator-framework) 的帮助下创建的。Istio 的安装现在使用 proto 来描述 API，这样就可以通过 schema 对执行运行时进行验证。
|
||||
已经创建了几个框架，通过为部分或所有组件生成存根来帮助实现 Operator。Istio Operator 是在 [kubebuilder](https://github.com/kubernetes-sigs/kubebuilder) 和 [Operator Framework](https://github.com/operator-framework) 的帮助下创建的。Istio 的安装现在使用 proto 来描述 API，这样就可以通过 schema 对执行运行时进行验证。
|
||||
|
||||
有关实现的更多信息可以在 [Istio operator 仓库](https://github.com/istio/operator)中的 README 和 ARCHITECTURE 文档中找到。
|
||||
有关实现的更多信息可以在 [Istio Operator 仓库](https://github.com/istio/operator) 中的 README 和 ARCHITECTURE 文档中找到。
|
||||
|
||||
## 总结{#summary}
|
||||
|
||||
从 Istio 1.4 开始，Helm 安装将被新的 `istioctl` 命令所取代，该命令使用新的 operator 自定义资源定义，`IstioControlPlane`，作为配置 API。一个 alpha controller 也被提供用于 operator 的早期实验。
|
||||
从 Istio 1.4 开始，Helm 安装将被新的 `istioctl` 命令所取代，该命令使用新的 Operator 自定义资源定义，`IstioControlPlane`，作为配置 API。一个 alpha controller 也被提供用于 Operator 的早期实验。
|
||||
|
||||
新的 `istioctl` 命令和 operator controller 都会验证配置 schema，并执行安装更改或升级的一系列检查。这些检查与工具紧密集成，以防止常见错误并简化故障排除。
|
||||
新的 `istioctl` 命令和 Operator controller 都会验证配置 schema，并执行安装更改或升级的一系列检查。这些检查与工具紧密集成，以防止常见错误并简化故障排除。
|
||||
|
||||
Istio 维护者们期望这种新方法能够改善安装和升级期间的用户体验，更好地稳定安装 API，帮助用户更好地管理和监控他们的 Istio 安装。
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ target_release: 1.3
|
|||
|
||||
## Knative Serving{#Knative-serving}
|
||||
|
||||
[Knative Serving](https://knative.dev/docs/serving/) 基于 [Kubernetes](https://kubernetes.io/) 来支持 Serverless 应用的部署和服务（Serving）。一个 Serverless 平台的核心功能就是 scale-to-zero，该功能可减少非活动工作负载的资源使用量和成本。当空闲应用收到新请求时，需要一种新的机制来 scale-from-zero。
|
||||
[Knative Serving](https://knative.dev/docs/serving/) 基于 [Kubernetes](https://kubernetes.io/zh-cn/) 来支持 Serverless 应用的部署和服务（Serving）。一个 Serverless 平台的核心功能就是 scale-to-zero，该功能可减少非活动工作负载的资源使用量和成本。当空闲应用收到新请求时，需要一种新的机制来 scale-from-zero。
|
||||
|
||||
下图表示当前 Knative scale-from-zero 的架构。
|
||||
|
||||
|
|
@ -32,19 +32,22 @@ target_release: 1.3
|
|||
|
||||
Mixer 是一个属性处理引擎，它使用面向操作员（operator-supplied）的配置通过可插拔（Pluggable）的适配器将 Istio 代理的请求属性映射到对基础设施后端系统的调用。适配器使 **Mixer** 暴露单个统一的 API，与使用中的基础设施后端无关。运行时使用的适配器是由操作员配置决定的，适配器可以轻松扩展以适应新的或定制的基础设施后端。
|
||||
|
||||
为了实现 Knative scale-from-zero，我们使用 Mixer [进程外适配器](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide)来调用 Autoscaler。Mixer 的进程外适配器使开发人员可以使用任何编程语言，并以独立程序的形式构建和维护您的扩展程序，而无需构建 Istio 代理。
|
||||
为了实现 Knative scale-from-zero，我们使用 Mixer [进程外适配器](https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide) 来调用 Autoscaler。
|
||||
Mixer 的进程外适配器使开发人员可以使用任何编程语言，并以独立程序的形式构建和维护您的扩展程序，而无需构建 Istio 代理。
|
||||
|
||||
下图表示使用 **Mixer** 适配器的 Knative 设计。
|
||||
|
||||
{{< image width="60%" link="knative-mixer-adapter.png" caption="Knative scale-from-zero" >}}
|
||||
|
||||
在这种设计中，无需像 Knative 原有的设置中那样为空闲应用程序更改到 **Activator** 的路由。当由 Istio 代理（Ingress 网关）收到对空闲应用程序的新请求时，它将通知 Mixer，包括所有相关的元数据信息。然后 Mixer 调用您的适配器，该适配器使用 Knative 原有的协议触发 Knative Autoscaler。
|
||||
在这种设计中，无需像 Knative 原有的设置中那样为空闲应用程序更改到 **Activator** 的路由。
|
||||
当由 Istio 代理（Ingress 网关）收到对空闲应用程序的新请求时，它将通知 Mixer，包括所有相关的元数据信息。
|
||||
然后 Mixer 调用您的适配器，该适配器使用 Knative 原有的协议触发 Knative Autoscaler。
|
||||
|
||||
{{< idea >}}
|
||||
通过使用这种设计，您不需要处理缓存，重试和负载平衡的问题，因为 Istio 代理已经处理了这些问题。
|
||||
{{< /idea >}}
|
||||
|
||||
Istio 的 Mixer 适配器模式使得我们可以用更简单的方式实现原本复杂并且基于网络的应用逻辑，如 [Knative 适配器](https://github.com/zachidan/istio-kactivator)中所示。
|
||||
Istio 的 Mixer 适配器模式使得我们可以用更简单的方式实现原本复杂并且基于网络的应用逻辑，如 [Knative 适配器](https://github.com/zachidan/istio-kactivator) 中所示。
|
||||
|
||||
当适配器从 **Mixer** 接收到消息时，它会使用 Knative 协议直接向 **Autoscaler** 发送一个 `StatMessage`。Istio 代理将 **Autoscaler** 所需的元数据信息（`namespace` 和 `service name`）传输到 **Mixer**，再从那里传输到适配器。
|
||||
|
||||
|
|
|
|||
|
|
@ -21,5 +21,6 @@ Kubernetes 1.12 引入了 `可信任` JWT 来解决这些问题。但是，直
|
|||
根据您选择的平台进行以下考虑：
|
||||
|
||||
- **GKE：** 至少将群集版本升级到 1.13。
|
||||
- **本地 Kubernetes** 和 **私有 GKE：** 将[额外配置](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)添加到您的 Kubernetes。您也可以参考 [API 服务页面](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/)以获取最新的标志名称。
|
||||
- **本地 Kubernetes** 和 **私有 GKE：** 将 [额外配置](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) 添加到您的 Kubernetes。
|
||||
您也可以参考 [API 服务页面](https://kubernetes.io/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) 以获取最新的标志名称。
|
||||
- 对于其他平台，请与您的提供商联系。如果您的提供商不支持可信任 JWT，则您将需要使用文件挂载的方式来传播 Istio 1.3 中的工作负载密钥和证书。
|
||||
|
|
|
|||
|
|
@ -34,7 +34,8 @@ $ wasme deploy istio webassemblyhub.io/ceposta/demo-add-header:v0.2 \
|
|||
|
||||
## 声明式方法{#a-declarative-approach}
|
||||
|
||||
WebAssembly Hub 工具还包括[用于将 Wasm 扩展部署到 Istio 工作负载的 operator](https://docs.solo.io/web-assembly-hub/latest/tutorial_code/wasme_operator/)。[operator](https://kubernetes.io/zh/docs/concepts/extend-kubernetes/operator/)允许用户使用声明式的格式定义其 WebAssembly 扩展，并将其交给 operator 以修正部署状态。例如，我们使用 `FilterDeployment` 资源来定义需要扩展的镜像和工作负载：
|
||||
WebAssembly Hub 工具还包括[用于将 Wasm 扩展部署到 Istio 工作负载的 Operator](https://docs.solo.io/web-assembly-hub/latest/tutorial_code/wasme_operator/)。[Operator](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/) 允许用户使用声明式的格式定义其 WebAssembly 扩展，
|
||||
并将其交给 Operator 以修正部署状态。例如，我们使用 `FilterDeployment` 资源来定义需要扩展的镜像和工作负载：
|
||||
|
||||
{{< text yaml >}}
|
||||
apiVersion: wasme.io/v1
|
||||
|
|
|
|||
|
|
@ -62,7 +62,7 @@ Istio 的[认证](/zh/docs/concepts/security/#authentication-policies)和[授权
|
|||
|
||||
## 改进生命周期管理{#improved-lifecycle-management}
|
||||
|
||||
为了改进 Istio 的生命周期管理，我们使用了基于 [operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) 的安装方式。这里介绍 **[Istio Operator CRD 的两种安装模式](/zh/docs/setup/install/istioctl/)**：
|
||||
为了改进 Istio 的生命周期管理，我们使用了基于 [Operator](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/) 的安装方式。这里介绍 **[Istio Operator CRD 的两种安装模式](/zh/docs/setup/install/istioctl/)**：
|
||||
|
||||
- 人为触发：使用 istioctl 将设置应用至集群。
|
||||
- 机器触发：使用一个控制器，实时观察 CRD 的改动并使其生效。
|
||||
|
|
|
|||
|
|
@ -6,13 +6,20 @@ attribution: "Craig Box (Google)"
|
|||
keywords: [traffic-management,gateway,gateway-api,api,gamma,sig-network]
|
||||
---
|
||||
|
||||
今天我们要[祝贺 Kubernetes SIG Network 社区发布了 Gateway API 规范的 beta 版本](https://kubernetes.io/blog/2022/07/13/gateway-api-graduates-to-beta/)。除了上述的这个里程碑，我们很高兴地宣布，对在 Istio ingress 中使用 Gateway API 的支持正在升级为 Beta版本，并且我们打算让 Gateway API 成为未来所有 Istio 流量管理的默认 API。我们也很高兴地欢迎来自服务网格接口（SMI）社区的朋友，他们将加入我们的行列，并使用网关 API 来标准化服务网格用例。
|
||||
今天我们要 [祝贺 Kubernetes SIG Network 社区发布了 Gateway API 规范的 beta 版本](https://kubernetes.io/blog/2022/07/13/gateway-api-graduates-to-beta/)。
|
||||
除了上述的这个里程碑，我们很高兴地宣布，对在 Istio ingress 中使用 Gateway API 的支持正在升级为 Beta版本，
|
||||
并且我们打算让 Gateway API 成为未来所有 Istio 流量管理的默认 API。
|
||||
我们也很高兴地欢迎来自服务网格接口（SMI）社区的朋友，他们将加入我们的行列，并使用网关 API 来标准化服务网格用例。
|
||||
|
||||
## Istio 流量管理 API 的历史{#the-history-of-istios-traffic-management-apis}
|
||||
|
||||
API 设计与其说是一门科学，不如说是一门艺术，Istio 经常被用作一个 API 来配置其他 API 的服务！仅在流量路由的情况下，我们必须考虑生产者与消费者、路由与被路由，以及如何使用正确数量的对象来表达复杂的特征集——考虑到这些对象必须由不同的团队拥有。
|
||||
API 设计与其说是一门科学，不如说是一门艺术，Istio 经常被用作一个 API 来配置其他 API 的服务！
|
||||
仅在流量路由的情况下，我们必须考虑生产者与消费者、路由与被路由，以及如何使用正确数量的对象来表达复杂的特征集——考虑到这些对象必须由不同的团队拥有。
|
||||
|
||||
当我们在 2017 年推出 Istio 时，我们从 Google 的生产 API 服务基础设施和 IBM 的 Amalgam8 项目的多年经验带到了 Kubernetes 上。我们很快就遇到了 Kubernetes 的 Ingress API 的限制。支持所有代理实现的愿望意味着 Ingress 仅支持最基本的 HTTP 路由功能，而其他功能通常作为供应商特定的注释来实现。Ingress API在基础设施管理员 （"创建和配置负载均衡器"），集群 Operator（"为我的整个域管理 TLS 证书"）和应用程序用户（“使用它将 /foo 路由到 foo 服务”）之间共享。
|
||||
当我们在 2017 年推出 Istio 时，我们从 Google 的生产 API 服务基础设施和 IBM 的 Amalgam8 项目的多年经验带到了 Kubernetes 上。
|
||||
我们很快就遇到了 Kubernetes 的 Ingress API 的限制。支持所有代理实现的愿望意味着 Ingress 仅支持最基本的 HTTP 路由功能，
|
||||
而其他功能通常作为供应商特定的注释来实现。Ingress API在基础设施管理员 （"创建和配置负载均衡器"），
|
||||
集群 Operator（"为我的整个域管理 TLS 证书"）和应用程序用户（“使用它将 /foo 路由到 foo 服务”）之间共享。
|
||||
|
||||
我们[在 2018 年初重写了流量 API](/zh/blog/2018/v1alpha3-routing/) 以解决用户反馈问题，并更充分地解决这些问题。
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,9 @@ test: no
|
|||
sleep-88ddbcfdd-cc85s 1/1 Running 0 7h
|
||||
{{< /text >}}
|
||||
|
||||
1. Kubernetes 采取无侵入的和逐步的[滚动更新](https://kubernetes.io/docs/tutorials/kubernetes-basics/update-intro/)方式用启用 Istio 的 Pod 替换了原有的 Pod。Kubernetes 只有在新的 Pod 开始运行的时候才会终止老的 Pod，它透明地将流量一个一个地切换到新的 Pod 上。也就是说，它不会在声明一个新的 Pod 之前结束一个或者以上的 Pod。这些操作都是为了防止破坏您的应用，因此在注入 Istio 的过程中应用能够持续工作。
|
||||
1. Kubernetes 采取无侵入的和逐步的 [滚动更新](https://kubernetes.io/zh-cn/docs/tutorials/kubernetes-basics/update/update-intro/) 方式用启用 Istio 的 Pod 替换了原有的 Pod。
|
||||
Kubernetes 只有在新的 Pod 开始运行的时候才会终止老的 Pod，它透明地将流量一个一个地切换到新的 Pod 上。
|
||||
也就是说，它不会在声明一个新的 Pod 之前结束一个或者以上的 Pod。这些操作都是为了防止破坏您的应用，因此在注入 Istio 的过程中应用能够持续工作。
|
||||
|
||||
1. 检查 `productpage` Istio Sidecar 的日志：
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ test: no
|
|||
|
||||
1. 安装 [Docker](https://docs.docker.com/install/)。
|
||||
|
||||
1. 安装 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/)。
|
||||
1. 安装 [`kubectl`](https://kubernetes.io/zh-cn/docs/tasks/tools/#kubectl)。
|
||||
|
||||
1. 为您从教程中收到的配置文件或者在上一个模块自己创建的配置文件设置环境变量 `KUBECONFIG`。
|
||||
|
||||
|
|
|
|||
|
|
@ -378,7 +378,7 @@ Istio Sidecar 原理为拦截入站和出站流量并将它们转发到 Sidecar
|
|||
|
||||
### 基于 `NetworkPolicy` 的纵深防御{#defense-in-depth-with-network-policy}
|
||||
|
||||
为了进一步确保流量安全， Istio 策略可以基于 Kubernetes [网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)。这将启动强大的[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))策略来进一步确保您的网格安全性。
|
||||
为了进一步确保流量安全， Istio 策略可以基于 Kubernetes [网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/)。这将启动强大的[纵深防御](https://en.wikipedia.org/wiki/Defense_in_depth_(computing))策略来进一步确保您的网格安全性。
|
||||
|
||||
例如，您可以只允许流量通过端口 `9080` 进入应用 `reviews`。在存在达不到安全标准的
|
||||
Pod 或者有安全弱点情况下，这可能限制或者阻止攻击者。
|
||||
|
|
@ -447,7 +447,7 @@ spec:
|
|||
### 限制 `Gateway` 创建权限{#restrict-gateway-creation-privileges}
|
||||
|
||||
Istio 推荐将网关资源创建权限只分配给信任的集群管理员。这可以通过
|
||||
[Kubernetes RBAC policies](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
|
||||
[Kubernetes RBAC policies](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/rbac/)
|
||||
或者 类似 [Open Policy Agent](https://www.openpolicyagent.org/) 的工具实现。
|
||||
|
||||
### 避免过于宽泛的 `hosts` 配置{#avoid-overly-broad-hosts-configurations}
|
||||
|
|
@ -564,7 +564,7 @@ Istio 可以[自动确定流量协议](/zh/docs/ops/configuration/traffic-manage
|
|||
|
||||
为了透明地劫持所以流量， Istio 依赖 通过 `istio-init` `initContainer` 配置 `iptables` 规则。
|
||||
这增加了一个[要求](/zh/docs/ops/deployment/requirements/)，即需要提供给 Pod `NET_ADMIN`
|
||||
和 `NET_RAW` [capabilities](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)。
|
||||
和 `NET_RAW` [capabilities](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/#set-capabilities-for-a-container)。
|
||||
|
||||
为了减少给予 Pods 的权限， Istio 提供了 [CNI plugin](/zh/docs/setup/additional-setup/cni/) 功能，即不再需要以上权限。
|
||||
|
||||
|
|
@ -656,7 +656,7 @@ $ kubectl get --raw /api/v1 | jq '.resources[] | select(.name | index("serviceac
|
|||
{{< /text >}}
|
||||
|
||||
尽管大多数云供应商现已支持该特性，许多的本地开发工具以及自定义安装还在 Kubernetes 1.20 之前的版本。
|
||||
因此为了启用该特性，请参考 [Kubernetes 文档](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)。
|
||||
因此为了启用该特性，请参考 [Kubernetes 文档](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)。
|
||||
|
||||
## 配置下游连接数限制{#configure-a-limit-on-downstream-connections}
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ owner: istio/wg-user-experience-maintainers
|
|||
test: no
|
||||
---
|
||||
|
||||
来自 [Kubernetes 准入控制机制](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)：
|
||||
来自 [Kubernetes 准入控制机制](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/)：
|
||||
|
||||
{{< tip >}}
|
||||
准入 Webhook 是 HTTP 方式的回调，接收准入请求并对其进行相关操作。可定义两种类型的准入 Webhook，Validating 准入 Webhook 和 Mutating 准入 Webhook。使用 Validating Webhook，可以通过自定义的准入策略来拒绝请求；使用 Mutating Webhook，可以通过自定义默认值来修改请求。
|
||||
|
|
@ -23,7 +23,7 @@ Webhook 设置过程需要了解 Kubernetes 动态准入 Webhook 相关的知识
|
|||
|
||||
请参阅[平台设置说明](/zh/docs/setup/platform-setup/)了解 Kubernetes 提供的详细的设置说明。如果集群配置错误，Webhook 将无法正常工作。集群配置后，当动态 Webhook 和相关特性不能正常工作时，您可以通过以下步骤进行检查。
|
||||
|
||||
1. 验证当前使用正确的 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/) 和 Kubernetes 服务 [支持的版本](/zh/docs/releases/supported-releases#support-status-of-istio-releases)({{< supported_kubernetes_versions >}})：
|
||||
1. 验证当前使用正确的 [`kubectl`](https://kubernetes.io/zh-cn/docs/tasks/tools/#kubectl) 和 Kubernetes 服务 [支持的版本](/zh/docs/releases/supported-releases#support-status-of-istio-releases)({{< supported_kubernetes_versions >}})：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl version --short
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ $ istioctl install --set values.global.variant=distroless
|
|||
Distroless 镜像缺少所有调试工具（包括 Shell！）。
|
||||
虽然对安全性有好处，但这限制了使用 `kubectl exec` 对代理容器进行临时调试的能力。
|
||||
|
||||
幸运的是，[临时容器](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/)可以在此处提供帮助。
|
||||
幸运的是，[临时容器](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/) 可以在此处提供帮助。
|
||||
`kubectl debug` 可以将临时容器附加到 Pod。
|
||||
通过使用带有额外工具的镜像，我们可以像以前一样进行调试：
|
||||
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ $ curl example.com -v
|
|||
|
||||
一旦 Istio 确定了预期的目的地，它必须选择要发送到的地址。由于 Istio 的高级[负载均衡能力](/zh/docs/concepts/traffic-management/#load-balancing-options)，这往往不是客户端发送的原始 IP 地址。根据服务配置的不同，Istio 有几种不同的方式来实现：
|
||||
|
||||
* 使用客户端的原始 IP 地址（上例中为 `192.0.2.0`）。这种情况适用于 `resolution: NONE` 类型的 `ServiceEntry` 和[无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)。
|
||||
* 使用客户端的原始 IP 地址（上例中为 `192.0.2.0`）。这种情况适用于 `resolution: NONE` 类型的 `ServiceEntry` 和 [无头服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)。
|
||||
* 在一组静态 IP 地址上进行负载均衡。这种情况适用于 `resolution: STATIC` 类型的 `ServiceEntry`，将使用其中所有的 `spec.endpoints`，或者对于标准 `Service` 将使用所有 `Endpoint`。
|
||||
* 使用 DNS 定期解析地址，并在所有结果中进行负载均衡。这种情况适用于 `resolution: DNS` 类型的 `ServiceEntry`。
|
||||
|
||||
|
|
|
|||
|
|
@ -422,7 +422,7 @@ Istio 支持两种类型的租赁模型：
|
|||
|
||||
### 命名空间租赁{#namespace-tenancy}
|
||||
|
||||
Istio 使用[命名空间](https://kubernetes.io/docs/reference/glossary/?fundamental=true#term-namespace)作为网格内的租赁单位。
|
||||
Istio 使用 [命名空间](https://kubernetes.io/zh-cn/docs/reference/glossary/?fundamental=true#term-namespace) 作为网格内的租赁单位。
|
||||
Istio 还可以在未实现命名空间租用的环境中使用。在这样的环境中，您可以授予团队权限，以仅允许其将工作负载部署到给定的或一组命名空间。
|
||||
默认情况下，来自多个租赁命名空间的服务可以相互通信。
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ Istio 为应用程序提供了大量的功能，而对应用程序代码本身
|
|||
|
||||
作为 Istio 服务网格中的一部分，Kubernetes 集群中的 Pod 和 Service 必须满足以下要求：
|
||||
|
||||
- **Service 关联**：不管一个 Pod 是否对外暴露端口，每个 Pod 必须至少属于一个 [Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/)。假如一个 Pod 同时属于多个 Kubernetes Service，那么它不能在不同 Service 的端口号上使用不同的协议（比如 HTTP 和 TCP）。
|
||||
- **Service 关联**：不管一个 Pod 是否对外暴露端口，每个 Pod 必须至少属于一个 [Kubernetes Service](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/)。假如一个 Pod 同时属于多个 Kubernetes Service，那么它不能在不同 Service 的端口号上使用不同的协议（比如 HTTP 和 TCP）。
|
||||
|
||||
- **应用 UID**：确保您的 Pod 不会被 ID（UID）为 `1337` 的用户运行应用，因为 `1337` 是为 Sidecar 代理保留的。
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,8 @@ spec:
|
|||
|
||||
### Kubernetes Ingress
|
||||
|
||||
cert-manager 通过[在 Ingress 对象上配置注解](https://cert-manager.io/docs/usage/ingress/)，做到与 Kubernetes Ingress 的直接集成。如果使用此方法，则 Ingress 必须与 `istio-ingressgateway` Deployment 位于同一命名空间中，因为 Secret 只能在同一命名空间中被读取。
|
||||
cert-manager 通过 [在 Ingress 对象上配置注解](https://cert-manager.io/docs/usage/ingress/)，做到与 Kubernetes Ingress 的直接集成。
|
||||
如果使用此方法，则 Ingress 必须与 `istio-ingressgateway` Deployment 位于同一命名空间中，因为 Secret 只能在同一命名空间中被读取。
|
||||
|
||||
或者，也可以按照 [Istio Gateway](#istio-gateway) 部分的描述创建 `Certificate`，然后在 `Ingress` 对象中引用它：
|
||||
|
||||
|
|
|
|||
|
|
@ -5,8 +5,9 @@ owner: istio/wg-user-experience-maintainers
|
|||
test: no
|
||||
---
|
||||
|
||||
当认证策略指定使用 JWT 认证但目标 [Kubernetes 服务](https://kubernetes.io/docs/concepts/services-networking/service/)配置不正确时，会出现此消息。
|
||||
正确定位到 Kubernetes 服务需要使用 http|http2|https 前缀来命名端口（请参见[协议选择](/zh/docs/ops/configuration/traffic-management/protocol-selection/)），并且还需要协议使用 TCP；协议留空也可以，因为其默认值就是 TCP。
|
||||
当认证策略指定使用 JWT 认证但目标 [Kubernetes 服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/) 配置不正确时，会出现此消息。
|
||||
正确定位到 Kubernetes 服务需要使用 http|http2|https 前缀来命名端口
|
||||
（请参见 [协议选择](/zh/docs/ops/configuration/traffic-management/protocol-selection/)），并且还需要协议使用 TCP；协议留空也可以，因为其默认值就是 TCP。
|
||||
|
||||
## 示例{#example}
|
||||
|
||||
|
|
|
|||
|
|
@ -3,5 +3,5 @@ title: CRD
|
|||
test: n/a
|
||||
---
|
||||
|
||||
[自定义资源定义 (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
[自定义资源定义 (CRD)](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
是默认的 Kubernetes API 扩展。Istio 使用 Kubernetes CRD API 来配置，即使是在非 Kubernetes 环境下部署的 Istio 也是如此。
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ title: Injection
|
|||
test: n/a
|
||||
---
|
||||
|
||||
注入，或 sidecar 注入，是指在创建时使用[动态 Webhooks](https://kubernetes.io/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) 来修改 Pod 规范。
|
||||
注入可用于为网格服务添加 Envoy sidecar 配置或配置[网关](/zh/docs/reference/glossary/#gateway)的 Envoy 代理。
|
||||
注入，或 sidecar 注入，是指在创建时使用 [动态 Webhooks](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) 来修改 Pod 规范。
|
||||
注入可用于为网格服务添加 Envoy sidecar 配置或配置 [网关](/zh/docs/reference/glossary/#gateway) 的 Envoy 代理。
|
||||
|
||||
有关更多信息，请参阅[安装 sidecar](/zh/docs/setup/additional-setup/sidecar-injection)。
|
||||
有关更多信息，请参阅 [安装 sidecar](/zh/docs/setup/additional-setup/sidecar-injection)。
|
||||
|
|
|
|||
|
|
@ -3,4 +3,5 @@ title: Operator
|
|||
test: n/a
|
||||
---
|
||||
|
||||
Operator 是打包，部署和管理 Kubernetes 应用程序的一种方法。有关更多信息，请参见 [Operator pattern](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/)。
|
||||
Operator 是打包，部署和管理 Kubernetes 应用程序的一种方法。
|
||||
有关更多信息，请参见 [Operator pattern](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/operator/)。
|
||||
|
|
|
|||
|
|
@ -3,6 +3,6 @@ title: Pod
|
|||
test: n/a
|
||||
---
|
||||
|
||||
Pod 中包含了一个或多个共享存储和网络的容器 （例如 [Docker](https://www.docker.com/) 容器），
|
||||
Pod 中包含了一个或多个共享存储和网络的容器（例如 [Docker](https://www.docker.com/) 容器），
|
||||
以及如何运行容器的规范。
|
||||
Pod 是 Istio 的 [Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/pod-overview/) 部署中的一个[工作负载实例](/zh/docs/reference/glossary/#workload-instance)。
|
||||
Pod 是 Istio 的 [Kubernetes](https://kubernetes.io/zh-cn/docs/concepts/workloads/pods/) 部署中的一个 [工作负载实例](/zh/docs/reference/glossary/#workload-instance)。
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Istio CNI 插件代替了 `istio-init` 容器所实现的功能。
|
|||
[dataplane v2](https://cloud.google.com/kubernetes-engine/docs/concepts/dataplane-v2)。
|
||||
* OpenShift 默认启用了 CNI。
|
||||
|
||||
1. Kubernetes 需要启用 [ServiceAccount 准入控制器](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#serviceaccount)。
|
||||
1. Kubernetes 需要启用 [ServiceAccount 准入控制器](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/admission-controllers/#serviceaccount)。
|
||||
* Kubernetes 文档中强烈建议所有使用 `ServiceAccounts` 的 Kubernetes 安装实例都启用该控制器。
|
||||
|
||||
### 用 CNI 插件安装 Istio {#install-istio-with-cni-plugin}
|
||||
|
|
|
|||
|
|
@ -154,4 +154,4 @@ spec:
|
|||
|
||||
1. [IstioOperator - 自定义安装](/zh/docs/setup/additional-setup/customize-installation)
|
||||
1. [高级 Helm 技术](https://helm.sh/docs/topics/advanced/)
|
||||
1. [自定义](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/)
|
||||
1. [自定义](https://kubernetes.io/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/)
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ owner: istio/wg-environments-maintainers
|
|||
完成下面步骤需要您有一个 {{< gloss >}}cluster{{< /gloss >}}，
|
||||
且运行着兼容版本的 Kubernetes ({{< supported_kubernetes_versions >}})。
|
||||
您可以使用任何支持的平台，例如：
|
||||
[Minikube](https://kubernetes.io/zh/docs/tasks/tools/install-minikube/)
|
||||
[Minikube](https://kubernetes.io/zh-cn/docs/tasks/tools/#minikube)
|
||||
或[特定平台安装说明](/zh/docs/setup/platform-setup/)章节中指定的其他平台。
|
||||
|
||||
请按照以下步骤开始使用 Istio：
|
||||
|
|
|
|||
|
|
@ -48,8 +48,8 @@ Ingress Gateway 也安装在 `istio-system` 命名空间中，以提供对外部
|
|||
|
||||
变量名称 | 描述
|
||||
-------- | -----------
|
||||
`CTX_EXTERNAL_CLUSTER` | 默认 [Kubernetes配置文件](https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)中的上下文名称，用于访问外部控制平面集群。
|
||||
`CTX_REMOTE_CLUSTER` | 默认 [Kubernetes配置文件](https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)中的上下文名称，用于访问远程集群。
|
||||
`CTX_EXTERNAL_CLUSTER` | 默认 [Kubernetes 配置文件](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 中的上下文名称，用于访问外部控制平面集群。
|
||||
`CTX_REMOTE_CLUSTER` | 默认 [Kubernetes 配置文件](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 中的上下文名称，用于访问远程集群。
|
||||
`REMOTE_CLUSTER_NAME` | 远程集群的名称。
|
||||
`EXTERNAL_ISTIOD_ADDR` | 外部控制平面集群上的 Ingress Gateway 的主机名。 远程集群使用它来访问外部控制平面。
|
||||
`SSL_SECRET_NAME` | 拥有外部控制平面集群上 Ingress Gateway 的 TLS 证书的密钥名称。
|
||||
|
|
|
|||
|
|
@ -34,8 +34,8 @@ owner: istio/wg-environments-maintainers
|
|||
|
||||
变量 | 描述
|
||||
-------- | -----------
|
||||
`CTX_CLUSTER1` | [Kubernetes 配置文件](https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)中的默认上下文名称，用于访问集群 `cluster1`。
|
||||
`CTX_CLUSTER2` | [Kubernetes 配置文件](https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)中的默认上下文名称，用于访问集群 `cluster2`。
|
||||
`CTX_CLUSTER1` | [Kubernetes 配置文件](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)中的默认上下文名称，用于访问集群 `cluster1`。
|
||||
`CTX_CLUSTER2` | [Kubernetes 配置文件](https://kubernetes.io/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)中的默认上下文名称，用于访问集群 `cluster2`。
|
||||
|
||||
继续之前，设置这两个变量：
|
||||
|
||||
|
|
|
|||
|
|
@ -243,7 +243,8 @@ EOF
|
|||
$ kubectl --namespace "${VM_NAMESPACE}" apply -f workloadgroup.yaml
|
||||
{{< /text >}}
|
||||
|
||||
使用自动创建 `WorkloadEntry` 的特性，还可以进行应用程序的健康检查。与 [Kubernetes Readiness Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) 具有相同行为和 API 。
|
||||
使用自动创建 `WorkloadEntry` 的特性，还可以进行应用程序的健康检查。
|
||||
与 [Kubernetes Readiness Probes](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/) 具有相同行为和 API 。
|
||||
|
||||
例如，在应用程序的 `/ready` 端点上配置探针：
|
||||
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ test: no
|
|||
在 Kubernetes 集群 1.22 或更高版本上运行 Istio 不需要特殊配置。对于以前的 Kubernetes 版本，您将需要继续执行这些步骤。
|
||||
{{< /tip >}}
|
||||
|
||||
如果您想要在 Kops 管理的集群上为 Mesh 运行 Istio [Secret Discovery Service](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration) (SDS)，必须添加 [Extra Configurations](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)，以便在 API Server 中启动服务令牌 Projection Volumes。
|
||||
如果您想要在 Kops 管理的集群上为 Mesh 运行 Istio [Secret Discovery Service](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret#sds-configuration) (SDS)，必须添加 [Extra Configurations](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection)，以便在 API Server 中启动服务令牌 Projection Volumes。
|
||||
|
||||
1. 打开配置文件:
|
||||
|
||||
|
|
|
|||
|
|
@ -78,7 +78,7 @@ $ kubectl get nodes
|
|||
[CUSTOM]: https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingclusterusingoke_topic-Using_the_Console_to_create_a_Custom_Cluster_with_Explicitly_Defined_Settings.htm
|
||||
[OCICLI]: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
|
||||
[K8S]: https://docs.oracle.com/en-us/iaas/Content/ContEng/Concepts/contengaboutk8sversions.htm
|
||||
[KUBECTL]: https://kubernetes.io/docs/tasks/tools/
|
||||
[KUBECTL]: https://kubernetes.io/zh-cn/docs/tasks/tools/
|
||||
[CONCEPTS]: https://docs.oracle.com/en-us/iaas/Content/GSG/Concepts/concepts.htm
|
||||
[BASTION]: https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengdownloadkubeconfigfile.htm#localdownload
|
||||
[CONSOLE]: https://docs.oracle.com/en-us/iaas/Content/GSG/Concepts/console.htm
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ TLS 所需的私钥、服务器证书和 root 证书是通过以下方式配置
|
|||
$ kubectl create namespace mesh-external
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建 Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)来保存服务器的和 CA 的证书。
|
||||
1. 创建 Kubernetes [Secrets](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) 来保存服务器的和 CA 的证书。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt
|
||||
|
|
@ -120,7 +120,7 @@ TLS 所需的私钥、服务器证书和 root 证书是通过以下方式配置
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
来保存 NGINX 服务器的配置。
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -393,7 +393,7 @@ Egress 网关将使用 SDS 而不是文件挂载来提供客户端证书。
|
|||
$ kubectl create namespace mesh-external
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建 Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)来保存服务器的证书。
|
||||
1. 创建 Kubernetes [Secrets](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) 来保存服务器的证书。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create -n mesh-external secret tls nginx-server-certs --key my-nginx.mesh-external.svc.cluster.local.key --cert my-nginx.mesh-external.svc.cluster.local.crt
|
||||
|
|
@ -430,7 +430,7 @@ Egress 网关将使用 SDS 而不是文件挂载来提供客户端证书。
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
1. 创建一个 Kubernetes [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
来保存 NGINX 服务器的配置。
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -500,7 +500,7 @@ Egress 网关将使用 SDS 而不是文件挂载来提供客户端证书。
|
|||
|
||||
### 使用 SDS 给 Egress 流量配置双向 TSL 连接{#configure-mutual-TLS-origination-for-egress-traffic-using- SDS}
|
||||
|
||||
1. 创建 Kubernetes [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/)来保存客户的证书。
|
||||
1. 创建 Kubernetes [Secrets](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/)来保存客户的证书。
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create secret -n istio-system generic client-credential --from-file=tls.key=client.example.com.key \
|
||||
|
|
|
|||
|
|
@ -288,7 +288,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
|
|||
$ kubectl create namespace mesh-external
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建 Kubernetes [Secret](https://kubernetes.io/docs/concepts/configuration/secret/)，
|
||||
1. 创建 Kubernetes [Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/)，
|
||||
保存服务器和 CA 的证书。
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -326,7 +326,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 生成 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
1. 生成 Kubernetes [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)
|
||||
保存 NGINX 服务器的配置文件：
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
@ -442,7 +442,7 @@ $ kubectl delete destinationrule egressgateway-for-cnn
|
|||
|
||||
### 使用客户端证书重新部署 egress 网关 {#redeploy-the-egress-gateway-with-the-client-certificates}
|
||||
|
||||
1. 生成 Kubernetes [Secret](https://kubernetes.io/docs/concepts/configuration/secret/)
|
||||
1. 生成 Kubernetes [Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/)
|
||||
保存客户端和 CA 的证书。
|
||||
|
||||
{{< text bash >}}
|
||||
|
|
|
|||
|
|
@ -401,7 +401,7 @@ Istio 只是通过 sidecar 代理实现了这种流向。攻击者只要绕过 s
|
|||
出于安全考虑，集群管理员和云供应商必须确保网格所有的出站流量都要经过 egress gateway。
|
||||
这需要通过 Istio 之外的机制来满足这一要求。例如，集群管理员可以配置防火墙，
|
||||
拒绝 egress gateway 以外的所有流量。
|
||||
[Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)也能禁止所有不是从
|
||||
[Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 也能禁止所有不是从
|
||||
egress gateway 发起的出站流量（[下一节](#apply-Kubernetes-network-policies)有一个这样的例子）。
|
||||
此外，集群管理员和云供应商还可以对网络进行限制，让运行应用的节点只能通过 gateway 来访问外部网络。
|
||||
要实现这一限制，可以只给 gateway Pod 分配公网 IP，并且可以配置 NAT 设备，
|
||||
|
|
@ -409,7 +409,7 @@ egress gateway 发起的出站流量（[下一节](#apply-Kubernetes-network-pol
|
|||
|
||||
## 应用 Kubernetes 网络策略{#apply-Kubernetes-network-policies}
|
||||
|
||||
本节中展示了如何创建 [Kubernetes 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)来阻止绕过
|
||||
本节中展示了如何创建 [Kubernetes 网络策略](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 来阻止绕过
|
||||
egress gateway 的出站流量。为了测试网络策略，首先创建一个 `test-egress` 命名空间，
|
||||
并在其中部署 [sleep]({{< github_tree >}}/samples/sleep) 示例应用，
|
||||
然后尝试发送一个会通过安全网关的外部服务请求。
|
||||
|
|
@ -487,7 +487,7 @@ egress gateway 的出站流量。为了测试网络策略，首先创建一个 `
|
|||
{{< /text >}}
|
||||
|
||||
{{< warning >}}
|
||||
[网络政策](https://kubernetes.io/docs/concepts/services-networking/network-policies/)由您的
|
||||
[网络政策](https://kubernetes.io/zh-cn/docs/concepts/services-networking/network-policies/) 由您的
|
||||
Kubernetes 集群中的网络插件实现。根据您的测试群集，以下情况可能不会阻止下面的步骤。
|
||||
{{< /warning >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ owner: istio/wg-networking-maintainers
|
|||
test: yes
|
||||
---
|
||||
|
||||
Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) 服务和带 [Endpoints](https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors) 的 Kubernetes 服务使你可以创建一个外部服务的本地 DNS 别名。这个 DNS 别名与本地服务的 DNS 条目具有相同的形式，即 `<service name>.<namespace name>.svc.cluster.local`。DNS 别名为您的工作负载提供“位置透明性”：工作负载可以以相同的方式调用本地和外部服务。如果您决定在某个时间在集群内部部署外部服务，您只需更新其 Kubernetes 服务以引用本地版本即可。工作负载将继续运行，而不会有任何变化。
|
||||
Kubernetes [ExternalName](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#externalname) 服务和带 [Endpoints](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#services-without-selectors) 的 Kubernetes 服务使你可以创建一个外部服务的本地 DNS 别名。这个 DNS 别名与本地服务的 DNS 条目具有相同的形式，即 `<service name>.<namespace name>.svc.cluster.local`。DNS 别名为您的工作负载提供“位置透明性”：工作负载可以以相同的方式调用本地和外部服务。如果您决定在某个时间在集群内部部署外部服务，您只需更新其 Kubernetes 服务以引用本地版本即可。工作负载将继续运行，而不会有任何变化。
|
||||
|
||||
这部分内容表明这些访问外部服务的 Kubernetes 机制在 Istio 中依然有效。您只需要配置使用 TLS 模式即可，并不需要 Istio 的[双向 TLS](/zh/docs/concepts/security/#mutual-TLS-authentication)。因为外部服务不是 Istio 服务网格的一部分，所以它们无法执行 Istio 的双向 TLS。您在配置 TLS 模式时，一要按照外部服务的 TLS 模式的要求、二要遵从您的工作负载访问外部服务的方式。当您的工作负载发起的是 HTTP 请求但是外部服务需要 TLS，你可以通过 Istio 发起 TLS。当您的工作负载已经使用 TLS 来加密流量，您可以禁用 Istio 的双向 TLS。
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networkin
|
|||
|
||||
## Kubernetes ExternalName 服务访问外部服务{#ks-external-name-service-to-access-an-external-service}
|
||||
|
||||
1. 在默认命名空间中，为 `httpbin.org` 创建一个 Kubernetes [ExternalName](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) 服务：
|
||||
1. 在默认命名空间中，为 `httpbin.org` 创建一个 Kubernetes [ExternalName](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#externalname) 服务：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl apply -f - <<EOF
|
||||
|
|
|
|||
|
|
@ -208,7 +208,7 @@ _SNI_ 字段在 TLS 握手过程中以未加密的形式发送。
|
|||
|
||||
### 配置客户端——sleep Pod{#configure-the-client-sleep-pod}
|
||||
|
||||
1. 创建 Kubernetes [密钥](https://kubernetes.io/docs/concepts/configuration/secret/)来保存客户端的证书：
|
||||
1. 创建 Kubernetes [密钥](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/)来保存客户端的证书：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create secret generic client-credential --from-file=tls.key=client.example.com.key \
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ test: yes
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建 Kubernetes [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 以保存代理的配置：
|
||||
1. 创建 Kubernetes [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 以保存代理的配置：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create configmap proxy-configmap -n external --from-file=squid.conf=./proxy.conf
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ test: yes
|
|||
|
||||
## 部署一个 NGINX 服务{#deploy-an-nginx-server}
|
||||
|
||||
1. 创建一个 Kubernetes 的 [Secret](https://kubernetes.io/docs/concepts/configuration/secret/) 资源来保存服务的证书：
|
||||
1. 创建一个 Kubernetes 的 [Secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) 资源来保存服务的证书：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create secret tls nginx-server-certs --key nginx.example.com.key --cert nginx.example.com.crt
|
||||
|
|
@ -75,7 +75,7 @@ test: yes
|
|||
EOF
|
||||
{{< /text >}}
|
||||
|
||||
1. 创建一个 Kubernetes 的 [ConfigMap](https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源来保存 NGINX 服务的配置：
|
||||
1. 创建一个 Kubernetes 的 [ConfigMap](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 资源来保存 NGINX 服务的配置：
|
||||
|
||||
{{< text bash >}}
|
||||
$ kubectl create configmap nginx-configmap --from-file=nginx.conf=./nginx.conf
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ aliases:
|
|||
- /zh/news/announcing-0.1
|
||||
---
|
||||
|
||||
Google、IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。
|
||||
Google、IBM 和 Lyft 骄傲的宣布了 [Istio](/zh) 的首个公开版本。Istio 是一个以统一方式对微服务实施连接、管理、监控以及安全增强的开源项目。当前版本专注于支持 [Kubernetes](https://kubernetes.io/zh-cn/) 环境，我们计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。
|
||||
Istio 为微服务添加了流量管理能力，同时为比如安全、监控、路由、连接管理和策略等附加能力打下了基础。此软件构建于来自 Lyft 的经过实战检验的 [Envoy](https://envoyproxy.github.io/envoy/) 代理之上，能在 *无需改动任何应用代码* 的情况下赋予对应用流量的可见性和控制能力。Istio 为 CIO 们提供了一个在企业内加强安全、策略和合规性的强有力的工具。
|
||||
|
||||
## 背景{#background}
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ aliases:
|
|||
|
||||
- _TCP 服务的策略与安全_: 除了 HTTP ，我们还为 TCP 服务增加了透明双向 TLS 认证和策略实施。这将让拥有像遥测，策略和安全等 Istio 功能的同时，保护更多 Kubernetes deployment 。
|
||||
|
||||
- _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。这使得你可以使用 `kubectl` 命令部署微服务，这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。
|
||||
- _自动注入 sidecar_: 通过利用 Kubernetes 1.7 提供的 alpha [初始化程序](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) ，当您的集群启用了该程序时，envoy sidecar 就可以自动注入到应用的 deployment 里。这使得你可以使用 `kubectl` 命令部署微服务，这与您通常在没有 Istio 的情况下部署微服务的命令完全相同。
|
||||
|
||||
- _扩展 Istio_ : 改进的 Mixer 设计，可以允许供应商编写 Mixer 适配器以实现对其自身系统的支持，例如应用管理或策略实施。该 [Mixer 适配器开发指南](https://github.com/istio/istio/wiki/Mixer-Compiled-In-Adapter-Dev-Guide)可以轻松的帮你将 Istio 集成于你的解决方案。
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ aliases:
|
|||
|
||||
### 通用{#general}
|
||||
|
||||
- **更新配置模型**。Istio 现在使用了 Kubernetes 的 [Custom Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
- **更新配置模型**。Istio 现在使用了 Kubernetes 的 [Custom Resource](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
来描述和存储其配置。当运行在 Kubernetes 上时，现在可以使用 `kubectl` 命令来管理配置。
|
||||
|
||||
- **多 namespace 的支持**。Istio 控制平面组件现在位于专用的 `istio-system` namespace 下。
|
||||
|
|
@ -65,7 +65,7 @@ Istio 可以管理其他非系统名称空间中的服务。
|
|||
|
||||
- **多环境的支持**。初步支持将 Istio 与其他服务注册表（包括 Consul 和 Eureka ）结合使用。
|
||||
|
||||
- **自动注入 Sidecar**。使用 Kubernetes 中的 [Initializers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。
|
||||
- **自动注入 Sidecar**。使用 Kubernetes 中的 [Initializers](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) alpha 功能，可以在部署后将 Istio 边车自动注入到 Pod 中。
|
||||
|
||||
### 性能及品质{#performance-and-quality}
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ Istio 可以管理其他非系统名称空间中的服务。
|
|||
- **Egress 规则**。现在可以为 Egress 流量指定路由规则。
|
||||
|
||||
- **新协议**。Mesh-wide 现在支持 WebSocket 链接, MongoDB 代理,
|
||||
和 Kubernetes [headless 服务](https://kubernetes.io/docs/concepts/services-networking/service/#headless-services)。
|
||||
和 Kubernetes [headless 服务](https://kubernetes.io/zh-cn/docs/concepts/services-networking/service/#headless-services)。
|
||||
|
||||
- **其它改进**。Ingress 正确支持 gRPC 服务，更好的支持健康检查和 Jaeger 追踪。
|
||||
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ aliases:
|
|||
|
||||
- **降低插件的负载均衡的要求**。不再通过单独的负载均衡公开插件。而是通过 Istio 网关公开插件。要使用 HTTP 或 HTTPS 协议从外部公开插件，请使用 [Addon Gateway 文档](/zh/docs/tasks/observability/gateways/)。
|
||||
|
||||
- **附加安全凭证**。更改了附加凭证的存储。为了提高安全性与合规性，Grafana、Kiali 以及 Jaeger 的用户名密码现在存储在 [Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/) 中。
|
||||
- **附加安全凭证**。更改了附加凭证的存储。为了提高安全性与合规性，Grafana、Kiali 以及 Jaeger 的用户名密码现在存储在 [Kubernetes secret](https://kubernetes.io/zh-cn/docs/concepts/configuration/secret/) 中。
|
||||
|
||||
- **更加灵活的 `statsd` 收集器**。删除了内置的 `statsd` 收集器。Istio 现在支持您自己的 `statsd`，以提高现有 Kubernetes 部署的灵活性。
|
||||
|
||||
|
|
@ -113,6 +113,6 @@ aliases:
|
|||
- **安装验证命令**。添加 [`istioctl verify-install`](/zh/docs/reference/commands/istioctl/#istioctl-verify-install) 命令，用于验证指定了 YAML 文件的 Istio 安装的状态。
|
||||
|
||||
- **弃用命令**。弃用 `istioctl create`、`istioctl replace`、`istioctl get` 和 `istioctl delete` 命令。
|
||||
请使用 [`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl) 替代。`istioctl gen-deploy` 命令也被弃用。请改用 [`helm template`](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template)。这些命令将在 1.2 版被删除。
|
||||
请使用 [`kubectl`](https://kubernetes.io/zh-cn/docs/tasks/tools/#kubectl) 替代。`istioctl gen-deploy` 命令也被弃用。请改用 [`helm template`](/zh/docs/setup/install/helm/#option-1-install-with-helm-via-helm-template)。这些命令将在 1.2 版被删除。
|
||||
|
||||
- **短命令**。`kubectl` 包含了一些简短命令，可用于 gateway，虚拟服务，目标规则和服务条目。
|
||||
|
|
|
|||
|
|
@ -14,12 +14,12 @@ aliases:
|
|||
|
||||
- **新增** 新增了包含 `MeshConfig.DefaultConfig` 配置的稳定子集，用于配置 `ProxyConfig` 值的一个 API (CRD)。
|
||||
|
||||
- **新增** 新增了基于主机名的支持东西向流量的多网络网关。主机名将在控制平面和每个 IP 将用作端点。可以通过设置禁用此行为 istiod 的 `RESOLVE_HOSTNAME_GATEWAYS= false`。
|
||||
- **新增** 新增了基于主机名的支持东西向流量的多网络网关。主机名将在控制平面和每个 IP 将用作端点。可以通过设置禁用此行为 istiod 的 `RESOLVE_HOSTNAME_GATEWAYS= false`。
|
||||
([Issue #29359](https://github.com/istio/istio/issues/29359))
|
||||
|
||||
- **新增** 新增了对 gRPC 探针重写的支持。
|
||||
|
||||
- **新增** 新增了一个功能标志 `PILOT_LEGACY_INGRESS_BEHAVIOR`，默认为 false。如果设置为 true，Istio ingress 将执行不符合[Kubernetes 规范](https://kubernetes.io/docs/concepts/services-networking/ingress/#multiple-matches)。
|
||||
- **新增** 新增了一个功能标志 `PILOT_LEGACY_INGRESS_BEHAVIOR`，默认为 false。如果设置为 true，Istio ingress 将执行不符合 [Kubernetes 规范](https://kubernetes.io/zh-cn/docs/concepts/services-networking/ingress/#multiple-matches)。
|
||||
([Issue #35033](https://github.com/istio/istio/issues/35033))
|
||||
|
||||
- **新增** 新增了通过 `proxyMetadata` 在 Envoy 工作线程之间取得平衡监听器的支持。
|
||||
|
|
|
|||
|
|
@ -187,8 +187,9 @@ aliases:
|
|||
- **修复** `istioctl install --dry-run` 的意外警告日志。
|
||||
([Issue #37084](https://github.com/istio/istio/issues/37084))
|
||||
|
||||
- **修复** 使用 `kube-inject` 时出现 nil 指针，取消引用恐慌，没有通过所需的修订，但也传递了 `injectConfigMapName`。 ([Issue #38083](https://github.com/istio/istio/issues/38083))
|
||||
- **修复** 使用 `kube-inject` 时出现 nil 指针，取消引用恐慌，没有通过所需的修订，但也传递了 `injectConfigMapName`。
|
||||
([Issue #38083](https://github.com/istio/istio/issues/38083))
|
||||
|
||||
- **修复** Kubernetes 1.24+ 上 `istioctl create-remote-secret` 的行为。在这些版本中，
|
||||
不再自动创建包含 `ServiceAccount` API 令牌的 Secret，因此 `istioctl`
|
||||
将要[创建一个服务账号令牌](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)。
|
||||
将要 [创建一个服务账号令牌](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#manually-create-an-api-token-for-a-serviceaccount)。
|
||||
|
|
|
|||
|
|
@ -98,7 +98,7 @@ weight: 10
|
|||
|
||||
- **新增** 在 `istio-init` 容器中增加了 `--log_output_level` 和 `--log_as_json`（正如它们在 `istio-proxy` 中一样）。
|
||||
|
||||
- **新增** 为 Istio Gateway Helm chart 增加了配置网关部署的 [topologySpreadConstraints](https://kubernetes.io/docs/concepts/workloads/pods/pod-topology-spread-constraints/) 的值。
|
||||
- **新增** 为 Istio Gateway Helm chart 增加了配置网关部署的 [topologySpreadConstraints](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/topology-spread-constraints/) 的值。
|
||||
|
||||
- **新增** 新增了对监视外部 istiod 的本地密钥资源更新的支持。
|
||||
([Issue #31946](https://github.com/istio/istio/issues/31946))
|
||||
|
|
|
|||
|
|
@ -28,4 +28,4 @@ aliases:
|
|||
- 通过将重试设置为 0，允许用户禁用 Istio 的默认重试（[Issue 14900](https://github.com/istio/istio/issues/14900)）
|
||||
- 引入 Redis 过滤器（此功能由环境特性标志 `PILOT_ENABLE_REDIS_FILTER` 保护，默认情况下处于禁用状态）
|
||||
- 将 HTTP/1.0 支持添加到网关配置生成（[Issue 13085](https://github.com/istio/istio/issues/13085)）
|
||||
- 为 Istio 组件添加了[容忍](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)（[Pull Request 15081](https://github.com/istio/istio/pull/15081)）
|
||||
- 为 Istio 组件添加了[容忍](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)（[Pull Request 15081](https://github.com/istio/istio/pull/15081)）
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ aliases:
|
|||
## 安装和升级 {#installation-and-upgrade}
|
||||
|
||||
- **更新** 默认代理内存大小限制 (`global.proxy.resources.limits.memory`) 从 `128Mi` 扩大到 `1024Mi`，以此保证代理有充足的内存。
|
||||
- **增加** pod 的[反亲和性](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)和[容错](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/)功能支持了所有的控制平面组件。
|
||||
- **增加** Pod 的 [反亲和性](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 和 [容错](https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) 功能支持了所有的控制平面组件。
|
||||
- **增加** `sidecarInjectorWebhook.neverInjectSelector` 和 `sidecarInjectorWebhook.alwaysInjectSelector` 配置，通过标签选择器让用户可以进一步控制 workload 是否应该自动注入 sidecar。
|
||||
- **增加** `global.logging.level` 和 `global.proxy.logLevel` 配置，允许用户方便的给控制平面和数据平面组件全局的配置日志。
|
||||
- **增加** 支持通过设置 [`global.tracer.datadog.address`](/zh/docs/reference/config/installation-options/#global-options) 来配置 Datadog 的地址。
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ weight: 20
|
|||
|
||||
## 配置管理{#configuration-management}
|
||||
|
||||
我们已经在 Istio 资源 的 Kubernetes schema 中介绍过 OpenAPI V3 [Custom Resource Definitions (CRD)](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)，此 schema 描述 Istio 资源并且确保你创建和修改的 Istio 资源能够结构化并且保持正确。
|
||||
我们已经在 Istio 资源 的 Kubernetes schema 中介绍过 OpenAPI V3 [Custom Resource Definitions (CRD)](https://kubernetes.io/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)，此 schema 描述 Istio 资源并且确保你创建和修改的 Istio 资源能够结构化并且保持正确。
|
||||
|
||||
如果配置的某个或者多个字段是 unknown 或者错误的类型，那么当你创建或者修改 Istio 资源的时候 Kubernetes API server 会拒绝。这个特性，`CustomResourceValidation` 是 Kubernetes 1.9+ 版本的默认选项。需要注意的是如果某个之前已经存在的配置并且没有被修改过那么他们 __不会__ 受到影响。
|
||||
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ weight: 10
|
|||
- **毕业** [自动双向 TLS](/zh/docs/tasks/security/authentication/authn-policy/#auto-mutual-TLS) 从 alpha 转到 beta。该特性现在默认启用。
|
||||
- **改进** 通过将 Node Agent 与 Pilot Agent 作为 Istio Agent 合并，并删除跨 Pod UDS，从而提高了 [SDS 安全性](https://www.envoyproxy.io/docs/envoy/latest/configuration/security/secret) ，不再需要用户为 UDS 连接部署 Kubernetes Pod 安全策略。
|
||||
- **改进** 通过在 istiod 中包含证书来改进 Istio。
|
||||
- **新增** [`first-party-jwt`](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#service-account-tokens) 在 [`third-party-jwt`](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) 不支持的集群中添加了支持 Kubernetes 作为 CSR 身份验证的后备令牌。
|
||||
- **新增** [`first-party-jwt`](https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens) 在 [`third-party-jwt`](https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#service-account-token-volume-projection) 不支持的集群中添加了支持 Kubernetes 作为 CSR 身份验证的后备令牌。
|
||||
- **新增** 支持 Istio CA 和 Kubernetes CA 为控制平面提供证书，可以通过 `values.global.pilotCertProvider` 进行配置。
|
||||
- **新增** Istio Agent 为 Prometheus 设置了密钥和证书。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue