Kubees网关API经过形象复杂性并提供申明式的方法来定义路由和流量战略，简化了性能流程。

译自EffectiveTrafficManagementwithKubernetesGatewayAPIPolicies。

在本文中，咱们将深化讨论Kubernetes网关API战略及其在治理和控制Kubernetes集群内流量中的关键作用。

经过片面了解这些战略、如何有效应用它们，以及它们对流量治理战略能够发生的反派性影响，您将把握所需的常识和通经常出现地，以充散施展Kubernetes网关API战略在优化流量治理中的后劲。

Kubernetes网关API扭转了咱们在Kubernetes集群内治理和控制流量的形式，提供了许多清楚长处。首先，它经过形象复杂性并提供申明式的方法来定义路由和流量战略，简化了性能环节。

此外，它与Kubernetes的本地集成确保了无缝配合，应用了Kubernetes的编排和可裁减性才干。有了Kubernetes网关API，可以启动细粒度的流量控制，准许在各个阶段启动准确治理，从恳求路由到照应转换。

随着运行程序裁减，Kubernetes网关API可以轻松裁减，处置高流量负载并顺应一直变动的上班负载，无需人工干预。它联合了Kubernetes的自我修复性能，即使在pod缺点或降级时期也可以确保继续的流量散发。安保至关关键，Kubernetes网关API无缝集成了Kubernetes的安保机制，确保只要授权的流量可以抵达您的服务。另外，它提供了增强的可观测性，具备弱小的监控和缺点扫除性能。

与传统流量治理方法的比拟

与传统的流量治理方法(如配件设备或外部负载平衡器)相比，Kubernetes网关API具备几个共同长处。传统方法通常会参与基础设备复杂度，经常须要配件或虚构设备，而Kubernetes网关API应用了现有的Kubernetes集群基础设备。

裁减传统流量治理处置方案或许须要人工干预和额外老本，但Kubernetes网关API可以依据pod和服务智能裁减。性能矫捷性是另一个区别点，由于Kubernetes网关API驳回申明式性能，繁难轻松降级和回滚，而传统处置方案或许须要手动从新性能，从而造成停机时期。供应商锁定是传统处置方案的一个疑问，而Kubernetes网关API是开源和供应商中立的，提供灵敏性并防止供应商依赖。

此外，Kubernetes网关API器重资源效率，优化应用了现有的Kubernetes资源，而传统处置方案或许须要公用资源。最后，Kubernetes网关API受益于兴盛的Kubernetes社区，保障继续开发、降级和片面的支持。

实质上，Kubernetes网关API作为一种现代化的、原生Kubernetes的流量治理方法，提供了繁难性、可裁减性和与Kubernetes生态系统的无缝集成，因此相较传统流量治理方法具备十分强的长处。

Kubernetes网关API战略概述

Kubernetes网关API战略是治理和控制Kubernetes集群内流量的关键组成局部。这些战略定义了管控流量的规定和行为，确保了优秀的性能、安保性和牢靠性。了解和实施这些战略关于Kubernetes环境中的有效流量治理至关关键。

战略在流量治理中的经常出现运行场景

Kubernetes网关API战略可运行于各种流量治理场景。经常出现运行场景包括速率限制以防止服务过载、恳求和照应转换以启动数据格局转换或增强、认证和授权以控制服务访问、断路器以优雅处置缺点、负载平衡以高效散发流量，以及流量分流以口头A/B测试或金丝雀部署。这些战略处置了多种流量治理需求，并可依据详细要求启动定制。

关键战略类型简介

Kubernetes网关API战略蕴含若干关键类型，每个都服务于不同目的:

如何在流量流程的不同阶段运行战略

Kubernetes网关API战略可在流量流程各个阶段运行，这取决于详细需求和场景。这些阶段包括:

了解如何在不同阶段运行这些战略，使Kubernetes用户能够设计满足详细需求和运维要求的有效流量治理处置方案。

逐渐实施Kubernetes网关API战略指南

为了有效实施Kubernetes网关API战略，了解可用的详细战略类型及其各自运行场景十分关键。以下是每个战略类型的逐渐指南:

YAML示例和解释

关于每种战略类型，YAML示例和详细解释都是贵重资源。这些示例展现了如何用Kubernetes自身的形式定义战略。

以下是2种Kubernetes网关API战略的代码示例及解释:

