19、Kubernetes核心技术 - 资源限制

这篇具有很好参考价值的文章主要介绍了19、Kubernetes核心技术 - 资源限制。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

一、概述

二、Kubernetes 中的资源单位

2.1、CPU资源单位

2.2、内存资源单位

三、Pod资源限制

四、namespace资源限制

4.1、为命名空间配置内存和 CPU 配额

4.2、为命名空间配置默认的内存请求和限制

4.3、为命名空间配置默认的CPU请求和限制

五、超过容器限制的内存


一、概述

当定义 Pod 时,我们可以定义多个容器,我们知道,容器的程序要运行肯定是要占用一定资源的,比如CPU和内存等,默认情况下,Pod运行没有CPU和内存的限额。如果不对某个容器的资源进行限制,那么它就可能消耗大量资源,导致其他容器无法运行。

针对这样情况,kubernetes提供了对内存和CPU资源进行配额的机制,这种机制主要通过配置spec.containers[].resources选项实现,resources提供了2个主要的参数,如下:

  • limits

用于限制运行时容器的最大占用资源,当容器占用资源超过limit时就会被终止,并将进行重启。当为容器指定了 limit 资源时,kubelet 就可以确保运行的容器不会使用超出所设限制的资源,设置为0表示对使用的资源不做限制, 可无限的使用。

  • requests

用于设置容器需要的最小资源,如果环境资源不够,容器将无法启动。当为Pod中的容器指定了 request资源时,调度器( kube-scheduler )就使用该信息来决定将 Pod 调度到哪个节点上,只有当前节点上可分配的资源量 >= request 时才允许将容器调度到该节点。

如果 Pod 运行所在的节点具有足够的可用资源,容器可能(且可以)使用超出对应资源 request 属性所设置的资源量。不过,容器不可以使用超出其资源 limit 属性所设置的资源量。

例如,如果你将容器的 memory 的请求量设置为 256 MiB,而该容器所处的 Pod 被调度到一个具有 8 GiB 内存的节点上,并且该节点上没有其他 Pod 运行,那么该容器就可以尝试使用更多的内存。

如果你将某容器的 memory 限制设置为 4 GiB,kubelet (和容器运行时)就会确保该限制生效。 容器运行时会禁止容器使用超出所设置资源限制的资源。 例如:当容器中进程尝试使用超出所允许内存量的资源时,系统内核会将尝试申请内存的进程终止, 并引发内存不足(OOM)错误。

针对每个容器,你都可以指定其资源限制和请求,包括如下选项:

pod.spec.containers.resources:
	requests: <map[string]string>
		cpu:		// 定义创建容器时预分配的CPU资源
		memory:		// 定义创建容器时预分配的内存资源
	limits: <map[string]string>
		cpu:		// 定义cpu的资源上限 
		memory:		// 定义内存的资源上限

二、Kubernetes 中的资源单位

2.1、CPU资源单位

CPU 资源的限制和请求以 “cpu” 为单位。 在 Kubernetes 中,一个 CPU 等于 1 个物理 CPU 核 或者 1 个虚拟核, 取决于节点是一台物理主机还是运行在某物理主机上的虚拟机。

也可以表达带小数 CPU 的请求。 当定义一个容器,将其 spec.containers[].resources.requests.cpu 设置为 0.5 时, 所请求的 CPU 是请求 1.0 CPU 时的一半。 对于 CPU 资源单位,数量 表达式 0.1 等价于表达式 100m,可以看作 “100 millicpu”(“一百毫核”)。

CPU 资源总是设置为资源的绝对数量而非相对数量值。 例如,无论容器运行在单核、双核或者 48-核的机器上,500m CPU 表示的是大约相同的计算能力。

2.2、内存资源单位

以字节为单位。可以以整数表示,或者以10为底数的指数的单位(E、P、T、G、M、K)来表示, 或者使用对应的 2 的幂数:Ei、Pi、Ti、Gi、Mi、Ki(Ei、Pi、Ti、Gi、Mi、Ki)来表示。

三、Pod资源限制

vim resource-limit.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          resources:
            limits:	# 限制最大资源,上限
              memory: 1Gi 		# 定义内存的资源上限
              cpu: 1  		# 定义cpu的资源上限
            requests:	#请求资源(最小,下限)
              memory: 256Mi   	# 定义创建容器时预分配的内存资源
              cpu: 100m   		# 定义创建容器时预分配的CPU资源

