k8s-组件简介

前言

下文我将会介绍各种组件 .

Label 标签

打标的好处肯定就是鉴别出来 , Label 在 k8s 中的用处主要有几个 :

kube-controller 进程(Master 机器上)通过资源对象RC 上定义的Label Selector 来筛选要监控的Pod 副本的数量，从而实现Pod 副本的数量始终符合预期设定的全自动控制流程。
kube-proxy 进程(各个Node 节点上)通过Service 的Label Selector 来选择对应的Pod ，自动建立起每个Service到对应Pod 的请求转发路由表，从而实现Service 的智能负载均衡机制。
通过对某些Node 定义特定的Label.并且在Pod 定义文件中使用NodeSelector 这种标签调度策略， kube咽heduler 进程可以实现Pod "定向调度"的特性。

Replication Controller (RC)

Replication Controller(RC) 也是一个虚拟概念.
当我们定义了一个RC 并提交到Kubemetes 集群中以后， Master 节点上的Control1er Manager组件就得到通知，定期巡检系统中当前存活的目标Pod，并确保日标Pod 实例的数量刚好等于此RC 的期望值，如果有过多的Pod 副本在运行，系统就会停掉一些Pod，否则系统就会再自动创建一些Pod。可以说，通过RC ， Kubemetes 实现了用户应用集群的高可用性，并且大大减少了系统管理员在传统IT 环境中需要完成的许多手主运维工作(如主机监控脚本、应用监控脚本等)

Replication Controller (RC) 和 Replica Set

由于Replication Controller 与Kubemetes 代码中的模块Replication Controller 同名，同时这个词也无法准确表达它的本意，所以在Kubemetes 1.2 的时候，它就升级成了另外→个新的概念一--Replica Set，官方解释为"下一代的RC".

它与RC 当前存在的唯一区别是: Replica Sets支持基于集合的Label selector (Set-based selector) ，而RC 只支持基于等式的Label Selector (equality-based selector) ，这使得Replica Set 的功能更强.

Replica Set 的使用

此外，当前我们很少单独使用Replica Set ，它主要被Deployment 这个更高层的资源对象所使用，从而形成一整套Pod 创建、删除、更新的编排机制。当我们使用Deployment 时，无须关心它是如何创建和维护Replica Set 的，这一切都是自动发生的。Replica Set 与Deployment 这两个重要资源对象逐步替换了之前的RC 的作用，是Kubemetes 1.3里Pod 自动扩容(伸缩)这个告警功能实现的基础.

Deployment

Deployment 就是一个 部署过程 的抽象过程, 例如我要部署一整套系统 , 或是升级整套系统, 我不会使用 kind : pod这样的 yaml 文件来执行完成我的部署 ,而是使用一个更高层次的 Deployment .

k8s 中不仅把一些逻辑的概念进行抽象, 还会把平时一系列的动作(例如一个部署过程, 一个容器扩展收缩等)进行抽象 , 这才是它的厉害的地方

Deployment 使用场景

Deployment 的典型使用场景有以下几个。

创建一个Deployment 对象来生成对应的Replica Set 并完成Pod 副本的创建过程。
检查Deployment 的状态来看部署动作是否完成CPod 副本的数量是否达到预期的值)。
更新Deplo严nent 以创建新的Pod C 比如镜像升级)。
如果当前Deployment 不稳言，则回宿到一个早先的Deployment 版本。

Service (服务)

Service 概述

Service 的位置在哪里 , 又是如何提供服务的
Service 也是Kubemetes 里的最核心的资源对象之一， Kubemetes 里的每个Service 其实就是我们经常提起的微服务架构中的一个"微服务"，之前我们所说的Pod、RC 等资源对象其实都是为这节所说的"服务"一-Kubemetes Service 做"嫁衣"的。图1.1 4 显示了Pod、RC 与Service的逻辑关系。

从图1.1 4 中我们看到， Kubemetes 的Service 定义了一个服务的访问入口地址，前端的应用(Pod) 通过这个入口地址访问其背后的一组由Pod 副本组成的集群实例， Service 与其后端Pod副本集群之间则是通过Label Selector 来实现"无缝对接"的。而RC 的作用实际上是保证Service的服务能力和服务质量始终处于预期的标准。

