k8s是一个可移植的,可拓展的开源平台,用于管理容器化的工作负载或服务。可促进声明式配置和自动化。

容器的优势:

由于他们与基础架构分离,因此可以跨云和os运行
敏捷应用程序的创建和部署:与使用vm镜像相比,提高了容器创建的简便性和效率
可移植性

为什么需要K8s:

当你的容器down机时,我们需要手动去重启容器,但是当有大量的容器部署时,我们手动去重启容器,就会影响到系统的可用性,因此我们需要用一个工具或者服务来帮我们管理容器。K8s的一个作用就是帮助我们管理容器的生命周期,它还有其他延申的作用,包括扩展要求,故障转移,部署模式。它为用户提供了一个可弹性运行分布式系统的框架

我们为什么要用k8s它有什么优势:

自动装箱:建构于容器之上,基于资源依赖和其他约束自动完成容器部署,并且不影响其可用性,并通过调度机制混合关键性运行和非关键性应用,提高资源的利用率
自我修复:支持容器故障后自动重启,已经节点故障后重新调度容器,以及其他可用检点的健康状态检查,失败后关闭容器并且重新创建等自我修复机制。
水平扩展:支持通过命令和ui手动水平扩展,以及基于CPU等资源负载率的手动水平扩展
服务发现和负载均衡:k8s通过其附加组件kubedns为系统内置了服务发现功能,他会为每个service分配一个dns名称,并且集群内的客户端可以通过此名称发出请求,而Service则通过iptabels和ipvs提供负载均衡机制。
自动发布和回滚:K8s支持灰度更新应用程序和其配置信息,它会监控更新过程中的程序的状态,以确保他不会在同一时刻杀掉所有实例,而此过程中一旦发生故障就会立即产生回滚操作
密钥和配置管理:k8s的configmap实现了配置数据与docker解耦,需要时,仅需要对配置数据进行重新加载,不要对docker容器进行重构,极大的提高了开发的灵活性。此外对于应用程序的敏感数据,如密码等k8s提供了secre对象为其解耦。提高了安全保障
存储编排:k8s支持pod对象按需自动挂载不同的存储系统。
以上都是k8s能够提供的功能,我们可以看出k8s对于容器的管理是有很大的便利。能极大的提升容器的运行效率和解决容器运行时的各种可能的故障,它都提供了解决方案。所以k8s是一个非常不错的容器管理工具。

K8s的组件:

当你部署完k8s你就拥有一个完整的集群。

一个kubernets集群至少有一组被称作工作节点的机器组成,这些工作节点上运行k8s所管理的容器化应用。一个k8s集群至少有一个工作节点。
工作节点托管作为应用负载的组件的pod,控制平面,管理集群中的工作节点和pod,为集群提供故障转移和高可用性,控制平面跨多个主机运行,集群跨多个工作节点运行。

Master:集群中的一台服务器用作Master节点,负责管理整个集群,它是集群的网关也是中枢,它是用户或客户端与集群的核心联络点,它的功能有:为用户和客户端暴露api,负责检查其他服务器的健康状态,以最优的方式调度工作负载,以及编排其他组件之间的通信任务。并负载k8s上的大多数集中管控逻辑,单个master既可以完成所有的任务,但是为了提高可用性,以及冗余和负载均衡,一般都会部署多个主机。
Node:node是k8s的工作节点,接受来自master的指令,负责创建和销毁pod对象,以及调优网络规则以合理的路由和转发流量。理论上来说node可以是任何形式的计算设备,不过master对将它抽象为node对象来管理。

k8s会将所有的node对象集结于一处,作为一台强大性能的服务器。在用户将应用部署与master上时,master会采用调度算法将其自动指派到某个node上,在node加入或者移除集群时,master会自动将影响到的容器进行重新编排,用户无需关心容器运行在何处。

用户是在master节点上创建容器,但是master只接受请求,会将具体的任务指派到相应的node中。对于用户来说,这些操作都是透明的。实际上为用户提供服务的是整个k8s集群。在实际的生产中,我们将k8s集群构建到服务器上。只需要将指定的应用提交到集群中我们就可以使用此应用提供的功能。

image.png

控制平面组件:

控制平面组件可以在集群中的任一节点中运行,但是为了简单起见,通常会在单独的一台机器上部署所有控制平面组件,并且不会在此节点运行容器。

