12. Kubernetes进阶篇-权限控制

最新推荐文章于 2024-12-03 19:06:14 发布

王茗渠

最新推荐文章于 2024-12-03 19:06:14 发布

阅读量654

点赞数 11

分类专栏： Kubernetes 文章标签： kubernetes

本文链接：https://blog.csdn.net/weixin_40901913/article/details/140695144

版权

Kubernetes 专栏收录该内容

14 篇文章

订阅专栏

RBAC

简介

什么是RBAC

RBAC（Role-Based Access Control，基于角色的访问控制）是一种访问控制模型，它通过角色来控制对资源的访问权限。
RBAC 是用于管理和控制集群资源的访问权限的一种机制。它允许你定义角色（Roles）和角色绑定（RoleBindings），然后将这些角色绑定到特定的用户、用户组或服务账号。
在 RBAC 中，用户被分配一个或多个角色，每个角色都与一组特定的权限相关联。这些权限定义了用户可以执行的操作，如读取、写入、执行等。

RBAC 的顶级资源

角色（Roles）：
- 角色是一组权限的集合，可以应用于单个命名空间或集群范围。
- 角色可以定义对 API 对象的访问权限，如 Pod、Service、ConfigMap 等。
- 角色可以有范围限制，比如只能应用于特定的命名空间。
- 角色没有拒绝规则，只是附加允许；且角色有Namspace隔离，只能用于命名空间内。
集群角色（ClusterRoles）：
- 集群角色是角色的一种，它定义了集群范围内的权限。
- 集群角色可以被绑定到用户、用户组或服务账号。
- 集群角色绑定是角色绑定的一种，它将集群角色绑定到用户或用户组。
- 集群角色没有拒绝规则，只是附加允许；且集群角色没有namespace概念。
角色绑定（RoleBindings）：
- 角色绑定将角色分配给用户、用户组或服务账号。
- 角色绑定可以应用于单个命名空间或集群范围。
- 角色绑定定义了哪些用户或用户组可以访问哪些资源。
- 作用于namespace下，将Role或ClusterRole绑定到User、Group、ServiceAccount。
集群角色绑定（ClusterRoleBindings）：
- 集群角色绑定是将集群角色绑定到用户、用户组或服务账号的机制。
- 集群角色绑定可以在集群范围内应用。
- 作用于整个集群下（没有namespace概念），将Role或ClusterRole绑定到User、Group、ServiceAccount。

什么是ServiceAccount

ServiceAccount 是为 Pod 定义身份和权限的抽象。
每个 ServiceAccount 都关联一个特定的命名空间，并为该命名空间内的 Pod 提供一个唯一的身份。
ServiceAccount 还提供了对 Kubernetes API 的认证和授权。

ServiceAccount的关键特点

身份：ServiceAccount 定义了一个身份，它用于标识 Pod。ServiceAccount 的名称和命名空间用于生成对 API 的认证令牌。
认证：ServiceAccount 关联了一个令牌（token），该令牌用于对 Kubernetes API 进行认证。当 Pod 访问 API 时，它会使用这个令牌进行身份验证。
授权：ServiceAccount 可以与角色（Roles）和角色绑定（RoleBindings）关联，以定义 Pod 能够访问的资源。这些角色和绑定定义了 Pod 可以执行的操作和可以访问的资源。
自动创建：当使用 kubectl 创建 Deployment、ReplicaSet、DaemonSet 等资源时，Kubernetes 会自动为这些资源创建一个 ServiceAccount。
使用场景：ServiceAccount 通常用于 Kubernetes 集群中的服务，如数据库、缓存、消息队列等。这些服务需要访问 Kubernetes API 来管理资源或执行其他操作。

Roles和ClusterRoles可执行操作

Verbs 是一组用于描述对资源可以执行的操作的动词。
这些动词用于定义角色的权限规则，以及用户或用户组对 Kubernetes API 资源的访问权限。

create：创建一个资源。
delete：删除一个资源。
get：获取一个资源的详细信息。
list：获取资源的列表。
patch：部分更新资源。
update：完全更新资源。
watch：监听资源的变化。
proxy：使用 Kubernetes API 代理访问服务的端口。
use：使用某个资源（如 PersistentVolumeClaim）。

Roles和ClusterRoles可访问资源

