pod

最近研究了一段时间的Kubernetes，将我们服务的测试环境服务部署到了Kubernetes上，上周末在团队中分享了下，顺便整理成文章。 阅读对象：对Kubernetes尚未深入了解的同学 首先，为什么要用Kubernetes? 使用一个工具先要梳理下使用这个工具的目标，我们不是为了工具而用工具。 Kubernetes的目标用一张被很多人引用过的图来说明最好： 一句话，Kubernetes的目标是让你可以像管理牲畜一样管理你的服务，而不是像宠物一样，同时提高资源的利用率，让码农关注在应用开发本身，高可用的事情就交给Kubernetes吧。这个图本来是openstack提出的，但纯粹IaaS层的解决方案实现不了这个目标，于是有了Kubernetes。 Kubernetes和Borg系出同门，基本是Borg的开源改进版本，引用Google Borg论文里的说法： it (1) hides the details of resource management and failure handling so its users can focus on application development instead; (2) operates with very high reliability and availability, and supports applica- tions

本篇专注在调度过程中 Predicates 和 Priorities 这两个调度策略主要发生作用的阶段。 Predicates 首先，我们一起看看 Predicates。 Predicates 在调度过程中的作用，可以理解为 Filter ，即：它按照调度策略，从当前集群的所有节点中，“过滤”出一系列符合条件的节点。这些节点，都是可以运行待调度 Pod 的宿主机。 而在 Kubernetes 中，默认的调度策略有如下三种。 第一种类型，叫作 GeneralPredicates。 顾名思义，这一组过滤规则，负责的是最基础的调度策略。 PodFitsResources PodFitsResources 计算的就是宿主机的 CPU 和内存资源等是否够用。 当然，我在前面已经提到过，PodFitsResources 检查的只是 Pod 的 requests 字段。需要注意的是，Kubernetes 的调度器并没有为 GPU 等硬件资源定义具体的资源类型，而是统一用一种名叫 Extended Resource 的、Key-Value 格式的扩展字段来描述的。比如下面这个例子： apiVersion: v1 kind: Pod metadata: name: extended-resource-demo spec: containers: - name: extended-resource

