K8s简单介绍

本文详细介绍了Kubernetes(K8S),包括其用于容器化应用部署、管理和扩展的功能,如自我修复、弹性伸缩、服务发现。深入探讨了K8S集群架构,包括Master节点的kube-apiserver、kube-controller-manager、kube-scheduler,以及Node节点的kubelet、kube-proxy和容器引擎。还涵盖了K8S核心概念和常见的部署方式。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、K8S简介

1、Kubernetes 是Google在2014年开源的一个容器集群管理系统,Kubernetes简称K8S。
2、K8S用于容器化应用程序的部署,扩展和管理。
3、K8S提供了容器编排,资源调度,弹性伸缩,部署管理,服务发现等-一系列功能。
4、Kubernetes目标是让部署容器化应用简单高效。

官方网站: http://www.kubernetes.io

二、K8S集群架构与组件

1、自我修复

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

2、弹性伸缩

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

3、自动部署和回滚

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

4、服务发现和负载均衡

K8S为多个容器提供一个统一访问入口 (内部IP地址和一个DNS名称),并且负载均衡关联的所有容器,使得用户无需考虑容器IP问题。

5、机密和配置管理

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

6、存储编排

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

7、批处理

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

三、Kubernetes集群架构与组件

在这里插入图片描述
在这里插入图片描述

1、Master节点

(1)kube-apiserver

Kubernetes API,集群的统一入口, 各组件协调者,以RESTful API提供接口服务,所有对象资源的增删改查和监听操作都交给 API Server 处理后再提交给Etcd存储。

(2)kube-controller-manager

处理集群中常规后台任务,一个资源对应一个控制器,而ControllerManager就是负责管理这些控制器的。
由一系列控制器组成,通过API Server 监控整个集群的状态,并确保集群处于预期的工作状态,比如当某个Node意外宕机时,Controller Manager会及时发现并执行自动化修复流程,确保集群始终处于预期的工作状态。

这些控制器主要包括:
●Node Controller(节点控制器):负责在节点出现故障时发现和响应
●Replication Controller (副本控制器) :负责保证集群中一个RC (资源对 象Replication Controller) 所关联的Pod
副本数始终保持预设值。可以理解成确保集群中有且仅有N个Pod实例,N是RC中定义的Pod副本数量
●Endpoints Controller (端点控制器) :填充端点对象 (即连接Services 和Pods) ,负责监听 Service 和对应的Pod副本的变化
可以理解端点是一个服务暴露出来的访问点,如果需要访问一个服务,则必须知道它的endpoint
●Service Account & Token Controllers ( 服务帐户和令牌控制器) :为新的命名空间创建默认帐户和API访问令牌
●ResourceQuota Controller(资源配额控制器):确保指定的资源对象在任何时候都不会超量占用系统物理资源
●Namespace Controller ( 命名空间控制器) :管理namespace的生命周期
●Service C