访问的资源类型（Resources）指的是集群中可以访问的对象。
这些资源类型通常与 Kubernetes API 对象相关，包括 Pod、Service、Deployment、ConfigMap 等。

Pods：Pods 是 Kubernetes 中的最小调度单元，用于运行应用程序。
Services：Services 定义了 Pod 的逻辑访问点，可以定义负载均衡和 DNS 名称。
Deployments：Deployments 用于自动化 Pod 的创建、更新和扩展。
ReplicaSets：ReplicaSets 用于确保集群中 Pod 的副本数量始终等于期望的数量。
DaemonSets：DaemonSets 确保每个节点上运行一个 Pod 的副本。
Jobs：Jobs 用于运行有终点的批处理作业。
CronJobs：CronJobs 用于运行定期作业。
StatefulSets：StatefulSets 用于部署有状态应用程序，并确保每个 Pod 都有唯一的标识符。
ConfigMaps：ConfigMaps 用于存储非敏感的配置数据，如环境变量。
Secrets：Secrets 用于存储敏感信息，如密码、OAuth 令牌等。
Namespaces：Namespaces 用于隔离集群中的资源，每个命名空间都有自己的资源。
PersistentVolumes：PersistentVolumes 提供了集群内持久化存储的抽象。
PersistentVolumeClaims：PersistentVolumeClaims 用于请求使用 PersistentVolumes 的存储。
Configurations：Configurations 用于定义 ConfigMap 的集合。
Roles：Roles 用于定义命名空间内的访问权限。
ClusterRoles：ClusterRoles 用于定义集群范围的访问权限。
RoleBindings：RoleBindings 将角色绑定到用户、用户组或服务账号。
ClusterRoleBindings：ClusterRoleBindings 将 ClusterRoles 绑定到用户、用户组或服务账号。
ServiceAccounts：ServiceAccounts 为 Pod 定义了身份和权限。
PriorityClasses：PriorityClasses 用于为 Pod 定义优先级。
PriorityLevelConfigurations：PriorityLevelConfigurations 用于定义优先级级别的配置。

Roles&ClusterRoles

创建Role&ClusterRole

Role

#格式：
kubectl create role 角色名称 --namespace=命名空间 --verb=可执行操作 --resource=可访问资源

#举例：
kubectl create role test-role --namespace=default --verb=get,list,update --resource=pods

ClusterRole

#格式：
kubectl create clusterrole 集群角色名称 --verb=可执行操作 --resource=可访问资源

#举例：
kubectl create clusterrole test-cluster-role --verb=list,get,update,watch --resource=pods

查看Role&ClusterRole

Role

#格式：
kubectl get role --namespace=命名空间 角色名称

#举例：
kubectl get role --namespace=default test-role

ClusterRole

#格式：
kubectl get clusterrole 集群角色名称

#举例：
kubectl get clusterrole test-cluster-role

修改Role&ClusterRole

Role

#格式：
kubectl edit role --namespace=命名空间 角色名称

#举例：
kubectl edit role --namespace default test-role

ClusterRole

#格式：
kubectl edit clusterrole 集群角色名称

#举例：
kubectl edit clusterrole test-cluster-role

删除Role&ClusterRole

Role

#格式：
kubectl delete role --namespace=命名空间 角色名称

#举例：
kubectl delete role --namespace default test-role

ClusterRole

#格式：
kubectl delete clusterrole 集群角色名称

#举例：
kubectl delete clusterrole test-cluster-role

RoleBinding&ClusterRoleBinding

绑定RoleBinding&ClusterRoleBinding

RoleBinding

#格式：
kubectl create rolebinding 角色绑定名称 --role=角色名称[--clusterrole=集群角色名称] --user=用户名称 --group=用户组名称 --namespace=命名空间

#举例：
kubectl create rolebinding test-rolebinding --role=test-role --user=wangmingqu --group=yunweizu --namespace=default

ClusterRoleBinding

#格式：
kubectl create clusterrolebinding 集群角色绑定名称 --clusterrole=集群角色名称 --user=用户名称 --group=用户组名称

#举例：
kubectl create clusterrolebinding test-clusterrolebinding --clusterrole=test-cluster-role --user=wangmingqu --group=yunweizu

查看RoleBinding&ClusterRoleBinding

RoleBinding

#格式：
kubectl get rolebindings.rbac.authorization.k8s.io --namespace=命名空间 角色绑定名称