以下YAML代码段设置了一个速率限制战略。网关定义了路由规定，HTTPRoute指定了带有URI前缀的恳求应遭到速率限制，准许每秒最多100个恳求。

apiVersion:networking.x-k8s.io/v1alpha1kind:Gatewaymetadata:name:rate-limit-gatewayspec:rules:-http:paths:-path:/apipathType:Prefixbackend:service:name:my-serviceport:number:80---apiVersion:networking.x-k8s.io/v1alpha1kind:HTTPRoutemetadata:name:rate-limit-routespec:gateway:rate-limit-gatewayrules:-matches:-uri:prefix:/apifilters:-type:RequestRateLimitmaxRequests:100window:1s

以下YAML代码段性能了一个恳求转换战略。它为带有URI前缀的传入恳求参与了一个自定义标头X-Custom-Header。

apiVersion:networking.x-k8s.io/v1alpha1kind:Gatewaymetadata:name:request-transform-gatewayspec:rules:-http:paths:-path:/apipathType:Prefixbackend:service:name:my-serviceport:number:80---apiVersion:networking.x-k8s.io/v1alpha1kind:HTTPRoutemetadata:name:request-transform-routespec:gateway:request-transform-gatewayrules:-matches:-uri:prefix:/apifilters:-type:RequestHeaderTransformationrequestHeaders:add:-name:X-Custom-Headervalue:"true"

这些是简化的示例。在通常中，战略可以具备更复杂的性能，并依据详细流量治理需求蕴含额外参数。

战略参数和性能选项

了解战略参数和性能选项的纤细差异，关于依据详细要求定制战略至关关键。本节深化讨论了与每种战略类型关系的各种参数，如速率限制、转换规定、认证提供者、断路器阈值、负载平衡算法和流量调配百分比等，并解释如何微调这些参数以成功希冀的流量治理结果。

缺点扫除和调试

与任何技术一样，经常使用Kubernetes网关API战略或许会带来必定应战。一些经常出现疑问包括战略性能失误造成意在行为、失误路由规定和战略抵触等。还或许遇四处置认证授权失误、调试速率限制疑问以及诊断照应转换疑问等。对这些潜在圈套有所了解并制订缺点扫除战略，关于有效的战略治理至关关键。

调试技术和工具

当疑问发生时，领有有效的调试技术和工具至关关键。Kubernetes提供了各种工具比如、 kubectllogs 和 kubectldescribe 来审核资源和访问日志。监控和可观测性工具，如Prometheus和Grafana，可以协助跟踪与战略关系的目的。此外，日志聚合系统如Elasticsearch和Fluentd可以协助识别和诊断疑问。面向容器的调试工具，如exec进入pod和容器运转时日志，关于定位容器内的疑问十分有价值。

如何优雅地处置战略失败

优雅地处置战略失败是维持服务牢靠性的关键方面。Kubernetes网关API战略通常在复杂环境中运转，或许由于各种起因造成失败。实施断路器战略可以经过隔离有疑问的服务来防止缺点级联。运行程序中的有效失误处置可以确保当遇到基于战略的限制时，用户收到信息性失误信息。继续监控和警报系统可以实时洞悉战略失败，准许采取被动照应和弥补措施。

裁减和性能优化

这里是一些裁减和性能优化的揭示:

经常使用Kubernetes网关API裁减流量治理的战略:经常使用Kubernetes网关API启动裁减的战略包括基于资源应用率或自定义目的智能调整pod数量的水平Pod智能缩放(HPA)。成功Ingress或AmbassadorIngress等KubernetesIngress控制器可以协助有效调配流量。负载平衡战略可以平均调配流量，而流量分流准许受控地测试新版本。裁减思考不只应包括网关API，还应涵盖底层服务和基础设备。

性能优化技术:为了优化性能，可以思考在API网关级别缓存频繁访问的数据来缩小后端负载等战略。最小化不用要的照应转换可以提高照应时期。应用CDN服务缓存静态资源可以改善内容交付。此外，优化数据库查问、缩小服务间通讯提前以及驳回内容紧缩技术都可以协助提高全体性能。

基准测试和测量战略对性能的影响:基准测试和测量战略对性能的影响关于做出理智决策至关关键。应用Benchmark(ab)或专业负载测试工具来模拟不同流量场景，评价战略如何影响照应时期和吞吐量。继续监控和目的搜集关于跟踪性能影响随时期变动十分关键。这些基准和目的为战略能否满足性能预期或须要进一步优化提供了贵重见地。

