pod

什么是Pod? Kubernetes中最小的管理单元，作为应用运行的载体。当Pod运行多个容器时，同一个Pod中的所有容器可以共享PID、Network、IPC、UTS命名空间。 打个比方，例如Pod是豆荚，Container容器就是豆子，一个豆荚里可以有一个或者多个豆子。 Pod的使用方式 通过kubectl创建 kubectl run nginx-pod --image=nginx:1.16 通过yaml资源定义清单创建 kubectl apply -f nginx-pod.yaml apiVersion: v1 #表示api资源是哪一个组及版本 kind: Pod #表示资源类别 metadata: #表示元数据 name: nginx #名称，作用域在名称空间内唯一 spec: #表示期望状态 containers: #表示容器资源 - name: nginx #名称，作用域在Pod内唯一 image: nginx:1.16 #指定镜像 通过kubectl命令查看Pod kubectl get pods Pod的资源管理 Pod开始创建时会进行请求所需资源，Kubernetes会根据Pod所需要的资源量安排在最合适的Node节点上，这保证了Pod所需要的资源是可以成功获得的。Pod的资源管理可以设置内存，CPU，临时存储所需的资源及最大资源使用限制。 kubectl

声明式API 所谓“声明式”,指的就是我只需要提交一个定义好的 API 对象来“声明”,我所期望的状态是什么样子 “声明式 API”允许有多个 API 写端,以 PATCH 的方式对 API 对象进行修改,而无需关心本地原始 YAML 文件的内容 Kubernetes 项目才可以基于对 API 对象的增、删、改、查，在完全无需外界干预的情况下,完成对“实际状态”和“期望状态”的调谐（Reconcile）过程 声明式 API,才是 Kubernetes 项目编排能力“赖以生存”的核心所在 AdmissionControl机制 在K8S中 当一个Pod或者任何一个API对象提交给APIServer之后 总需要做一些 初始化的工作 比如在自动为Pod添加上某些标签 这些功能的实现依赖于一组Admission Controller来实现 可以选择性的编译到 APIServer中 在API对象创建之后会被立即调用 需要重新编译自己的APIServer添加自己的规则 比较麻烦 热插拔Admission机制(Dynamic Admission) Istio实现机制 编写一个用来为所有Pod自动注入自己定义的容器的Initializer 这个Initializer的定义会以ConfigMap的方式进行保存在集群中 在Initializer更新用户的Pod对象的时候，必须使用PATCH API来完成

写本文是自己对所掌握技术体系的一些俯瞰总结，初心以最简的解释来理解和概括这些概念，检验自己在对应领域的理解熟练度。 目录 对镜像的理解 容器是什么？ Docker是什么？干什么用的？ k8s又是做什么的？ 对镜像的理解 可以理解为系统在某个时候的一个快照，是一组rootfs，一个不含内核的Linux文件系统，相比于一个虚拟机完整的磁盘镜像来说轻便的多。 创建镜像时基于联合挂载的方式创建出一套文件系统，Ubuntu中是aufs（Advance UnionFS）。联合挂载的目录下，有一个完整的操作系统目录供容器使用。 镜像分层概念（多增量rootfs联合挂载）：镜像层（只读层）、容器层（读写层）、初始化层（init），每层对应包含了操作系统中一部分目录。Init 层是 Docker 项目单独生成的一个内部层，专门用来存放 /etc/hosts、/etc/resolv.conf等信息。 分层设计使得容器镜像需要的总空间缩小。 容器是什么？ 首先，容器是一个进程，是一个特殊的进程。 可以把容器想象为一个沙盒，一个集装箱，能把你的应用装起来的一种技术。容器要把应用装起来那就需要边界，所谓的边界就是基于Linux Namespace（隔离）、Linux Cgroups（限制）、rootfs（文件系统）构建的隔离环境，是一种特殊的进程，其中Cgroups 技术是用来制造约束的主要手段，而

说明 1.当集群中的计算资源不很充足, 如果集群中的pod负载突然加大, 就会使某个node的资源严重不足, 为了避免系统挂掉, 该node会选择清理某些pod来释放资源, 此时每个pod都可能成为牺牲品 2.kubernetes保障机制： 限制pod进行资源限额 允许集群资源被超额分配, 以提高集群的资源利用率 为pod划分等级, 确保不同的pod有不同的服务质量qos, 资源不足时， 低等级的pod会被清理, 确保高等级的pod正常运行 3.kubernetes会根据Request的值去查找有足够资源的node来调度此pod limit对应资源量的上限, 既最多允许使用这个上限的资源量, 由于cpu是可压缩的, 进程是无法突破上限的, 而memory是不可压缩资源, 当进程试图请求超过limit限制时的memory, 此进程就会被kubernetes杀掉 对于cpu和内存而言, pod的request和limit是指该pod中所有容器的 Requests或Limits的总和, 例如： 某个节点cpu资源充足, 而内存为4G，其中3GB可以运行pod, 而某个pod的memory request为1GB, limit为2GB， 那么这个节点上最多可以运行3个这样的pod 待调度pod的request值总和超过该节点提供的空闲资源, 不会调度到该节点node上; 示例