cpu的单位m:代表“千分之一核心”,譬如100m的含义是指100/1000核心,即10%,表示每 1000 毫秒容器可以使用的 CPU 时间总量为 0.1*1000 毫秒。

注意:Gi和G,Mi和M的区别,官网解释:Mi表示(1Mi=1024×1024),M表示(1M=1000×1000)(其它单位类推, 如Ki/K Gi/G);

如上,nginx容器的request值为0.1个cpu和256MiB内存,nginx容器的limit 值为1个cpu和1GiB内存。

创建并查看pod:

$ kubectl apply -f resource-limit.yaml 
deployment.apps/nginx created

$ kubectl get pod -o wide
NAME                   READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
nginx-8c777cc7-6jj8x   1/1     Running   0          9s    192.168.1.3   node01   <none>           <none>

可以看到,pod被调度到node01节点,我们查看节点描述信息:

$ kubectl describe nodes node01

19、Kubernetes核心技术 - 资源限制,# Kubernetes,kubernetes,容器,云原生,k8s,k8s资源限制 

四、namespace资源限制

4.1、为命名空间配置内存和 CPU 配额

默认情况下, Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用 Kubernetes 资源配额, 管理员(也称为集群操作者)可以在一个指定的命名空间内限制集群资源的使用与创建。 在命名空间中,一个 Pod 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。

如果需要为命名空间设置容器可用的内存和 CPU 总量,可以通过 ResourceQuota 对象来定义,对每个命名空间的资源消耗总量提供限制。使用 ResourceQuota 限制命名空间中所有容器的内存请求总量、内存限制总量、CPU 请求总量和CPU 限制总量。

需要理解的是ResourceQuota是给命名空间去配额,而不是给pod去配额,是所有pod运行的总量和。

下面是 ResourceQuota 的示例清单:

vim resource-quota.yaml 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    requests.cpu: "1"		# 所有非终止状态的 Pod,其 CPU 需求总量不能超过该值。
    requests.memory: 1Gi	# 所有非终止状态的 Pod,其内存需求总量不能超过该值。
    limits.cpu: "2"			# 所有非终止状态的 Pod,其 CPU 限额总量不能超过该值。
    limits.memory: 2Gi		# 所有非终止状态的 Pod,其内存限额总量不能超过该值。

创建并查看 ResourceQuota 详情:

$ kubectl create -f resource-quota.yaml --namespace=default
resourcequota/my-resource-quota created

$ kubectl get resourcequota my-resource-quota --namespace=default --output=yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  creationTimestamp: "2023-01-30T05:12:54Z"
  name: my-resource-quota
  namespace: default
  resourceVersion: "1753"
  uid: f6170a87-f22f-45f7-9dac-c721f9eb1a44
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: "0"
    limits.memory: "0"
    requests.cpu: "0"
    requests.memory: "0"

ResourceQuota 在 default 命名空间中设置了如下要求:

  • 在该命名空间中的每个 Pod 的所有容器都必须要有内存请求和限制,以及 CPU 请求和限制。
  • 在该命名空间中所有 Pod 的内存请求总和不能超过 1 GiB。
  • 在该命名空间中所有 Pod 的内存限制总和不能超过 2 GiB。
  • 在该命名空间中所有 Pod 的 CPU 请求总和不能超过 1 cpu。
  • 在该命名空间中所有 Pod 的 CPU 限制总和不能超过 2 cpu。

接下来,我们创建一个Pod,清单如下:vim quota-mem-cpu-nginx-pod.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "800Mi"
        cpu: "800m"
      requests:
        memory: "600Mi"
        cpu: "400m"

创建并查看Pod:

$ kubectl apply -f quota-mem-cpu-nginx-pod.yaml 
pod/nginx created

$ kubectl get pod -o wide 
NAME    READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          17s   192.168.1.3   node01   <none>           <none>

 可以看到,Pod处于正常运行状态,接着再次查看 ResourceQuota 的详情:

$ kubectl get resourcequota my-resource-quota --namespace=default --output=yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  creationTimestamp: "2023-01-30T05:12:54Z"
  name: my-resource-quota
  namespace: default
  resourceVersion: "1943"
  uid: f6170a87-f22f-45f7-9dac-c721f9eb1a44
spec:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
status:
  hard:
    limits.cpu: "2"
    limits.memory: 2Gi
    requests.cpu: "1"
    requests.memory: 1Gi
  used:
    limits.cpu: 800m
    limits.memory: 800Mi
    requests.cpu: 400m
    requests.memory: 600Mi

