Kubernetes架构和组件

‍

‍一、Kubernetes架构和组件

核心组件组成： kubectl: 客户端命令行工具，将接受的命令格式化后发送给kube-apiserver，作为整个系统的操作入口。 kube-apiserver: 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；这是kubernetes API，作为集群的统一入口，各组件协调者，以HTTPAPI提供接口服务，所有对象资源的增删改查和监听操作都交给APIServer处理后再提交给Etcd存储。 kube-scheduler: 资源调度，按照预定的调度策略将Pod调度到相应的机器上；它负责节点资源管理，接受来自kube-apiserver创建Pods任务，并分配到某个节点。它会根据调度算法为新创建的Pod选择一个Node节点。 kube-controller-manager: 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；它用来执行整个系统中的后台任务，包括节点状态状况、Pod个数、Pods和Service的关联等, 一个资源对应一个控制器，而ControllerManager就是负责管理这些控制器的。 etcd: 集群的主数据库，保存了整个集群的状态; etcd负责节点间的服务发现和配置共享。etcd分布式键值存储系统, 用于保持集群状态，比如Pod、Service等对象信息。 kubelet: 负责维护容器的生命周期，负责管理pods和它们上面的容器，images镜像、volumes、etc。同时也负责Volume（CVI）和网络（CNI）的管理；kubelet运行在每个计算节点上，作为agent，接受分配该节点的Pods任务及管理容器，周期性获取容器状态，反馈给kube-apiserver; kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。kubelet将每个Pod转换成一组容器。 container runtime: 负责镜像管理以及Pod和容器的真正运行（CRI）； kube-proxy: 负责为Service提供cluster内部的服务发现和负载均衡；它运行在每个计算节点上，负责Pod网络代理。定时从etcd获取到service信息来做相应的策略。它在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。 docker或rocket(rkt): 运行容器。 其中: master组件包括: kube-apiserver, kube-controller-manager, kube-scheduler; Node组件包括: kubelet, kube-proxy, docker或rocket(rkt); 第三方服务：etcd

Master kubernetes集群的管理节点，负责管理集群，提供集群的资源数据访问入口。拥有Etcd存储服务（可选），运行Api Server进程，Controller Manager服务进程及Scheduler服务进程，关联工作节点Node。Kubernetes API server提供HTTP Rest接口的关键服务进程，是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程；Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度（Pod调度）的进程.

Node Node是Kubernetes集群架构中运行Pod的服务节点（亦叫agent或minion）。Node是Kubernetes集群操作的单元，用来承载被分配Pod的运行，是Pod运行的宿主机。关联Master管理节点，拥有名称和IP、系统资源信息。运行docker eninge服务，守护进程kunelet及负载均衡器kube-proxy. 每个Node节点都运行着以下一组关键进程: - kubelet：负责对Pod对于的容器的创建、启停等任务 - kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件 - Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作 Node节点可以在运行期间动态增加到Kubernetes集群中，默认情况下，kubelet会想master注册自己，这也是Kubernetes推荐的Node管理方式，kubelet进程会定时向Master汇报自身情报，如操作系统、Docker版本、CPU和内存，以及有哪些Pod在运行等等，这样Master可以获知每个Node节点的资源使用情况，冰实现高效均衡的资源调度策略。

二、基本概念

Namespace:

• 命名空间将对象逻辑上分配到不同Namespace，实现多租户

Pod

• 最小部署单元
• 容器组，一个Pod有一个或多个容器组成，Pod中容器共享存储和网络，进程间通信和文件共享; Pod 中的容器会作为一个整体被Master调度到一个Node上运行
• kubernetes的最核心功能就是为了运行pod，其他组件是为了pod能够正常运行而执行的
• 一个pod上有两类元数据，label 和 annotation label：标签，对数据类型和程度要求严格，键/值对，每个对象可以由多个标签，通过 annotation：注解，用于存储自己定义的复杂元数据，用来描述pod的属性

