k8s的系统组件构成

k8s的前身borg

borg的架构
BorgMaster类似于是中心调度的大脑,Borglet是一些真正运行服务的节点,其中包含某些节点的副本,一般来说节点的数量都是奇数的为了防止投票的时候出现平手的现象一般都是用奇数个节点。

scheduler调度器

scheduler将数据写入Paxos数据库当中之后再发给Borglet去消费这些数据。

K8s的架构

k8s架构图

master服务器分为三部分

  • scheduler : 调度器
  • replication controller :配置控制器,负责控制副本数量得,伸展和收缩容器的数量
  • api server:所有数据访问和请求的接口

外部组件

kubectl: 命令行管理工具也会与api server进行交互
webUI:也是与api server进行交互
etcd:api server接收到操作的请求之后访问etcd,起到了持久化的作用

etcd介绍

etcd一个可信赖分布式键值存储服务,他本身就支持分布式存储,不需要其他的中间件的存在。用于为整个分布式集群存储一些关键数据,协助分布式集群的正常运转。
在k8s集群中使用EtcdV3,v2版本已经在v1.11弃用。V2版本是没有做备份操作的,需要单独做备份,v3是有做持久化的。
Etcd结构

  • httpserver提供所有的服务的接口
  • raft存储着所有的信息
  • wal生成日志,将每条数据的都备份到Entry记录当中,并且会定时的对数据进行快照完整备份。因为不可能随时进行完整备份,也不能一直用临时备份,可能会导致增量数据太多后面再进行完整备份的时候太麻烦,所以隔一段时间就进行一下快照。同事也会将数据存储到本地磁盘当中进行持久化设置。
底层的节点的作用

kubelet
可以选择使用的容器类型,常见的是docker,kubelet管理docker
kube proxy
pod与pod之间的访问和负载均衡需要依靠kube proxy来实现。默认是通过操作防火墙来实现pod的映射,新版本支持IPVS。

其他插件

coreDNS:可以为及群众的SVC创建一个域名IP的对应关系解析
dashboard:给k8s集群的bs访问体系
Ingress Controller可以进行七层代理
federation:提供一个可以跨集群中心多k8s统一管理的功能
prometheus:提供k8s集群的监控能力
ELK: 提供K8s集群日志的统一分析接入平台

Pod的概念

  • 一个pod里面可以管理多个docker容器
  • 每一个pod里面都具备一个pause容器,这个容器是创建pod的时候就会生成的一个容器,主要的作用就是为所有的进程隔离的容器提供一个统一的网络协议栈,这样两个容器看起来就像是运行在一个系统的网络环境下面的两个process。所以需要注意的是不能使用同样的ip和端口。如果pause和外界的html资源有联系的话,pause上面的资源也会被pod内所有其他的容器节点所共享。
  • pod中的容器共用一个网络命名空间
  • pod是临时性的,每次被销毁之后再创建就会改变为新的ip和端口

Pod存在的意义

  1. 创建容器使用的是docker,一个docker对应一个容器一个进程,运行一个应用程序。如果运行多个程序就不方便管理内部的某一个线程,不能做统一管理
  2. pod是多进程的设计方式,pod内部管理多个docker容器,并且还有管理容器的pause容器。
  3. pod的设计支持亲密性应用
    • 应用之间可以进行交互
    • 内部都属于一个网络栈不需要单独设置其他的ip和端口
    • 两个应用需要频繁调用
  4. 实现共享存储的机制,使用数据卷volume来做持久化存储,方式其中某个docker宕机,可以立即恢复数据

image拉取策略

apiVersion: V1
kind: Pod
metadata: 
	name: mypod
spec: 
	containers:
		- name: nginx
		  image: nginx:1.14
		  imagePullPolicy: Always
		  # IfNotPresent: 默认值,镜像在宿主机上不存在才拉取
		  # Always: Pod每次创建都会重新拉取一次
		  # Never: Pod永远不会主动去拉取这个镜像

pod调度的资源限制

资源限制

apiVersion: V1
kind: Pod
metadata: 
	name: mypod