输出结果显示了配额以及有多少配额已经被使用,可以看到 Pod 的内存和 CPU 请求值及限制值没有超过配额。

我们再次尝试创建另外一个Pod,清单如下:vim quota-mem-cpu-redis-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    resources:
      limits:
        memory: "1Gi"
        cpu: "800m"
      requests:
        memory: "700Mi"
        cpu: "400m"

在清单中,你可以看到 Pod 的内存请求为 700 MiB。 请注意新的内存请求与已经使用的内存请求之和超过了内存请求的配额: 600 MiB + 700 MiB > 1 GiB。

尝试创建 Pod:

$ kubectl apply -f quota-mem-cpu-redis-pod.yaml 
Error from server (Forbidden): error when creating "quota-mem-cpu-redis-pod.yaml": pods "redis" is forbidden: exceeded quota: my-resource-quota, requested: requests.memory=700Mi, used: requests.memory=600Mi, limited: requests.memory=1Gi

可以看到,第二个 Pod 不能被创建成功。输出结果显示创建第二个 Pod 会导致内存请求总量超过内存请求配额。

4.2、为命名空间配置默认的内存请求和限制

如果想对命名空间中的单个容器而不是所有容器进行限制,需要使用 LimitRange对象。

LimitRange 是限制命名空间内可为每个适用的对象类别 (例如 Pod 或 PersistentVolumeClaim) 指定的资源分配量(限制和请求)的策略对象。

一个 LimitRange(限制范围) 对象提供的限制能够做到:

  • 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
  • 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
  • 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
  • 设置一个命名空间中对计算资源的默认申请/限制值,并且自动的在运行时注入到多个 Container 中。

当某命名空间中有一个 LimitRange 对象时,将在该命名空间中实施 LimitRange 限制。

以下为 LimitRange 的示例清单。 清单中声明了默认的内存请求和默认的内存限制。

vim memory-default.yaml 

apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
spec:
  limits:
    - default:
        memory: 512Mi
      defaultRequest:
        memory: 256Mi
      type: Container

在default命名空间创建限制范围:  

$ kubectl create -f memory-default.yaml --namespace=default
limitrange/mem-limit-range created

如上,如果我们在default命名空间中创建Pod,并且该 Pod 中所有容器都没有声明自己的内存请求和内存限制,那么控制面会将内存的默认请求值 256MiB 和默认限制值 512MiB 应用到 Pod 上。

以下为只包含一个nginx容器的 Pod 的清单,该容器没有声明内存请求和限制。

vim nginx-without-resource.yaml 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx

 创建并查看pod:

$ kubectl apply -f nginx-without-resource.yaml 
deployment.apps/nginx created

$ kubectl get pod       
NAME                     READY   STATUS    RESTARTS   AGE
nginx-748c667d99-gq5rs   1/1     Running   0          13s

19、Kubernetes核心技术 - 资源限制,# Kubernetes,kubernetes,容器,云原生,k8s,k8s资源限制 

可以看到,输出显示nginx容器已经被指定一个默认的最小内存请求256 MiB和一个默认的最大内存限制512 Mib。

4.3、为命名空间配置默认的CPU请求和限制

以下为 LimitRange 的示例清单。 清单中声明了默认 CPU 请求和默认 CPU 限制。

vim cpu-default.yaml

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-limit-range
spec:
  limits:
    - default:
        cpu: 1
      defaultRequest:
        cpu: 0.5
      type: Container

在命名空间 default中创建 LimitRange 对象:

$ kubectl create -f cpu-default.yaml --namespace=default
limitrange/cpu-limit-range created

如果在 default命名空间创建一个Pod,并且该 Pod 中所有容器都没有声明自己的 CPU 请求和 CPU 限制, 控制面会将 CPU 的默认请求值 0.5 和默认限制值 1 应用到 Pod 上。

以下为只包含一个nginx容器的 Pod 的清单,该容器没有声明 CPU 请求和限制。

vim nginx-without-cpu-resource.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx

创建并查看pod:

$ kubectl apply -f nginx-without-cpu-resource.yaml 
deployment.apps/nginx created

$ kubectl get pod 
NAME                     READY   STATUS    RESTARTS   AGE
nginx-748c667d99-p2mqk   1/1     Running   0          69s

19、Kubernetes核心技术 - 资源限制,# Kubernetes,kubernetes,容器,云原生,k8s,k8s资源限制 

