kubernetes基本框架和基本概念

kubernetes基本框架和基本概念

Kubernetes是什么？我(们)为什么使用？

Kubernetes主要概念
Kubernetes总体结构
Kubernetes核心原理
Kubernetes网络模型

Kubernetes是什么？我(们)为什么使用？

Kubernetes是Google(基于borg)开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用，其主要功能如下：
使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。
以集群的方式运行、管理跨机器的容器。
解决Docker跨机器容器之间的通讯问题。
Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

为什么使用？

开发人员各司其职，轻装上阵（架构师负责服务组件提炼，开发工程师负责业务代码的开发，运维或系统公司师负责部署与运维）
全面拥抱微服务框架
使用Kubernetes我们系统可以随时的整体迁移
Kubernetes系统具备了超强的横向扩容能力

Kubernetes概念

Master: 集群控制节点，master节点上运行着一组关键的进程
Kubernetes API Server(kube-apiserver), 提供 HTTP Rest 接口的关键服务程序，kubernets里所有资源增、删、改、查等操作的唯一入口，也是集群控制的入口进程
Kubernetes Controller Manager(kube-controller-manager)，所有资源对象的自动化控制中心（资源对象的大总管）
Kubernetes Scheduler(kube-scheduler)，资源调度(pod)的进程（调度室）
etcd Server，Kubernetes 里所有资源对象的数据全部是保持在etcd中

Node： Node是与Master而言的工作主机，可以使物理主机、VM等，运行Kubelet、kube-proxy和docker Engine

kubelet: pod对应容器的创建、暂停等任务
kube-proxy: k8s service 的通信与负载均衡机制的重要组件
Docker Engine dokcer 引擎，本机容器的创建与管理

Pods：最小部署单元，可包含多个容器，是连接在一起的容器组合并共享文件卷。它们是最小的部署单元，由 Kubernetes 统一创建、调度、管理。Pods是可以直接创建的，但推荐的做法是使用 Replication Controller，即使是创建一个 Pod。

Labels： Label以key/value形式附加到Pos、Service、RC、Node等上面，每个对象可以定义多个label，以提供Label Selector来选择对象， Label Selector有两种形式：

基于等式，name=redis-slave选择k/v都相等的，env!=production选择k=env但是v!=production的
基于集合，name [not] in (redis-master,redis-slave)，类似于SQL中in

Replication controllers： 管理 Pods 的生命周期。它们确保指定数量的 Pods 会一直运行，还有实现资源伸缩。

定义RC实现Pod的创建与副本数量的自动控制
RC 通过Lable Selector机制实现对副本的自动控制
通过改变RC的Pod副本数量，实现Pod的扩容或缩容
通过改变RC里Pod模板中的镜像版本，实现Pod的滚动更新

Deployment: 1.2引入，为了更好地解决pod的编排问题，内部使用了Replica Set 实现；它相对于RC的最大的升级是可以随时知道当前Pod部署的进度

Horizontal Pod Autocaler(HPA): Pod横向自动扩容，通过追踪分析RC控制的所有目标Pod的负载变化情况，确定是否需要针对性地调整目标Pod的副本数

Services：抽象服务出口。它就像一个基础版本的负载均衡器。

Volume ：Pod中能够被多个容器访问的共享目录，其生命周期与Pod相同跟容器无关。

EmptyDir，Pod分配到Node时创建的，初始内容为空，Pod从Node中移除时EmptyDir数据永久删除。主要用于临时空间、CheckPoint临时保存目录等
hostPath，在Pod上挂载宿主机上的文件或目录，主要用于需要永久保存的
gcePersistentDisk,使用谷歌计算引擎上永久磁盘上的文件，写入数据永久保存。
awsElasticBlockStore，使用Amazon提供的EBS Volume
nfs，使用NFS(网络文件系统)提供的共享目录
iscsi，使用iSCSI设备
glusterfs，使用开源GlusterFS网络文件系统
rbd，使用Linux块设备共享存储
gitRepo，通过挂载一个空目录，从Git库clone一个> - git repository给Pod使用
secret，一个secret volume用于为Pod提供加密的信息
persistent Volume, "网络存储"，独立于“计算资源”而存在的实体资源，可以看做一个与Kubernetes无关的网盘
Annotation：与Lable类似，也使用key/value 键值对的形式定义，不同于Lable定义Kubernetes的元数据，它是用户任意定义的附加信息，以便于外部工具进行查找