#举例：
kubectl get rolebindings.rbac.authorization.k8s.io --namespace=default test-rolebinding

ClusterRoleBinding

#格式：
kubectl get clusterrolebindings.rbac.authorization.k8s.io 集群角色绑定名称

#举例：
kubectl get clusterrolebindings.rbac.authorization.k8s.io test-clusterrolebinding

修改RoleBinding&ClusterRoleBinding

RoleBinding

#格式：
kubectl edit rolebindings.rbac.authorization.k8s.io --namespace=命名空间 角色绑定名称

#举例：
kubectl edit rolebindings.rbac.authorization.k8s.io --namespace=default test-rolebinding

ClusterRoleBinding

#格式：
kubectl edit clusterrolebindings.rbac.authorization.k8s.io 集群角色绑定名称

#举例：
kubectl edit clusterrolebindings.rbac.authorization.k8s.io test-clusterrolebinding

解绑RoleBinding&ClusterRoleBinding

RoleBinding

#格式：
kubectl delete rolebindings.rbac.authorization.k8s.io --namespace=命名空间 角色绑定名称

#举例：
kubectl delete rolebindings.rbac.authorization.k8s.io --namespace=default test-rolebinding

ClusterRoleBinding

#格式：
kubectl delete clusterrolebindings.rbac.authorization.k8s.io 集群角色绑定名称

#举例：
kubectl delete clusterrolebindings.rbac.authorization.k8s.io test-clusterrolebinding

ClusterRole聚合

什么是ClusterRole aggregationRule

ClusterRole 的 aggregationRule 是一个用于自动将多个 ClusterRole 的权限规则聚合到一个 ClusterRole 中的功能。
可以创建一个主 ClusterRole，它自动包含了所有匹配特定标签选择器的 ClusterRole 的权限规则。

ClusterRole aggregationRule举例

编辑yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-ming                                    #创建一个名字叫role-ming 的集群角色
  labels:
    app: role-ming                                   #创建集群角色的标签，用于下方集群角色聚合时使用
rules:
  - apiGroups:
      - "*"
    verbs:
      - list
      - watch
      - get
    resources:
      - pods
      - nodes
      - services

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-qu                                    #创建一个名字叫role-qu 的集群角色
  labels:
    app: role-qu                                   #创建集群角色的标签，用于下方集群角色聚合时使用
rules:
  - apiGroups:
      - "*"
    verbs:
      - list
      - watch
      - get
    resources:
      - pods
      - nodes
      - services

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: role-aggregationrule
  labels:
    app: role-aggregationrule

aggregationRule:                                      #用于自动聚合匹配特定标签选择器的其他 ClusterRole 的权限规则
  clusterRoleSelectors:                               #集群角色选择器
    - matchLabels:
        app: role-ming                                #聚合所有带有标签 app: role-ming的集群角色
    - matchLabels:
        app: role-qu                                  #聚合所有带有标签 app: role-qu的集群角色

创建聚合

kubectl create -f clusterrole-aggregationrule.yaml

查看ClusterRole

kubectl get clusterrole | grep role
# role-aggregationrule                                                   2024-07-23T06:28:53Z
# role-ming                                                              2024-07-23T06:28:53Z
# role-qu                                                                2024-07-23T06:28:53Z

查看聚合

kubectl get clusterrole role-aggregationrule -oyaml
# aggregationRule:
#   clusterRoleSelectors:
#   - matchLabels:
#       app: role-ming
#   - matchLabels:
#       app: role-qu
# apiVersion: rbac.authorization.k8s.io/v1
# kind: ClusterRole
# metadata:
#   creationTimestamp: "2024-07-23T06:28:53Z"
#   labels:
#     app: role-aggregationrule
#   managedFields:
#   - apiVersion: rbac.authorization.k8s.io/v1
#     fieldsType: FieldsV1
#     fieldsV1:
#       f:rules: {}
#     manager: kube-controller-manager
#     operation: Update
#     time: "2024-07-23T06:28:53Z"
#   - apiVersion: rbac.authorization.k8s.io/v1
#     fieldsType: FieldsV1
#     fieldsV1:
#       f:aggregationRule:
#         .: {}
#         f:clusterRoleSelectors: {}
#       f:metadata:
#         f:labels:
#           .: {}
#           f:app: {}
#     manager: kubectl-create
#     operation: Update
#     time: "2024-07-23T06:28:53Z"
#   name: role-aggregationrule
#   resourceVersion: "181596"
#   uid: a3017bbc-1796-4144-baac-0a6ac55f102b
# rules:
# - apiGroups:
#   - '*'
#   resources:
#   - pods
#   - nodes
#   - services
#   verbs:
#   - list
#   - watch
#   - get

