CSI是Container Storage Interface的简称,旨在能为容器编排引擎和存储系统间建立一套标准的存储调用接口,实现解耦,通过该接口能为容器编排引擎提供存储服务。
CSI是Container Storage Interface的简称,旨在能为容器编排引擎和存储系统间建立一套标准的存储调用接口,实现解耦,通过该接口能为容器编排引擎提供存储服务。
Kubernetes 和 Docker 类似,也是通过 Volume 的方式提供对存储的支持。但是Kubernetes对容器存储做了一层自己的抽象,相比docker的存储来讲,K8S的存储抽象更全面,更面向应用,体现在如下几个方面:
我们一般都是使用dockerfile来制作镜像。但是在镜像制作中,也有着很多的注意点,比如优化构建后的体积,还要优化构建速度,时区,证书等等。
这篇文章主要是对client-go中的informer机制的原理做源码解析。
client-go中的informer机制可以说是客户端交互中一种比较特别的机制,适用于像k8s这种控制器的各种模式。
client-go就是字面意思,一个go的client库,用于和k8s的各种资源对象进行交互,但是它比传统的api客户端库多了很多高级的交互机制,比如informer,dynamic机制,这些也和k8s机制有一定的关系。
Pod 水平自动伸缩(Horizontal Pod Autoscaler)和垂直扩展(Vertical Pod Autoscaler)以及CA( cluster-autoscaler)特性,可以说是很实用的特性,完全自动化实现了资源的充分利用,所以单独拿出来说说。
OpenKruise 是阿里云开源的大规模应用自动化管理引擎,在功能上对标了 Kubernetes 原生的 Deployment / StatefulSet 等控制器,但 OpenKruise 提供了更多的增强功能如:优雅原地升级、发布优先级/打散策略、多可用区workload抽象管理、统一 sidecar 容器注入管理等,都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。
CNI(Container Network Interface)是 CNCF 旗下的一个项目,最早是由CoreOS发起的容器网络规范,由一组用于配置 Linux 容器的网络接口的规范和库组成,同时还包含了一些插件。
pod只是运行的最小单元,我们一般不会直接使用pod。大部分情况下我们都是使用deployment(RS),deamonset,statefulset,job等控制器来完成部署调度使用。
apiserver是集群的核心,是k8s中最重要的组件,因为它是实现声明式api的关键。
kubernetes API server的核心功能是提供了kubernetes各类资源对象(pod、RC 、service等)的增、删、改、查以及watch等HTTP Rest接口。
kubelet用于处理master节点下发到本节点的任务,管理Pod以及Pod中的容器。每个kubelet进程会在API Server上注册节点信息,定期向master节点汇报节点资源的使用情况,并通过cAdvisor监控容器和节点的资源。
容器网络的建立和控制是一种结合了network namespace、iptables、linux网桥、route table等多种Linux内核技术的综合方案,在宿主机和容器内分别创建虚拟接口,并让它们彼此连通。
kube-proxy是Kubernetes的核心组件,部署在每个Node节点上,它是实现Kubernetes Service的通信与负载均衡机制的重要组件; kube-proxy负责为Pod创建代理服务,从apiserver获取所有server信息,并根据server信息创建代理服务,实现server到Pod的请求路由和转发,从而实现K8s层级的虚拟转发网络。
kube-scheduler是 kubernetes 系统的核心组件之一,主要负责整个集群资源的调度功能,根据特定的调度算法和策略,将 Pod 调度到最优的工作节点上面去,从而更加合理、更加充分的利用集群的资源。
istio是一款 Service Mesh 模式的落地实现,是目前servicemesh实现使用最多的一个方案,istio本身和平台无关,但是一般都是和k8s结合使用,首先k8s服务间通信和流控的相关操作。
在以前的一篇文章中云计算CDCI系列—- helm2中,我们说明了helm的架构使用,目前helm已经发展到了helm3,重架构方面发送了很大的变化,所以今天我们来看看helm3。
Kubernetes 项目的核心原理,就是“控制器模式”。
CRI就是kubelet 把对容器的操作,统一地抽象成一个接口。这样,kubelet 就只需要跟这个接口打交道了。而作为具体的容器项目,比如 Docker、 rkt、runV,它们就只需要自己提供一个该接口的实现,然后对 kubelet 暴露出 gRPC 服务即可。
为了方便查阅 API 接口的详细定义,Kubernetes 使用了 swagger-ui 提供 API 在线查询功能,其官网为http://kubernetes.kansea.com/docs/reference/, Kubernetes开发团队会定期更新、生成 UI 及文档。
运行在 Master 节点上的 API Server 进程同时提供了 swagger-ui 的访问地址:http://
Swagger UI 是一款 REST API 文档在线自动生成和功能测试软件,关于 Swagger 的内容请访问官网 http://swagger.io。
在基于k8s做应用开发的时候,都是使用admin来使用k8s,基本不用去关注授权的问题。但是,当我们将k8s作为PaaS平台的容器编排引擎,并引入多租户时,就涉及到权限管理相关的问题了,paas平台的安全都是基于k8s的安全机制来实现的。
Docker实质上是汇集了linux容器(各种namespaces)、cgroups以及“叠加”类文件系统(changeroot)等多种核心技术的一种复合技术。
Kubernetes中有三种网络和三种IP。
docker是一种虚拟化的技术,相对于虚拟机更加轻量级。
PaaS就是一个为应用提供自动化研发,部署,调度,运维的管理平台。
很多的集群管理项目(比如 Yarn、Mesos,以及 Swarm)所擅长的,都是把一个容器,按照某种规则,放置在某个最佳节点上运行起来。这种功能,我们称为“调度”。
Kubernetes 项目所擅长的,是按照用户的意愿和整个系统的规则,使用声明式api,完全自动化地处理好容器之间的各种关系。这种功能,就是我们经常听到的一个概念:编排。
所以说,Kubernetes 项目的本质,是为用户提供一个具有普遍意义的容器编排工具。
Jenkins是一款开源 CI&CD 软件,用于自动化各种任务,包括构建、测试和部署软件,Jenkins 支持各种运行方式,可通过系统包、Docker 或者通过一个独立的 Java 程序。
Harbor是由VMware公司开源的企业级的Docker Registry管理项目,它包括权限管理(RBAC)、LDAP、日志审核、管理界面、自我注册、镜像复制和中文支持等功能。harbor项目是由VMware中国研发的团队负责开发,所以对国内非常友好。
etcd operator管理部署到Kubernetes的 etcd集群,并自动执行与操作etcd集群相关的任务(创建,销毁,调整,故障转移,滚动升级,备份还原)。
k8s有很多的插件是必须的,我们下面来看看一些重要的组件。
Operator 是指一类基于 Kubernetes 自定义资源对象(CRD)和控制器(Controller)的云原生拓展服务,其中 CRD 定义了每个 operator 所创建和管理的自定义资源对象,Controller 则包含了管理这些对象所相关的运维逻辑代码。
其实operator和控制器是差不多,只不过operator是针对特定应用程序的控制器,比如数据库etcd,需要结合很多etcd的专业部署运维知识做逻辑处理。
kubernetes是一种容器管理开源项目,用于管理容器化的工作负载和服务,可促进声明式配置和自动化,支持容器自身的不足。
Helm 是 Deis (https://deis.com/) 开发的一个用于 kubernetes 的包管理器。每个包称为一个 Chart,一个 Chart 是一个目录(一般情况下会将目录进行打包压缩,形成 name-version.tgz 格式的单一文件,方便传输和存储),可以将 Helm 看作 Kubernetes 下的 apt-get/yum。
应用程序升级面临最大挑战是新旧业务切换,将软件从测试的最后阶段带到生产环境,同时要保证系统不间断提供服务。长期以来,业务升级渐渐形成了几个发布策略:蓝绿发布、金丝雀发布和滚动发布等灰度发布策略,目的是尽可能避免因发布导致的流量丢失或服务不可用问题。
记录rpm的打包过程
开发相关事项。
Rancher是一个开源的企业级容器管理平台,Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。