最佳通常和揭示

有效实施Kubernetes网关API战略须要遵照最佳通常和驳回经过验证的流量治理战略。

设计有效的流量治理战略时，思考诸如繁难性、模块化和分歧性等起因。尽或许坚持战略繁难以缩小复杂性和潜在失误。模块化战略以促成重用性和便于治理。确保命名商定和性能的分歧性以维持明晰度。另外，经过实施适当的认证和授权战略来优先思考安保性。最后，让各团队(如开发、运维、安保)的利益关系者介入，共同定义满足一切方需求的战略。

有效的测试和监控关于确保流量治理战略按预期运转至关关键。经过创立涵盖不同用例和边缘状况的测试场景来实施健全的测试战略。应用Gatling或Locust等工具启动负载测试，评价战略在各种条件下的行为。经常使用Prometheus和Grafana等处置方案成功片面的监控，捕捉关系目的并可视化性能。设置警报以被动检测和处置疑问。并活期审查和降级测试与监控战略，以顺应一直变动的流量形式和战略变卦。

战略版本控制和降级是战略治理的关键方面。为战略实施版本控制方案，以跟踪更改和确保向后兼容性。在没有明白推出方案和与关系利益关系者的适当沟通的状况下，不要启动保守的战略更改。应用Kubernetes的本机性能比如滚动降级和金丝雀部署来治理战略降级，防止终止。彻底记载战略更改并有效地传播给所无关系团队。一直在准消费环境中测试战略降级，以识别潜在疑问，而后再将更改运行于消费环境。

---

调用k8s API

如上图所示，用户（User和Service Account）在调用API时会经过三个步骤：认证、鉴权和准入控制。

如上图步骤 1所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。 集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。

认证步骤输入的是整个 HTTP 请求，但是组件通常只检查头部和客户端证书。

认证模块包含客户端证书、密码、普通令牌、引导令牌和 JSON Web 令牌（JWT，用于服务账户）。

可以指定多个认证模块，在这种情况下，服务器依次尝试每个验证模块，直到其中一个成功。

如果请求认证不通过，服务器将以 HTTP 状态码 401 拒绝该请求。 反之，该用户被认证为特定的username ，并且该用户名可用于后续步骤以在其决策中使用。 部分验证器还提供用户的组成员身份，其他则不提供。

如上图的步骤 2所示，将请求验证为来自特定的用户后，请求必须被鉴权。

请求必须包含请求者的用户名、请求的行为以及受该操作影响的对象。 如果现有策略声明用户有权完成请求的操作，那么该请求被鉴权通过。

Kubernetes 支持多种鉴权模块，例如 ABAC 模式、RBAC 模式和 Webhook 模式等。 管理员创建集群时，他们配置应在 API 服务器中使用的鉴权模块。 如果配置了多个鉴权模块，则 Kubernetes 会检查每个模块，任意一个模块鉴权该请求，请求即可继续； 如果所有模块拒绝了该请求，请求将会被拒绝（HTTP 状态码 403）。

准入控制模块是可以修改或拒绝请求的软件模块。 除鉴权模块可用的属性外，准入控制模块还可以访问正在创建或修改的对象的内容。

准入控制器对创建、修改、删除或（通过代理）连接对象的请求进行操作。 准入控制器不会对仅读取对象的请求起作用 。 有多个准入控制器被配置时，服务器将依次调用它们。

这一操作如上图的步骤 3所示。

与身份认证和鉴权模块不同，如果任何准入控制器模块拒绝某请求，则该请求将立即被拒绝。

除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。

请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 4所示）。

所有 Kubernetes 集群都有两类用户：普通用户和由 Kubernetes 管理的服务账号。

Kubernetes 并不包含用来代表普通用户账号的对象 。 普通用户的信息无法通过 API 调用添加到集群中。

但是Kubernetes 仍然认为能够提供由集群的证书机构签名的合法证书的用户是通过身份认证的用户。基于这样的配置，Kubernetes 使用证书中的 subject 的通用名称（Common Name）字段（例如，/CN=bob）来确定用户名。然后，基于角色访问控制（RBAC）子系统会确定用户是否有权针对 某资源执行特定的操作。

与普通用户不同，服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间， 或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret 保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。

Kubernetes 使用身份认证插件利用客户端证书、持有者令牌（Bearer Token）、身份认证代理（Proxy） 或者 HTTP 基本认证机制来认证 API 请求的身份。HTTP 请求发给 API 服务器时， 插件会将以下属性关联到请求本身：

你可以同时启用多种身份认证方法，并且你通常会至少使用两种方法：

当集群中启用了多个身份认证模块时，第一个成功地对请求完成身份认证的模块会 直接做出评估决定。API 服务器并不保证身份认证模块的运行顺序。

要启动客户端证书身份认证，需要配置apiserver， 传入参数 --client-ca-file=SOMEFILE，其中ca要与集群的ca一致。集群使用的ca可以通过以下命令查看

如果客户端的证书认证通过，则 subject 中的公共名称（Common Name）就被 作为请求的用户名。 自 Kubernetes 1.4 开始，客户端证书还可以通过证书的 organization 字段标明用户的组成员信息。 要包含用户的多个组成员信息，可以在证书种包含多个 organization 字段。

当 API server的命令行设置了--token-auth-file=SOMEFILE选项时，会从文件中读取持有者令牌。目前，令牌会长期有效，并且在 不重启 API server的情况下 无法更改令牌列表。

令牌文件是一个 CSV 文件，包含至少 3 个列：令牌、用户名和用户的 UID。 其余列被视为可选的组名。

服务账号（Service Account）是一种自动被启用的用户认证机制，使用经过签名的 持有者令牌来验证请求。

当服务账号创建后，k8s会自动生成对应的secret，存有可以用来认证的token。

上面的token就可以用来认证。

所有使用token进行认证的请求 ，都要加上Authorization的 HTTP请求头，其值格式为Bearer TOKEN 。

例如：如果持有者令牌为31ada4fd-adec-460c-809a-9e56ceb ，则其 出现在 HTTP 头部时如下所示：

使用这种认证方式，apiserver将从请求头中获取用户信息，认证过程如图所示。

使用这种认证方式需要对apiserver进行如下配置：

例子：

假设apiserver配置如下

收到的请求头如下

会生成如下的用户信息用于鉴权

Role 总是用来在某个namespace内设置访问权限；在你创建 Role 时，你必须指定该 Role 所属的namespace。

与之相对，ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同（Role 和 ClusterRole）是因为 Kubernetes 对象要么是namespace作用域的，要么是集群作用域的， 不可两者兼具。

ClusterRole 有若干用法。你可以用它来：

如果你希望在namespace内定义角色，应该使用 Role； 如果你希望定义集群范围的角色，应该使用 ClusterRole。

Role例子

ClusterRole例子

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。 它包含若干 主体 （用户、组或服务账户）的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权，而 ClusterRoleBinding 在集群范围执行授权。

一个 RoleBinding 可以引用同一的名字空间中的任何 Role。 或者，一个 RoleBinding 可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole 绑定到集群中所有名字空间，你要使用 ClusterRoleBinding。

RoleBinding例子

ClusterRoleBinding例子

以上就是RBAC鉴权的一个概述，总结下就是Role定义了角色有哪些权限，RoleBinding则将角色和用户关联起来。这里的权限指的是对哪些资源有哪些操作的权限，用户则包括了普通用户和服务账号。

更多的关于RBAC的描述可以看下 官网 ，包括了k8s内置的一些默认角色。

这里测试使用的k8s集群是通过kubeadm安装的，这种安装方式会将k8s中的组件如kube-apiserver、kube-scheduler等作为static pod的形式运行。因此可以通过 kubectl get pod 命令来查看对应组件的配置。

从上面的结果可以看到使用的ca是 /etc/kubernetes/pki/ ，接下来开始生成客户端的证书。

这样就生成了一个用户名为test的客户端证书，接下来用这个证书去调k8s的api。

这代表我们认证通过了，但是鉴权没有通过。接下来给test授权。

先创建一个角色()，拥有kube-system namespace下读取pod的权限，使用命令 kubectl apply -f 来让他生效。

接下来创建一个RoleBinding，将刚刚创建的角色绑定到test上，并使用命令 kubectl apply -f 来让他生效

生效后再次使用curl调用api，一切正常。

先创建一个kube-system下的服务账号，命令如下

查看有没有生效

可以看到名称为test的sa(service account)已经创建了。接下来查看他对应的secret来获得token。