综合应用

注意：生产环境中很少使用命令方式创建准入控制，准入控制的细节可以参考KubeSphere的学习笔记。

案例说明

允许开发人员读取和部署命名空间development中的Pods。
允许运维人员读取、更新和删除命名空间production中的所有资源。

创建命名空间

编辑yaml文件

# development-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: development

# production-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: production

创建服务

kubectl apply -f development-namespace.yaml
kubectl apply -f production-namespace.yaml

创建角色

为开发人员和运维人员创建角色。

编辑yaml

# developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]

# operator-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: resource-manager
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "watch", "list", "create", "update", "patch", "delete"]

创建服务

kubectl apply -f developer-role.yaml
kubectl apply -f operator-role.yaml

创建角色绑定

创建角色绑定，将角色与用户或组关联起来。

编辑yaml文件

# developer-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: "dev-user" # 假设这是开发人员的用户名
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

# operator-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: operator-binding
  namespace: production
subjects:
- kind: User
  name: "ops-user" # 假设这是运维人员的用户名
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: resource-manager
  apiGroup: rbac.authorization.k8s.io

创建服务

kubectl apply -f developer-rolebinding.yaml
kubectl apply -f operator-rolebinding.yaml

测试权限

模拟dev-user和ops-user的行为。

开发人员权限

#登录开发用户（假设使用kubectl配置了dev-user的上下文）
kubectl config use-context dev-user

#尝试获取development命名空间中的Pods
kubectl get pods -n development

#尝试在development命名空间中创建一个Pod
# test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: development
spec:
  containers:
  - name: test-container
    image: nginx:latest

#创建Pod
kubectl apply -f test-pod.yaml

#尝试获取production命名空间中的Pods（应该被拒绝）
kubectl get pods -n production

运维人员权限

#登录运维用户（假设使用kubectl配置了ops-user的上下文）
kubectl config use-context ops-user

#尝试获取production命名空间中的所有资源
kubectl get all -n production

#尝试在production命名空间中创建一个Pod
# prod-test-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: prod-test-pod
  namespace: production
spec:
  containers:
  - name: prod-test-container
    image: nginx:latest

#创建Pod
kubectl apply -f prod-test-pod.yaml

#尝试获取development命名空间中的资源（应该被拒绝）
kubectl get all -n development

高级RBAC配置

ClusterRole 和 ClusterRoleBinding：为用户提供跨所有命名空间的权限。
资源范围限制：限制用户只能访问特定的资源实例（例如，只能访问特定标签的Pods）。
聚合角色：将多个角色组合在一起，创建更复杂的权限集。

编辑yaml

# clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-wide-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  
# clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-wide-pod-reader-binding
subjects:
- kind: User
  name: "cluster-user" # 假设这是需要跨集群读取Pods的用户名
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-wide-pod-reader
  apiGroup: rbac.authorization.k8s.io

创建服务

kubectl apply -f clusterrole.yaml
kubectl apply -f clusterrolebinding.yaml

QoS

简介

什么是QoS

QoS（Quality of Service，服务质量）是一种网络技术，它允许通过网络传输的数据获得不同的优先级。
QoS的目的是确保某些类型的数据流量（如视频会议、VoIP电话或关键业务数据）在网络拥塞时能够获得比其他非关键流量更高的优先级，从而保证重要数据流的性能和可靠性。

Kubernetes的QoS

在Kubernetes中，QoS（Quality of Service）指的是对运行在Pods中的容器如何分配资源的优先级和策略。
Kubernetes定义了三种QoS级别，这些级别基于Pod中容器的资源请求（request）和资源限制（limit）来确定。

三种QoS级别

