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为主。
