pod

一、K8s Service 简介 Service 是 k8s 网络部分的核心概念，在 k8s 中，Service 主要担任了四层负载均衡的职责。 Service 是主要用来实现应用程序对外提供服务的机制。 如上图所示，Service 是对 Pod 的一层抽象，主要通过 TCP/IP 机制及监听 IP 和端口号来对外提供服务。与 Pod 不同的是，Service 一旦创建，系统会为其分发一个 ClusterIP (也可以自己指定)，且在其生命周期内不会发生变化。 二、Cluster Network演示 准备工作 创建2个pod 进入dev虚机上 cd ~ cd deployk8s-master/ cd pod-basic/ kubectl create -f pod_nginx.yml kubectl create -f pod_tomcat.yml 进入node节点 21，22，23 分别ping下pod的节点看能否ping通 ping nginx 都是可以ping通的 ping tomcat 都是可以ping通的 说明pod节点直接都是互相通信的 进入这3个node节点发现 他们都使用了Flannel的网络 详细看看官网怎么说 https://kubernetes.io/docs/concepts/cluster-administration/networking/ all

我们在使用pod的时候，pod之前可以相互ping通的，机器本身也可以ping通pod和另外机器的pod，如果是一个serivce的话，我们通过端口号，就可以访问service。 不要直接使用和管理Pods，为什么？ 当我们使用ReplicaSet 或者ReplicationController做水平扩展scale的时候，Pods可能被结束。 当我们使用Deployment的时候，我们去更新Docker Image Version，旧的Pods会被结束，然后新的Pods创建，Ip地址发生了变化。 Service kubectl expoese命令，会给我们的pod创建一个Service，供外部访问。 Service 主要有三种类型： ClsterIP、NodePort、LoadBalancer 另外也可以使用DNS，但是需要DNS的add-on Service的演示 创建service。 get pod kubectl get pod -o wide kubectl expose pods nginx #查看到已经创建的service kubectl get svc 访问service ping 10.254.233.245 创建deployment cd deployk8s-master/ cd labs/ cd deployment/ more deployment_nginx

ScheduleAlgorithm是一个接口负责为pod选择一个合适的node节点,本节主要解析如何实现一个可扩展、可配置的通用算法框架来实现通用调度,如何进行算法的统一注册和构建,如何进行metadata和调度流程上下文数据的传递 1. 设计思考 1.1 调度设计 1.1.1 调度与抢占 当接收到pod需要被调度后，默认首先调用schedule来进行正常的业务调度尝试从当前集群中选择一个合适的node 如果调度失败则尝试抢占调度,根据优先级抢占低优先级的pod运行高优先级pod 1.1.2 调度阶段 在k8s的调度算法运行流程中，主要分为两个阶段：预选和优选，即从当前集群中选择符合要求的node，再从这些node中选择最合适的节点 1.1.3 节点选择 随着集群的增加集群中的node数量越来越多，k8s并不是遍历所有集群资源，而是只选取部分节点，同时借助之前说的 schedulerCache来实现pod节点的分散 1.2 框架设计 1.2.1 注册表与算法工厂 针对不同的算法，声明不同的注册表，负责集群中当前所有算法的注册，从而提供给调度配置决策加载那些插件，实现算法的可扩展性 并通过工厂模式来进行统一管理，解耦算法的注册与具体调度流程中的使用，由每个算法的工厂方法来接受参数进行具体算法的创建 1.2.3 metadata与PluginContext 在调度实际运行的过程中

一、Job （1）Job概述 Job负责处理短暂的一次性任务，即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束。 Kubernetes支持以下几种Job： 非并行Job： 通常创建一个Pod直到其成功结束； 固定结束次数的Job： 在spec字段下添加completions字段。创建多个Pod，直到满足completions规定的数值。如果不添加的话，默认情况下是1个； 带有工作队列的并行Job： 在spec字段下添加Parallelism字段。表示几个job同时并行工作。如果不添加的话，默认情况下是1个； 根据可以设置completions字段、Parallelism字段，可以将Job分为以下几种： （2）Job Controller Job Controller负责根据Job yaml文件中Spec字段定义的内容创建Pod，并持续监控Job的状态，直至其成功结束。如果失败，则根据restartPolicy（只支持OnFailure和Never，不支持Always）决定是否创建新的pod再次重试任务。 如图： （3）应用示例 一个简单的小示例： [root@master job]# cat job.yaml kind: Job apiVersion: batch/v1 metadata: name: test-job spec: template: metadata

