kubernetes之pod拓扑分布约束在日常使用kubernetes的过程中中，很多时候我们并没有过多的关心pod的到底调度在哪里，只是通过多副本的测试，来提高的我们的业务的可用性，但是当多个

kubernetes之pod重调度descheduler1\.kubernetessigs/descheduler简介

这是一个统计基于Swift&ObjectiveC工程的代码覆盖率的自动化脚本。之所以做成Pod，是便于更好的复用，该Pod只包含了收集生成代码覆盖率的脚本。整体比较简单方便。

Kubernetes增强了应用服务的横向扩容能力，在应对线上应用服务的资源使用率在高峰和低谷的时候，我们需要能够自动去感知应用的负载变化去调整Pod的副本数量，削峰填谷，提高集群的整体资源利用率和应用的服务质量。为此，Kubernetes1.2版本中引入HorizontalPodAutoscaling(HPA),它与kubectlsc

Kubernetes工作流程!(https://oscimg.oschina.net/oscnet/125154c88288a56d3f8a0a76942105107de.png)客户端创建pod流程：1.用户管理员创建Pod的请求默认是通过kubectl客户端管理命令apiser

一、Service的概念　　运行在Pod中的应用是向客户端提供服务的守护进程，比如，nginx、tomcat、etcd等等，它们都是受控于控制器的资源对象，存在生命周期，我们知道Pod资源对象在自愿或非自愿终端后，只能被重构的Pod对象所替代，属于不可再生类组件。而在动态和弹性的管理模式下，Service为该类Pod对象提供了一

kubernetes创建pod的yaml文件，参数说明apiVersion:v1指定api版本，此值必须在kubectlapiversion中kind:Pod指定创建资源的角色/类型metadata:资源的元数据/属性name:web04pod资源的名字，在同一个namespace中必须唯一lab

命令说明kubectln<namespacegetpods获取指定命名空间podkubectldescribepods<pod查看指定pod事件明细kubectlexecit<podbash进入指定pod容器kubectldescribepod查看pod描述信息与Event事件kub

在Docker的设计实现中，容器中的数据是临时的，即当容器被销毁时，其中的数据将会丢失。如果需要持久化数据，需要使用Docker数据卷挂载宿主机上的文件或者目录到容器中。在K8S中，当Pod重建的时候，数据是会丢失的，K8S也是通过数据卷挂载来提供Pod数据的持久化的。K8S数据卷是对Docker数据卷的扩展，K8S数据卷是Pod级别的，可以用来实现Pod中

摘要：Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命：　　１．监视分配给该Node节点的pods　　２．挂载pod所需要的volumes　　３．下载pod的secret　　４．通过docker/rkt来运行pod中的容器　　５．周期的执行pod中为容器定义的

一、核心概念1、NodeNode作为集群中的工作节点，运行真正的应用程序，在Node上Kubernetes管理的最小运行单元是Pod。Node上运行着Kubernetes的Kubelet、kubeproxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁、以及实现软件模式的负载均衡。Node包含

Pod概念Pod是kubernetes集群中最小的部署和管理的基本单元，协同寻址，协同调度。Pod是一个或多个容器的集合，是一个或一组服务（进程）的抽象集合。Pod中可以共享网络和存储（可以简单理解为一个逻辑上的虚拟机，但并不是虚拟机）。Pod被创建后用一个UID来唯一标

\原文链接：KubernetesPod驱逐详解(https://www.oschina.net/action/GoToLink?urlhttps%3A%2F%2Fwww.yangcs.net%2Fposts%2Fkuberneteseviction%2F)在Kubernetes中，Pod使用的资源最重要的是CPU、内存和磁盘IO

问题：Kubernetes创建Pod失败，无法获取imageFailedcreatepodsandbox:rpcerror:codeUnknowndescfailedpullingimage"harbor.od.com/public/pause:latest":Errorresponsefromdaemon

一、介绍ServiceAccount概念的引入是基于这样的使用场景：运行在pod里的进程需要调用KubernetesAPI以及非KubernetesAPI的其它服务。ServiceAccount它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。二、创建ServiceAcco

podPod是K8S的最小操作单元，一个Pod可以由一个或多个容器组成；整个K8S系统都是围绕着Pod展开的，比如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。特点Pod是能够被创建、调度和管理的最小单元；每个Pod都有一个独立的IP；一个Pod由一个或多个容器构成，并共享命名空间和共享存储等；Pod所有容

问题产生在使用Kubernetes时，有时会遇到Pod状态一直处理Terminating。Pod一直没有正常退出，一般情况会使用命令kubectldeletepodspodnameforcegraceperiod0强制删除。如果按照上面命令强制删除Pod，有一定概率会报Orphanedp

概述首先k8s里面容器是存在于pod里面的，所以容器之间通讯，一般分为三种类型：1\.pod内部容器之间2\.pod与pod容器之间3\.pod访问service服务pod内部容器之间这种情况下容器通讯比较简单，因为k8spod内部容器是共享网络空间的，所以容器直接可以使用localhost访

Pod控制器:　　ReplicationController：早期K8s只有这一个控制器,但后来发现让这一个来完成所有任务,太复杂.因此被废弃.　　ReplicaSet:它用于帮助用户创建指定数量的Pod副本，并确保Pod副本数量一直满足用户期望的副本数量。　　　　　　　　副本数量"多退少补"等机制。【它可认为就是Repli

一、发现问题在一次系统上线后，我们发现某几个节点在长时间运行后会出现内存持续飙升的问题，导致的结果就是Kubernetes集群的这个节点会把所在的Pod进行驱逐OOM；如果调度到同样问题的节点上，也会出现Pod一直起不来的问题。我们尝试了杀死Pod后手动调度的办法（label），当然也可以排除调度节点。但是在一段时间后还会复现，我们通过监控