Kubernetes 从提交 deployment 到 pod 运行的全过程
当用户向 Kubernetes
提交了一个创建 deployment
的请求后,Kubernetes
从接收请求直至创建对应的 pod
运行这整个过程中都发生了什么呢?
kubernetes 架构简述
在搞清楚从 deployment
提交到 pod
运行整个过程之前,我们有先来看看 Kubernetes
的集群架构:
当用户向 Kubernetes
提交了一个创建 deployment
的请求后,Kubernetes
从接收请求直至创建对应的 pod
运行这整个过程中都发生了什么呢?
在搞清楚从 deployment
提交到 pod
运行整个过程之前,我们有先来看看 Kubernetes
的集群架构:
在 kubernetes 中有一系列内置的资源,诸如:pod
、deployment
、configmap
、service
…… 等等,它们由 k8s 的内部组件管理。而除了这些内置资源之外,k8s 还提供了另外一种方式让用户可以随意地自定义资源,这就是 CRD
(全称 CustomResourceDefinitions
) 。
原文为 Akihiro Suda 在日本京都大学做的在线讲座,完整的 PPT 可 点击此处下载
本文内容分为以下三个部分:
容器是一组用于隔离文件系统、CPU 资源、内存资源、系统权限等的各种轻量级方法。容器在很多意义上类似于虚拟机,但它们比虚拟机更高效,而安全性则往往低于虚拟机。
如何结合使用 JVM Heap 堆和 Kubernetes 内存的 requests 和 limits 并远离麻烦。
在容器环境中运行 Java 应用程序需要了解两者 —— JVM 内存机制和 Kubernetes 内存管理。这两个环境一起工作会产生一个稳定的应用程序,但是,错误配置最多可能导致基础设施超支,最坏情况下可能会导致应用程序不稳定或崩溃。我们将首先仔细研究 JVM 内存的工作原理,然后我们将转向 Kubernetes,最后,我们将把这两个概念放在一起。
Kubernetes Admission Controller(准入控制器)是什么?
如下图所示:
当我们向 k8s api-server 提交了请求之后,需要经过认证鉴权、mutation admission、validation 校验等一系列过程,最后才会将资源对象持久化到 etcd 中(其它组件诸如 controller 或 scheduler 等操作的也是持久化之后的对象)。而所谓的 Kubernetes Admission Controller 其实就是在这个过程中所提供的 webhook 机制,让用户能够在资源对象被持久化之前任意地修改资源对象并进行自定义的校验。
你一定知道 JSON 吧,那专门用于修改 JSON 内容的 JSON PATCH 标准你是否知道呢?
RFC 6902 就定义了这么一种 JSON PATCH 标准,本文将对其进行介绍。
JSON Patch 本身也是一种 JSON 文档结构,用于表示要应用于 JSON 文档的操作序列;它适用于 HTTP PATCH
方法,其 MIME 媒体类型为 "application/json-patch+json"
。
文本翻译自: https://blog.palark.com/why-cilium-for-kubernetes-networking/
原文作者是 Palark 平台工程师 Anton Kuliashov,其说明了选择 Cilium 作为 Kubernetes 网络接口的原因以及喜爱 Cilium 的地方。
多亏了 CNI(容器网络接口),Kubernetes 提供了大量选项来满足您的网络需求。在多年依赖简单的解决方案之后,我们面临着对高级功能日益增长的客户需求。Cilium 将我们 K8s 平台中的网络提升到了一个新的水平。
文本翻译自: https://itnext.io/cpu-limits-and-requests-in-kubernetes-fa9d55948b7c
在 Kubernetes 中,我应该如何设置 CPU 的 requests 和 limits?
热门答案包括:
让我们深入研究它。
文本翻译自: https://medium.com/geekculture/kubernetes-gateway-api-the-intro-you-need-to-read-80965f7acd82
您以前听说过 SIG-NETWORK 的 Kubernetes Gateway API 吗?好吧,可能你们中的大多数人都是第一次遇到这个话题。尽管如此,无论您是第一次听说还是已经以某种方式使用过它,本博客的目的都是为您提供一个基本的和高度的概述来理解这个主题。
文本翻译自: https://www.scrivano.org/posts/2022-10-21-the-journey-to-speed-up-oci-containers/
原文作者是 Red Hat 工程师 Giuseppe Scrivano ,其回顾了将 OCI 容器启动的时间提速 30 倍的历程。
当我开始研究 crun (https://github.com/containers/crun) 时,我正在寻找一种通过改进 OCI 运行时来更快地启动和停止容器的方法,OCI 运行时是 OCI 堆栈中负责最终与内核交互并设置容器所在环境的组件。