pod

作者 | 汤志敏、谢瑶瑶 会议完整视频回顾： https://www.bilibili.com/video/av88668762 2 月 12 日，阿里云和 CNCF 联合举办了线上研讨会，首次完整介绍了阿里云对 Kubernetes 社区的布局，包括了 10 个类别，20 多个开源项目，提供了完整的 Kubernetes 生命周期管理。本文汇集了此次会议完整视频回顾及资料下载，并整理了会议上未能及时回答的问题，希望能够对大家有所帮助~ 关注“阿里巴巴云原生”公众号，后台回复 “会议” 即可下载 PPT。 什么是 SIG Cloud Provider 随着时间的发展，越来越多的企业在生产环境使用 Kubernetes。Kubernetes 被广为接受，离不开其良好的设计和繁荣的社区。目前围绕着 Kubernetes 已经有 20 个左右的兴趣小组（SIG），SIG Cloud Provider 则是 Kubernetes 的重要兴趣小组之一，致力于推动所有云厂商以标准的能力提供 Kubernetes 服务。 SIG-Cloud-Provider-Alibaba 是 SIG Cloud Provider 在国内唯一的子项目。 Cloud Provider SIG 是 Kubernetes 的云厂商兴趣小组，致力于让 Kubernetes 的生态系统往厂商中立的方向演进

注意此篇文章接上篇：K8s之Pod进阶 https://blog.51cto.com/14464303/2472123 原理： kubernetes通过watch的机制进行每个组件的协作，每个组件之间的设计实现了解耦 调度方式： nodeName用于将Pod调度到指定的Node名称上（跳过调度器直接分配） nodeSelector用于将Pod调度到匹配Label的Node上（前提是node要有标签） 图解： 左上角的运维人员往节点中创建一个nginx资源 （1）API Server和etcd和Scheduler是master （2）Kubelet和Docker是node节点 API Server做为唯一入口，接受create创建资源的属性信息写入到etcd中（属性信息：名称，镜像名称，限制条件），etcd完善发现机制（watch）给Scheduler调度器（查看那个节点适合），然后绑定相关pod的网络信息，反馈给API Server，收到信息后api写入etcd中，此时etcd存储了pod的网络信息（IP），node1、中的kubelet会管理pod资源，会触发容器的创建命令，安装完成后docker就会反馈状态信息给API Server，当API Server收到状态信息写入到etcd中 总结： apiserver相当于是平台中的书记（负责记录） etcd相当于书记的记事本

K8s相关概念：master/node master Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行，实现高可用，可以运行多个 Master。 运行的相关组件： Kubernetes API Server(kube-apiserver)，集群的统一入口，各组件协调者，以RESTful API提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。 Kubernetes Controller Manager，处理集群中常规后台任务，一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。 Kubernetes Scheduler，根据调度算法为新创建的Pod选择一个Node节点，可以任意部署,可以部署在同一个节点上,也可以部署在不同的节点上。 etcd Server，分布式键值存储系统。用于保存集群状态数据，比如Pod、Service等对象信息 node Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。运行的相关组件如下： kubelet：是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret

Pod特点 k8s的最小管理单元 一组容器的集合 一个Pod中的容器共享网络命令空间 Pod是短暂的 Pod容器分类 1.infrastructure container 基础容器（维护整个Pod网络空间） node节点操作 #查看容器的网络 cat /opt/kubernetes/cfg/kubelet #每次创建Pod时候就会创建，与Pod对应的，对于用户是透明的,网络组件会被自动加载成一个组件提供出去 docker ps 2.initcontainers 初始化容器 pod在进行创建时一定会被执行当中的初始化initcontainers， 在老版本中执行时不会区分前后顺序（在系统进行加载时PID号数字越小，优先级别越高，越先被启动）， 随着云平台的改进，启动模式改为主机形式，分隔出的初始化容器会被优先加载， 在初始化容器加载完成之后后面的业务容器才能正常接着运行 3.container 业务容器,并行启动 示例 ： Init containers in use This example defines a simple Pod that has two init containers. The first waits for myservice, and the second waits for mydb. Once both init containers complete

Pod特点 k8s的最小管理单元 一组容器的集合 一个Pod中的容器共享网络命令空间 Pod是短暂的 Pod容器分类 1.infrastructure container 基础容器（维护整个Pod网络空间） node节点操作 #查看容器的网络 cat /opt/kubernetes/cfg/kubelet #每次创建Pod时候就会创建，与Pod对应的，对于用户是透明的,网络组件会被自动加载成一个组件提供出去 docker ps 2.initcontainers 初始化容器 pod在进行创建时一定会被执行当中的初始化initcontainers， 在老版本中执行时不会区分前后顺序（在系统进行加载时PID号数字越小，优先级别越高，越先被启动）， 随着云平台的改进，启动模式改为主机形式，分隔出的初始化容器会被优先加载， 在初始化容器加载完成之后后面的业务容器才能正常接着运行 3.container 业务容器,并行启动 示例 ： Init containers in use This example defines a simple Pod that has two init containers. The first waits for myservice, and the second waits for mydb. Once both init containers complete