spec: 
	containers:
	- name: mysql
	  env:
	  - name: ADMIN_PWD
	  	value: "passwd"
	  #resources项用于配置调度资源的限制和要求
	  resources:
	  	request: #调度大小
	  		memory: "64Mi"
	  		cpu: "250m"
	  	limits: # 限制大小
	  		memory: "128Mi"
	  		cpu: "500m"

Pod的创建过程

master节点

  1. create pod操作
  2. 发送给apiserver
  3. apiserver将新pod的信息记录在etcd中
  4. sheduler 通过apiserver获得新节点
  5. apiserver访问etcd将节点的信息传给sheduler
  6. 使用调度算法把pod调度到某个node节点

node节点

  1. kubelet访问apiserver
  2. 通过读取etcd得到当前节点的pod
  3. 使用docker命令创建容器

create pod

Pod的调度

影响调度的属性

  1. pod资源限制对Pod调用差生的影响
  2. 节点选择器影响pod调度,将node节点划分为不同的分组,在nodeSelector配置项下选择组名,就可以在固定的几个节点中进行调度。 对节点创建一个标签就可以使用标签来做分组
kubectl label node xx env_role=prod
  1. 节点的亲和性影响pod调度: nodeAffinity
    • 硬亲和性: 约束条件必须满足,如果条件不满足就会处于等待状态
    • 软亲和性: 尝试满足,但是不保证一定可以

污点和污点容忍

Taint污点:节点不做普通分配调度,污点是节点的属性
针对特定的应用场景做分配

  1. 专用节点
  2. 配置特点硬件节点
  3. 基于Taint驱逐
指令

查看污点情况

kubectl describe node k8smaster | grep  Taint

为节点添加污点

kubectl taint node [node] key=value:NoSchedule
污点值内容
  1. NoSchedule:一定不会被调度
  2. PerferNoSchedule :尽量不被调度
  3. NoExecute: 不会调度,并且还会驱逐Node已经有的Pod

污点容忍

即便是打上污点的节点也会被调度到,称为污点容忍

Pod控制器

ReplicationController && ReplicaSet && deployment
在集群上管理和运行容器的对象

Pod与Controller之间的关系

Pod通过controller来实现对于应用的运维(伸缩、滚动升级等)两者通过label标签来建立关系
工作负载会使用selector来对某一个label的app进行一定的管理

ReplicationController

用来确保容器应用的副本数始终保持在用户定义的副本数,即如果有容器异常退出,会自动创建新的Pod来代替,而如果异常多出来的容器也会自动回收。

ReplicatSet

与ReplicationController本质上没有任何区别,只是名字布一样而已,而且replicaSet支持集合式的selector

Deployment

自动管理ReplicaSet,无需担心跟其他的机制不兼容的问题发生。(ReplicaSet不支持rolling-update但是deployment支持)

滚动更新:一个deloyment会设置一个Rs去管理pod,如果需要升级这些Pod的版本就会再生成一个RS从旧的Rs中拿一个pod重启之后再放入新的Rs中,如果中间的升级有问题的话还可以undo回滚,因为之前的旧的RS处于暂停的状态,并不会被删除,只有整个全部更新完毕才会删掉之前的RS。

应用场景

  • 部署无状态应用
  • 管理pod和ReplicaSet
  • 部署,滚动升级等功能
  • web服务、微服务中常用
    应用升级
#升级到1.15版本
kubectl set image deployment web nginx=nginx:1.15

查看升级状态

kubectl rollout status deployment web

查看升级版本

kubectl rollout history deployment web

回滚上一个版本

kubectl rollout undo deployment web

回滚到指定版本

kubectl rollout undo deployment web --to-revision=2
使用deployment部署一个应用

https://kubernetes.io/zh/docs/tasks/run-application/run-stateless-application-deployment/

HPV:平滑扩展根据利用率

v1中根据pod的cpu利用率来进行平滑扩展。HPV也是一个对象,当Cpu大于80的时候就需要被扩展,新建一个或多个pod,如果创建一个pod还没有低于八十,那就继续创建。最大数量pod是10,在利用率比较低的时候就会删除多余的pod。未来可以支持内存和用户自定义metrics扩容。

StatefulSet

