KubeBrain 是字节跳动针对 Kubernetes 元信息存储的使用需求，基于分布式 KV 存储引擎设计并实现的、可以取代 etcd 的元信息存储系统，目前支撑着线上超过 20,000 节点的超大规模 Kubernetes 集群的稳定运行。

本文将基于高性能轻量级可观测采集器iLogtail探讨Job日志的多种采集方案，分析这些方案在不同场景下对日志采集所能做到稳定性保证以及方案优化空间。

本篇文章以理论+线上实践的方式详细介绍下哈啰基于水位自定义调度器的落地过程。

Kubernetes HPA一定会减少资源使用吗？HPA可观测性实践分享。

近年来，随着腾讯内部自研上云项目的不断发展，越来越多的业务开始使用云原生方式托管自己的工作负载，容器平台的规模因此不断增大。以 Kubernetes 为底座的云原生技术极大推动了云原生领域的发展，已然成为各大容器平台事实上的技术标准。在云原生场景下，为了最大化实现资源共享，单台宿主机往往会运行多个不同用户的计算任务。如果在宿主机内没有进行精细化的资源隔离，在业务负载高峰时间段，多个容器往往会对资源产生激烈的竞争，可能导致程序性能的急剧下降，主要体现为：

1. 资源调度时频繁的上下文切换时间
2. 频繁的进程切换导致的 CPU 高速缓存失效

因此，在云原生场景下需要针对容器资源分配加以精细化的限制，确保在 CPU 利用率较高时，各容器之间不会产生激烈竞争从而引起性能下降。

随着vivo业务迁移到k8s的增长，我们需要将k8s部署到多个数据中心。如何高效、可靠的在数据中心管理多个大规模的k8s集群是我们面临的关键挑战。

An important part of running Airbnb’s infrastructure is ensuring our cloud spending automatically scales with demand, both up and down. Our traffic fluctuates heavily every day, and our cloud footprint should scale dynamically to support this.

To support this scaling, Airbnb utilizes Kubernetes, an open source container orchestration system. We also utilize OneTouch, a service configuration interface built on top of Kubernetes, and is described in more detail in a previous post.

In this post, we’ll talk about how we dynamically size our clusters using the Kubernetes Cluster Autoscaler, and highlight functionality we’ve contributed to the sig-autoscaling community. These improvements add customizability and flexibility to meet Airbnb’s unique business requirements.

In a previous blog post, we discussed LyftLearn’s infrastructure built on top of Kubernetes. In this post, we will focus on the compute layer of LyftLearn, and will discuss how LyftLearn solves some of the major pain points faced by Lyft’s machine learning practitioners.

应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让应用中的Pod个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放。

详细介绍了 Cisco Nexus L2 交换机进行 vPC 后 L3 改造的方案~

如何使高优先级任务获得更多的 CPU 资源，更快完成任务？

pv controller是 kcm 的组件之一，它负责处理集群中的pvc/pv对象，对pvc/pv 对象进行状态转换。

ASI：Alibaba Serverless infrastructure，阿里巴巴针对云原生应用设计的统一基础设施。

本文将介绍 vivo 内部容器化平台跨大版本无损升级中遇到的问题和解决方法，以期帮助读者更快速、更安全的升级自己的集群。

像绝大部分公司的业务一样，流利说也经历了业务流量从小到大、后端服务从少数到多数的过程。

业务网关作为所有服务的入口，有着举足轻重的作用。随着业务的发展，业务网关的架构和运维方式也在不断演进，目标是在提供更稳定的服务的同时，既能够更安全可控的对业务网关进行变更，又便于未来能够扩展和更新，以提升运维的灵活性。

目前，流利说通过将网关层K8s化，来实现上述灵活性。本文将简要介绍流利说网关与后端业务架构的”前世今生“，并引出网关层的K8s化过程，供感兴趣的同学作为一个参考。

进入 K8s 的世界，会发现有很多方便扩展的 Interface，包括 CNI, CSI, CRI 等，将这些接口抽象出来，是为了更好的提供开放、扩展、规范等能力。

K8s 网络模型采用 CNI(Container Network Interface, 容器网络接口) 协议，只要提供一个标准的接口，就能为同样满足该协议的所有容器平台提供网络功能。

CNI 是 CoreOS 提出的一种容器网络规范，目前已被 Apache Mesos、Cloud Foundry、Kubernetes、Kurma、rkt 等众多开源项目所采用，同时也是一个 CNCF(Cloud Native Computing Foundation) 项目。可以预见，CNI 将会成为未来容器网络的标准。

本文将从 kubelet 启动、Pod 创建/删除、Docker 创建/删除 Container、CNI RPC 调用、容器网络配置等核心流程，对 CNI 实现机制进行了解析。