Kubernetes总体结构

Master组件：

ApiServer：作为kubernetes系统的入口，封装了核心对象的增删改查操作。
Scheduler：插件式的调度器，负责集群的资源调度，为新建的pod分配机器。
Controller：负责管理各种控制器。如- - ReplicationController，
EndPointController等。

Node组件：

kubelet：负责管控docker容器，如启动/停止、监控运行状态等。
proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。

公共组件：

Etcd
flannel

Kubernetes核心原理

API Server

提供集群管理的API接口；

api-server进程提供http(8080)/https(6443)两个端口供访问；

成为集群内各个功能模块之间数据交互和通信的中心枢纽；�      集群内部功能模块通过API Server将信息存入etcd，其他模块通过API �        Server（用get、list或watch）读取这些信息，实现模块之间的信息交互。

拥有完备的集群安全机制。

Controller Manager

Replication Controller

确保在任何时候集群中一个rc下的pod都保持一定数量的pod副本处于正常运行状态。
重新调度、弹性伸缩。
滚动更新（Rolling Updates）

Node Controller

负责发现、管理和监控集群中的各个Node节点。

ResourceQuota Controller

资源配额管理确保制定对象在任何时候都不会超量占用系统资源。
三个维度配额：容器（C/M）、Pod、namespace（pod、rc、service、resourceQuota、Secret、PV）

Endpoint Controller

定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。

Services Controller

监听Service的变化

Scheduler

负责Pod调度
通过调度算法为待调度Pod列表的每个Pod从   Node列表中选择一个最合适的Node

预选策略：

NoDiskConflict
PodFitsResources
PodSelectorMatches
PodFitsHost
CheckNodeLabel…

Kubelet

负责本Node节点上的Pod的创建、修改、监控、删除等，同时定时同步本Node的状态信息到API Server

kube-Proxy

实现Service的代理及软件模式的负载均衡器
Kubernetes网络模型

容器到容器通信，共享网络空间；

同Node上pod间通信，通过docker0网桥；
不同Node上pod间通信？

隧道方案

通过隧道，或者说Overlay Networking的方式：

Weave，UDP广播，本机建立新的BR，通过PCAP互通。

Open vSwitch（OVS），基于VxLAN和GRE协议，但是性能方面损失比较严重。

Flannel，UDP广播，VxLan。

隧道方案在IaaS层的网络中应用也比较多，大家共识是随着节点规模的增长复杂度会提升，而且出了网络问题跟踪起来比较麻烦，大规模集群情况下这是需要考虑的一个点。

路由方案

还有另外一类方式是通过路由来实现，比较典型的代表有：

Calico，基于BGP协议的路由方案，支持很细致的ACL控制，对混合云亲和度比较高。

Macvlan，从逻辑和Kernel层来看隔离性和性能最优的方案，基于二层隔离，所以需要二层路由器支持，大多数云服务商不支持，所以混合云上比较难以实现。

路由方案一般是从3层或者2层实现隔离和跨主机容器互通的，出了问题也很容易排查。

Flannel方案

首先连上etcd，利用etcd管理可以分配的IP地址段资源，同事监控etcd中每个Pod的实际地址，并在内存中建立一个Pod节点路由表，然后下连docker0和物理网络，使用内存中的Pod节点路由表，将docker0发给它的数据包包装起来，利用物理网络连接将数据包投递到目标flanneld上。

Flannel之间的底层通信协议可选余地很多，有UDP、VxLan、AWS VPC等，只要能通到对端的Flannel就可以。源flanneld加包，目标flanneld解包，对于docker0是透明的。一般以UDP为主。

------本页内容已结束，喜欢请分享------

感谢您的来访，获取更多精彩文章请收藏本站。