微服务之——K8S基本概念+组件

首先先来谈谈Kubernetes 优势：

? 自我修复

在节点故障时重新启动失败的容器，替换和重新部署，保证预期的副本数量；杀死健康检查失败的容器，并且在未准备好之前不会处理客户端请求，确保线上服务不中断。

? 弹性伸缩

使用命令、UI或者基于CPU使用情况自动快速扩容和缩容应用程序实例，保证应用业务高峰并发时的高可用性；业务低峰时回收资源，以最小成本运行服务。

? 自动部署和回滚

K8S采用滚动更新策略更新应用，一次更新一个Pod，而不是同时删除所有Pod，如果更新过程中出现问题，将回滚更改，确保升级不受影响业务。

? 服务发现和负载均衡

K8S为多个容器提供一个统一访问入口（内部IP地址和一个DNS名称），并且负载均衡关联的所有容器，使得用户无需考虑容器IP问题。 ? 机密和配置管理

管理机密数据和应用程序配置，而不需要把敏感数据暴露在镜像里，提高敏感数据安全性。并可以将一些常用的配置存储在K8S中，方便应用程序使用。

? 存储编排

挂载外部存储系统，无论是来自本地存储，公有云（如AWS），还是网络存储（如NFS、GlusterFS、Ceph）都作为集群资源的一部分使用，极大提高存储使用灵活性。 ? 批处理

提供一次性任务，定时任务；满足批量数据处理和分析的场景。

基于以上的优点，我们要了解K8S 的基本概念，以及组件

四组基本概念:

? Pod/Pod控制器

? Name/Namespace

? Label/Label选择器

? Service/Ingress

Pod

?Pod 是K8S中能够被运行的最小逻辑单元

?1个Pod里可以运行多个容器, 它们共享UTS+NET+IPC名称空间

?一个Pod里运行多个容器, 可称为SideCar模式

Pod控制器

Pod控制器是Pod启动的一种模板, 用来保证在K8S里启动的Pod始终按照人们的预期运行(副本数, 生命周期, 健康状态检查…)

K8S 内提供了众多的Pod控制器, 常用的有:

?Deployment

?DaemonSet (每一个运算节点都起一份)

?ReplicaSet (本身不提供对外服务, 真正暴露在外的是Deployment。Deployment -> ReplicaSet -> Pod)

?StatefulSet (管理有状态应用的Pod控制器)

?Job

?Cronjob (管理周期任务)

Name

?由于K8S内部, 使用 “资源” 来定义每一种逻辑概念(功能), 所以每种 “资源”, 都应该有自己的 “名称 “

?”资源” 有API版本(apiVersion) 类别 (kind)、元数据(metadata) 、定义清单(spec list)、状态(status) 等配置信息

?”名称” 通常定义在 ”资源“ 的 ”元数据“ 信息中

Namespace

?随着项目增多、人员增加、集群规模的扩大, 需要一种能够隔离K8S内各种 “资源” 的方法, 此即为名称空间

?可以理解为K8S内部的虚拟集群组

?不同的名称空间内的 “资源”, 名称可以相同; 相同名称空间内的同种 “资源”， “名称” 不能相同

?合理的使用K8S的名称空间, 使得集群管理员能够更好地对交付到K8S里的服务进行分类管理和浏览

?K8S里默认存在的名称空间有:

?default

?kube-system

?kuben-public

?可以自建

查询K8S 里特定 “资源” 要带上相应的名称空间

Label

?标签是K8S特色的管理方式, 便于分类管理资源对象

?一个标签可以对应多个资源, 一个资源也可以有多个标签, 它们是多对躲的关系

?一个资源拥有多个标签, 可以实现不同维度的管理

?标签的组成: key = value

?与标签类似的, 还有注解(annotations)

Label Selector

?给资源打上标签后, 可以使用标签选择器过滤指定的标签

?标签选择器目前有两个: 基于等值关系(等于、不等于) 和 基于集合关系(属于、不属于、存在)

?许多资源支持内嵌标签选择器字段

?matchLabels

?matchExpressions

Service

?每个Pod都会被分配一个单独的IP地址, 但这个IP地址会随着Pod的销毁而消失

?Service (服务) 就是用来解决这个问题的核心概念

?一个Service可以看作一组提供相同服务的Pod的对外访问接口

?Service作用于哪些Pod是通过标签选择器来定义的

Ingress

?Ingress 是K8S集群里工作在OSI网络参考模型下, 第7层的应用, 对外暴露的接口

?Service只能进行L4流量调度, 表现形式是ip+port

?Ingress则可以调度不同业务域、不同URL访问路径的业务流量

基本组件(主要是两大节点):

主控 (master) 节点:

etcd(非关系型数据库) ->配置存储中心

kube-apiserver服务

?提供了集群管理的Restful风格API接口(包括鉴权、数据校验及集群状态变更), 可以类比ElasticSearch的Restful风格API, curl -xput | xget | xdelete 等。

?负责其他模块之间的数据交互, 承担通信枢纽功能。

?是资源配额控制的入口

?提供完备的集群安全机制

kube-controller-manager服务

?由一系列控制器组成, 通过apiserver监控整个集群的状态, 并确保集群处于预期的工作状态

?Node Controller

?Deployment Controller

?Service Controller

?Volume Controller (存储卷控制器)

?EndPoint Controller (接入点控制器)

?Garbage Controller (垃圾控制器 类似GC)

?Namespace Controller (名称空间控制器)

?Job Controller

?Resource quota Controller (资源调度控制器)

kube-scheduler服务

?主要功能是接收调度pod到适合的运算节点上

?预算策略 (predict)

?优选策略 (priorities)

运算 (node) 节点:

kube-kubelet 服务

?主要功能是定时从某个地方获取节点上 pod 的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配 置等等), 并调用对应的容器平台接口达到这个状态

?定时汇报当前节点的状态给apiserver, 以供调度的时候使用

?镜像和容器的清理工作, 保证节点上镜像不会占满磁盘空间, 退出的容器不会占用太多资源。

kube-proxy 服务

? 是K8S在每个节点上运行网络代理, service资源的载体

? 建立了pod网络和集群网络的关系 (clusterip -> podip)

?常用三种流量调度模式:

?Userspace (废弃, 需要大量用户态内核态转换, 资源消耗过多)

?Iptables (濒临废弃)

? Ipvs (推荐) 相当于在K8S中内嵌了一套LVS

?负责建立和删除包括更新调度规则、通知apiserver自己的更新, 或者从apiserver那里获取其他kube-proxy的调度规则变化来更新自己