一、Kubernetes核心概念 1、Kubernetes介绍 Kubernetes（k8s）是自动化容器操作的开源平台，这些操作包括部署，调度和节点集群间扩展。如果你曾经用过Docker容器技术部署容器，那么可以将Docker看成Kubernetes内部使用的低级别组件。Kubernetes不仅仅支持Docker，还支持Rocket，这是另一种容器技术。 使用Kubernetes可以： 自动化容器的部署和复制 随时扩展或收缩容器规模 将容器组织成组，并且提供容器间的负载均衡 很容易地升级应用程序容器的新版本 提供容器弹性，如果容器失效就替换它，等等... 实际上，使用Kubernetes只需一个部署文件，使用一条命令就可以部署多层容器（前端，后台等）的完整集群： $ kubectl create -f single-config-file.yaml kubectl是和Kubernetes API交互的命令行程序。现在介绍一些核心概念。 2、集群 集群是一组节点，这些节点可以是物理服务器或者虚拟机，之上安装了Kubernetes平台。下图展示这样的集群。注意该图为了强调核心概念有所简化。这里可以看到一个典型的Kubernetes架构图。 上图可以看到如下组件，使用特别的图标表示Service和Label： Pod Container（容器） Label( )（标签）

1、Docker技术基础 对进程做隔离。隔离CPU和内存，限制命名空间 Docker是分层的 Containerd是核心组件 Docker Client实现到Docker Engine之间通信 　　主要关注： 　　　　containers 　　　　images 　　　　networks 　　RunC负责容器应用程序的运行 　　容器里跑的程序都是前台程序，不能是后台程序 Docker联合文件系统（Union Filesystem）-overly2 Docker Images用来运行Docker容器 DockerFile自动创建Docker镜像 　　命令大写: 　　　　FROM 　　　　RUN 　　　　WORKDIR 　　　　COPY 　　　　CMD 特性 ：Docker对资源（cpu、memory、network、storage）细粒度划分，秒起秒开 2、Docker深入理解 镜像管理： 　　Harbor镜像中心 　　Docker Registry实现对容器的管理 　　每个镜像都是一个tar包 Docker容器网络模式：　　 　　主机模式 　　网桥模式 Docker容器跨主机模： 　　VXLAN模式 问题一：容器地址重复 　　Flannel解决方案： 　　　　中心化容器地址分配，Etcd配置存储服务 问题二：容器地址不可达 　　Flannel解决方案： 　　　　方案一：覆盖网络

作者：殷成文 2019 年 12 月 31 日，我们在 GitHub 上正式开源了 Chaos Mesh。作为一个云原生的混沌测试平台，Chaos Mesh 提供在 Kubernetes 平台上进行混沌测试的能力。本篇文章将围绕 Chaos Mesh 起源及原理等方面进行介绍，并结合具体案例带领大家一起探索混沌测试的世界。 现实世界中，各类故障可能会随时随地的发生，其中有很多故障我们无法避免，例如磁盘突然写坏，或者机房突然断网断电等等。这些故障可能会给公司造成巨大损失，因此提升系统对于故障的容忍度成为很多工程师努力的目标。 为了更方便地验证系统对于各种故障的容忍能力，Netflix 创造了一只名为 Chaos 的猴子，并且将它放到 AWS 云上，用于向基础设施以及业务系统中注入各类故障类型。这只 “猴子” 就是混沌工程起源。 在 PingCAP 我们也面临同样的问题，所以在很早的时候就开始探索混沌工程，并逐渐在公司内部实践落地。 在最初的实践中我们为 TiDB 定制了一套自动化测试平台，在平台中我们可以自己定义测试场景，并支持模拟各类错误情况。但是由于 TiDB 生态的不断成熟，各类周边工具 TiDB Binlog 、 TiDB Data Migration 、 TiDB Lightning 等的出现，测试需求也越来越多，逐渐出现了各个组件的的测试框架。但是混沌实验的需求是共有的

