pod

设置资源请求数量 创建Pod的时候，可以为每个容器指定资源消耗的限制。Pod的资源请求限制则是Pod中所有容器请求资源的总和。 apiVersion: v1 kind: Pod metadata: name: requests-pod spec: containers: - image: busybox command: ["dd", "if=/dev/zero", "of=/dev/null"] name: main resources: requests: cpu: 200m memory: 10Mi 如果不指定CPU请求资源，表示不关心容器会分到多少CPU资源，有可能会一直分不到而处于等待状态。指定资源请求表示Pod对资源的最小需求，因此在调度的时候会如果Node剩余的资源不能满足Pod的需求，则不会调度到对应的Node上。Scheduler调度的时候并不关注在调度时具体的资源使用情况，而是根据现存Pod的资源请求情况来进行调度。这就会有问题，特别是当允许Pod使用超过请求的资源时。下面的图一看就能理解。 调度判断首先将不符合请求的Node排除在外，然后将符合要求的Node进行排序。节点排序根据资源请求数量的不同分为两个策略， LeastRequestPolicy 和 MostRequestPolicy 。从字面上我们可以看到，一个是优先分派到资源请求少的节点

K8S Pod status的状态分析 CrashLoopBackOff： 容器退出，kubelet正在将它重启 InvalidImageName： 无法解析镜像名称 ImageInspectError： 无法校验镜像 ErrImageNeverPull： 策略禁止拉取镜像 ImagePullBackOff： 正在重试拉取 RegistryUnavailable： 连接不到镜像中心 ErrImagePull： 通用的拉取镜像出错 CreateContainerConfigError： 不能创建kubelet使用的容器配置 CreateContainerError： 创建容器失败 m.internalLifecycle.PreStartContainer 执行hook报错 RunContainerError： 启动容器失败 PostStartHookError： 执行hook报错 ContainersNotInitialized： 容器没有初始化完毕 ContainersNotReady： 容器没有准备完毕 ContainerCreating：容器创建中 PodInitializing：pod 初始化中 DockerDaemonNotReady：docker还没有完全启动 NetworkPluginNotReady： 网络插件还没有完全启动 K8S-YAML的使用及命令

PV和PVC Kubernetes Volume提供了非常好的数据持久化方案，不过对于大型Kubernetes集群来说管理上还有不方便之处。Volume方案需要创建Pod或者Deployment的管理员对共享存储的参数和机制比较清楚，甚至对一些存储的访问是需要身份验证的，这导致集群用户（存储使用者）和系统管理员（存储管理员）的职责耦合在一起了。但对于大型的生产环境，为了管理的效率和安全，集群用户（存储使用者）和系统管理员（存储管理员）是分置的。 Kubernetes引入了两个新的API资源PersistentVolume和PersistentVolumeClaim来解决这个问题。 PersistentVolume（PV）是集群中由系统管理员配置的一段网络存储。它是集群中的资源，就像node是集群资源一样。PV也是像是Volumes一样的存储插件，但其生命周期独立于使用PV的任何单个Pod。PV配置存储实现的详细信息，包括NFS，iSCSI或特定于云提供程序的存储系统。PV属于集群级别资源，不属于任何的Namespace。 PersistentVolumeClaim（PVC）是使用存储的请求，属于Namespace中的资源。PVC类似于Pod，Pod消耗node资源，PVC消耗PV资源。Pod可以请求特定级别的计算资源（CPU和内存），PVC可以请求特定大小和访问模式的存储资源。

存储卷介绍 一个容器的对文件系统的写入都是发生在文件系统的可写层的，一旦该容器运行结束，所有写入数据都会被丢弃。在K8S集群之中，Pod会在各个节点之间漂移，如何保障Pod的数据持久和不同节点数据的共享。Kubernetes提出了存储卷Volume的概念，Kubernetes存储卷主要解决了依次递增的几个问题： 当运行的容器崩溃时，kubelet会重新启动该容器，但容器会以干净状态被重新启动。容器崩溃之前写入的文件将会被丢失。 当一个Pod中同时运行多个容器时，这些容器之间需要共享文件。 在k8s中，由于Pod分布在各个不同的节点之上，并不能实现不同节点之间持久性数据的共享，并且在节点故障时，可能会导致数据的永久性丢失。 Kubernetes存储卷拥有明确的生命周期，与所在的Pod的生命周期相同。因此Kubernetes存储卷独立于任何容器，所以数据在Pod重启的过程中还会保留，当然如果这个Pod被删除了，那么这些数据也会被删除。 Kubernetes 支持的卷类型 Type Type Type Type Type Type awsElasticBlockStore azureDisk azureFile cephfs cinder configMap csi downwardAPI emptyDir fc (fibre channel) flexVolume flocker