Guaranteed（保证）：当Pod中的所有容器都设置了相同的CPU和内存请求与限制时，Pod被赋予Guaranteed级别的QoS。这意味着Pod将获得它所请求的资源的完全保障。
Burstable（可突发）：如果Pod中的至少一个容器设置了资源请求小于限制，那么Pod的QoS级别为Burstable。这类Pod在资源充足时可以使用超出请求的资源，但在资源紧张时可能被限制。
BestEffort（尽力而为）：如果Pod中的所有容器都没有设置资源请求和限制，或者只有资源限制没有资源请求，那么Pod的QoS级别为BestEffort。系统会尽量分配资源给这类Pod，但在资源不足时，它们将是最先被杀死的。

注意：在Kubernetes中，每个Pod都会被分配一个QoS等级，这个等级决定了Pod的调度优先级和驱逐优先级，以及Pod在不同节点上的资源分配策略。

QoS的关键点

CPU：对于Guaranteed QoS的Pod，它们将获得CPU资源的完全保障。对于Burstable和BestEffort QoS的Pod，它们可能会在CPU资源空闲时获得更多的CPU时间。
内存：内存分配更为严格。Guaranteed QoS的Pod将获得它们请求的内存。对于Burstable和BestEffort QoS的Pod，如果系统内存不足，它们可能会被OOM Killer（Out-of-Memory Killer）杀死。

注意事项

Pod的QoS等级是根据容器的资源要求和系统中其他Pod的资源使用情况来判断的。
容器的资源要求可以通过在容器定义中指定相应的request和limit来定义。
Kubernetes会根据这些要求来计算Pod的QoS等级，并据此进行资源分配和调度决策。

应用

BestEffort

说明
- 这是最低级别的QoS，适用于那些不需要保证资源使用的Pod。
- 在这种QoS等级下，Pod中的容器没有指定CPU和内存的requests和limits，因此它们可以使用任何可用的资源，但也可能因为资源不足而被系统驱逐。
- BestEffort Pod通常用于一些非关键的任务，如系统服务或日志收集器。
编辑yaml

就是没有进行资源限制的Pod

apiVersion: v1  
kind: Pod  
metadata:  
  name: effort-pod  
spec:  
  containers:  
  - name: nginx-web
    image: nginx

Burstable

说明
- 这种QoS等级适用于那些需要一定量的CPU和内存资源，但也可能需要超过这些资源的Pod。
- Burstable Pod被分配了一定的CPU和内存资源，但当系统中其他Pod消耗了更多的资源时，它们的资源可用性可能会受到影响。
- 容器能够使用超过所分配的资源量（称为“突发资源”），但实际可用资源量取决于其他Pod和系统资源占用情况。
编辑yaml

apiVersion: v1  
kind: Pod  
metadata:  
  name: burstable-pod  
spec:  
  containers:  
  - name: nginx-web  
    image: nginx  
    resources:  
      requests:  
        cpu: 100m  
        memory: 100Mi

Guaranteed

说明
- 这是最高级别的QoS，适用于那些需要保证资源使用的Pod。
- 在这种QoS等级下，Pod里的每个容器都必须有内存/CPU限制和请求，而且值必须相等。
- Kubernetes会严格限制这些Pod的资源使用，确保它们始终有足够的资源来运行，并且不会被其他Pod或系统资源竞争所影响。
编辑yaml

apiVersion: v1  
kind: Pod  
metadata:  
  name: guaranteed-pod  
spec:  
  containers:  
  - name: nignx-web  
    image: nginx  
    resources:  
      requests:  
        cpu: 500m  
        memory: 500Mi  
      limits:  
        cpu: 500m  
        memory: 500Mi

ResourceQuota

简介

什么是ResourceQuota

ResourceQuota是一种资源配额机制，它用于限制一个命名空间内资源的使用总量。
资源配额可以应用于多种资源类型，包括Pod、镜像、存储、网络插槽等。
ResourceQuota允许集群管理员为命名空间设置资源限制，以防止资源被过度消耗或浪费。

关键特点

限制资源总量：ResourceQuota允许管理员为命名空间设置资源限制，确保命名空间内的资源使用不会超过这些限制。
跨多个API组：资源配额可以跨多个API组应用，这意味着它可以限制来自不同API组的资源使用。
灵活的资源类型：资源配额可以针对多种资源类型设置限制，包括但不限于Pod、镜像、存储、网络插槽等。
适用于命名空间内所有Pod：资源配额适用于命名空间内的所有Pod，包括系统Pod。
动态更新：资源配额可以动态更新，管理员可以根据需要调整限制。
与其他资源管理机制结合：资源配额可以与Pod资源请求和限制、QoS策略等资源管理机制结合使用，以实现更精细的资源控制。

