Kubernetes - Mechanism
基础架构
Master
Worker
工作流程
插件
All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles
2021-06-06
容器基础 -- Namespace & Cgroups
VM vs Container Hypervisor 通过硬件虚拟化，模拟出一个操作系统所需要的各种硬件，然后在虚拟的硬件上安装Guest OS 对应用进程的隔离环境负责 额外的资源消耗和占用 使用虚拟化技术作为应用沙盒，必须由Hypervisor来负责创建VM，该VM是真实存在的且里面运行一个完整的Guest OS Docker Engine 『轻量级』虚拟化 不存在真正的『Docker容器』运行在宿主机里面，Docker只是在创建进程时，加上各种不同的Namespace参数 真正对隔离环境负责的是宿主机操作系统，而非Docker Engine 容器化后的用户应用，依然还是宿主机上的普通进程 相对于VM的优势：敏捷 + 高性能 基于Linux Namespace劣势：隔离不彻底 多个容器之间使用的还是同一个宿主机的操作系统内核 低版本的Linux宿主机不能运行高版本的Linux容器 容器给应用暴露出来的攻击面是很大的 – Seccomp（对容器内部发起的系统调用做过滤拦截，影响容器性能） 在Linux内核中，很多资源和对象是不能被Namespace化的，如时间 Namesp...
2021-06-18
容器编排 -- Job
编排对象 在线业务：Deployment、StatefulSet、DaemonSet 离线业务：Job、CronJob Jobjob.yaml Job对象不需要定义spec.selector（借助UUID） job.yaml12345678910111213141516apiVersion: batch/v1kind: Jobmetadata: name: pispec: template: spec: containers: - name: pi image: resouer/ubuntu-bc command: - sh - '-c' - "echo 'scale=10000; 4*a(1)' | bc -l" restartPolicy: Never backoffLimit: 4 创建Job123456# kubectl apply -f job.yamljob.batch/pi ...
2023-02-10
FaaS - Scaling
概述 Serverless 的弹性扩缩容可以将实例缩容为 0，并根据请求量级自动扩缩容，从而有效地提升资源利用率 极致动态扩缩容是 FaaS 的核心内涵，是与 PaaS 平台的核心差异 - 降本增效 调度形态 开源的 Serverless 函数计算引擎核心，一般是基于 Kubernetes HPA 云厂商一般有封装好的各种底座服务，可以基于底座服务来做封装 云厂商容器调度服务，通常有两种调度形态 基于 Node 调度 基于容器实例的调度 - Serverless 云厂商的函数计算通常是基于容器服务的底座 Node 维度 组件 Scheduler 负责将请求打到指定的函数实例（Pod）上，同时负责为集群中的 Node 标记状态，记录到 etcd Local-Controller Node 上的本地控制器，负责管理 Node 上所有函数实例的生命周期，以 DeamonSet 形式存在 AutoScaler 定期检测集群中 Node 和 Pod 的使用情况，并根据策略进行扩缩容 在扩容时，向底层的 PaaS 平台申请资源 Pod Cold 表示该 Pod 未被使用 Warm 表示...
2023-01-29
Kubernetes - Scaling
Aggregated APIServer 123456789101112131415161718192021222324$ k get apiservices.apiregistration.k8s.ioNAME SERVICE AVAILABLE AGEv1. Local True 36dv1.admissionregistration.k8s.io Local True 36dv1.apiextensions.k8s.io Local True 36dv1.apps Local True ...
2022-07-12
Kubernetes - YAML
YAML API 对象列表 + 诊断 描述 文档 + 模板
2026-04-29
K8S Orchestration - KRO V2
ResourceGraphDefinitions概述生命周期 写一个 RGD YAML，kro 就帮你把它变成一个完整的 Operator 定义 RGD 是 KRO 中唯一需要你编写的 API 定义 Schema - 用户能看到/配置哪些字段 定义 Resources - 底层要创建哪些 K8s 资源 用 CEL 表达式把 Schema 的值绑定到 Resources 上 执行 apply 这个 RGD 后，kro 全自动完成 生成 CRD - 把你的 Schema 转成真正的 Kubernetes API 注册到 API Server - 集群里立刻就能用 kubectl get Application 这样的命令 监听实例 - 用户创建实例后，kro 按依赖拓扑排序创建底层资源，并持续管理生命周期 How it Works RGD 从定义到运行的 4 步核心流程：你定义蓝图 → kro 造工厂 → 用户下订单 → kro 自动生产 步骤 谁 做什么 1 你 写一个 RGD，定义新的 API（比如 Application） 2 kro 自动生成 CRD，注...