一，k8s的资源对象 Deployment、Service、Pod是k8s最核心的3个资源对象 Deployment： 最常见的无状态应用的控制器，支持应用的扩缩容、滚动升级等操作。 Service： 为弹性变动且存在生命周期的Pod对象提供了一个固定的访问接口，用于服务发现和服务访问。 Pod： 是运行容器以及调度的最小单位。同一个pod可以同时运行多个容器，这些容器共享net、UTS、IPC，除此之外还有USER、PID、MOUNT。 ReplicationController： 用于确保每个Pod副本在任意时刻都能满足目标数量，简单来说，它用于每个容器或容器组总是运行并且可以访问的：老一代无状态的Pod应用控制器。 RwplicatSet： 新一代的无状态的Pod应用控制器，它与RC的不同之处在于支持的标签选择器不同，RC只支持等值选择器（键值对），RS还额外支持基于集合的选择器。 StatefulSet： 用于管理有状态的持久化应用，如database服务程序，它与Deployment不同之处在于，它会为每一个pod创建一个独有的持久性标识符，并确保每个pod之间的顺序性。 DaemonSet： 用于确保每一个节点都运行了某个pod的一个副本，新增的节点一样会被添加到此类pod，在节点移除时，此pod会被回收。 Job： 用于管理运行完成后即可终止的应用

StatefulSet（状态集） 1，什么是StatefulSet ？ StatefulSet又叫PetSet（之前的名称），它和RS,RC,Deployment等一样，都是pod控制器。 StatefulSet是为了解决有状态服务的问题（对应于deoloyment和RS，RC，ReplicaSet都是为无状态服务而设计的）。 什么是无状态服务？ 在生产环境中，pod的名称是随机的，扩缩容的是时候没有规律，每一个pod都可以被新生成的pod代替。 2，StatefulSet的应用场景包括： 稳定的持久化存储：即pod重新调度后还是能够访问到相同的持久化数据，基于PVC来实现。 稳定的网络标志：即pod重新调度后其pod名称和host名称不变，基于Headless Service（即没有cluster ip的service）来实现。 有序部署，有序扩展：即pod是由顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即从0到N-1， 在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现。 有序收缩,有序删除：（即N-1到0） 从上面的引用场景可以发现，statefulset由以下几个部分组成： 1）headless Service：无头服务。用来定义pod的网络标识的（域名解析）。 2）statefulSet

参考《每天5分钟玩转kubernetes》 ColdMan著。 一、概念 1. Cluster cluster是计算、存储和网络资源的集合, k8s使用这些资源运行基于容器的应用 2. Master cluster的大脑，主要职责是调度，决定将应用放在哪里运行。在linux上运行（物理机or虚拟机）。为了高可用，可运行多个master。 3. Node 职责是运行容器应用。由master管理，监控、汇报容器状态，要据master要求管理容器生命周期。运行于linux(物理机or虚拟机） 4. Pod 最小工作单元，每个pod包含1个or多个容器。作为整体被master调度到node上运行。 4.1 引入pod（比容器更高层次的抽象）的目的: (1) 可管理性。 将需要一起工作的（紧密联系的）容器封装到同一个部署单元，以pod为最小单位进行调度、扩展、共享资源、管理生命周期。 (2) 通信和资源共享。 pod中所有容器使用同一个网络namespace（相同ip+port)，可直接用localhost通信。共享存储，k8s挂载volume到pod，本质是将volume挂载到pod中的每个容器。 4.2 Pods的2种使用方式 (1) 运行单一容器 one-container-per-Pod， 只将单个容器简单封装成pod. (2) 运行多个容器

kubelet命令： https://blog.csdn.net/qq_25744595/article/details/85096162 Kubernetes-Host网络模式，指定Pod 物理机IP： https://blog.csdn.net/meifannao789456/article/details/103877109 kubernetes 网络组件简介： https://blog.csdn.net/kjh2007abc/article/details/86751730 K8S 核心组件 kubelet 与 kube-proxy： https://www.jianshu.com/p/cab9467301f2 为什么需要Pod？ http://www.sohu.com/a/327114311_198222 其他： https://www.cnblogs.com/sxgaofeng/p/12039742.html 来源： https://www.cnblogs.com/heboxiang/p/12182159.html