1 [预告]Kubernetes v1.17 新增特性

临近年底,最新版本的 Kubernetes 即将发布,继上周拓扑感知服务路由后,社区又透露了一些可能会在正式版出现的有趣特性。

Feature 1053:Kubeadm 命令的结构化输出

kubeadm 是开发者设置 Kubernetes 集群的常用方法之一。一些高级工具,如 Terraform,也会在后台使用 kubeadm。有时这些工具需要解析和处理 kubadm 产生的输出,这个输出的任何细微变化都可能破坏整个链条。

这个新特性允许 kubeadm 生成结构化输出,例如用 command -o json 产生 JSON 格式输出,方便其他工具进行解析。目前它还处于 Alpha 阶段。

Feature 382:允许在一定条件下污染节点

从 1.12 版本开始,这个特性已经存在于 K8s 中了。在 1.17 版本中,它终于达到稳定。它允许节点控制器根据其观察到的一些预定义条件来污染节点,和往常一样,用户可以通过在 Pod 中添加 tolerations 来忽视被污染的节点。

Feature 548:kube-Scheduler 负责调度 DaemonSet Pod

这也是一个即将在 1.17 版本中步入稳定的特性。和#382一样,这个功能自 1.12 版本起就已经存在了,但还处于开发的早期阶段。

通过本次迭代,开发者可以用 kube-scheduler 调度 DaemonSet Pod,而不是 DaemonSet 控制器。这样做的优点是 DaemonSet 可以无视 Pod 优先级和抢占进行调度。

Feature 563:IPv6 支持

在新版本中,开发者现在可以将 IPv4 和 IPv6 分配给 Pod。这个功能还处于 Alpha,正在大规模开发中。

Feature 980:确保在删除其父服务时删除 Service LoadBalancers

默认情况下,删除类型为 LoadBalancer 的服务时,也应删除基础 LoadBalancer 资源。但在某些情况下,删除服务后不会删除 LoadBalancer。

1.17 版本的这个新特性可确保在删除服务时删除 LoadBalancer。并且在完全删除 LoadBalancer 之前,删除过程将一直被阻止。

Feature 177:支持 Volume 快照

这个特性出现于 1.12 版本,在 1.17 版本中,它即将升级为 Beta。

开发者可以使用 VolumeSnapshot 和 VolumeSnapshotContent 创建和使用 Volume 快照。

2 关注容器镜像大小

现如今,容器的使用已经超乎所有人想象。尽管容器可以用于大型整体应用程序,但这并不意味着开发人员应该忽略效率,盲目地将遗留应用程序及其膨胀的系统环境转换为单个容器镜像。

对于开发者,容器化应用程序应始终遵守 KISS 原则:简单就是美。

单关注原则。这一原则旨在促进重用和可替换性。当开发者将具有各种依赖关系的多个功能组合到一个容器中时,每个容器应专注于解决一个问题。遵守这一原则有助于将容器将变得更小、更易于管理,部署更快,更新也不那么复杂。

自给自足原则。这一原则源于容器的基本特性。它要求将容器放在一个单一的关注点上,并将最少的代码和库捆绑在一起,得到更小、更有效的容器镜像。例如,开发者不再需要将 Web 服务器、数据库和用户界面应用程序一起部署。

运行时限制原则。这一原则表明容器必须在三方面忠于系统要求:CPU 使用率、系统内存和持久性存储。为了让容器编排平台能够编排、伸缩集群上的容器,这些信息至关重要。

总之,开发人员应该确保容器镜像中包含最少的必需文件,并在打包镜像之前清理所有临时文件和构建构件。容器镜像越小越容易部署、调试、更新和管理,也更安全。

3 LivenessProbe 可能很危险

对于 Pod 的健康状态检测,Kubernetes 提供了 LivenessProbe 和 ReadinessProbe 两种探针。其中前者用于判断容器是否存活,如果探测到容器不健康,则杀死容器,并根据容器的重启策略确定是否重启。

近日,国外一工程师建议开发者应避免使用探针,因为错误的探针设置可能会导致高负载(级联失败和容器/应用程序启动时间过长),甚至降低依赖性。如果开发者不慎将 LivenessProbe 与外部 DB 运行状况检查依赖项结合使用,单个 DB Hiccup 将重启所有容器!

注意事项:

  • 对于提供 HTTP 端点的微服务(REST 服务等),请始终定义一个就绪探针,以检查应用程序(Pod)是否已准备好接收流量;
  • 确保就绪探针覆盖了实际Web服务器端口的就绪状态;
  • 确保就绪探针包括数据库初始化/迁移;
  • 在关键健康检查端点用 httpGet 作为 ReadinessProbe;
  • 了解探针的默认行为(间隔:10s;超时:1s;成功阈值:1;失败阈值:3);
  • 如果你的技术堆栈(例如 Java/Spring)允许将管理运行状况和指标与正常流量分开,请使用其他“管理员”或“管理”端口。

更多值得提防的操作,请见:

https://srcco.de/posts/kubernetes-liveness-probes-are-dangerous.html

4 本周 K8s 开源项目推荐

kube-s

  • github.com/binura-g/kube-s
  • 一个轻量级的 CLI 工具,用于在 kubectl 可用的所有集群中快速查找特定的 K8s 资源(通过模式匹配名称)。

gitops-engine

  • github.com/argoproj/gitops-engine
  • GitOps 最大的两个项目 Argo CD 和 Flux CD 正在联手,使运营商和企业的开发工作更加轻松。

oomhero

  • github.com/ricardomaraschini/oomhero
  • 这是一种辅助工具,可帮助开发者跟踪容器的内存使用情况,并发送警报,战胜“劲敌” OOMKiller。

kubeadm-playbook

  • github.com/ReSearchITEng/kubeadm-playbook
  • 这是部署完全成熟(HA)Kubernetes 集群的最佳指南集。它最出色的地方在于 kubeadm、各种附加功能的官方 Helm 图表、文档微调和最佳实践。

kubepox

  • github.com/aporeto-inc/kubepox
  • 这是一个 Kubernetes 网络策略部署工具,可让开发者查询所有已定义的网络策略以及关联的受影响 Pod。

kube-sigterm-test

  • github.com/mikkeloscar/kube-sigterm-test
  • 这是一种工具,用于测试 Kubernetes 中 Pod/容器的正常终止。

5 [荐读]审核 K8s RBAC 策略的工具和方法

对于任何安全系统,访问和授权控制都是至关重要的,Kubernetes 也不例外。在日常工作中,开发人员需要时刻关注集群是否具有足够的访问控制,因为在 Kubernetes 中,配置访问控制有时很难一直保证正确。

在这篇博客中,作者详细介绍了通过基于角色的访问控制(RBAC)审核集群授权的理论和实践。

www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2019/august/tools-and-methods-for-auditing-kubernetes-rbac-policies

6 [荐读]K8s 把延迟提高了 10 倍

应公司要求,作者所属的团队忙于将微服务迁移至中央平台,该中央平台捆绑了 CI/CD、基于 Kubernetes 的运行时、指标和其他功能。

但在将应用程序部署到 Kubernetes 中并路由一些生产流量之后,糟糕的事情却发生了——Kubernetes 部署中的请求延迟比 EC2 上的请求延迟高出了 10 倍!

srvaroa.github.io/kubernetes/migration/latency/dns/java/aws/microservices/2019/10/22/kubernetes-added-a-0-to-my-latency.html