<think>好的,我现在需要帮助用户理解Kubernetes的RBAC。用户之前询问过如何让开发人员通过创建的用户访问集群查看Pod日志,现在他们想简单了解RBAC。首先,我应该回顾之前的对话,确保回答的一致性和连贯性。 用户当前的问题是“简单介绍k8s的rbac”,所以需要给出一个简明扼要的解释。但用户之前的问题涉及到具体的RBAC配置步骤,所以在回答时可能需要稍微展开,但保持简洁。 首先,RBAC的全称是Role-Based Access Control,也就是基于角色的访问控制。我需要解释清楚它的核心概念:Role、ClusterRole、RoleBinding、ClusterRoleBinding,以及它们之间的关系。要说明RBAC的作用是管理用户和服务账户对集群资源的访问权限。 接下来,需要区分Role和ClusterRole。Role是命名空间级别的,只能授权特定命名空间内的资源;而ClusterRole是集群范围的,可以授权所有命名空间的资源,或者非资源型端点如节点。例如,在之前的例子中,用户创建了一个Role来允许读取Pod日志,这个Role只作用于default命名空间。 然后是RoleBinding和ClusterRoleBinding。RoleBinding将角色绑定到主体(用户、组、服务账户),并且作用在特定的命名空间;而ClusterRoleBinding则是集群范围的绑定。例如,用户之前创建的RoleBinding将developer用户绑定到pod-logs-reader角色,限制在default命名空间。 需要提到主体可以是User、Group或ServiceAccount。这里的User通常指的是外部用户,比如通过证书认证的,如用户之前用X.509证书创建的developer用户。而ServiceAccount是集群内部的账户,用于Pod中的进程与API Server通信。 权限规则(Rules)由API组、资源、动词组成。例如,在用户之前的例子中,授权了core API组(空字符串)中的pods/log资源,允许get和list操作。需要说明如何组合这些元素来定义细粒度的权限。 还要强调RBAC的优势,比如细粒度控制、灵活授权、审计能力,以及如何帮助实现最小权限原则,提高安全性。可能还需要提到实际应用中的常见场景,比如开发人员只能查看特定命名空间的日志,管理员有更广泛的权限等。 在之前的回答中,用户已经接触过如何创建Role和RoleBinding,所以这里可以简要提及这些示例,但不需要详细展开步骤,因为用户现在需要的是概述而非操作指南。需要注意使用用户之前提到的例子来加强理解,比如pod-logs-reader角色。 此外,用户可能对RBAC的实际应用场景感兴趣,比如多团队环境中的权限隔离,或者CI/CD系统中的服务账户权限管理。虽然用户的问题只是简单介绍,但可能需要点到为止。 最后,要确保语言简洁,结构清晰,使用列表或小标题帮助用户快速抓住重点。避免使用过于专业的术语,但保持准确性。可能需要检查是否有必要提到其他访问控制机制,比如ABAC,但根据问题,重点在RBAC,所以可以忽略其他,除非对比有助于理解。 总结回答的结构应该是:定义RBAC,核心组件,Role与ClusterRole的区别,Binding的作用,主体类型,权限规则的结构,优势和应用场景。保持段落简短,使用项目符号或编号列表提高可读性。</think>### Kubernetes RBAC 简明指南 **RBAC(Role-Based Access Control)** 是 Kubernetes 的核心权限控制系统,通过 **角色关联权限** + **绑定关联主体** 的二级授权模式,实现精准的访问控制。 --- #### 🔑 **核心概念** | 对象 | 作用域 | 功能描述 | 示例场景 | |---------------------|-------------|-------------------------------------------|----------------------------| | **Role** | 命名空间级别 | 定义单个命名空间内的操作权限 | 允许读取 default 命名空间的 Pod 日志 | | **ClusterRole** | 集群级别 | 定义集群范围/跨命名空间的权限 | 允许查看所有节点的信息 | | **RoleBinding** | 命名空间级别 | 将 Role/ClusterRole 绑定到主体(用户/组) | 开发团队访问测试环境命名空间 | | **ClusterRoleBinding** | 集群级别 | 全局权限绑定 | 集群管理员全局访问权限 | --- #### 📜 **权限规则结构** 每个权限规则包含三个关键维度: ```yaml rules: - apiGroups: ["apps"] # API组 (核心API用空字符串"") resources: ["deployments"] # 资源类型 (pods, services等) verbs: ["get", "list"] # 操作动作 (create/delete/watch等) resourceNames: ["frontend"] # 可选:指定具体资源名称 ``` --- #### 👥 **授权主体类型** 1. **User**:外部用户(如通过证书认证的开发者) 2. **Group**:用户组(证书中的`O`字段,如`dev-group`) 3. **ServiceAccount**:服务账号(Pod内部使用的身份) --- #### ⚡ **典型操作流程**(以开发人员查看日志为例) 1. **创建角色**:定义允许访问`pods/log`的 Role 2. **绑定用户**:通过 RoleBinding 将 Role 关联到 User 3. **权限验证**:用户只能执行`kubectl logs <pod>`,其他操作被拒绝 --- #### 🌟 **核心优势** - **最小权限原则**:精确控制到`资源+操作`级别 - **权限组合复用**:ClusterRole 可被多个命名空间复用 - **动态生效**:权限修改实时生效,无需重启组件 - **审计追踪**:结合审计日志可追溯所有访问记录 --- #### 🛠️ **常用命令** ```bash # 检查用户权限 kubectl auth can-i list pods --as developer # 查看绑定关系 kubectl get rolebindings,clusterrolebindings -A # 诊断权限问题 kubectl describe role/pod-logs-reader ``` --- #### 📌 **特别注意** - **权限叠加**:用户最终权限是**所有绑定角色的并集** - **默认拒绝**:未明确允许的操作自动拒绝 - **服务账号**:Pod 自动挂载的 `default` SA 通常权限过高,建议显式配置
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值