kubernetes基本框架和基本概念

阅读更多

作者：翼动晴空

链接：https://www.jianshu.com/p/0a656b3d94b2
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。

kubernetes基本框架和基本概念

• Kubernetes是什么？我(们)为什么使用？
• Kubernetes主要概念
• Kubernetes总体结构
• Kubernetes核心原理
• Kubernetes网络模型

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

Kubernetes是Google(基于borg)开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用，其主要功能如下：

1. 使用Docker对应用程序包装(package)、实例化(instantiate)、运行(run)。

2. 以集群的方式运行、管理跨机器的容器。

3. 解决Docker跨机器容器之间的通讯问题。

4. Kubernetes的自我修复机制使得容器集群总是运行在用户期望的状态。

为什么使用？

1. 开发人员各司其职，轻装上阵（架构师负责服务组件提炼，开发工程师负责业务代码的开发，运维或系统公司师负责部署与运维）
2. 全面拥抱微服务框架
3. 使用Kubernetes我们系统可以随时的整体迁移
4. 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为主。