apiserver:是整个集群的网关,负责输出restful风格的k8sApi,它是发往集群所有rest请求的接入点。并负责接受,校验和响应所有的Rest请求,结果状态被持久保存到etcd中。
etcd:k8s集群的所有状态信息都将被持久保存到etcd中,etcd是由coreos基于Raft协议开发的分布式键值存储,可用于服务发现,共享配置和一致性保障,如数据库的主节点选择。它是独立的组件,不隶属于k8s集群本身,它不仅能提供键值对存储,还提供了监听机制,k8s集群中,etcd中的键值发生变化会通知apiserver
kube-controller-manager:k8s中集群级别的功能大多数由几个被称为控制器的进程执行实现的,这几个进程被集成到kube-controller-manager中,由控制器完成的功能大概包括生命周期和api业务逻辑。
kube-schedule:apiserver确定了pod对象的创建请求之后,便需要由schedule根据集群中个节点的资源状态,以及需要运行的容器的资源需求做出调度决策。

Node组件:

kubelet:kubelet是工作节点上的一个守护进程,它从Apiserver接受关于pod对象的信息,并确保他们处于期望的状态,kubblet会在apiserver上注册当前的工作节点,定期向master汇报资源的使用情况
kubeproxy:每个工作都需要运行一个kubeproxy守护进程,它能按需为service资源对象生成iptables和ipvs规则,从而捕获当前service的流量,并将其转发到后端的pod对象中
容器运行时的环境:每个node必须提供容器运行的环境,它负责下载镜像和运行容器。k8s支持多个容器运行时的环境。


重要组件:

COREDNS:可以为集群中的SVC创建一个域名IP的对应关系解析。
DASHBORD:是一个B/S结构的访问体系。提供web界面
INGRESS CONTROLER:官方只能提供四层负载均衡,ingress可以提供七层负载均衡
fedetation:提供一个可以跨集群中心多K8S统一管理
PROMETHEUS:提供一个K8S集群的监控能力
ELK:提供K8S集群日志统一分析接入平台。

k8s的网络模型:

一个k8s集群至少包含3个网络。
一个是主机自身所属的网络,其地址配置于主机的网络接口,用于各个主机间进行通信,例如master和Node节点的通信,这个网络不属于k8s所管理,它构建与集群构建之前。
一个是k8s集群中专门用于pod资源对象的网络,它是一个虚拟网络,用于为各pod对象设立ip地址等网络参数,其地址配置于pod对象的网络接口上,pod网络需要借助kubenet插件或者cni插件实现该插件可以独立部署在k8s之外,也可以布置在k8s集群中,他需要在构建k8s集群时,由系统管理员进行定义,而后在创建pod对象时由其自动完成各项网络参数的动态配置。
一个是专用于service资源对象的网络,用于为k8s集群中的service配置网络,但次地址不配置于任何主机或者容器的接口上,而是通过Node上的kube-proxy配置为iptables和ipvs规则,从而将发往此地址的所有流量调度到后端的pod对象之上,service网络在k8s集群创建时指定,而service地址则在用户创建service时予以动态配置。
image.png

CNI网络插件:k8s中pod之间的通信,pod和外界的通信,k8s并没有过多涉及,而是需要我们使用cni网络插件来进行pod间的通信以及pod和外界的通信。

Restful风格的接口:就是用于web访问时,url的一种格式。客户端和服务端交互的一种接口格式。

Raft协议:是一种分布式一致性协议。
原理:一个节点有三种状态,follower,condidate,leader。
分布式一致性,是指各服务器节点是分开的,但是他们所收到的内容全是同步更新的。总的方法就是选举一个leader,修改的信息发送给leader,leader会将此信息传递给后面的服务器,当所有服务器都修改之后会返回一个成功的状态给leader,leader收到消息后,最后将值也修改,再返回一个成功的状态给外部,来宣告我已经成功将值给更改了。

Pod是什么:
知道为什么一个Pod中的容器总是配置成一起工作么?因为这是嵌套的容器
容器是依托于Linux的namespace和cgroup这两个特性而运行的正常的系统进程。需要指出的是namespace和cgroup是分开的特性,可以只使用namespace中的几种隔离,也可以只使用cgroup的资源隔离。用户可以在单独的namespace空间中运行几个进程,这些进程可以相互通信,也可以在cgroup中创建一组进程,这些进程的资源受到限制。
使用dcoker创建容器时,docker会为每个进程创建namespace和cgroup
此时。我们运行一个nginx容器也将ghost这个服务运行在nginx的namespace下

Pod是一种容器

我们已经看到可以将命名空间和cgroup和多个线程结合起来,而这就是pods的本质。pods让你指定想要运行的容器,而k8s自动的构建相应的namesapce和cgroup。这样的好处是,可以将运行的容器抽象成一个api,供其他进程去调用。
http://www.dockerone.com/article/2682 //Pod的解释

多个程序运行在一个容器.png