使用token调用k8s的api

从结果可以确认认证通过了，现在给sa授权，修改，修改后内容如下

使用命令 kubectl apply -f 生效后，再次调用api，这时就不会返回403了。

之前查看apiserver的配置时，看到以下配置，说明apiserver是开启了代理认证的，并且指明了使用的ca。

接下来根据ca生成代理所使用的证书，注意这个ca一般与X509所使用的ca不一致。

并且使用这种方法调用api时，不同的用户只需更改对应的请求头即可，证书不用变更，而如果使用X509的方法，则不同的用户需要使用不同的证书。

调用api

这里由于使用的请求头表明了当前的用户是test，并且之前已经给test授权过了，所以没有返回403。

接下来更改用户名为jojo，再次调用api

返回结果如下

这里 是官方的API参考文档，说明了有哪些api以及对应的使用方式。

2020-05-18【Istio服务治理，K8S各个组件】

今日鸡汤：

愿你能遇到了解你的人：）

Istio流量治理的目标是什么？ 以基础设施的方式提供给用户非侵入的流量治理能力，用户只需要关注自己的业务逻辑开发，无须关注服务访问管理。

Istio流量治理的方式是什么？ 在控制面：管理员通过命令或API创建流量规则，Pilot将该规则转换为Envoy标准形式后下发给Envoy。 在数据面：Envoy拦截Pod本地容器的Inbound和Outbound流量，在流量经过Envoy时执行对应的流量规则，进行治理。

服务发现和负载均衡的工作流程是什么？ 第一步，服务注册，各服务将服务名和服务实例注册到服务注册中心； 第二步，服务发现，客户端发起服务访问时，从服务注册中心获取服务对应的实例； 第三步，负载均衡，从实例列表中选择一个服务实例。

Pilot将服务发现数据通过Envoy的标准接口发给数据面，Envoy根据配置的负载均衡策略选择一个实例转发请求。

为什么需要服务熔断？ 防止网络和服务调用故障级联发生，限制故障的影响范围，防止故障蔓延导致系统整体性能下降或雪崩。 在Istio中提供了连接池和故障实例隔离的能力。 -连接池：在Istio中通过限制某个客户端对目标服务的连接数、访问请求数等，避免对一个服务的过量访问，如果超过配置阈值，则快速断路请求。 -故障实例隔离：如果某个服务频繁超时或出错，则将该实例隔离。

什么是故障注入？ 使用一种手段在待测试的系统中引入故障，从而测试其健壮性和应对故障的能力。

灰度发布的场景？ 第一种，蓝绿发布。新版本部署在另一套独立的资源上，当可用时，直接将所有流量从老版本切换到新版本，当有问题时，快速切回老版本。 第二种，AB测试。同时在线上部署A和B两个对等的版本来接受流量，收集反馈，最终决定用哪个版本。 第三种，金丝雀发布。上线一个新版本，从老版本切一部分流量到新版本上来判定新版本在生产环境的实际表现，没有问题的话，逐步增加切换比例直到全部切换完成。

Istio的服务访问入口是什么？ 在Istio中通过Gateway访问网格内的数据，也是一个Envoy，从Istio的控制面板接受配置，统一执行配置规则，Gateway一般为LoadBalancer类型的service。

在Istio中怎么接入外部服务？ 通过一个ServiceEntry的资源对象将网格外的服务注册到网格上，然后像对网格内的普通服务一样对网格外的服务访问进行治理。

推荐一篇文章： 换个角度入门K8S ，从业务演进的角度讲K8S的各个组件功能，总结一下：

运行编排系统的服务器叫做 master节点 ，运行业务容器的服务器叫做 worker节点 。 master节点上提供管理接口的组件叫 kube apiserver 。 与api server交互的客户端中，提供给集群运维管理员使用的叫做 kubectl ，提供给worker节点使用的叫做 kubelet 。 运维人员可以通过kubelet向master发送命令，master收到请求后，根据集群中worker节点的资源信息进行调度，然后把创建指令下发到对应的worker上，负责调度的叫 kube scheduler 。 每个worker上的kubelet会周期性的上报节点资源和容器运行情况，然后master把数据存储到 etcd 的开源系统中。 为了与其他worker节点通信，每个worker节点需要有容器ip的路由转发信息，由一个专门负责监听并调整路由转发配置的组件来负责，叫 kube proxy 。