Kubernetes系统基础

　　　　　　　　　　　　　　　Kubernetes系统基础

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　作者：尹正杰

版权声明：原创作品，谢绝转载！否则将追究法律责任。

 

 

 

一.容器编排系统概述

1>.容器编排系统生态圈

　　Docker通过“镜像”机制极富创造性地解决了应用程序打包的根本性难题，它推动了容器技术的快速普及生产落地。
　　
　　容器本身仅提供了托管运行应用的底层逻辑，而容器编排（Orchestration）才是真正产生价值的所在。

　　我们知道在云计算时代，主机编排系统开源的佼佼者自然是OpenStack，比较优秀的容器编排系统有：
　　　　（1）Docker 容器编编排系统三剑客：docker-compose，docker-swam（cluster），docker-machine
　　　　（2）Apache开源的Mesos和YARN
　　　　（3）出身名门的（Google）的Kubernetes，借鉴于Google内部Borg和Omega两个非开源容器编排系统（据说在Google内部已经运行10年之久）运维经验，Google使用Golang编写了K8s。
　　
　　后者Kubernetes的出现对Docker容器编排系统无疑是降维打击，在2017年底左右，Kubernetes几乎完胜Docker自身编排容器。以至于K8s已经成为容器编排的代名词。

　　Kubernetes的出现对OpenStack无疑也是一种降维打击，据说京东就用Kubernetes集群替换掉了OpenStack集群。现在很多云服务的商家已经支持K8s一件式部署了，比如亚马逊，微软，阿里等。

　　所以说你现在还在学习OpenStack无意是落伍了，除非你确定你要去的这家公司正在使用OpenStack，否则我们就没有多大必要花费过多精力去学习它了。因为Kubernetes的出现几乎让OpenStack要凉凉了~

2>.容器编排系统特点 

　　容器编排是用来管理容器生命周期的组件，尤其是在大规模动态环境当中，比如目前来讲比较火热的微服务技术场景。我们一般而言要使用容器解决以下任务：
　　　　（1）提供并部署容器；
　　　　（2）管理容器的冗余及可用性；
　　　　（3）我们可以通过向上扩展容器的机制或者将容器分散到多个主机之上运行多个容器基于向外扩展的方式来完成系统扩展；
　　　　（4）容器运行在服务器之上，若随着业务的发展，当前运行的容器的服务器硬件要求不满足该容器的运行条件时，可以把该容器迁移到可以满足的硬件运行环境的物理机上，或者当运行容器的主机挂掉之后依旧可以在另外一个节点启动起来；
　　　　（5）可以将整个资源在多个容器之间完成合理分配；
　　　　（6）可以根据业务需求将运行容器的服务暴露到公网；
　　　　（7）容器之间的服务可以让各组件互相访问（服务发现逻辑）；
　　　　（8）监控容器及各个宿主的运行状态；
　　　　（9）配置应用程序并确保容器之间他们有关联关系；　　

　　简单来说，容器编排是指容器应用的自动布局，协同及管理，它主要负责完成以下具体任务：
　　　　（1）Service Discovery，即服务发现
　　　　（2）Load Balancing，即负载均衡
　　　　（3）Secrets/configuration/storage management,即配置和存储
　　　　（4）Health checks，即健康状态检查
　　　　（5）Auto-[scaling/restart/healing] of containers and nodes，即包含容器和节点自动的伸缩/重启/健康状态监测
　　　　（6）Zero-downtime delopys，即零宕机部署

　　以上这些功能恰恰使容器编排变得极其有用且强大的核心原因，容器编排可以解决上述问题自然也就解决了运维工作中的痛点。

3>.kubernetes集群架构

    如上图所示，相比大家不难看出kubernetes集群主要是中建两个核心组件：
　　　　（1）API,UI,CLI
　　　　　　　　用于发送请求给Kubernetes（K8S）集群。
　　　　（2）Kubernetes Master
　　　　　　　　用于处理客户端的发来的请求，根据需求调度后端节点运行任务。其内部核心组件分为：
　　　　　　　　　　　　1）API Server 
　　　　　　　　　　　　　　　　提供API服务的组件，是一个独立的守护进程，是Kubernetes集群的唯一入口（无论是客户端还是内部组件都必须通过它来访问）。它提供基于https和rpc协议来提供服务的。它用来处理客户端传来的JSON格式的请求数据而非HTML格式哟。它也是K8S集群唯一能操作etcd的组件。
　　　　　　　　　　　　2）Scheduler  
 　　　　　　　　　　　　　　　 用于调度的组件，比如客户端通过API Server提交了一个新增容器的请求，该请求保存在etcd中，etcd通过API Server通知Scheduler，Scheduler接收到通知后会在管理的资源中选择一个最佳运行的节点去创建容器，该指令依旧存放在etcd中（Scheduler不能直接访问etcd，而是通过API Server间接访问etcd）。
　　　　　　　　　　　　3）Controller manager
　　　　　　　　　　　　　　　　用于管理K8S集群的组件，确保我们所创建的容器能够按照期望的状态运行的核心组件（比如：监控集群的所有容器运行，当某个容器挂掉后它可以迅速在另一个节点启动），我们甚至可以说Controller manager是K8s的大脑。
　　　　　　　　　　　　4）etcd　　　　  
　　　　　　　　　　　　　　　　etcd只能被API Server直接访问。是整个集群的核心，负责存储K8S请求数据所有的数据。etcd基于raft协议使用Golang语言开发的分布式强一致的键值对（key/value）数据库存储系统。存储方式和redis很像，但是功能却比redis要强大，因为它支持数据的强一致性，也支持leader选举等各种分布式协同功能。
　　　　（3）Node
　　　　　　　　被Kubernetes调度的，即负责真正干活的节点（运行容器）。其内部核心组件分为：
　　　　　　　　　　　　1）kubelet

　　　　　　　　　　　　2）容器
　　　　　　　　　　　　　　　　典型代表有Docker，其实kubernetes可远远不止支持Docker一种容器，它支持很多类型的容器，比如kubernetes有自己的容器引擎。不过迄今为止，我们不得不说Docker是容器的佼佼者，它也是容器的代名词。
　　　　　　　　　　　　3）kube-proxy
　　　　　　　　　　　　　　　　用于对外暴露相关规则，比如对外暴露外网映射之类的。　　　　　　　　　
　　　　　　　　　　　　4）Pod

　　　　　　　　　　　　5）
　　　　（4）Registry
　　　　　　　　存放镜像文件的仓库，并不直接被Kubernetes集群管理，即并不算k8s原生组成部分。

 

二.Kubernetes系统基础

 

转载于:https://www.cnblogs.com/yinzhengjie/p/10915293.html