这份分步指南将向你展示如何使用 Kubeadm 工具在 Debian 11 上安装 Kubernetes 集群。 Kubernetes（k8s）集群包含主控节点和工作节点，用于运行容器化的应用程序。主控节点作为控制平面，工作节点为实际工作负载提供环境。
KubeBrain 是字节跳动针对 Kubernetes 元信息存储的使用需求，基于分布式 KV 存储引擎设计并实现的取代 etcd 的元信息存储系统，支撑线上超过 20,000 节点的超大规模 Kubernetes 集群的稳定运行。 项目地址：github.com/kubewharf/kubebrain
在洪峰流量下，如何确保应用的服务质量不受影响的同时，最大限度提升资源利用率，是考验混部技术成熟度的关键。本文将展开介绍Koordinator在资源隔离，单机QoS保障，以及应用干扰检测方面的设计实现和进展。
在 K8s 中，Pod 作为工作负载的运行载体，是最为核心的一个资源对象。Pod 具有复杂的生命周期，在其生命周期的每一个阶段，可能发生多种不同的异常情况。K8s 作为一个复杂系统，异常诊断往往要求强大的知识和经验储备。结合实战经历以及 EDAS 用户真实场景的归纳，我们总结了 K8s Pod 的 13 种常见异常场景，给出各个场景的常见错误状态，分析其原因和排查思路。
K8s丰富的controller为容器编排提供了极大的便利，其中针对单次任务和定时任务的需求，K8s提供了Job和Cronjob控制器来满足非常驻容器编排的需要。由于这种非常驻的特征，任务容器的时长可能很短（如定时清理数据的任务），甚至有些任务因为一启动就运行失败出现秒退的情况，这给采集Job日志带来了很大的挑战。 本文将基于高性能轻量级可观测采集器iLogtail探讨Job日志的多种采集方案，分析这些方案在不同场景下对日志采集所能做到稳定性保证以及方案优化空间。
随着云原生时代的到来，开发者为了构建符合云原生的应用架构，不得不面对大量云和基础设施的复杂 API ，不仅使用难度大、学习门槛高，还会因为直接操作底层基础设施产生很大的稳定性风险。Kubernetes 很好的帮助基础设施提供了统一的 API 集成界面，但是其定位是“为平台构建者提供的平台”，所以对于上层应用开发者而言就缺失了这样一层“以应用为中心”的使用界面。开放应用模型（ OAM） 应运而生，它由阿里和微软在 2019 年联合发布，汇集了两家企业在云原生应用开发中的大量实践经验，为构建云原生时代的应用平台提供了理论依据。 OAM 模型一经发布，便受到了包括 Oracle、腾讯、字节、第四范式在内的大量企业欢迎和采纳。但是对于更多的企业而言，OAM 只是一个理论模型，缺乏可以直接使用的实践平台，难以落地。于是，阿里云的工程师联合社区采纳 OAM 的企业，基于大家的共同实践，一起构建了开箱即用的 OAM 实现引擎，KubeVela 便诞生了。
KubeGateway 是字节跳动针对 kube-apiserver 流量特征专门定制的七层网关，它彻底解决了 kube-apiserver 负载不均衡的问题，同时在社区范围内首次实现了对 kube-apiserver 请求的完整治理，包括请求路由、分流、限流、降级等，显著提高了 Kubernetes 集群的可用性。
随着云原生的发展，云原生应用一致性、可靠性、灵活编排的能力让大部分企业选择将应用往云上迁移，但同时云基础设施在稳定性、可观测、也接受的强大的考验。 ChaosBlade 是阿里巴巴开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，帮助企业提升分布式系统的容错能力，并且在企业上云或往云原生系统迁移过程中业务连续性保障。 ChaosBlade Operator 是 kubernetes 平台实验场景的实现，将混沌实验通过 Kubernetes 标准的 CRD 方式定义，很方便的使用 Kubernetes 资源操作的方式来创建、更新、删除实验场景，包括使用 kubectl、client-go 等方式执行，同时也可以使用 chaosblade cli 工具执行。 本文将主要介绍 ChaosBlade 在 Kubernetes 中故障注入的底层实现原理、版本优化过程以及大规模应用演练测试。
云计算带来的优势之一便是弹性能力，云原生场景下 Kubernetes 提供了水平弹性扩容能力（HPA），让应用可以随着实时指标进行扩/缩。然而 HPA 的实际工作情况可能和我们直观预想的情况是不一样的，这里面存在一些认知误区。本文总结了一下 EDAS 用户在使用 HPA 时常遇到的三个认知误区，具体如下：
Kubernetes作为云原生计算的基础项目，已经在开发者和企业中获得广泛的支持。然而其自身复杂性和陡峭的学习曲线依然让人望而生畏。在 CNCF 2020年度调研报告中，在Kubernetes技术落地过程中面临最大的挑战就是复杂性。 IBM大型机之父 Fred Brooks 著名的论文No Silver Bullet[1]，软件系统中的复杂性可以分为本质复杂性 (essential complexity) 和附属复杂性 (accidental complexity) 。本质复杂性是构建系统过程中不可避免的复杂性。附属复杂性则是任何非必要的复杂性，比如由于设计失误或者工具不当等引入的复杂性。附属复杂性会随着工具的改善而逐渐解决，而本质性的困难难以解决。 Kubernetes的本质复杂性与附属复杂性到底有什么？我们应该如何应对？
