1.什么是Kubernetes
Kubernetes 是一个跨主机集群的 开源的容器调度平台，它可以自动化应用容器的部署、扩展和操作 , 提供以容器为中心的基础架构。(官方文档第一行)
1.1 Kubernetes服务于微服务
每个微服务都是独立的进程，通过定义好的接口(restful api ,amqp)互相调用
微服务常见的问题
不同服务依赖库导致的混乱，需要将每个服务独立开(通过docker改善)
- 服务注册，服务发现：需要动态的更新当前服务。
- 服务编排(即docker容器的编排，docker自身很难解决集群部署的问题)：哪些服务需要在哪些宿主机上启动
二 Kubernetes的主要组成
2.1 Master
k8s集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。
- Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；
- Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；
- Kubernetes Schedule是负责资源调度（Pod调度）的进程。
2.2 Node
Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy.
每个Node节点都运行着以下一组关键进程
- kubelet：负责对Pod对于的容器的创建、启停等任务，同时与Master节点协作，实现集群管理的基本功能；
- kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件；
- Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作。
Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，并实现高效均衡的资源调度策略。
2.3 Pod
运行于Node节点上，若干相关容器的组合。Pod内包含的容器运行在同一宿主机上，使用相同的网络命名空间、IP地址和端口，能够通过localhost进行通信。Pod是Kurbernetes进行创建、调度和管理的最小单位，它提供了比容器更高层次的抽象，使得部署和管理更加灵活。一个Pod可以包含一个容器或者多个相关容器。
Pod有两种类型：普通Pod和静态Pod。后者比较特殊，它并不存在Kubernetes的etcd存储中，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动。普通Pod一旦被创建，就会被放入etcd存储中，随后会被Kubernetes Master调度到摸个具体的Node上进行绑定，随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动起来，在默认情况下，当Pod里的某个容器停止时，Kubernetes会自动检测到这个问题并且重启这个Pod（重启Pod里的所有容器），如果Pod所在的Node宕机，则会将这个Node上的所有Pod重新调度到其他节点上。
2.4 Label（标签）
Kubernetes中的任意API对象都是通过Label进行标识，Label的实质是一系列的Key/Value键值对，其中key与value可自定义。Label可以附加到各种资源对象上，如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去。Label是Replication Controller和Service运行的基础，二者通过Label来进行关联Node上运行的Pod,可以通过Label Selector（标签选择器）查询和筛选资源对象。
一些常用的Label如下：
- 版本标签："release":"stable","release":"canary"......
- 环境标签："environment":"dev","environment":"qa","environment":"production"
- 架构标签："tier":"frontend","tier":"backend","tier":"middleware"
- 分区标签："partition":"customerA","partition":"customerB"
- 质量管控标签："track":"daily","track":"weekly"
Label相当于我们熟悉的标签，给某个资源对象定义一个Label就相当于给它大了一个标签，随后可以通过Label Selector（标签选择器）查询和筛选拥有某些Label的资源对象，Kubernetes通过这种方式实现了类似SQL的简单又通用的对象查询机制。
Label和Label Selector共同构成了Kubernetes系统中最核心的应用模型，是的被管理对象能够被精细的分组管理，同时实现了整个集群的高可用性。
Label场景：
- kube-Controller进程通过资源对象RC上定义Label Selector来筛选要监控的Pod副本的数量，从而实现副本数量始终符合预期设定的全自动控制流程
- kube-proxy进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service岛对应Pod的请求转发路由表，从而实现Service的智能负载均衡
- 通过对某些Node定义特定的Label，并且在Pod定义文件中使用Nodeselector这种标签调度策略，kuber-scheduler进程可以实现Pod”定向调度“的特性。
2.5 Replication Controller
Replication Controller用来管理Pod的副本，保证集群中存在指定数量的Pod副本。集群中副本的数量大于指定数量，则会停止指定数量之外的多余容器数量，反之，则会启动少于指定数量个数的容器，保证数量不变。Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。
定义RC包括如下几个部分：
- Pod期待的副本数（replicas）；
- 用于筛选目标Pod的Label Selector；
- 当Pod的副本数小于预期数量时，用于创建Pod的Pod模板（template）。
RC机制：
当定义了RC并提交至Kubernetes集群中之后，Master节点上的Controller Manager组件获悉，并同时巡检系统中当前存活的目标Pod，并确保目标Pod实例的数量刚好等于此RC的期望值，若存在过多的Pod副本在运行，系统会停止一些Pod，反之则自动创建一些Pod。
注意：删除RC并不会影响通过该RC已经创建的Pod。
提示：下一代RC，即Replica Sets与RC唯一的区别是RS支持基于集合的Label selector。
RC特性及场景：
- 通过定义RC实现Pod的创建过程及副本数量自动控制；
- RC里包括完整的Pod定义模板；
- RC通过Label Selector机制实现副本的自动控制；
- 通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容功能；
- 通过改变RC的Pod模板的镜像版本，可以实现Pod的滚动升级功能。
2.6 Deployment
Deployment在内部使用了RS来实现目的，Deployment相当于RC的一次升级，其最大的特色为可以随时获知当前Pod的部署进度。
Deployment场景：
- 创建一个Deployment对象来生成对应的RS并完成Pod副本的创建过程；
- 检查Deployment的状态来看部署动作是否完成（即副本数量是否达到预期值）；
- 更新Deployment以创建新的Pod（比如镜像升级）；
- 如果当前Deployment不稳定，则回滚到一个早先Deployment版本；
- 挂起或恢复一个Deployment。
2.7 HPA（Horizontal Pod Autoscaler）
Pod的横向自动扩容，也是Kubernetes的一种资源，通过追踪分析RC控制的所有Pod目标的负载变化情况，来确定是否需要针对性的调整Pod副本数量。
HPA针对Pod负载的两种度量方式：
- CPUUtilizationPercentage；
- 应用程序自定义的度量指标。
2.8 Service
Service定义了Pod的逻辑集合和访问该集合的策略，是真实服务的抽象。Service提供了一个统一的服务访问入口以及服务代理和发现机制，关联多个相同Label的Pod，用户不需要了解后台Pod是如何运行。
外部系统访问Service的机制：
Kubernetes的三种IP：
- Node IP：Node节点的IP地址
- Pod IP： Pod的IP地址
- Cluster IP：Service的IP地址
首先,Node IP是Kubernetes集群中节点的物理网卡IP地址，所有属于这个网络的服务器之间都能通过这个网络直接通信。这也表明Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务的时候，必须通过Node IP进行通信；
其次，Pod IP是每个Pod的IP地址，他是Docker Engine根据docker0网桥的IP地址段进行分配的，通常是一个虚拟的二层网络；
最后Cluster IP是一个虚拟的IP，但更像是一个伪造的IP网络，Cluster IP特点：
- Cluster IP仅仅作用于Kubernetes Service这个对象，并由Kubernetes管理和分配P地址；
- Cluster IP无法被ping，他没有一个“实体网络对象”来响应；
- Cluster IP只能结合Service Port组成一个具体的通信端口，单独的Cluster IP不具备通信的基础，并且他们属于Kubernetes集群这样一个封闭的空间。
- Kubernetes集群之内，Node IP网、Pod IP网与Cluster IP网之间的通信，采用的是Kubernetes自己设计的一种区别于常规的IP路由的编程方式的特殊路由规则。
2.9 Volume（存储卷）
Volume是Pod中能够被多个容器访问的共享目录，Kubernetes中的Volume是定义在Pod上，可以被一个或多个Pod中的容器挂载到某个目录下。Kubernetes中的Volume与Pod的生命周期相同，与容器的生命周期并无直接关系。Kubernetes的Volume支持多种类型的后端驱动，如glusterfs、ceph。
Volume常见类型：
- emptyDir：为Pod分配到Node的时候创建。无需指定宿主机的目录文件，为Kubernetes自动分配的目录。
场景：
临时空间，用于某些应用程序运行时所需的临时目录，且无须永久保存；
长时间任务的中间过程CheckPoint的临时保存目录；
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。
- hostPath：为在Pod上挂载宿主机上的文件或目录。
场景：
容器应用程序生产的日志文件需要永久保存，可以使用宿主机的高速文件系统进行存储；
需要访问宿主机的Docker内部数据结构的容器。可指定hostPath为/var/lib/docker，使容器内部应用直接访问Docker的文件系统；
提示：若不同Node上具有相同配置的Pod可能因为宿主机的目录结构不一致从而导致访问结构不一致。
- NFS：NFS网络文件系统；
- iSCSI：iSCSI存储设备；
- flocker；
- rbd：
- glusterfs。
2.10 Namespace（命名空间）
Namespace用于实现多租户的资源隔离，可将集群内部的资源对象分配到不同的Namespace中，形成逻辑上的不同项目、小组或用户组，便于不同的Namespace在共享使用整个集群的资源的同时还能被分别管理。
提示：Kubernetes集群在启动后，会创建一个名为“default”的Namespace，且默认情况下Kubernetes的相关资源，如Pod、RC、Service都将被系统创建到此默认名为default的Namespace中。
2.11 Annotation（注释）
Annotation类似Label，也使用key/value形式进行定义。Annotation是用户任意定义的“附加信息”，如电话号码、负责人、网站等
原文地址：https://www.cnblogs.com/zyxnhr/p/12169141.html