注意此篇文章接上篇：K8s之Pod资源管理及创建Harbor私有镜像仓库 https://blog.51cto.com/14464303/2471369 一、资源限制： pod和container的资源请求和限制： spec.containers[].resources. limits .cpu #cpu上限 spec.containers[].resources. limits .memory #内存上限 spec.containers[].resources. requests .cpu #创建时分配的基本cpu资源 spec.containers[].resources. requests .memory #创建时分配的基本内存资源 示例（在master1上操作）： [root@master1 demo]# vim pod2.yaml apiVersion: v1 kind: Pod metadata: name: frontend #Pod资源的名称 spec: containers: - name: db #容器1的名称 image: mysql env: - name: MYSQL_ROOT_PASSWORD value: "password" resources: requests: memory: "64Mi" cpu: "250m" limits: memory:

Pod特点 k8s的最小管理单元 一组容器的集合 一个Pod中的容器共享网络命令空间 Pod是短暂的 Pod容器分类 1.infrastructure container 基础容器（维护整个Pod网络空间） node节点操作 #查看容器的网络 cat /opt/kubernetes/cfg/kubelet #每次创建Pod时候就会创建，与Pod对应的，对于用户是透明的,网络组件会被自动加载成一个组件提供出去 docker ps 2.initcontainers 初始化容器 pod在进行创建时一定会被执行当中的初始化initcontainers， 在老版本中执行时不会区分前后顺序（在系统进行加载时PID号数字越小，优先级别越高，越先被启动）， 随着云平台的改进，启动模式改为主机形式，分隔出的初始化容器会被优先加载， 在初始化容器加载完成之后后面的业务容器才能正常接着运行 3.container 业务容器,并行启动 示例 ： Init containers in use This example defines a simple Pod that has two init containers. The first waits for myservice, and the second waits for mydb. Once both init containers complete

pod是k8s管理的最小单元 pod中有多个容器，现实生产环境中只有一个容器 特点: 1.最小部署单元 2.一组容器的集合 3.一个Pod中的容器共享网络命令空间 4.Pod是短暂的 Pod容器分类： 1：infrastructure container 基础容器（透明的过程，用户无感知） 维护整个Pod网络空间 node节点操作 `查看容器的网络` [root@node1 ~]# cat /opt/kubernetes/cfg/kubelet KUBELET_OPTS="--logtostderr=true \ --v=4 \ --hostname-override=192.168.18.148 \ --kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \ --bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \ --config=/opt/kubernetes/cfg/kubelet.config \ --cert-dir=/opt/kubernetes/ssl \ --pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

在docker和K8S中都存在容器是有生命周期的，因此数据卷可以实现数据持久化。 数据卷解决的主要问题： 1.数据持久性：当我们写入数据时，文件都是暂时性的存在，当容器崩溃后，host就会将这个容器杀死，然后重新从镜像创建容器，数据就会丢失。 2.数据共享：在同一个Pod中运行容器，会存在共享文件的需求。 数据卷的类型： 1.emptyDir emptyDir数据卷类似于docker数据持久化的docker manager volume，该数据卷初分配时，是一个空目录，同一个Pod中的容器可以对该容器中的目录具有执行读写操作，并且共享数据。 场景特点：一个相同的pod，不同的容器，共享数据卷 如果容器被删除，数据仍然存在，如果Pod被删除，数据也会被删除 测试： **vim emptyDir.yaml** apiVersion: v1 kind: Pod metadata: name: producer-consumer spec: containers: - image: busybox name: producer volumeMounts: - mountPath: /producer_dir#这里的路径指的是容器内的路径 name: shared-volume#指定本地的目录名 args:#定义容器运行后，会进行的操作 - /bin/sh - -c - echo

ConfigMap和Secret是Kubernetes中两种特殊类型的存储卷，ConfigMap这种资源对象主要用于提供配置数据以定制程序行为，不过一些敏感的配置信息，比如像用户名、密码、密钥等通常都是由Secret这种资源对象来进行配置的，他们将相应的配置信息保存于对象中，而后在Pod资源上以存储卷的形式将其挂载并获取相应配置，以实现配置与镜像文件的解耦。 一、Secret资源对象 1） Secret概述 Secret资源对象存储数据的方式是以键值对的方式进行存储的，在Pod资源进行Secret的方式是通过环境变量或存储卷的方式进行访问数据，解决了密码、token、密钥等敏感数据的配置问题，而不需要将这些敏感数据暴露到镜像或者Pod的spec字段中。另外，Secret对象的数据存储和打印格式为Base64编码的字符串，因此用户在创建Secret对象时，也需要提供该类型的编码格式的数据。在容器中以环境变量或存储卷的方式访问时，会自动解码为明文格式。需要注意的是，如果是在Master节点上，Secret对象以非加密的格式存储在etcd中，所以需要对etcd的管理和权限进行严格控制。 2）Secret资源的类型 Secret有四种类型： 1）Service Account ：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run