Kubernetes v1.19 正式发布

美国时间 8 月 26 日,Kubernetes v1.19 正式发布,这是 2020 年的第二个新版本。新版本包含 33 个增强功能:其中 12 个增强功能已趋于稳定,18 个进入 beta,13 个进入 alpha。根据 K8sMeetup 中国社区上周整理的 v1.19 亮点内容,新版本主要包括以下五大核心改动:

  • Kubernetes 的支持周期延长到一年:从 Kubernetes v1.19 开始,新版本的支持周期将延长至一年,可以让超过 80% 的用户使用受支持的版本。
  • 储存容量追踪:这是一项新的 Alpha 功能,它能为 CSI 驱动程序添加 API 来报告存储容量,并在为 Pod 选择节点时在 Kubernetes 调度程序中使用该信息。
  • Ingress API 升入 GA:这个 API 本身已经在 Beta 中已使用很久,并达到了事实上的 GA 状态。
  • 结构化日志:新版本向 klog 库中引入了新的方法,该方法提供了更高结构化程度的接口用于格式化日志消息。
  • Kubelet 客户端 TLS 证书轮换:v1.18 中,集群引入了一项 beta 流程,用于获取初始证书、密钥并在证书到期时进行轮替,在 v1.19 中,其正式进入稳定版本。

详情请见《Kubernetes v1.19 重磅发布 | 新版本核心主题 & 主要变化解读》

Docker 将限制免费账户

现在的 Docker 拥有着世界上最大的容器注册表 Docker Hub,共有 650 万的开发人员在使用,存储着超过 15PB 的容器镜像,涵盖了 Docker 官方镜像和 Docker 社区创建的 1.5 亿个镜像。

根据 Docker 内部分析工具显示,在这 15PB 的镜像中,有超过 10PB 的镜像在近 6 个月内未被访问,其中超过 4.5 PB 的无效镜像是由免费账户创建的,这些镜像大多作为临时镜像短暂使用。为解决上述问题,官方决定实施新的镜像档保留政策,平台将会开始自动删除由免费账户托管,且 6 个月内没有使用过的镜像。这一政策将从 11 月 1 日开始实行,付费账户、官方认证发布者以及官方镜像不受此限制。另外,官方称,由于少数匿名的免费使用者过度使用镜像,有近 30% 的镜像拉取请求来自 1% 的匿名用户,因此官方将限制免费账户拉取容器镜像的次数,匿名的免费账户每六小时最多 100 次,经过验证的免费账户每小时 200 次,付费使用者不受此影响。

K8s 集群优化管理技巧

IT 运营团队必须管理各种 Kubernetes 组件,以实现所需的工作负载,但就像 IT 中的许多事情一样,Kubernetes 集群的有效管理需要牢固地掌握相关技术概念以及实践经验。以下是几个 Kubernetes 容器集群管理技巧:

根据资源使用情况运行 Pod 

在 Kubernetes 节点上运行的 Pod 数量并不是随意的。Kubernetes 会使用调度规则将 Pod 中的容器分配给集群中的节点。IT 管理员应根据容器资源要求来设置规则,以确保最佳调度,从而提高应用程序性能。另外,我们可以使用 Kubernetes 集群监控工具来追踪容器到容器、容器到节点的有关资源使用状态。

优化集群中的节点数

就像要确定在节点上运行的 Pod 数量一样,IT 管理员也要考虑资源的使用情况,来确定在 kubernetes 集群上要运行多少个节点。决定节点数量的一般因素有三个:工作负载性能目标、可用性要求和节点类型。

图源:searchitoperations.techtarget.com

节点向 Kubernetes 集群提供各种资源,例如计算和内存。在考虑每个集群的节点数时,我们需要评估这些资源的贡献度,例如大量的轻量级节点可能比少量的大节点贡献较少的总体资源。此外,如果某些节点发生故障,我们需要确保有足够数量的备用节点以保持可用性。

确保主节点的高可用性

如前所述,Kubernetes 集群中的节点会影响工作负载可用性,在具有多个节点的集群中,一个或多个节点发生故障时,其余节点将承担一定的工作量,以减少影响。Kubernetes 集群中的高可用性至关重要,我们最好确保主节点组件的安全。

仔细规划集群网络

网络是 Kubernetes 集群管理的核心,它支持着各种集群组件之间的通信。最佳的 Kubernetes 网络策略最终取决于组织当前以及未来的云需求。

电信公司迎接云原生

随着我们以前所未有的速度想着云原生的未来迈进,组织现在必须在完全不同的环境中权衡每一步。这里讨论了电信公司在云原生未来考虑的几个问题。

电信公司为什么要使用云原生?