Predicates预选算法过程分析 Scheduler工作流程 Predicates预选流程 predicate的并发过程 用 podFitsOnNode 函数实现一个node的预选过程 单个predicate执行过程 Scheduler工作流程 我们在使用K8S集群时，常常需要对Deployment Controller做创建、修改、删除操作，K8S对应的会创建、销毁和重新调度Pod在合适的节点上，这个调度过程是通过K8S的Scheduler调度器实现的。Schduler的工作流程如下图所示： Informer组件一直在监听etcd中Pod信息的变化，准确来说，监听的是Pod信息中Spec.nodeName字段的变化，一旦检测到该字段为空，则认为集群中有Pod尚未调度到Node中，这时Informer开始将这个Pod的信息加入队列中，同时更新Scheduler Cache缓存。接下来Pod信息从队列中出队，进入Predicates（预选阶段），该阶段通过一系列的预选算法选出集群中适合Pod运行的节点，带着这些信息进入Priorities（优选阶段）。同理，该阶段通过一系列的优选算法为适合该Pod调度对每个Node进行打分，最后选出集群中最适合（也就是分数最高的）Pod运行的 一个节点 ，最后将这个节点和Pod进行绑定（Bind），更新缓存，从而实现Pod的调度。

1. kubernetes简介 1.1 kubernetes介绍 Kubernetes是google开源的一套微服务，容器化的编排引擎，是google内部容器十多年实战沉淀的结晶，已战胜Swarm，Messo成为容器编排的行业标准。kuberntes内置有很多非常优秀的特性使开发者专注于业务本身，其包含的功能如下： Service discovery and load balancing，服务发现和负载均衡，通过DNS实现内部解析，service实现负载均衡 Storage orchestration，存储编排，通过plungin的形式支持多种存储，如本地，nfs，ceph，公有云快存储等 Automated rollouts and rollbacks，自动发布与回滚，通过匹配当前状态与目标状态一致，更新失败时可回滚 Automatic bin packing，自动资源调度，可以设置pod调度的所需（requests）资源和限制资源（limits） Self-healing，内置的健康检查策略，自动发现和处理集群内的异常，更换，需重启的pod节点 Secret and configuration management，密钥和配置管理，对于敏感信息如密码，账号的那个通过secret存储，应用的配置文件通过configmap存储，避免将配置文件固定在镜像中，增加容器编排的灵活性

Pod Preset 注意：PodPreset 资源对象只有 kubernetes 1.8 以上版本才支持。 Preset 就是预设，有时候想要让一批容器在启动的时候就注入一些信息，比如 secret、volume、volume mount 和环境变量，而又不想一个一个的改这些 Pod 的 template，这时候就可以用到 PodPreset 这个资源对象了。 本页是关于 PodPreset 的概述，该对象用来在 Pod 创建的时候向 Pod 中注入某些特定信息。该信息可以包括 secret、volume、volume mount 和环境变量。 理解 Pod Preset Pod Preset 是用来在 Pod 被创建的时候向其中注入额外的运行时需求的 API 资源。 您可以使用 label selector 来指定为哪些 Pod 应用 Pod Preset。 使用 Pod Preset 使得 pod 模板的作者可以不必为每个 Pod 明确提供所有信息。这样一来，pod 模板的作者就不需要知道关于该服务的所有细节。 关于该背景的更多信息，请参阅 PodPreset 的设计方案 。 如何工作 Kubernetes 提供了一个准入控制器（ PodPreset ），当其启用时，Pod Preset 会将应用创建请求传入到该控制器上。当有 Pod 创建请求发生时，系统将执行以下操作：