可以看到,输出显示nginx容器已经被指定默认的 最小CPU请求为0.5和默认的最大CPU限制值为1。

五、超过容器限制的内存

当节点拥有足够的可用内存时,容器可以使用其请求的内存。 但是,容器不允许使用超过其限制的内存。 如果容器分配的内存超过其限制,该容器会成为被终止的候选容器。 如果容器继续消耗超出其限制的内存,则终止容器。 如果终止的容器可以被重启,则 kubelet 会重新启动它,就像其他任何类型的运行时失败一样。

我们看一个示例,资源清单如下:

vim oom-demo.yaml

apiVersion: v1
kind: Pod
metadata:
  name: stress
spec:
  containers:
  - name: stress
    image: polinux/stress
    resources:
      requests:
        memory: "50Mi"
      limits:
        memory: "100Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]

这里定义了一个容器,该容器的内存请求为 50 MiB,内存限制为 100 MiB。并且在配置文件的 args 部分中,可以看到容器会尝试分配 250 MiB 内存,这远高于 100 MiB 的限制。

创建并查看Pod:

$ kubectl apply -f oom-demo.yaml 
pod/stress created

$ kubectl get pod -o wide 
NAME     READY   STATUS      RESTARTS      AGE   IP            NODE     NOMINATED NODE   READINESS GATES
stress   0/1     OOMKilled   2 (26s ago)   30s   192.168.1.3   node01   <none>           <none>

可以看到,容器已经被杀死,并且kubelet 会尝试重启它。获取容器更详细的状态信息:

$ kubectl get pod stress -o yaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/containerID: b371e450fa7a62b0a3ad0744ef21c05aef265b049ad754ef6296f95c979fdb00
    cni.projectcalico.org/podIP: 192.168.1.3/32
    cni.projectcalico.org/podIPs: 192.168.1.3/32
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"stress","namespace":"default"},"spec":{"containers":[{"args":["--vm","1","--vm-bytes","250M","--vm-hang","1"],"command":["stress"],"image":"polinux/stress","name":"stress","resources":{"limits":{"memory":"100Mi"},"requests":{"memory":"50Mi"}}}]}}
  creationTimestamp: "2023-01-30T06:20:50Z"
  name: stress
  namespace: default
  resourceVersion: "2112"
  uid: a2ee4e2f-2e12-4403-89ba-502956ab4f70
spec:
  containers:
  - args:
    - --vm
    - "1"
    - --vm-bytes
    - 250M
    - --vm-hang
    - "1"
    command:
    - stress
    image: polinux/stress
    imagePullPolicy: Always
    name: stress
    resources:
      limits:
        memory: 100Mi
      requests:
        memory: 50Mi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-sckdb
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: node01
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-sckdb
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2023-01-30T06:20:50Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2023-01-30T06:21:38Z"
    message: 'containers with unready status: [stress]'
    reason: ContainersNotReady
    status: "False"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2023-01-30T06:21:38Z"
    message: 'containers with unready status: [stress]'
    reason: ContainersNotReady
    status: "False"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2023-01-30T06:20:50Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: containerd://a735f113298aa42255bda94e798291330e9db922ebdc820855be290a049e9dad
    image: docker.io/polinux/stress:latest
    imageID: docker.io/polinux/stress@sha256:b6144f84f9c15dac80deb48d3a646b55c7043ab1d83ea0a697c09097aaad21aa
    lastState:
      terminated:
        containerID: containerd://a735f113298aa42255bda94e798291330e9db922ebdc820855be290a049e9dad
        exitCode: 1
        finishedAt: "2023-01-30T06:22:19Z"
        reason: OOMKilled
        startedAt: "2023-01-30T06:22:19Z"
    name: stress
    ready: false
    restartCount: 4
    started: false
    state:
      waiting:
        message: back-off 1m20s restarting failed container=stress pod=stress_default(a2ee4e2f-2e12-4403-89ba-502956ab4f70)
        reason: CrashLoopBackOff
  hostIP: 172.30.2.2
  phase: Running
  podIP: 192.168.1.3
  podIPs:
  - ip: 192.168.1.3
  qosClass: Burstable

19、Kubernetes核心技术 - 资源限制,# Kubernetes,kubernetes,容器,云原生,k8s,k8s资源限制 

输出结果显示:由于内存溢出(OOM),容器已被杀掉。文章来源地址https://www.toymoban.com/news/detail-809377.html