电信公司考虑采用云原生方法有三个主要原因:云本地化可以使电信公司自由地在任何地方部署新应用程序;可以加快服务部署速度;可以控制并安全地大规模部署应用程序。许多电信公司已经在其 IT、网络运营,视频和 OSS/BSS 环境中使用了容器、微服务架构和云原生应用程序,以实现业务现代化。另外对于 5G,许多电信公司正在考虑采用云原生技术,将其作为其下一代网络基础架构。

容器化的 5G 网络有什么好处?

云原生方法为下一代 5G 网络基础架构提供了几大潜在优势:

  • 开销更低:容器消耗硬件资源较少。
  • 启动时间更快:容器镜像是小型应用程序模块,可以 50 毫秒内启动。
  • 易于使用:容器提供了高度的可移植性,可以在私有云和公共云之间轻松移动工作负载。此外,容器具有弹性和可伸缩性,易于部署。
  • 减少维护:同时使用正确的自动化和操作工具时,容器的维护工作量将大大减少。

云原生 5G 网络的主要好处是可以更快地部署服务,灵活扩展规模并轻松缓解运营网络和服务环境的复杂性,从而电信公司将在降低运营成本的同时加快收入增长。

无服务器时代使用 K8s 的理由

无服务器已经席卷了技术界,它在以惊人的速度发展,其成功的原因在于对开发人员的友好性,易于运行的微服务以及较低的基础架构开销。另一方面,Kubernetes 是一个开源、功能强大、使用广泛的容器编排平台,可以大规模运行应用程序。它是 IaaS 和 PaaS 的混合体,可让容器标准化应用程序在任何地方运行。让我们来看看相比无服务器,Kubernetes 的几点优势:

Kubernetes 具有便携性并可以在多种环境中工作

无服务器产品会因云提供商不同而不同。选择平台时,我们会受限于供应商,并且如果想从一个平台迁移到另一个平台也会比较麻烦。另一方面,Kubernetes 重在可移植性。我们几乎可以将任何东西从这一平台迁移到另一平台,因为 Kubernetes 在任何地方都是相同的,它是一个标准平台,这使得在 kubernetes 上运行的代码具有可移植性。它适合于运行混合云模型的公司,他们可以根据成本等因素选择平台,并在云中迁移应用程序。

并非所有内容都可简化为临时功能

无服务器具有最小范围,它适用于临时功能以处理内容,但不能存储状态。无服务器不适合有状态的应用程序。在很多应用程序中,并非所有事物都可以简化为临时功能。另一方面,Kubernetes 提供了很多方式来托管各种工作负载,从微服务到数据库再到整体,我们可以在 Kubernetes 容器上运行任何东西。它提供了一个同质化的环境,可以将所有内容简化为容器,并且所有内容都可以在 Kubernetes 上运行,这就是灵活性。

不是所有事情都可以在短时间内完成

无服务器有一些限制,我们不能在其中运行长时间运行的任务,一切都需要在短时间内完成。大多数使用无服务器的组织还必须配合使用其他 IaaS 和 PaaS 产品,因此他们最终需要管理异构环境,但使用 Kubernetes 则没有这样的限制,我们可以随意运行各种工作负载。二者谁更强?这没有答案,因为二者不是竞争关系。无服务器的目的不是取代传统架构,它更多地是为了满足特定于微服务的特定用户群的需求。另一方面,Kubernetes 可以更好地管理传统架构。真正决定我们要使用什么的是业务需求,在正确的情况下使用它们,二者都可以发挥出各自长处。

https://medium.com/better-programming/4-reasons-to-use-kubernetes-in-the-serverless-era-cf77ea3b018b

本周 K8s 开源项目推荐pangolin

  • 它是用于 Kubernetes 的水平 Pod 自动伸缩器,它使用各种可配置的控制策略,根据 Prometheus 指标扩展部署。
  • github.com/dpeckett/pangolin

dynamic-pv-scaler

  • 它是基于 Golang 的 Kubernetes 应用程序,可以解决 Kubernetes 中持久卷的扩展问题。
  • github.com/opstree/dynamic-pv-scaler

cheekymonkey

  • 这是一个有趣的 Kubernetes 混沌游戏。
  • github.com/richstokes/cheekymonkey

terraform-kubestack

  • 这是一个基于 Terraform 和 Kustomize 的 Kubernetes 托管服务 Gitops 框架。
  • github.com/kbst/terraform-kubestack

yh

  • 这是一个 YAML 突出显示器,可以将其与 kubectl 结合使用。
  • github.com/andreazorzetto/yh

chart-testing

  • 这是用于整理和测试 Helm 图表的命令行工具。
  • github.com/helm/chart-testing