单节点集群 多节点集群 注意node通过连接loadbalancer 转发到mateter 的apiserver来进行运作的 集群规划： 角色 ip 组件 K8S-master1 192.168.0.101 kube-apiserver kube-controller-manager kube-scheduleretcd K8S-master2 192.168.0.102 kube-apiserver kube-controller-manager kube-scheduleretcd K8S-node1 192.168.0.103 kubelet kube-proxy docker etcd K8S-node2 192.168.0.104 kubelet kube-proxy docker etcd K8S-load-balancer 192.168.0.106(vip）实际IP105 Nginx L4 1,系统初始化 ##关闭防火墙： systemctl stop firewalld systemctl disable firewalld ##关闭selinux： setenforce 0 ## 临时 sed -i 's/enforcing/disabled/' /etc/selinux/config ## 永久 ##关闭swap： swapoff -a ## 临时 vim

第1章 k8s系统架构 从系统架构来看，k8s分为2个节点 Master 控制节点 指挥官 Node 工作节点 干活的 1.Master节点组成 API Server ：提供k8s API接口 主要处理Rest操作以及更新Etcd中的对象 是所有资源增删改查的唯一入口。 Scheduler：资源调度器 根据etcd里的节点资源状态决定将Pod绑定到哪个Node上 Controller Manager 负责保障pod的健康存在 资源对象的自动化控制中心，Kubernetes集群有很多控制器。 Etcd 这个是Kubernetes集群的数据库 所有持久化的状态信息存储在Etcd中 2.Node节点的组成 Docker Engine 负责节点容器的管理工作，最终创建出来的是一个Docker容器。 kubelet 安装在Node上的代理服务，用来管理Pods以及容器/镜像/Volume等，实现对集群对节点的管理。 kube-proxy 安装在Node上的网络代理服务，提供网络代理以及负载均衡，实现与Service通讯。 第2章 k8s逻辑架构 从逻辑架构上看，k8s分为 Pod Controller Service 1.POD POD是k8s的最小单位 POD的IP地址是随机的，删除POD会改变IP POD都有一个根容器 一个POD内可以由一个或多个容器组成

版权声明：本文由turboxu原创文章，转载请注明出处: 文章原文链接： https://www.qcloud.com/community/article/152 来源：腾云阁 https://www.qcloud.com/community Kubernetes作为容器编排生态圈中重要一员，是Google大规模容器管理系统borg的开源版本实现，吸收借鉴了google过去十年间在生产环境上所学到的经验与教训。 Kubernetes提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接运行在物理机上.kubernetes是一个开放的容器调度管理平台，不限定任何一种言语，支持java/C++/go/python等各类应用程序 。 kubernetes是一个完备的分布式系统支持平台，支持多层安全防护、准入机制、多租户应用支撑、透明的服务注册、服务发现、内建负载均衡、强大的故障发现和自我修复机制、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力,完善的管理工具，包括开发、测试、部署、运维监控，一站式的完备的分布式系统开发和支撑平台。 一. 系统架构

六、深入 Pod ——一 pod 多容器 一 pod 多容器 ，可以说是 kube 精华 所在， 让多个同应用的单一容器可以整合到一个类虚拟机中，使其所有容器共用一个 vm 的资源，提高耦合度，神来之笔，从而方便副本的复制，提高整体的可用性 接下来会从我自己的学习历程，讲诉 一 pod 多容器 ，其中历经的困难，此问题有困扰一个月之久。 1、测试过程： 根据文章： http://www.csdn.net/article/2014-12-18/2823196 ，看到 pod 还有 一 pod 多容器 的功能，仅是看了文章便激动不已， 一 pod 多容器 ，可以说是 kube 的精华 所在，具体优点，可以参考 第一章的简介 （ 14 项） ①、第一次测试——失败： 使用文件： 【 nginx_redis_pod.json 】 目的 ： 一 pod 两容器 结论 ： 失败， 1 个启动成功， 1 个启动失败，一直在重启，不知道是配置文件的问题，还是什么 提前说明下各 image 启动的端口： images port www.perofu.com:7070/centos6.4_ip_nginx 80 、 22 www.perofu.com:7070/centos6.4_redis 6379 、 22 [root@www pod_nginx_redis_kube]# vi nginx

一、k8s的UI访问界面-dashboard 在dashboard中，虽然可以做到创建、删除、修改资源等操作，但通常情况下，我们会把它当做健康k8s集群的软件。 作为Kubernetes的Web用户界面，用户可以通过Dashboard在Kubernetes集群中部署容器化的应用，对应用进行问题处理和管理，并对集群本身进行管理。通过Dashboard，用户可以查看集群中应用的运行情况，同时也能够基于Dashboard创建或修改部署、任务、服务等Kubernetes的资源。通过部署向导，用户能够对部署进行扩缩容，进行滚动更新、重启Pod和部署新应用。当然，通过Dashboard也能够查看Kubernetes资源的状态。 1、Dashboard提供的功能 在默认情况下，Dashboard显示默认(default)命名空间下的对象，也可以通过命名空间选择器选择其他的命名空间。在Dashboard用户界面中能够显示集群大部分的对象类型。 1）集群管理 集群管理视图用于对节点、命名空间、持久化存储卷、角色和存储类进行管理。 节点视图显示CPU和内存的使用情况，以及此节点的创建时间和运行状态。 命名空间视图会显示集群中存在哪些命名空间，以及这些命名空间的运行状态。角色视图以列表形式展示集群中存在哪些角色，这些角色的类型和所在的命名空间。 持久化存储卷以列表的方式进行展示

Kubernetes对资源的限制实际上是通过cgroup来控制的，cgroup是容器的一组用来控制内核如何运行进程的相关属性集合，针对内存、CPU各种设备都有对应的cgroup。 默认情况下，Pod运行没有CPU和内存的限制，这就意味着系统中的任何pod将能够像执行该pod所在的节点一样，消耗足够多的CPU和内存，一般会针对某些应用的Pod资源进行资源限制，这个资源限制是通过resources的limits来实现的。 注：以下只是在yaml文件中进行资源限制的一个片段，并不是完整的yaml文件！ 1）针对pod的资源限制 [root@master limit]# vim cgroup-pod.yaml spec: containers: - name: xxx image: xxx ports: - protocol: TCP containerPort: 80 resources: limits: #硬限制 cpu: "4" memory: 2Gi requests: #运行pod时请求的资源数量 cpu: 260m memory: 260Mi requests: 要分配的资源，limits为最高请求的资源值。可以简单的理解为初始值和最大值。 2）基于名称空间的资源限制（可以具体制定限制某一个名称空间） 1）计算资源配额 [root@master limit]# vim

Kubernetes1.3：QoS 服务 质量管理 在kubernetes中，每个POD都有个QoS标记，通过这个Qos标记来对POD进行 服务 质量管理 。QoS的英文全称为"Quality of Service",中文名为"服务质量"，它取决于用户对服务质量的预期，也就是期望的服务质量。对于POD来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是 内存 。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据POD具有的不同QoS标记，采取不同的处理策略。 在Kubernetes中，POD的QoS 服务 质量 一共有三个级别，如下图所示： 这三个QoS级别介绍，可以看下面表格： QoS级别 QoS介绍 BestEffort POD中的所有容器都没有指定CPU和内存的requests和limits，那么这个POD的QoS就是BestEffort级别 Burstable POD中只要有一个容器，这个容器requests和limits的设置同其他容器设置的不一致，那么这个POD的QoS就是Burstable级别 Guaranteed POD中所有容器都必须统一设置了limits，并且设置参数都一致，如果有一个容器要设置requests，那么所有容器都要设置，并设置参数同limits一致，那么这个POD的QoS就是Guaranteed级别

虚拟化Pod性能比裸机还要好，原因竟然是这样！ http://www.itpub.net/2020/02/27/5340/ 其实感觉 linux也可以做到 NUMA的节点优化其实 直接在 ESXi上面跑Pod的化 理论上跟 裸机道理一样。 之前的文章介绍过 VMware 在 VMworld 上宣布的太平洋项目 (Project Pacific) ，这是 vSphere 向 Kubernetes 原生平台的演进。太平洋项目引入了 vSphere 主管集群（ Supervisor Cluster ）的概念，该集群能够在 ESXi 上原生地运行 Kubernetes Pod（称为 Native Pod ）。 根据 VMware 官博上发布的信息，太平洋项目中通过虚拟化实现的 Native Pods，竟然比物理机（裸机）上 Kubernetes 的 pod 有8％的性能提升！ 是的，你的确没有看错，虚拟化 Pod 的性能要比裸机 Pod 要好，这似乎有悖常理，众所周知，虚拟化是有性能损失的，怎能优于裸机呢？且听笔者慢慢道来。 为什么太平洋项目的 Native Pods 更快？ 现代的服务器一般有多个处理器（CPU），采用的是 NUMA（非统一内存访问）的内存访问方式。在 NUMA 体系架构中，每个 CPU 负责管理一块内存，称为本地（local）内存。 当 CPU 访问自己管理的内存时