文章目录
- [一、 k8s概述](#一、 k8s概述)
-
- [1.1 k8s基本介绍](#1.1 k8s基本介绍)
- [1.2 k8s集群架构](#1.2 k8s集群架构)
- [二、 k8s核心概念](#二、 k8s核心概念)
-
- [2.1 集群 Cluster](#2.1 集群 Cluster)
- [2.2 容器 Container](#2.2 容器 Container)
- [2.3 pod](#2.3 pod)
-
- [2.3.1 pod基本概念](#2.3.1 pod基本概念)
- [2.3.2 pod存在意义](#2.3.2 pod存在意义)
- [2.3.3 pod的实现机制](#2.3.3 pod的实现机制)
-
- [2.3.3.1 共享网络](#2.3.3.1 共享网络)
- [2.3.3.2 共享存储](#2.3.3.2 共享存储)
- [2.3.4 pod的资源限制](#2.3.4 pod的资源限制)
- [2.3.5 pod的重启策略](#2.3.5 pod的重启策略)
- [2.3.6 pod的健康检查](#2.3.6 pod的健康检查)
- [2.4 controller](#2.4 controller)
-
- [2.4.1 什么是controller](#2.4.1 什么是controller)
- [2.4.2 controller和pod的关系](#2.4.2 controller和pod的关系)
- [2.5 service](#2.5 service)
-
- [2.5.1 什么是service](#2.5.1 什么是service)
- [2.5.2 service存在的意义](#2.5.2 service存在的意义)
- [2.6 副本集 ReplicaSet](#2.6 副本集 ReplicaSet)
- [2.7 发布 Deployment](#2.7 发布 Deployment)
- [2.8 ConfigMap/Secret](#2.8 ConfigMap/Secret)
- [2.9 DaemonSet](#2.9 DaemonSet)
一、 k8s概述
1.1 k8s基本介绍
Kubernetes 简称 k8s
,是支持云原生部署的一个平台,起源于谷歌。谷歌早在十几年之前就对其应用,通过容器方式进行部署。k8s 本质上就是用来简化微服务的开发和部署的,关注点包括自愈和自动伸缩、调度和发布、调用链监控、配置管理、Metrics 监控、日志监控、弹性和容错、API 管理、服务安全等,k8s 将这些微服务的公共关注点以组件形式封装打包到 k8s 这个大平台中,让开发人员在开发微服务时专注于业务逻辑的实现,而不需要去特别关注微服务底层的这些公共关注点,大大简化了微服务应用的开发和部署,提高了开发效率。
在 Kubernetes 中,我们可以创建多个容器,每个容器里面运行一个应用实例,然后通过内置的负载均衡策略,实现对这一组应用实例的管理、发现、访问,而这些细节都不需要运维人员去进行复杂的手工配置和处理。
1.2 k8s集群架构
master 节点由以下组件组成:
- API server,以restful方式对外提供操作和获取 k8s 集群资源的的 API,是唯一操作 etcd 的组件,其他的组件包括管理员操作都是通过 API server 进行交互的,可以将它理解成 etcd 的 "代理人"。
- scheduler,在 k8s 集群中做调动决策,负责资源的调度,按照预定的调度策略将 Pod 调度到相应的机器上。
- controller-manager,相当于集群状态的协调者,观察着集群的实际状态,与 etcd 中的预期状态进行对比,如果不一致则对资源进行协调操作让实际状态和预期状态达到最终的一致,维护集群的状态,比如故障检测、自动扩展、滚动更新等。
- etcd,一种分布式存储机制,底层采用 Raft 协议,k8s 集群的状态数据包括配置、节点等都存储于 etcd 中,它保存了整个集群的状态。
Worker 节点由以下组件组成:
- Controller Runtime,下载镜像和运行容器的组件,负责镜像管理以及 Pod 和容器的真正运行(CRI)。
- Pod,k8s 中特有的一个概念,可以理解为对容器的包装,是 k8s 的基本调度单位,实际的容器是运行在 Pod 中的,一个节点可以启动一个或多个 Pod。
- kubelet,负责管理 worker 节点上的组件,与 master 节点上的 API server 节点进行交互,接受指令执行操作。
- kube-proxy,负责对 Pod 进行寻址和负载均衡
用户操作 k8s 集群一般是通过 kubectl 命令行工具或者 dashboard;Pod 之间进行通讯是通过集群内部的覆盖网络 Overlay Network,外部流量想要进入集群访问 Pod 则是通过负载均衡 Load Balander 设备进行。
二、 k8s核心概念
2.1 集群 Cluster
集群由多个节点组成且可以按需添加节点(物理机/虚拟机),每一个节点都包含一定数量的 CPU 和内存 RAM。
2.2 容器 Container
k8s 本身是一个容器调度平台,从宿主机操作系统来看,容器就是一个一个的进程。从容器内部来看容器就是一个操作系统,它有着自己的网络、CPU、文件系统等资源。
2.3 pod
2.3.1 pod基本概念
k8s 不是直接调度容器的,而是将其封装成了一个个 POD,POD 才是 k8s 的基本调度单位。每个 POD 中可以运行一个或多个容器,共享 POD 的文件系统、IP 和网络等资源,每一个 POD 只有一个 IP,它的生命周期是短暂的(服务重启后的pod是新的)。
2.3.2 pod存在意义
我们使用docker创建容器,一个docker对应一个容器,一个容器有一个进程,一个容器运行一个应用实例,当然一个容器也可以运行多个,但是不方便管理,所以docker采用单进程设计。
pod是多进程设计,可以运行多个应用实例,一个pod有多个容器,一个容器里面运行一个应用程序。
pod的存在是为了亲密性应用(两个应用之间可以进行交互,或是两个应用之间需要频繁性交互)。
2.3.3 pod的实现机制
2.3.3.1 共享网络
pod里面有多个docker,而docker之间是隔离的。所以一个pod首先会创建一个pause容器(根容器,info容器),然后再创建业务容器,并加入到pause中。pause会有独立的ip、mac、port和namespace等,所以相当于一个pod中的容器共享一个namespace,在一个namespace下的容器可以实现网络共享。
2.3.3.2 共享存储
引入了volumn(数据卷),做持久化存储。假设有多个node,其中一个node宕机了,需要将这个node的pod移到其他node上,但是又想使用原来的数据,就需要对数据做持久化存储。下图是一个共享存储示例yaml文件demo。
2.3.4 pod的资源限制
requests
是node中的调度请求的资源大小,limits
是最大请求资源大小。
2.3.5 pod的重启策略
2.3.6 pod的健康检查
2.4 controller
2.4.1 什么是controller
Replication Controller(RC)是 Kubernetes 系统中核心概念之一,当我们定义了一个 RC并提交到 Kubernetes 集群中以后,Master 节点上的 Controller Manager 组件就得到通知,定期检查系统中存活的 Pod,并确保目标 Pod 实例的数量刚好等于 RC 的预期值,如果有过多或过少的 Pod 运行,系统就会停掉或创建一些 Pod.此外我们也可以通过修改 RC 的副本数量,来实现 Pod 的动态缩放功能。总结:在集群上管理和运行容器的对象。
2.4.2 controller和pod的关系
pod是通过controller实现应用的运维,比如伸缩、滚动升级等。pod和controller之间通过lable(标签)和selector(选择器)建立关系的。下图展示的是一个最简单的应用发布yaml:
2.5 service
2.5.1 什么是service
POD 在 k8s 中是不固定的,可能会挂起或者重启,且挂起重启都是不可预期的,那么这就会导致服务的 IP 也随着不停的变化,给用户的寻址造成一定的困难。而 service 就是用来解决这个问题的,它屏蔽了应用的 IP 寻址和负载均衡,消费方可直接通过服务名来访问目标服务,寻址和负载均衡均由 service 底层进行。
2.5.2 service存在的意义
- 防止pod失联(服务发现)
当发生升级、回滚等事件时,pod的IP地址也随之变化,如果采用外部应用直接访问pod时,就会导致访问不到。采用service后,每当pod的IP地址发生变化时,pod会将新IP注册到service,然后外部访问之前,会先去service拿IP后再访问。 - 定义了一组pod的访问策略(负载均衡)。
2.6 副本集 ReplicaSet
一个应用发布时会发布多个 POD 实例,副本集可对应一个应用的一组 POD,它可以通过模板来规范某个应用的容器镜像、端口,副本数量等。运行时副本集会监控和维护 POD 的数量,数量过多则会下线 POD,过少则启动 POD。
2.7 发布 Deployment
副本集就是一种基本的发布机制,可以实现基本的或者高级的应用发布,但操作较为繁琐。未来简化这些操作,k8s 引入了 Deployment 来管理 ReplicaSet,实现一些高级发布机制。
2.8 ConfigMap/Secret
微服务在上线时需要设置一些可变配置,环境不同则配置值不同,有些配置如数据库的连接字符串在启动时就应该配好,有些配置则可以在运行中动态调整。为了实现针对不同环境灵活实现动态配置,微服务就需要 ConfigMap 的支持。
k8s 平台内置支持微服务的配置(ConfigMap),开发人员将配置填写在 ConfigMap 中,k8s 再 将 ConfigMap 中的配置以环境变量的形式注入 POD,这样 POD 中的应用就可以访问这些配置。
Secret 是一种特殊的 ConfigMap,提供更加安全的存储和访问配置机制。
2.9 DaemonSet
在微服务中,每个节点需要配置一个常驻守护进程。DaemonSet 可支持在每一个 worker 节点上面配置一个守护进程。
参考文章如下: