与 Kubernetes 共存:强大的 API 使用和管理

Posted K8S中文社区

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了与 Kubernetes 共存:强大的 API 使用和管理相关的知识,希望对你有一定的参考价值。

name: socks.mine.k8s.io spec: group: mine.k8s.io versions: - name: v1alpha1 names: kind: Sock plural: socks scope: Namespaced


name: socks.mine.k8s.io spec: group: mine.k8s.io versions: - name: v1alpha1 served: true storage: false schema: ... - name: v1beta1 served: true storage: true schema: ... names: kind: Sock plural: socks scope: Namespaced

该规范是指两个/apsi/mine.k8s.io/v1alpha1/和/apis/mine.k8s.io/v1beta1/将从API服务。当一个新的“sock”对象被创建时,它会作为 v1beta1 存储在 etcd 中,因为 storage: true 在 v1beta1 版本下。etcd 中只能存储一个版本。

如果你的版本有方案更改,则需要在将资源提交给 API 时对其进行修改。此步骤通过转换 webhook处理 。webhook 负责读取资源并将方案转换为不同的版本并将其发送回 API 服务器。

你可以像这样将转换 webhook 规范添加到你的 CR:


  • conversion: strategy: Webhook webhook: clientConfig: url: "https://socks.converter.example/convert-me"

    任何时候在 Kubernetes API 服务器中创建 sock 资源时,其规范都会发送到指定的 URL 进行转换。转换 webhook 应该对资源执行任何必要的操作,并将其作为 ConversionReview 对象发送回 API 服务器。

    使用 webhooks 进行转换可以非常灵活地管理 CR 生命周期,并让你可以根据需要缓慢地从一个版本迁移到另一个版本。

    带有转换 webhook 的 CR 需要与聚合 API 相同数量的组件,但你可以利用 etcd`来存储对象。此外,默认的 API 模式可以简化你需要维护的工作量。

    更新所有资源后,你可以通过在 CR 定义版本中使用 deprecated: true来弃用旧版本。不推荐使用的版本仍将由 API 提供服务,但当使用不推荐使用的版本将资源提交给 API 服务器时,它们将打印警告。


    结论


    Kubernetes API 的核心优势之一是在任何环境中都具有灵活性。了解你的资源使用的组和版本是用户的责任,以确保他们的资源与当前的 Kubernetes API 兼容。
    在许多情况下,资源可以被通过修改并存储为较新的资源,而无需任何用户操作。此功能使用户对 API 升级更有信心,并允许逐步更改方案。

    无论你是使用 pluto 之类的工具静态验证你的资源还是使用转换 webhook 自动转换你的资源,重要的是确保你能够安全地将资源从一个版本迁移到另一个版本。尽早添加这些测试将帮助你在长期使用 Kubernetes 时充满信心。

    参考:https://www.kubernetes.org.cn/9768.html



    快速加 K8s学习交流群,与大佬共卷!

    扫码加我微信,进群和大佬们零距离


    与 Kubernetes 共存:集群升级的4种方式

    如果你已经使用 Kubernetes 一段时间了,则可能需要考虑计划定期升级。从 Kubernetes 1.19 开始,每个开源版本都提供一年的补丁。你需要升级到最新的可用次要版本或补丁版本才能获得安全性和错误修复。但是,如何在不停机的情况下升级基础架构的关键部分呢?本文将指导你了解在任何环境中升级 Kubernetes 时要考虑的常见模式。

    我们不会深入研究执行升级的所有工具和注意事项。如果你使用的是集群管理工具或托管 Kubernetes 服务,你应该查阅你的文档以获得最适合你环境的选项。你还需要注意,某些工作负载和环境可能会限制你选择的升级策略。

    我们将讨论集群升级的一些高级模式:

    这些模式类似于应用程序升级选项,但由于其潜在的影响可能需要考虑一些独特的因素。升级基础设施可能会产生相当大的成本,具体取决于升级需要多长时间以及你的规模有多大。

    控制平面组件

    Kubernetes 控制平面由 Kubernetes API Server、etcd 数据库、controller manager,、scheduler以及你的环境中可能拥有的任何其他控制器(例如云或ingress )组成。升级 API Server是升级集群的第一步。Kubernetes 将状态存储在 etcd 中,并且随着任何重大应用程序升级,你需要确保至少有一个备份,并且你已经验证可以恢复备份。在某些情况下,API Server升级可能还需要 etcd 升级。

    数据平面组件

    Kubernetes 数据平面由 kubelet、容器运行时以及你在集群工作负载中使用的任何网络、日志记录或存储驱动程序组成。对于许多集群,至少需要 kube-proxy 和 CNI 插件更新。你的数据平面组件可以小于等于你的 API Server版本。理想情况下,你的主机操作系统、容器运行时和数据平面组件可以相互独立升级。将这些组件解耦,将确保你可以在出现错误修复、新功能或安全补丁时快速升级。

    Kubernetes 托管服务

    如果你使用Amazon Elastic Kubernetes Service (EKS)等托管 Kubernetes 服务,则会为你处理控制平面升级。如果你使用的是托管数据平面服务,例如托管节点组 (MNG),你的数据平面升级也应该由你的云提供商自动处理。

    即使使用托管服务,你仍然有责任验证已安装在集群中的工作负载、附加控制器和第三方插件(例如 CNI)。在测试或开发环境中升级集群之前,应测试这些组件的 API 兼容性。

    在所有这些升级策略中,你应该避免在集群升级期间进行应用程序升级。如果可能,请保持你的工作负载使用相同的版本,以最大限度地减少可能错误地归因于 Kubernetes 升级的故障。还要尽量减少其他潜在问题,例如scheme升级或应用程序 API 兼容性。

    对于任何 Kubernetes 升级,你应该按以下顺序升级组件:

    1. 控制平面
    2. 数据平面和节点
    3. 附加组件
    4. 工作负载

    这些升级模式将帮助你决定如何升级最适合你的集群和环境的组件。

    原地升级(In-Place Upgrade)

    执行原地升级时,你必须格外小心,确保组件保持健康,因为你是在当前服务于生产流量的集群上执行工作。原地升级可以包括包更新(例如 yum、apt)、配置管理自动化(例如 Ansible、Chef)或 VM/容器镜像更改。理想情况下,你的升级将是脚本化和自动化的(包括回滚),但如果这是你第一次升级,在开发或测试环境中手动进行升级可能会有所帮助。

    原地升级意味着所有组件将大致同时升级。如果你通过配置管理更改所需的 API Server版本并推送新配置,则所有 API Server在收到新配置后都会升级。这与我们稍后讨论的滚动升级不同。

    原地升级的主要好处是:

    根据你的流程、规模和工具,原地升级可能是能够编写脚本的最直接的方法。脚本可以在本地或在开发集群中进行测试,而无需重新配置集群管理员团队可能无法访问的资源——例如负载均衡器或 DNS。

    如果要使用此方法进行升级,原地升级还需要考虑以下限制:

    蓝/绿升级

    蓝/绿集群升级需要你使用新版本的 Kubernetes 创建第二个集群。你需要部署新的控制平面和数据平面,然后将所有工作负载复制到新集群,然后再将流量从旧集群切换到新集群。你可以使用蓝/绿来更新集群的每个组件,但整体集群升级更易于部署和回滚。

    好消息是,设置新集群通常比升级集群更容易。关于如何将工作负载部署到新集群,你有多种选择。如果你的工作负载已经是 GitOps 或持续交付的一部分,你可以在升级之前或期间将部署同时转到新集群和旧集群。如果你没有自动部署,你可以使用Velero 之类的工具来备份你现有的工作负载并将它们部署到新集群。

    创建新的“Green”集群可以让你对新版本按预期工作充满信心,并让你控制何时切换版本。新集群还可用于验证自动化工具,例如 Terraform 模块或 GitOps 存储库。你可以随时通过 DNS 或负载均衡器进行更改,甚至可以在维护时段或低利用率期间进行更改。

    蓝/绿升级的主要好处是:

    蓝/绿部署要考虑的缺点包括:

    当你拥有较少数量的集群或少于几百个工作节点时,蓝/绿可能是一个很好的策略。它允许你跳过版本并且回滚是安全的,但它可能会需要更多的基础设施支出和协调时间。

    滚动升级

    如果你熟悉 Kubernetes 部署策略,你就会熟悉滚动升级。滚动升级将部署组件的一个升级为新副本,然后缩减一个旧副本。它将继续这种模式,直到所有旧组件都被删除。滚动升级的增量性质比原地升级和蓝/绿策略有一些优势。

    与原地升级类似,你需要一次升级 Kubernetes 的一个次要版本。当需要升级多个版本时,这可能是额外的工作,但它是唯一受支持的选项。根据你要升级的组件,你可以使用不同的工具来升级每个组件。

    对于像控制平面这样的资源,你可能希望将带有升级的 API Server的新服务器添加到控制平面,然后关闭旧服务器。如果你使用的是 AWS,则可以更改 Auto Scaling 组启动配置 AMI 并一次替换一个实例。其他控制平面组件(例如调度程序)可能在集群内作为容器运行,因此你可以使用标准的 Kubernetes 滚动部署升级来升级这些组件。

    与蓝/绿相比,滚动升级的主要区别在于你的外部流量路由(DNS 和负载均衡器)将保持指向同一位置。在进行生产集群升级之前,你需要确保在不同的集群或环境中测试所有附加组件和工作负载。

    请注意,AWS 托管节点组kOpsCluster-API和许多其他 Kubernetes 集群管理工具使用滚动升级策略。好处包括:

    滚动升级是最常见的自动化工具。它们在速度和成本之间取得了很好的平衡,也减少手动工作和风险。

    升级生产集群时,你现有的所有工作负载仍将被部署;只要你测试了它们的兼容性,你的升级就应该是可自动化的。

    使用滚动升级时的进一步考虑包括:

    金丝雀升级

    Canary 应用程序部署一次为应用程序的新版本提供少量流量。Canary 升级可以被认为是具有蓝/绿优势的滚动升级。

    通过 Canary 升级,你将使用要部署的版本创建一个新的 Kubernetes 集群。然后添加一个小型数据平面并将你现有的应用程序以较小的规模部署到新集群。通过负载均衡器配置、DNS 循环或服务网格将新的集群工作负载添加到现有的生产流量中。

    现在,你可以监控流向新集群的流量,慢慢扩展新集群中的工作负载并缩减旧集群中的工作负载。你可以一次完成一项工作,并且可以根据自己的习惯缓慢或快速完成。如果任何单个工作负载开始出现错误,你可以缩减新集群中的单个工作负载,使其自动使用旧集群。

    Canary 集群升级的好处包括:

    如果你想进行较大的更改(例如更改架构)或者你想添加额外的可用区,那么 Canary 是一个不错的选择。通过启动较小的集群并根据工作负载增加它,你可以确保在新实例更高效或工作负载请求和限制发生变化时不会过度配置基础设施。

    与任何事情一样,需要权衡取舍。使用金丝雀部署时,你应该注意以下一些问题:

    结论

    无论你选择哪种升级策略,重要的是要了解它们的工作原理以及随着 Kubernetes 使用量的增长可能出现的任何问题。你需要有一个升级策略,因为 Kubernetes 有频繁的发布和偶尔的错误。

    与新版本保持同步可能是你的基础设施安全流程的重要组成部分,并使应用程序能够快速利用新功能。如果你部署了 Kubernetes 并迁移了所有工作负载,而没有考虑如何升级,那么现在是开始计划的最佳时机。

    如果你没有运行自己的 Kubernetes 集群的业务需求,我强烈建议你使用可用的托管 Kubernetes 选项之一。选择托管控制平面和数据平面可以为你每年节省数天或数周的规划和升级时间。每个托管选项可能执行不同的升级,但它们都允许你专注于工作负载和业务价值,而不是控制平面高可用性或数据平面兼容性。

    译文链接:Living with Kubernetes: Cluster Upgrades – The New Stack

    以上是关于与 Kubernetes 共存:强大的 API 使用和管理的主要内容,如果未能解决你的问题,请参考以下文章

    与 Kubernetes 共存:集群升级的4种方式

    与 Kubernetes 共存:调试工作负载的 12 个命令

    一款强大的 Kubernetes API 流量查看神器

    一款强大的Kubernetes API流量查看神器

    使用 apache 虚拟主机使 Laravel 与多个其他 LAMP 项目共存

    经典 API 密钥与 REST API 凭证共存的贝宝可能性