docker比较支持的是无状态服务,但是如果希望让有状态的服务也能搭建到集群上面,就可以使用stateful来进行数据的持久化。
主要提供三个功能

  1. 稳定的持久化存储:pod重新调度后还是能访问到相同的持久化数据,基于PVC实现的
  2. 稳定的网络标识:Pod重新调度之后其podName和HostName不变,基于Headless Service来实现
  3. 有序部署,有序扩展,Pod是有顺序的,在部署或者扩展的时候要依据定义的顺序依次进行,只有当前一个的pod处于running或者是Ready状态下才可以启动新的pod。

DaemonSet

确保全部(或者一些)Node上运行一个Pod的副本,当有Node加入集群当中时,也会为他们新增一个Pod。当有Node从集群移除时,这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod。
如果被打上污点的pod就不会被参与调度。

使用demonSet的一些典型的用法:
  • 运行集群存储demon,在每个Node上运行的glusterd、ceph
  • 在每个Node上面运行日志收集deamon
  • 在每个Node上运行监控daemon

cron Job

负责批处理服务,仅执行一次的任务,保证批处理任务的一个或多个pod成功结束

cron job管理基于时间的job,即

  • 在给定时间点只运行一次
  • 周期性地在给定时间点运行

服务发现

应用场景:客户端想要去访问一组pod的时候,这几个pod有一些共同点(同一标签 or 同一deploy管理)
service去主动收集这些pod的服务,service是通过标签去收集这些pod的
service有IP和端口,client可以通过这些端口和IP去间接访问pod服务(轮询)
服务发现

### Kubernetes 控制平面组件详解 Kubernetes 是一种开源的容器编排平台,用于自动化部署、扩展和管理容器化应用程序。它的控制平面由多个关键组件组成,这些组件协同工作以实现整个系统的管理和协调。 #### 1. **kube-apiserver** `kube-apiserver` 是 Kubernetes 的前端接口,也是集群的核心交互点。它提供了 RESTful API 接口供客户端访问,并与其他控制平面组件通信。所有的集群管理操作都通过 `kube-apiserver` 进行[^2]。 主要职责包括: - 提供统一的 API 访问入口。 - 负责认证和授权请求。 - 维护集群状态的一致性和持久性。 #### 2. **etcd** `etcd` 是一个分布式键值存储系统,用于保存 Kubernetes 集群的所有数据。它是高可用的关键部分之一,支持快速读取和写入操作。为了提高性能和可靠性,可以通过清理报警和自动压缩历史记录来优化 `etcd` 的运行效率[^3]。 主要特点如下: - 存储所有集群配置信息、对象规格以及状态。 - 支持事务一致性。 - 可通过命令行工具(如 `etcdctl`)执行维护任务。 #### 3. **kube-scheduler** 调度器 (`kube-scheduler`) 负责将未分配的工作负载(Pods)放置到合适的节点上。它会根据预定义的策略评估每个节点的能力和需求,从而做出最优决策。 核心功能包括: - 动态分析资源利用率。 - 基于标签选择器匹配特定条件的节点。 - 实现多种插件化的调度算法。 #### 4. **kube-controller-manager** 控制器管理器 (`kube-controller-manager`) 运行一系列内置的控制器进程,用来维持期望的状态并与实际状态保持一致。常见的控制器有 ReplicaSet Controller、Deployment Controller 和 Node Controller 等。 具体作用如下: - 自动修复失败的 Pods 或 Nodes。 - 处理服务端点关联逻辑。 - 监控节点健康状况并标记不可达节点。 #### 5. **cloud-controller-manager** 云控制器管理器专门针对集成外部基础设施的服务而设计,比如 AWS、GCP 或 Azure。它可以分离与公有云相关的业务逻辑,使本地环境更加独立。 --- 以下是关于 kubelet 的认证过程补充说明:当 kubelet 启动时,它会被认证为属于 `system:bootstrappers` 组的一部分[^1]。随后,在向 API Server 发送请求的过程中,经过严格的权限校验机制确保安全性[^4]。 ```python # 示例 Python 客户端调用 K8S API from kubernetes import client, config config.load_kube_config() v1 = client.CoreV1Api() print("Listing pods with their IPs:") ret = v1.list_pod_for_all_namespaces(watch=False) for i in ret.items: print(f"{i.status.pod_ip}\t{i.metadata.namespace}\t{i.metadata.name}") ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值