容器

现代化的企业私有云IT基础架构中，越来越多的生产环境正在逐步变革，将以传统虚拟化为中心的架构向以容器和微服务为中心的云原生架构过渡，在这个过程中，存储如何有效支撑各种云主机应用与微服务应用，对于企业的私有云数据中心提出了很大挑战。 杉岩容器云存储解决方案充分发挥了杉岩存储产品的云服务能力，具备广泛的生态合作基础，可高效地对接各种云化的计算资源，降低复杂私有云数据中心的基础架构层管理运维成本。 面临的挑战 业务调度变更频繁，资源不能共享 随着容器、微服务平台在企业私有云环境的上线，大型企业的应用快速开发迭代、发布频繁对于存储系统的弹性支撑能力提出了严峻挑战，且不同的业务数据保存在计算节点本地或者不同的外部存储设备中，数据流动性差，不仅导致存储空间及性能资源浪费严重，数据灾备方案难以统一。 开源产品难维护，无法实现企业级产品化 基于开源技术的容器编排系统如Kubernetes等为众多客户提供了快速构建PaaS平台的能力，但是存储部分却不一样，开源的存储系统如Ceph虽然可以在生产环境部署，但也面临一些问题：与硬件和企业级应用生态融合程度不高，严重依赖人工开发运维，在性能和服务质量方面不能同时满足敏态与稳态应用的需求。 存储接口需求多样化，没有统一的存储平台 容器平台中的中间件、数据库等需要持久化存储的业务通常直接使用块设备或文件夹，一些无状态应用则需要对象存储

资源限制 pod和container的资源请求和限制 #cpu上限 spec.containers[].resources.limits.cpu #内存上限 spec.containers[].resources.limits.memory #创建时分配的基本cpu资源 spec.containers[].resources.requests.cpu #创建时分配的基本内存资源 spec.containers[].resources.requests.memory 示例演示（在master1端操作） 创建pod2.yaml文件 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: "128Mi" cpu: "500m" - name: wp #容器2的名称 image: wordpress resources: requests: memory: "64Mi"

作者 | 汤志敏、谢瑶瑶 会议完整视频回顾： 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相关概念：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

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

Docker 数据管理 在Docker中，为了方便查看容器内产生的数据或者将多个容器中的数据实现共享，就涉及到容器的数据管理操作。 管理Docker容器中数据只要有两种方式：数据卷（Data Volumes）和数据卷容器（Data Volumes Containers） 数据卷 数据卷是一个供容器使用的特殊目录，位于容器中，可将宿主机的目录挂载到数据卷上，对数据卷的修改操作立刻可见，并且更新数据不会影响镜像，从而实现数据在宿主机与容器之间的迁移。 1.创建数据卷 在docker run命令中使用-v选项可以在容器内创建数据卷。多次使用-v选项可以创建多个数据卷。使用--name选项可以给容器创建一个有好的自定义名称。 例子： docker pull centos #下载镜像 #宿主机目录/var/www 挂载容器中的/data1 docker run -v /var/www:/data1 --name web1 -it centos /bin/bash [root@63031797b41f /]# cd /data1/ [root@63031797b41f data1]# touch test [root@63031797b41f data1]# exit #返回宿主机进行查看 [root@localhost ~]# ls /var/www/ 2.数据卷容器

在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

Docker 容器 类似于一个轻量级的沙箱子（因为Docker是基于Linux内核的虚拟技术，所以消耗资源十分少），Docker利用容器来运行和隔离应用。 容器是从镜像创建的应用运行实例，可以将其启动、开始、停止、删除，而这些容器都是相互隔离、互不可见的。 可以吧每个容器看作一个简易版的Linux系统环境（包括了root用户权限、进程空间、用户空间和网络空间），以及与运行在其中的应用程序打包而成的应用盒子。 镜像自身是只读的。容器从镜像启动的时候，Docker会在镜像的最上层创建一个可写层，镜像本身将保持不变。就像用ISO装系统之后，ISO并没有什么变化一样。 Docker 容器相关操作 1.创建容器 docker create -it nginx /bin/bash #容器创建 docker ps -a #查看 2.容器查看 docker ps -a #查看所有 3.容器启动与关闭 docker start 7564a08a0005 #启动容器 docker run nginx /bin/bash -c ls / #启动执行命令查看系统根目录 备注：上条命令执行完成直接关闭 状态是Exited 持续在后台执行 docker run -d nginx /bin/bash -c "while true;do echo hello;done" docker ps 注意：docker