到了这里,关于19、Kubernetes核心技术 - 资源限制的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kubernetes 对Pod的资源限制详解;

    limits 限制容器最高使用多少资源: resources.limits.cpu resources.limits.memory request 是容器使用的最小资源申请,也就是说这个容器里的服务至少给它多少资源才能运行,作为容器调度时资源分配的依据:(对于k8s来说是预留,主要用作于k8s对node资源的一个规划和分配) requests一般小于

    2024年02月07日
    浏览(47)
  • kubernetes核心资源内容

    参考连接: https://blog.csdn.net/weixin_46703850/article/details/122922090 1.命令行的方式创建命名命名空间 1.1 查看命名空间 1.2 查看所有名称空间的pods信息 1.3 查看指定命名空间的pod信息 1.4 删除命名空间,会连带空间下的资源一期删除 2. yaml方式创建命名空间 2.1 创建命名空间yaml文件

    2024年02月05日
    浏览(37)
  • Kubernetes — 核心资源对象 — Controller

    Kubernetes 提供了多种 Controllers 来对 Pods 进行管理,包括:Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等,以满足不同的业务需求。这些控制器都运行在 Master 上。 在 Kuberentes 的 kubernetes/pkg/controller/ 目录中包含了官方提供的一些常见控制器,可以通过下面这个函数看到所有需要

    2024年02月11日
    浏览(37)
  • kubernetes(k8s) pod(资源限制、基础概念)

    目录  一、资源限制 1、概念 1.2、Pod和容器的资源请求和限制 1.3、CPU资源单位 1.4、内存资源单位 1.5、CPU和内存的Requests和Limits的特点 1.6、案例 二、pod 的两种使用方式 三、pod 资源共享 四、底层容器Pause 1、pause 共享资源 1.1、网络 1.2、存储 1.3、小结 2、Pause主要功能 3、Pod

    2024年02月05日
    浏览(76)
  • Kubernetes/k8s之HPA,命名空间资源限制

    Horizontal Pod Autoscaling:po的水平自动伸缩 这是k8s自带的模块 pod占用cpu比例达到一定的阀值,会触发伸缩机制。 根据cpu的阀值触发伸缩机制 replication controller 副本控制器 控制pod的副本数 deployment controller 节点控制器 部署pod hpa控制副本的数量,以及如何控制部署pod 1、hpa基于kub

    2024年01月24日
    浏览(45)
  • CKA 10_Kubernetes工作负载与调度 资源调度 资源限制 LimitRanger 资源配额 ResourceQuota

    官方文档: 概念 | 策略 | 限制范围 官方文档: 概念 | 策略 | 资源配额 默认情况下, Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用资源配额,集群管理员可以以名字空间为单位,限制其资源的使用与创建。 在命名空间中,一个 Pod 或 Container 最多能够使用命名空

    2024年02月08日
    浏览(67)
  • Kubernetes配置 Pods 和容器—将 Docker Compose 文件转换为 Kubernetes 资源

    你必须拥有一个 Kubernetes 的集群,同时你必须配置 kubectl 命令行工具与你的集群通信。 建议在至少有两个不作为控制平面主机的节点的集群上运行本教程。 我们有很多种方式安装 Kompose。首选方式是从最新的 GitHub 发布页面下载二进制文件。 Kompose 通过 GitHub 安装 只需几步,

    2024年02月12日
    浏览(49)
  • Kubernetes(k8s)核心资源解析:Pod详解

    💖The Begin💖点点关注,收藏不迷路💖 Pod是Kubernetes中最小的调度单元,它可以包含一个或多个容器。Pod中的所有容器共享网络和存储卷,它们一起运行在同一个节点上。Pod提供了一种抽象层,使得容器可以作为一个逻辑单元来管理。 Pod中的容器共享IP地址、端口空间和存储

    2024年04月11日
    浏览(76)
  • Kubernetes技术--Kubernetes架构组件以及核心概念

    1. Kubernetes集群架构组件   搭建一个 Kubernetes环境集群,其架构如下所示: 内容详解: Master : 控制节点,指派任务、决策 Node : 工作节点,实际干活的。 Master组件内容:

    2024年02月10日
    浏览(51)
  • 【云原生 • Kubernetes】kubernetes 核心技术 - Service

    1. Service 的定义 Service 是 Kubernetes 的核心概念之一,创建一个 Service 可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求负载分发到后端的各个容器应用上。 完整 yaml 格式的 Service 定义文件如下: 2. Service 的基本用法 一般情况下,对外部提供服务的应用

    2024年02月01日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包