请求如何在 Service 中找到Pod的

既然每个Pod 都会被分配一个单独的IP 地址，而且每个Pod 都提供了一个独立的Endpoint(Pod IP+ContainerPort) 以被客户端访问，现在多个Pod 副本组成了一个集群来提供服务，那么客户端如何来访问它们呢?

反向代理

反向代理是不是让你想起了 nginx , 没错 ,k8s 中 Service 分发流量到各个 Pod 也是使用反向代理 , 对外提供一个 IP ,然后把流量都接下来 ,再分到各个 Pod .Pod 对外提供的接口叫 Endpoint, 那么还有个问题, 类似于注册中心 (zookeeper, nacos) , 多个 Pod 的 Endpoint 的信息肯定需要上报到某个地方, 方便后续 Service 流量 .

是的, 这个地方就是 ETCD , 然后 kube-proxy 通过 API Servce ,获取同步节点信息 ,再通过分发算法, 对请求进行分发 . 也就是说 Pod 的增加减少删除等都会上报给 API Servie !! 而其他对外提供服务的时候或是拓展容器数量, 收缩容器数量的时候是通过 API service 获取Pod 信息的

Service 服务发现机制

我们已经知道了每个 Service 拥有一个 Cluster IP + 名字 , 那么外界是如何找到这个 Service 的呢 ?
是通过 DNS 的方式

外部系统访问Service 的问题

我们先看关于 IP 相关的知识 ,见其它章节的关于三个IP 类型的描述 , 其中和 Service 有关的是 Cluster IP

图中就是实际部署中的 service 的类型 , 有 ClusterIP 也有 LoadBalancer .
那么外部是如何访问 Service 的呢 ?

Node Port 方式

apiVersion: vl
kind: Service
metadata:
    name: tomcat-service
spec:
    type: NodePort
    ports:
        - port: 8080
    nodePort: 31002
selector:
    tier: fronte

NodePort 的实现方式是在Kubemetes 集群里的每个Node 上为需要外部访问的Service 开启一个对应的TCP 监昕端口，外部系统只要用任意一个Node 的IP 地址+具体的NodePort 端口号即可访问此服务，在任意Node 上运行netstat 命令，我们就可以看到有NodePort 端口被监昕:

 netstat -tlp | grep 31002

这种方式就像我们某个机器开个端口和ip一样 ,实际的部署环境肯定不是这样. 例如我们需要做负载均衡等等.

LoadBalancer

Load ba1ancer 组件独立于Kubemetes 集群之外，通常是一个硬件的负载均衡器，或者是以软件方式实现的，例如HAProxy 或者Nginx。 对于每个Service ，我们通常需要配置一个对应的Load balancer 实例来转发流量到后端的Node 上，这的确增加了工作量及出错的概率。

Volume (存储卷)

我们学习Docker 的时候都知道 Volume 通过挂载的方式挂载到容器内部 ,在 k8s 中是不是一样的东西呢?

Volume 是Pod 中能够被多个容器访问的共享目录。Kubemetes 的Volume 概念、用途和目的与Docker 的Volume 比较类似，但两者不能等价。

Volume在K8S和Volume在容器中的区别

Kubemetes 中的Volume 定义在Pod上，然后被一个Pod 里的多个容器挂载到具体的文件目录下
其次， Kubemetes 中的Volume 与Pod 的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时， Volume 中的数据也不会丢失。
Kubemetes 支持多种类型的Volume ，例如GlusterES 、Ceph 等先进的分布式文件系统。

Kubemetes 的 Volume 类型

这块先略过 , 展开说太多了, 后续篇幅再展开

Namespace (命名空间)

Namespace (命名空间)是Kubemetes 系统中的另一个非常重要的概念， Namespace 在很多情况下用于实现多租户的资源隔离。Namespace 通过将集群内部的资源对象"分配"到不同的Namespace 中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

举一个现实一点的例子 , 例如我是一个云服务商, 对外为众多软件应用商提供服务 , 我只提供基础服务 ,例如同时为 A , B 提供服务 . A , B 分别位于不同的 Namespace (命名空间) 内 NA , NB , NA 享有 2核CPU 500MB内存 , 而 NB 享有 4核CPU 2GB内存, (PS : 这不就是阿里云的玩法吗?!)