注意事项

ResourceQuota 的应用范围是命名空间级别的，每个命名空间可以有一个或多个 ResourceQuota 对象。
ResourceQuota 只限制命名空间中资源的创建和更新操作，对于已经存在的资源对象，修改 ResourceQuota 的配额值不会影响它们的使用。
在默认情况下，许多 Kubernetes 发行版都会启用这个插件，以确保 ResourceQuota 的功能可用。
ResourceQuota 的主要作用是在多用户共享 Kubernetes 集群时，确保每个命名空间中的资源使用量不会超过其配额限制，从而避免资源过度消耗和竞争。

应用

编辑yaml

apiVersion: v1  
kind: ResourceQuota  
metadata:  
  name: resource-quota-example  
  namespace: default            # 要被设置的命名空间
spec:  
  hard:  
    pods: "10"                  # 命名空间中允许的最大 Pod 数量  
    services: "5"               # 命名空间中允许的最大 Service 数量  
    replicationcontrollers: "2" # 命名空间中允许的最大 ReplicationController 数量  
    resourcequotas: "1"         # 命名空间中允许的最大 ResourceQuota 数量  
    secrets: "10"               # 命名空间中允许的最大 Secret 数量  
    persistentvolumeclaims: "4" # 命名空间中允许的最大 PersistentVolumeClaim 数量  
    services.loadbalancers: "1" # 允许的最大 LoadBalancer 类型 Service 数量  
    requests.cpu: "10"          # 命名空间中所有 Pods 可以请求的 CPU 总量  
    requests.memory: "10Gi"     # 命名空间中所有 Pods 可以请求的内存总量  
    limits.cpu: "1024"          # 命名空间中所有 Pods 可以使用的 CPU 总量上限  
    limits.memory: "200Gi"      # 命名空间中所有 Pods 可以使用的内存总量上限

创建服务

kubectl create -f resourcequota-namespace.yaml

LimitRange

简介

什么是LimitRange

LimitRange是一种资源配额机制，它用于限制一个命名空间内所有Pod或Container 的资源请求和限制。
LimitRange对象允许集群管理员为命名空间设置资源请求和限制的上下限，以确保资源使用在合理范围内。

关键特点

限制资源请求和限制：LimitRange允许管理员为命名空间内的Pod设置资源请求和限制的上下限。这有助于防止资源被过度消耗或浪费。
跨多个API组：资源配额可以跨多个API组应用，这意味着它可以限制来自不同API组的资源使用。
灵活的资源类型：资源配额可以针对多种资源类型设置限制，包括但不限于CPU、内存、磁盘等。
适用于命名空间内所有Pod：资源配额适用于命名空间内的所有Pod，包括系统Pod。
动态更新：资源配额可以动态更新，管理员可以根据需要调整限制。

注意事项

LimitRange 的使用在 Kubernetes 1.10 版本及之后的版本中默认启用，并且在许多 Kubernetes 发行版中也是默认启用的。

应用

编辑yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-example
  namespace: default												#限制作用于哪个命名空间
spec:
  limits:
  - type: Pod														#Pod级别的限制，作用于整个namespace的Pod
    max:															#Pod可以使用的最大资源量。
      cpu: "2"														#CPU限制
      memory: "2Gi"													#MEM限制
    min:															#Pod必须使用的最小资源量。
      cpu: "500m"													#CPU申请资源
      memory: "64Mi"												#MEM申请资源
#    default:														#如果Pod没有设置资源请求和限制，将使用的默认值。如设置了Pod则此处需要注释
#      cpu: "1"														#CPU默认资源
#      memory: "512Mi"												#MEM默认资源
  - type: Container													#容器级别的限制
    max:															#容器可以使用的最大资源量。
      cpu: "1"
      memory: "1Gi"
    min:															#容器必须使用的最小资源量。
      cpu: "200m"
      memory: "32Mi"
#    defaultRequest:												#容器默认的资源请求量。如设置了Container则此处需要注释
#      cpu: "500m"
#      memory: "256Mi"

创建服务

kubectl create -f limitrange-pod-container.yaml