主流架构

Device Plugin：K8s制定设备插件接口规范，定义异构资源的上报和分配，设备厂商只需要实现相应的API接口，无需修改kubelet源码即可实现对其他硬件设备的支持。
Extended Resource：Scheduler可以根据Pod的创建删除计算资源可用量，而不再局限于CPU和内存的资源统计，进而将有特殊资源需求的Pod调度到相应的节点上。

通过Device Plugin 异构资源调度流程如下：

1. Device plugin 向kubelet上报当前节点资源情况
2. 用户通过yaml文件创建负载，定义Resource Request
3. kube-scheduler根据从kubelet同步到的资源信息和Pod的资源请求，为Pod绑定合适的节点
4. kubelet监听到绑定到当前节点的Pod，调用Device plugin的allocate接口为Pod分配设备
5. kubelet启动Pod内的容器，将设备映射给容器
   阅读全文 »

JetBrains 远程开发的使用，Gateway 会在本地安装一个轻量的客户端，以及在 server 端安装远程后台 IDE。 - 本地客户端负责提供 UI 界面，它的操作跟基于 Intellij 的完整IDE一样，有同样的编辑器，能进行代码补全、导航、检查、重构等操作，就像本地 IDE 一样，但所有的这些代码都是保存在 server 端的，实际操作也是运行在 server 端的。 - 远程后台 IDE，负责托管远端的代码，所有处理都会在 server 端完成，例如执行脚本、调试。

Pod的优雅上下线依赖k8s的监控检查机制，以及 Pod lifecycle Hooks，通过这些kubernetes的机制，配合服务发现的流量管理机制，实现业务的优雅上下线。

线上集群中，业务跑着跑着，突然发现有个Pod上出现大量错误日志，其他的Pod是正常的，该如何处理呢？

• 直接删除Pod？

这样不便于保留现场，可能会影响判断问题的根因

• 让业务方忍一会，先排查下问题？

会被喷死

最好的方案是既让Pod停止接收流量，又保留Pod

通过一个case学习Terraform中的for_each和count的区别以及使用场景

介绍

Webhook就是一种HTTP回调，用于在某种情况下执行某些动作，Webhook不是K8S独有的，很多场景下都可以进行Webhook，比如在提交完代码后调用一个Webhook自动构建docker镜像

准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 可以定义两种类型的准入 Webhook， 即验证性质的准入 Webhook 和变更性质的准入 Webhook。 变更性质的准入 Webhook 会先被调用。它们可以修改发送到 API 服务器的对象以执行自定义的设置默认值操作。

在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后， 验证性质的 Webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。

Admission Webhook使用较多的场景如下

1. 在资源持久化到ETCD之前进行修改（Mutating Webhook），比如增加init Container或者sidecar Container
2. 在资源持久化到ETCD之前进行校验（Validating Webhook），不满足条件的资源直接拒绝并给出相应信息

什么是Packer

Packer 是一个强大的工具，它可以帮助我们轻松地构建各种类型的镜像，如虚拟机镜像、Docker 镜像等。

Packer 的工作原理是通过定义一个配置文件，该文件描述了要构建的镜像的特征和要求。然后 Packer 使用这个配置文件来执行一系列的步骤，例如安装必要的软件、配置系统设置、复制文件等，最终生成一个可用的镜像。

基础设施即代码（Infrastructure as Code）是一种将基础设施的配置和管理过程自动化的方法。它借鉴了软件开发中的一些实践，如版本控制、自动化测试和持续集成，将基础设施的配置和管理过程描述为可执行的代码。 通过使用基础设施即代码，开发团队可以将基础设施的配置和管理过程存储为代码，并将其纳入版本控制系统中。这样一来，团队成员可以对基础设施进行版本控制、进行代码审查和合并，并且可以使用自动化工具来验证和部署基础设施的更新。

背景

kubernetes 的原生调度器只能通过资源请求来调度 pod，这很容易造成一系列负载不均的问题，
并且很多情况下业务方都是超额申请资源，因此在原生调度器时代我们针对业务的特性以及评估等级来设置 Requests/Limit 比例来提升资源利用效率。
在这种场景下依然存在很多问题：

1. 节点负载不均：原生 Kubernetes Scheduler 根据 Requests 和节点可分配总量来调度 Pod，既不考虑实时负载，也不估计使用量，这种纯静态的调度导致节点资源利用率分配不均。
   在流量波动性业务的场景下，在流量高峰时，部分节点利用率突破安全阈值，但是很多节点的利用率特别点，节点利用率相差特别大
2. 业务周期性：在离线集群分离，在线集群底峰存在巨大资源浪费

koordinator 是一个基于 qos 的 kubernetes 混合工作负载调度系统。它旨在提高对延迟敏感的工作负载和批处理作业的运行时效率和可靠性，简化与资源相关的配置调整的复杂性，并增加 pod 部署密度以提高资源利用率。