Kubernetes

简介 Upjet 是一个代码生成框架，支持开发者构建用于生成 Crossplane 控制器的代码生成管道。Upiet主要由三部分组成: 构建代码生成器管道的框架。 所有自动生成 CRD 使用的通用 Reconciler 实现 为所有自动生成 CRD 提取文档的工具。 相关名词: MR: Managed Resource， Crossplane 管理的托管资源 CR: Custom Resource，自定义资源，Kubernetes API的扩展 CRD: Custom Resource Definition: 自定义资源定义。 资源配置 Upjet 使用 Terraform Resource Schema 中的信息尽可能多的生成 Provider 中的相关信息，包括符合XRM 模式的 Resource SchemaController 逻辑、延迟加载、敏感数据处理等。然后仍然有一些信息，需要通过查阅 Terraform 文档后手动输入配置: 外部名称 | External Name 跨资源引用 | Cross Resource Referencing 敏感字段及自定义连接详情 | AdditionalSensitive Fields and Custom Connection Details 延迟初始化行为 | Late lnitialization Behavior 覆盖 | Terraform Resource Schema 初始化器 | Initializers 外部名称 External Name 简介 Crossplane 使⽤ Managed Resource 中的 Annotation 来识别 Crossplane 管理的外部资源， Annotation key 为crossplane....

简介 Crossplane 是一种开源 Kubernetes 扩展，可将 Kubernetes 集群转换为通用控制平面。借助 Crossplane，平台团队可以利用 Kubernetes 策略、命名空间、基于角色的访问控制等的全部功能创建新的抽象和自定义 API， Crossplane 将所有非 Kubernetes 资源集中管理。 控制平面创建和管理资源的生命周期。控制平面不断检查预期资源是否存在，当预期状态与现实不符时报告并采取行动纠正错误。Crossplane 将 Kubernetes 控制平面扩展为通用控制平面，可以在任何地方检查、报告和处理任何资源。 基本概念 Package：OCI 镜像标准的包，包含 Provider CRDs、Provider 镜像、ServiceAccount 权限等信息。 Provider：云提供商插件，由一组 CRD 和 Controller 组成，CRD 定义了资源信息，Controller 通过 SDK 连接外部云服务，根据资源字段变更，执行相关操作。 Managed Resource：Provider 内部 CRD 定义的资源，创建并由 Crossplane 托管之后，称为 Managed Resource。 Compositions：Managed Resource 集合的模板，用于需要多个资源组合使用的场景，类似 Terraform Module。如 ECS + VPC + EBS。 Composite Resource（XR）：使用 Composition 模板创建的一组 Managed Resource。 Claims：开发人员与 Crossplane 交互的主要方式，开发人员通过 Claim 声明由 SRE 团队定义的 XRD 中的自定义字段值，最终在 XR 定义中引用。 和 Terraform 对比，XRD 比较类似 Terraform Module 中的 variables块；Composition 是模块的 HCL 代码的其余部分，它描述了如何使用这些变量来创建一堆资源；XR 和 Claim 类似为模块提供输入的 tfvars 文件。...

Autoscaler 简介 Autoscaler 是 Kubernetes 弹性伸缩的一个组件集合，主要包含三个组件： Cluster Autoscaler / CA：用于自动调整 Kubernetes 集群大小，以便所有 Pod 都能被调度到 Node 上运行，且没有多余的无负载 Node。GA 版本已随 Kubernetes 1.8 版本发布。 Vertical Pod Autoscaler / VPA：用于自动调整在 Kubernetes 中运行的 Pod 请求的 CPU 和内存量的一组组件。目前处于 beta 版本，主要由 3 个部分组成： Recommender：监控 Pod 的当前和过去的资源消耗，根据监控数据计算推荐的 CPU 和内存建议值。 Updater：检查 Pod 是否使用 Recommender 推荐的资源建议值，如果 Pod 没有使用推荐值，Updater 会尝试驱逐该 Pod。 Admission Plugin：在新的 Pod 上设置 Recommender 推荐的资源建议值。 Addon Resizer：VPA 的简化版，根据集群中 Node 数量修改资源请求。 CA 工作原理 工作流程 CA 顶层工作流程: 每 10s 检查集群是否存在无法被调度的 Pod 集群中没有足够资源分配给这些 Pod，CA 会触发云厂商 Provider 执行扩容流程 云厂商支持新节点加入集群 Pod 调度至新加入集群的 Node 核心控制循环 CA 是一个 CLI 应用程序。启动时，它会触发无限控制循环逻辑，每 10 秒执行一次。它会检查集群状态，以决定是否执行扩容或缩容操作。...

背景 Flannel 是专为 Kubernetes 设计的一种用于容器的网络结构插件，用于在 Kubernetes 集群中构建 3 层网络，实现跨宿主机 Pod 之间在 3 层网络相互通信。 Flannel 支持的三种模式： UDP：通过 TUN + 用户空间 Flannel 进程实现，由于存在多次用户空间和内核空间之间的 COPY，性能比较差，基本不再使用。 HOST-GW：纯三层解决方案，把 HOST 作为网关，需要宿主机二层互通，性能比较好，但是存在一定局限。 VXLAN：在 VLAN 基础上进行扩展，通过构建 Tunnel 实现二层互通。 名词 VXLAN（Virtual Extensible LAN 虚拟可扩展局域网） VTEP（VXLAN Tunnel Endpoints，VXLAN 隧道端点） VNI（VXLAN Network Identifier，VXLAN 网络标识符） 原理 同 Pod 通信 Pod 内部容器通过 pause 容器共享一个网络。 同 Node 跨 Pod 通过 veth pair 设备和 cni0（docker0） 网桥实现通信。 跨 Node 首先数据包从pod1内的eth0出来到达cni0网桥，cni0网桥接收到数据包后发现目的IP跟自己不在一个网段,那么自然需要转发出去，而Linux Bridge有个特殊规则： 网桥不会将这个数据包转发给任何设备，而是直接转交给主机的三层协议栈进行处理, 因此通过本机的route得知，目的地址为10.224.1.0段的数据包都将转到flannel.1。 [node1]# route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10....