K8s基础

K8s基础

简介：K8s全称为Kubernetes，这是一个开源的管理容器的平台，完成的具体工作就是将应用程序打包成容器，将这些容器部署到一个集群里面，用户更加方便的管理，部署容器化应用程序。

K8s架构

k8s中一个集群是通过多个节点组成的，在这里面Master节点作为集群的控制中心（可以类比一下内网渗透里面的域控功能）,Node节点就对应着一个个的容器

image-20250827154220418

这张图片的左边就是我们Master节点，里面的就是用来控制和管理的组件，右边的就是我们的Node节点，实现和Master节点的主要通信，这个pod表示的是一组正在运行的容器。

Mater节点(控制节点组件)

  • API-Server: 这个是k8s最核心的组件，提供集群里面各个组件之间的通信和管理的接口

这张图就可以直观的看出我们API-server的具体的作用，就是k8s里面的大脑image-20250827155015776

  • Etcd:这个组件是K8s里面用于保存集群中所有的状态信息和元数据的后台数据库，使用键值存储，包括 Pod、Service、Deployment 等对象的创建、更新和删除等操作，都将被记录在 Etcd 中。这样可以使得 Kubernetes 系统具有高可用性和复原能力，并且允许多个 Master 节点之间进行数据同步和共享。

  • kube-scheduler:这个相当于一个资源分配管理工具，是k8s实现负载均衡和资源最大化利用的重要组件

  • kube-Controller Manager:这个是负责运行控制器进程，控制器有很多不同的类型：

  • Node 控制器：负责在节点出现故障时进行通知和响应

  • Job 控制器：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成

  • EndpointSlice 控制器：填充 EndpointSlice 对象（以提供 Service 和 Pod 之间的链接）。

  • ServiceAccount 控制器：为新的命名空间创建默认的 ServiceAccount。

  • cloud-controller-manager: 这个只运行在特定的云环境上，这个允许将集群连接到云提供商的API上，主要起到将k8s集群的交互和我们云上交互分离开来

┌──────────────────────────────┐
│ kube-controller-manager │
│ 只有通用控制器 │
└──────────────────────────────┘
│
│ 只处理集群内部资源
▼
┌──────────────────────────────┐
│ Cloud Controller Manager │
│ - Node Controller │ ← 调用云 API 获取节点元数据
│ - Service Controller │ ← 调用云 API 创建/删除 LB
│ - Route Controller │ ← 调用云 API 配置路由
│ - Volume Controller │ ← 调用云 API 挂/卸载云盘
└──────────────────────────────┘
│
│ 通过云厂商 SDK
▼
AWS / GCP / Azure / ...

Node节点（节点组件）

  • kubelet: 这个组件是用来保证我们的容器都运行在Pod里面，也是负责和master节点实现通信的，会给master节点报告容器的运行状态和健康

  • kube-proxy: 这个组件是集群里面的网络代理组件，负责集群内Service的负载均衡和访问控制

  • Container Runtime:负责镜像管理以及 Pod 和容器的真正运行（CRI），早期是docker引擎作为组件，从v1.20开始使用 containerd、CRI-O 等

  • fluentd不是 Kubernetes 的核心组件，但常用于日志收集，将 Pod 的 stdout/stderr 日志采集到集中系统（如 Elasticsearch、Kafka）中

Node和Pod还有容器的关系

pod是k8s里面调度的最小单位，一个pod里面可以包括1个或者多个容器，pod内的容器可以共享相同的ip和端口。

每个Node上面可以有多个Pod,Node是一个执行操作的工作机器，当Node宕机的时候，pod会迁移到另外Node借着运行

image-20250827170759552

image-20250827171604220

补充一些概念

  • Deployment：用于管理 Pod 的“控制器”，定义 Pod 的部署规则（如副本数量、镜像版本），支持滚动更新、回滚等操作。
  • Service：为一组相同功能的 Pod 提供统一访问入口（固定 IP/域名），实现负载均衡，避免 Pod IP 变化导致服务不可用。
  • Namespace：用于划分集群资源的“逻辑隔离区”（如开发环境、测试环境、生产环境用不同 Namespace 隔离，避免资源冲突）。
  • ConfigMap/Secret：分别用于存储非敏感配置（如数据库地址）和敏感信息（如密码、密钥），避免配置硬编码到容器镜像中。

K8s特点

在k8s出现之前，使用docker工具部署容器的时候，容器的管理十分的混乱，有了k8s相当于容器集群有了一个“操作系统”

  • 微服务架构支持：Kubernetes非常适合部署和管理基于微服务的应用程序，每个服务可以独立运行在Pod中，并通过Service进行发现和通信。

  • 自动化部署与扩展：自动化的滚动更新、回滚以及水平扩展（HPA）功能使得应用程序的发布过程更加快速、可靠且无需人工干预。

  • 资源调度与优化：Kubernetes能够高效地跨集群节点调度容器，根据资源需求动态分配和调整容器的位置，从而最大化硬件资源利用率。

  • 容错性和高可用性：它提供了自我修复机制，当容器或节点出现问题时，会自动重新调度并恢复工作负载，保证应用的持续可用。

  • 网络管理：内置的服务发现和负载均衡机制，简化了服务间的通信，同时支持Ingress控制器对外提供统一入口和路由策略。

  • 存储集成：支持多种存储插件，方便为容器提供持久化存储解决方案，满足不同应用场景的数据持久化需求。

  • 安全与隔离：通过Namespace实现多租户隔离，使用RBAC等安全策略来控制用户权限，确保集群内资源的安全访问。

  • 可观测性与监控：集成Prometheus、Grafana等工具以实现资源和应用性能的实时监控，便于问题排查和性能优化。