我们学习容器docker 的时候就知道了 docker 容器的底层技术是 cgroup + nameSpace ,那么k8s又是如何做的呢? 交给后面的学习哇

Annotation (注解)

Annotation 与Label 类似，也使用key/value 键值对的形式进行定义。不同的是Label 具有严格的命名规则，它定义的是Kubemetes 对象的元数据( Metadata) ，并且用于Label Selector 。而Annotation 则是用户任意定义的"附加"信息，以便于外部工具进行查找，很多时候， Kubemetes的模块自身会通过Annotation 的方式标记资源对象的一些特殊信息。

(有点像变量)

通常来说，用Annotation 来记录的信息如下。

build 信息、release 信息、Docker 镜像信息等，例如时间戳、release id 号、PR 号、镜像hash 值、docker registry 地址等。
日志库、监控库、分析库等资源库的地址信息。
程序调试工具信息，例如工具名称、版本号等。
团队的联系信息，例如电话号码、负责人名称、网址等。

其他

k8s 中的IP

Node IP: Node 节点的IP 地址。
PodlP: Pod 的IP 地址。
Cluster IP: Service 的IP 地址。

Node IP

Node IP 是Kubemetes 集群中每个节点的物理网卡的IP 地址，这是一个真实存在的物理网络，所有属于这个网络的服务器之间都能通过这个网络直接通信，不管它们中是否有部分节点不属于这个Kubemetes 集群。这也表明了Kubemetes 集群之外的节点访问Kubemetes 集群之内的某个节点或者TCP/IP 服务的时候，必须要通过Node IP 进行通信。

PodlP

Pod IP 是每个Pod 的IP 地址，它是Docker Engine 根据dockerO 网桥的IP 地址段进行分配的，通常是一个虚拟的二层网络，前面我们说过， Kubemetes 要求位于不同Node 上的Pod 能够彼此直接通信，所以Kubemetes 里一个Pod 里的容器访问另外一个Pod 里的容器，就是通过PodlP 所在的虚拟二层网络进行通信的，而真实的TCP几P 流量则是通过Node IP 所在的物理网卡流出的。

Cluster IP

我们说说Service 的Cluster IP ，它也是一个虚拟的IP ，但更像是一个"伪造"的IP网络，原因有以下几点。

Cluster IP 仅仅作用于Kubemetes Service 这个对象，并由Kubemetes 管理和分配IP 地址(来源于Cluster IP 地址池)。
Cluster IP 无法被Ping ，因为没有一个"实体网络对象"来响应。
Cluster IP 只能结合Service Port 组成一个具体的通信端口，单独的Cluster IP 不具备TCP/IP 通信的基础，并且它们属于Kubemetes 集群这样一个封闭的空间，集群之外的节点如果要访问这个通信端口，则需要做一些额外的工作。

在Kubemetes 集群之内， Node IP 网、Pod IP 网与Cluster IP 网之间的通信，采用的是Kubemetes 自己设计的一种编程方式的特殊的路由规则，与我们所熟知的IP 路由有很大的不同。Service 的Cluster IP 属于Kubemetes 集群内部的地址，无法在集群外部直接使用这个地址。

想法1

k8s 对两方面进行抽象 :

过程抽象 : Deployment , ReplicaSet
逻辑抽象 : Pod , Service
资源抽象 : Node

想法2

一组资源 ,比如 CPU 资源和内存资料称之为 Node , Pod(容器组) 更像是微服务中的节点 , 例如系统提供售票服务 ,分别有售1节点 , 售2节点, 售3节点, 各节点地址低位一致 .

想法3

pod : 组合不同的容器镜像
deployment(部署的抽象) : 组合不同的 pod , 当然也可以是相同的 pod , 看部署需求

想法4

现在看阿里的控制台, 并没有以service 分类 , 而是以 deployment 分类 , Pod(容器组分类) 等等, 而不是以 Service 去分类, Service 相关只涉及网络相关的 , 下面的图, 工作负载 并没有 Service , Service 被放在 网络 菜单下

Service <======> 网络

总结

一个集群提供的多种服务 , k8s 不断地从顶层到底层都进行了抽象, 文章介绍了k8s中几个重要的组件 .

参考资料

<<Kubernetes权威指南>>

前言