Volume 数据卷

• Pod中能够被多个容器访问的共享目录，定义在Pod之上，被一个Pod里的多个容器挂载到具体的文件目录之下
• Volume与Pod生命周期相
• 可以通过写到宿主机的磁盘上或者写文件到 网络存储实现持久化

Controller 管理Pod

• 管理 Pod，定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等
• 多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job
  • 一次性任务，运行完成后Pod销毁，不再重新启动新容器。还可以任务定时运行。Kubernetes中的Job 用于运行结束就删除的应用。
  • 每个 Node 最多只运行一个 Pod 副本
  • 有状态应用部署
  • 保证 Pod 名称和网络标识符不变的
  • 部署前先创建Headless Service
  • 每个Pod都有独立DNS域名，与hostname相同
  • 按顺序启动、逆序更新
  • 稳定的、唯一的网络标识符。
  • 稳定的、持久的存储。
  • 有序的、优雅的部署和缩放。
  • 有序的、自动的滚动更新。
  • 适用于无状态应用部署
  • 使用 Deployment 时会自动创建 ReplicaSet，通过 ReplicaSet 来管理 Pod 的多个副本
  • 可以滚动升级
  • 新一代RC，提供同样的高可用能力
  • 与RC比，RS还支持基于集合的selector（version in (v1, v2)）；一般不单独使用，跟更高级的Deployment一起使用
  • 管理Pod的副本，保证集群中存在指定数量的Pod副本
  • 实现弹性伸缩、动态扩容和滚动升级的核心
  • RC只支持基于等式的selector（env=dev或app=nginx）
  • Replication Controller (副本集RC)
  • Replica Set (副本集RS）
  • Deployment (部署)
  • StatefuleSet
  • DaemonSet
  • Job

Service 暴露服务

• 一个应用服务抽象，定义了Pod逻辑集合和访问这个Pod集合的策略
• 对外表现是为一个访问入口，分配一个集群IP地址，来自这个IP的请求将负载均衡转发后端Pod中的容器。
• 关联多个相同Label的Pod，通过LabelSelector选择一组pod提供服务
• 三种IP
  • Node IP：Node节点的IP地址
  • Pod IP：Pod的IP地址
  • Cluster IP：Service的IP地址，VIP
• 默认iptables代理模式
  • iptables代理模式（默认）

  

  1. kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除，
  2. 对每个 Service，它会配置 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面，
  3. 对于每个 Endpoints 对象，它也会配置 iptables 规则，这个规则会选择一个 backend 组合。
• HeadlessService 1. 不需要或不想要负载均衡，以及单独的 Service IP，指定 Cluster IP（spec.clusterIP）的值为 "None" 来创建 Headless Service 2. 可以配置Selector，创建Endpoints 记录，直接到达 Service 的后端 Pod 上
• 四种类型
• ClusterIP（默认）

集群内部 IP 暴露服务

• NodePort

• LoadBalancer

• ExternalName

通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容（例如， foo.bar.example.com）。没有任何类型代理被创建。

Ingress k8s标准，需要配置Ingress Controller服务（一个pod服务），例如nginx ingress controller，类似负载均衡，封装了一个 web 前端负载均衡器，同时在其基础上实现了动态感知 Ingress 并根据 Ingress 的定义动态生成 前端 web 负载均衡器的配置文件，比如 Nginx Ingress Controller 本质上就是一个 Nginx，只不过它能根据 Ingress 资源的定义动态生成 Nginx 的配置文件，然后动态 Reload。 实现了集群统一的流量入口，而不是像 nodePort 那样给集群打多个孔。

apiVersion:networking.k8s.io/v1beta1 kind: Ingress metadata: name: jmq-web namespace: jmq4 spec: rules: - host:tpass.jmq4.jd.comku http: paths: - path: / backend: serviceName: joyqueue-web servicePort: 10031

‍

‍