K8s工作流程

  1. kubectl（使用命令行来管理集群）向apiserver发送部署请求（例如使用 kubectl create -f deployment.yml）

  2. apiserver将 Deployment 持久化到etcd；etcd与apiserver进行一次http通信。

  3. controller manager通过watch api监听 apiserver ，deployment controller看到了一个新创建的deplayment对象更后，将其从队列中拉出，根据deployment的描述创建一个ReplicaSet并将 ReplicaSet 对象返回apiserver并持久化回etcd。

以此类推，当replicaset控制器看到新创建的replicaset对象，将其从队列中拉出，根据描述创建pod对象。

  1. 接着scheduler调度器看到未调度的pod对象，根据调度规则选择一个可调度的节点，加载到pod描述中nodeName字段，并将pod对象返回apiserver并写入etcd。

  2. kubelet在看到有pod对象中nodeName字段属于本节点，将其从队列中拉出，通过容器运行时创建pod中描述的容器。

┌─────────────┐ ┌──────────────┐
│ 运维人员 │───HTTP/HTTPS──▶│ API Server │
│ (kubectl) │ │ 认证/鉴权 │
└─────────────┘ └──────┬───────┘
│
▼
┌──────────────┐
│ etcd │ ① 存储期望状态
└──────┬───────┘
│
▼
┌────────────────────────┐ ┌──────────────┐
│ Controller Manager │◀───┤ 监听变化 │
│ 生成 Pod 对象 │ └──────────────┘
└─────────────┬──────────┘
│
▼
┌────────────────────────┐
│ Scheduler │ ② 调度
│ ├ Predicate(预算) │
│ └ Priority(优选) │
└─────────────┬──────────┘
│
▼
┌────────────────────────┐
│ kubelet (目标节点) │ ③ 真正创建 Pod
│ ├ 拉取镜像 │
│ └ 启动容器 │
└─────────────┬──────────┘
│
▼
┌────────────────────────┐
│ kube-proxy │ ④ 暴露 Service
└────────────────────────┘

K8s安全问题

首先我们k8s常见组件的端口

api server 8080/6443
dashboard 8001/30000+/自定义
kubelet 10250/10255
etcd 2379/2380
kube-proxy 8001
docker 2375
kube-scheduler 10251
kube-controller-manager 10252

image-20250827174622690

通过这个图片可以知道潜在的攻击点

未授权访问

  • API Server未授权访问：8080端口在默认情况下不启用，这个端口不需要认证和授权检查，配置不当启用就可能导致未授权访问

  • Kubectl Proxy 不安全配置：kubectl proxy 允许你通过代理访问 Kubernetes API Server，进行集群管理和操作。这包括访问集群资源（如 Pods、Services、Deployments、ConfigMaps 等），执行命令（例如 kubectl get、kubectl apply）

  • Kubernetes Dashboard：默认情况下，Dashboard 可以在 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/http:kubernetes-dashboard:/proxy/ 访问,

如果用户为了方便或者其他原因，开启了跳过功能，就会导致 Dashboard 的未授权访问

  • etcd 未授权访问:未加密的数据传输,未加密的数据存储,缺乏认证和授权,Etcd 服务的暴露

  • 2379：用于客户端连接

  • 2380：用于多个etcd实例之间的通信

网络策略

在 K8s 中，一个 pod 可以连接到集群外部的其他 pod 和外部地址；默认情况下，其他人可以从集群内部连接到此 pod。网络策略用于管理和限制 pod、命名空间和 IP Blocks 之间的网络访问。Pod内的root用户具有CAP_NET_RAW权限（即允许使用原始套接字的权限，允许程序绕过常规的 TCP/UDP 协议栈，直接构造和发送自定义的 IP 包进行集群内网探测）网络策略可以与 pod 上的标签一起使用，而标签的不当使用可能会导致不必要的访问

容器漏洞

K8s 是一个容器编排平台，在工作节点上分发和运行容器。但是它不会检查容器的内容是否存在安全漏洞或暴露。如果有严重漏洞（如远程代码执行）的镜像在集群上运行就可能导致出现问题

访问机制安全

Kubernetes 中的访问控制机制主要由三个部分组成：

  • 认证机制
  • 授权机制
  • 准入机制

如果访问控制比较宽松或混乱或者允许 Kubernetes 的未授权访问，攻击人员可能借此直接获得集群管理员权限

一些Kubernetes 监控部署平台存在 "可能的验证缺失" 和 "对公网/外网开放" 的错误配置可能, 可以导致严重的集群接管的问题，并且利用这类平台即可实现k8s的权限维持

posted @ 2025-08-27 18:11  tammy66  阅读(11)  评论(0)    收藏  举报