本文将针对Serverless Container技术的特殊性，分享其对Kubernetes的架构影响，以及阿里云在Serverless Kubernetes方面架构选择。
B站基于k8s构建的私有云平台已达万级节点规模，托管了公司大部分的在线业务以及机器学习、大数据、转码等离线业务。在推进降本增效的过程中，我们发现业务申请的容器资源规格存在不合理的现象，通常设置的资源配额会比实际负载偏大很多。这就造成节点的cpu分配率很高，已经无法调度新容器，但是节点的实际cpu峰值利用率却很低（如图所示）。
基于 K8s 的云原生容器化已经在腾讯内部海量业务中大范围落地实践。业务从传统的虚拟机部署形态无缝切换到容器部署形态，运行在 K8s 上的应用从无状态服务扩展到有状态服务，这个过程经历了哪些改造？同时，K8s 如何经受住业务形态复杂多样、模块数量庞大的考验？遇到哪些新的挑战？如何优化？效果怎么样？腾讯云高级工程师林沐将为你解答。
最近在学习K8S，基础的知识参考于《Kubernetes in Action》。看完整本书基本上用了2~3个月的时间，进度比较慢；主要都是每天早晨到公司后，在正常工作时间之前的1个小时里完成的。由于时间拉的很长，各章的知识在我脑袋里是散状的，所以在我整理这篇笔记的时候，就想通过一个主题，把相关的内容串起来。第一篇笔记定的主题是“调度-当我们部署应用的时候都发生了什么？”，先从大的框架上记录一下K8S的架构与原理；对于卷、网络、configmap等组件会放在第二篇。初学者级别的学习笔记，有问题的地方大佬们及时勘误。 我在这里先给大家简单描述一下，当我们在aone里手动点击了升级之后，k8s里都发生了什么？ 当我们在aone里手动点击了重新部署，aone会通过k8s的api接口通知master节点创建一个Deployment，Deployment会按照配置里的声明要求创建一个新的RepliactionSet，RepliactionSet会按照配置的创建一个或者若干个Pod，pod会调度到相应的工作节点上，通过docker拉取镜像，启动应用。
现今有越来越多的企业开始采纳云原生理念进行应用架构转型。而 K8s 和微服务是云原生的两大支柱，随着云原生浪潮而被广泛应用。 对多数应用而言，提供对外服务的使命并不会改变，相比于原来的单体应用，微服务架构下的应用的服务出口更多，管理更繁琐，微服务网关也应运而生；而 K8s 也提供了多种方式来暴露应用的服务，各种 Ingress 实现百花齐放。面对众多技术方案，我们如何做出合理的选择，规避潜在风险，本文将给出一些选型建议，供大家参考。
本章通过对K8s内部原理的说明来对K8s有一个基础认知，来展示一些K8s的架构特种在后面对架构的分析与说明奠定基础。 在Ops的业务中有几项： 1.环境初始化：操作系统安装、运行环境安装、存储挂载、网络划分等等。 2.配置管理：根据运维配置，进行服务的配置。包括：副本数，可靠性保证，指标等。 3.运行服务：选择运行环境进行服务配置与服务启动等。 4.监控与升级：监控服务检查是否超过阈值进行相关的扩缩容，服务的升级工作等。 K8s主要解决的就是在Ops中的业务。以不可变基础设施来解决运行环境、配置管理、运行服务的问题。以声明式API来解决运维标准化的问题。
这份分步指南将向你展示如何使用 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 种常见异常场景，给出各个场景的常见错误状态，分析其原因和排查思路。