一、前言 k8s可以说是面向yaml文件编程，官方文档有很详细的说明各类yaml文件的写法。 二、yaml文件语法 参考博客： https://www.cnblogs.com/wn1m/p/11286109.html 。在Kubernetes中，只需要知道list和map就行。List即列表，说白了就是数组，例如： args -beijing -shanghai -shenzhen -guangzhou 可以指定任何数量的项在列表中，每个项的定义以破折号（-）开头，并且与父元素之间存在缩进。在JSON格式中，表示如下： { "args": ["beijing", "shanghai", "shenzhen", "guangzhou"] } 当然Lists的子项也可以是Maps，Maps的子项也可以是List，例如： apiVersion: v1 kind: Pod metadata: name: kube100-site labels: app: web spec: containers: - name: front-end image: nginx ports: - containerPort: 80 - name: flaskapp-demo image: jcdemo/flaskapp ports: 8080 如上述文件所示，定义一个containers的List对象

1. PodPreset 的作用 将一些公用的参数设置到pod中去，例如 时区统一设置为东八区等 2. API Server 开启PodPreset 编辑文件 /etc/kubernetes/manifests/kube-apiserver.yaml，添加配置 --runtime-config=settings.k8s.io/v1alpha1=true，添加PodPreset到--admission-control(新版本是--enable-admission-plugins) 重启kubelet服务，sudo systemctl restart kubelet 3. 部署统一时区的PodPreset yaml文件如下： apiVersion: settings.k8s.io/v1alpha1 kind: PodPreset metadata: name: setting-timezone spec: selector: matchLabels: env: - name: TZ value: Asia/Shanghai 其中 selector、matchLabels是必须的，不写任何的值就代表全局启用。 4. 禁用PodPreset 在一些情况下，用户不希望 Pod 被 Pod Preset 所改动，这时，用户可以在 Pod spec 中添加形如 podpreset

Serverless Kubernetes概述： 阿里云Serverless Kubernetes容器服务最新开放香港、新加坡、悉尼区域，同时全面开放2.0架构，帮助用户更加便捷、轻松地步入“以应用为中心”的全新架构。通过Serverless Kubernetes，用户50秒内可从零启动500应用容器，而无需关心底层服务器资源。 Serverless Kubernetes 2.0新架构 Serverless Kubernetes 2.0对后台架构进行了彻底升级，从之前的基于Namespace的多租户隔离，升级为租户独占k8s master，极大的增强了安全性和隔离型。每个租户拥有独立的apiserver，避免了共享Apiserver导致的租户干扰问题，同时一个集群中apiserver的安全风险也不会扩散到其他集群。 因为租户拥有完整的k8s master，所以天然支持更完整的原生kubernetes能力，包括多命名空间、CRD、RBAC等，详细对比如下： 通过CRD/RBAC的支持，我们可以在Serverless集群中部署Istio/knative/Argo/Spark/Kubeflow等多种controller，极大扩展了Serverless Kubernetes面向的应用场景，支撑更多云原生应用的Serverless化部署，充分享受Serverless带来的简单、敏捷和弹性能力

Serverless Kubernetes概述： 阿里云Serverless Kubernetes容器服务最新开放香港、新加坡、悉尼区域，同时全面开放2.0架构，帮助用户更加便捷、轻松地步入“以应用为中心”的全新架构。通过Serverless Kubernetes，用户50秒内可从零启动500应用容器，而无需关心底层服务器资源。 Serverless Kubernetes 2.0新架构 Serverless Kubernetes 2.0对后台架构进行了彻底升级，从之前的基于Namespace的多租户隔离，升级为租户独占k8s master，极大的增强了安全性和隔离型。每个租户拥有独立的apiserver，避免了共享Apiserver导致的租户干扰问题，同时一个集群中apiserver的安全风险也不会扩散到其他集群。 因为租户拥有完整的k8s master，所以天然支持更完整的原生kubernetes能力，包括多命名空间、CRD、RBAC等，详细对比如下： 通过CRD/RBAC的支持，我们可以在Serverless集群中部署Istio/knative/Argo/Spark/Kubeflow等多种controller，极大扩展了Serverless Kubernetes面向的应用场景，支撑更多云原生应用的Serverless化部署，充分享受Serverless带来的简单、敏捷和弹性能力

背景 Kubernetes作为通用的容器编排系统，承载了广泛的应用和场景，包括CI／CD,数据计算，在线应用，AI等，然而由于其通用性和复杂性，管理一个kubernetes集群对于很多用户而言还是充满挑战的，主要体现在： 学习成本高； 集群运维管理成本高，包括节点管理、容量规划，以及各种节点异常问题的定位； 计算成本在很多场景中没有达到最优，比如对于一个定时运行Jobs的集群，长期持有资源池对于用户来说是浪费的行为，资源利用率不高。 Serverless Kubernetes是阿里云容器服务团队对未来kubernetes演进方向的一种探索，通过对kubernetes做减法，降低运维管理负担，简化集群管理，让kubernetes从复杂到简单。 对Kubernetes集群做减法 无节点管理 我们相信未来用户会更加关注应用的开发，而不是基础设施的维护。体现在kubernetes集群中，我们希望用户能够关注在pod/service/ingress/job等应用编排语义上，对底层node则可以减少关注。 无需管理节点也可以显著降低集群的运维管理成本，经统计kubernetes常见的异常问题中大多数与节点相关，比如Node NotReady问题，也无需担忧Node的安全问题，以及基础系统软件的升级和维护。 在ASK集群中，我们使用虚拟节点virtual-kubelet代替ecs节点