引言
随着2013年docker的发布,服务的部署方式开始逐渐向docker迁移。因为docker启动更快,资源利用率更高;并且也极其便利,业务人员只需要编写好dockerfile,就可以任意支持docker的环境中运行相应的程序。
但是大家都知道,我们并不是只有一个节点,我们也不是只有一个服务。因此,在docker产生之后的一些年里,诞生了很多种容器编排工具,其中最著名的也就是本文着重要讲的kubernetes了。
kubernetes, 一般简称为k8s,用8代替8个字符“kubernete”而成的缩写, 是由google开源的用于管理云平台中多个主机上的容器化的应用。这个项目源于google内部的borg系统,从项目的架构来看,和borg的论文如出一辙,感兴趣的可以去看一看。这篇文章会讲k8s的设计理念,k8s的主要组件,希望大家看了这篇文章,能对k8s有一个比较清晰的认识和了解。
k8s能做什么呢?
- autoscale 可以根据我们制定的规则,实现自动扩缩容,以满足业务的需要.
- 蓝绿部署 启动运行着新版应用的副本集的同时,旧版应用依旧提供服务,直到新的应用ready
- 管理有状态/无状态应用,管理cronjob等
- 自带服务发现
- 负载均衡
- 支持第三方插件
- ......
对,你所需要的,k8s基本都能做。那么,k8s有那些关键的东西呢?
k8s关键词
- master
- node
- pod
- Deployment
- Service
- label
- namespace
- ingress
- ......
如果我们使用k8s的话,应该会经常接触到这些概念,那么他们是什么呢?
master
k8s也是master-agent架构,master可以认为是k8s的运行中心。
master上运行着kube-apiserver、kube-scheduler、 kube-controller-manager、 etcd等核心组件。 apiserver是整个k8s的调度中心,通过暴露rest接口, 接受来自其他组件的请求并且与持久化存储(etcd)交互。kube-scheduler是调度进程,支持多种算法,为pod找到适合的node。controller-manager是主要的守护进程,管理着所有的control loop, 通过监听api-server,使各个类型的资源达到预期的状态。etcd提供k8s的数据存储服务,是一个强一致性(基于raft实现)的内存数据库系统,存储配置以及资源对象。node
node是k8s中运行我们应用程序的节点,
node上运行着kubelet、kube-proxy、container runtime engine等组件。kubelet就是agent,监听着apiserver的接口,管理需要在当前节点运行的pod。kube-proxy管理各个节点上的网络规则,实现了service的流量转发以及负载均衡。支持userspace(deprecated)、iptables以及ipvs(推荐使用)。container runtime提供了容器运行时的接口,支持多种容器实现,比如docker、rkt等。pod
pod是k8s可以创建和管理的最小单元。一个pod可以有多个容器。不具有持久化的特性。pod内的容器共享网络空间和存储,可以认为是一个逻辑主机。
service
service是一个抽象概念,定义了服务访问pod的策略。是持久化的资源。有ClusterIP、NodePort、NodePort、ExternalName等类型。
ingress
k8s对外暴露服务主要有两种方式:NotePort和LoadBalance。ingress只需要一个NodePort或者一个LB就可以满足所有service对外服务的需求。运行机制如图
Architecture
那么,现在来看看k8s的整体架构吧
当我们创建deployment的时候发生了什么?
- api-server存储deployment到etcd中
- deployment controller监听到新的deployment,创建replicaset
- replicaset controller监听到新的replicaset,创建对应的pod
- scheduler监听到新的pod,选择适合的node
- kubelet运行pod, pod初始化
这个过程比较复杂。k8s通过api去解耦各个组件和etcd的交互,是通过 list-watch实现的此功能。后面会根据对应的代码进行一一分解。
参考: