Kubernetes-2

k8s-2

1、Kubernetes的核心组件

  • apiserver : 背后有一个程序去运行,提供了一个接口,像一个交通枢纽。(6443)
  • etcd:开源的key,value类型的数据库(2379,2380,2381)
  • scheduler:调度器—》监视新创建的,未指定运行节点的pod,并选择节点来让pod在上面运行
    • pod: 一个或者一组容器,最小的可部署单元。
  • kube-controller-manager: 管理控制器的
  • cloud-controller-manager: 与公有云进行对接的控制器
  • kubelet:启容器的,调用docker去启动容器,指挥docker去启动容器
  • Kube Proxy:将业务pod的网络对接出去,包括将数据接进来,把里面的数据送出去,本质上是一个网络代理。

2、pod

2.1、什么是pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

'Pod(就像在鲸鱼荚或者豌豆荚中)是一组(一个或多个) 容器; 这些容器共享存储、网络、以及怎样运行这些容器的声明。 Pod 中的内容总是并置(colocated)的并且一同调度,在共享的上下文中运行。 Pod 所建模的是特定于应用的 “逻辑主机”,其中包含一个或多个应用容器, 这些容器相对紧密地耦合在一起。 在非云环境中,在相同的物理机或虚拟机上运行的应用类似于在同一逻辑主机上运行的云应用。'

3、3种启动pod的方式

3.1、命令行启动pod

[root@master ~]# kubectl create deployment k8s-nginx  --image=nginx  -r 3
deployment.apps/k8s-nginx created
[root@master ~]# kubectl get pod
NAME                         READY   STATUS              RESTARTS   AGE
k8s-nginx-75f95db655-dxwc6   0/1     ContainerCreating   0          18s
k8s-nginx-75f95db655-f8cnx   0/1     ContainerCreating   0          18s
k8s-nginx-75f95db655-ww9mk   0/1     ContainerCreating   0          18s
[root@master ~]# 
3.1.1、执行下面命令,背后发生了什么?
kubectl create deployment k8s-nginx  --image=nginx  -r 3

执行命令 kubectl create deployment k8s-nginx --image=nginx -r 3 将创建一个名为 “k8s-nginx” 的部署(Deployment),使用 nginx 镜像,并且副本数设置为 3。

背后发生了以下一些步骤:

  1. 通过 kubectl 命令将部署的请求发送到 Kubernetes API 服务器。

  2. API 服务器接收到请求后,将创建一个新的 Deployment 对象,并将其保存到 Kubernetes 的 etcd 数据库中。

  3. **控制器管理器(Controller Manager)**注意到新创建的 Deployment 对象,并启动一个控制器来处理该部署。

  4. 控制器检查当前集群中的节点状态,并根据部署的副本数(这里是 3)开始创建 Pod。

  5. **调度器(Scheduler)**根据节点的可用资源和调度策略,将 Pod 分配到可用的节点上。

  6. **Kubelet 代理(Kubelet Proxy)**在分配给节点的每个节点上启动并管理 Pod 的容器。

  7. 容器运行时(如 Docker)根据指定的镜像(这里是 nginx)拉取镜像并在每个 Pod 中启动容器。

  8. 创建的 Pod 将进入运行状态,并通过 Kubernetes 网络插件与其他 Pod 和服务进行通信。

通过这个过程,您将在集群中创建一个名为 “k8s-nginx” 的 Deployment 对象,并且将有 3 个副本的 Pod 运行 nginx 镜像。

3.2、启动一个pod背后发生了什么

image-20240305212443282

image-20240305212510962

  1. kubectl 向apiserver发起请求,提交数据,需要创建pod和部署控制器
  2. apiserver收到请求后,会将数据写到ETCD数据库里,通知控制器有新的任务
  3. 副本控制器监视程序去访问apiserver的接口发现有新的任务,然后就立马执行
  4. 监视程序通知副本控制器去创建需要做的事情,例如: 创建几个程序,多少个副本(实例)。然后又将数据写入到ETCD数据库里
  5. 调度器获取新的任务,进行调度,例如:新的pod需要多少cpu或者内存,调度需要在哪台node节点上运行,调度器将调度信息写入到ETCD数据库里。
  6. apiserver会通知调度器选中的node节点上的kubelet,去部署pod,然后根据副本控制器的数据,例如:什么程序,多少个副本等,kubelet通过安装的docker容器去启动相应数量的容器
  7. kubeproxy会将pod的网络打通,配置好ip以及pod的发布和负载均衡

3.3、使用yml文件

3.3.1、标准的pod
[root@master ~]# mkdir /pod
[root@master ~]# cd /pod/
[root@master pod]# 
[root@master pod]# vim simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

[root@master pod]# 

这是一个名为 “simple-pod.yaml” 的 Pod 配置文件,其中定义了一个名为 “nginx” 的 Pod。

  • apiVersion: v1 表示该配置文件使用的 Kubernetes API 版本是 v1。
  • kind: Pod 表示该配置文件定义的是一个 Pod 对象。—>资源类型:pod,node,控制器等都是类型
  • metadata 部分包含了关于 Pod 的元数据,如名称和其他标签等。
    • name: nginx 指定了 Pod 的名称为 “nginx”。
  • spec 部分定义了 Pod 的规格,包括了容器和其他配置信息。—>具体的某个资源对象的详细信息
    • containers 列表中定义了一个容器
      • name: nginx 定义了容器的名称为 “nginx”。
      • image: nginx:1.14.2 指定了容器所使用的镜像为 “nginx:1.14.2”,即使用了版本为 1.14.2 的 Nginx 镜像。
      • ports 列表定义了容器所监听的端口
        • containerPort: 80 表示容器将监听端口号 80,允许其他服务通过该端口访问该容器。

这个配置文件描述了一个非常简单的 Pod,其中只有一个容器运行着 Nginx 服务,并监听容器的 80 端口。

[root@master pod]# kubectl apply -f simple-pod.yaml 
pod/nginx created
[root@master pod]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          3m42s
[root@master pod]# 
3.3.2、使用部署控制器启动pod
[root@master pod]# vim nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:			#打标签
    app: nginx		#具体的标签,一般采用key对应的value,key可以自己定义
spec:
  replicas: 3		#指定pod副本的数量 pod的数量
  selector:			#选择器,我们的副本控制器去匹配需要启动的容器的配置
    matchLabels:	#具体匹配的标签
      app: nginx	#根据app的值去找nginx的标签
  template:			#模板:启动pod的模板
    metadata:		#模板的启动的pod的元数据
      labels:		#给启动的pod打标签
        app: nginx	#具体的标签
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

这是一个名为 nginx-deployment.yaml 的配置文件,用于定义一个 Deployment(部署)资源,用于管理运行在 Kubernetes 集群中的多个 Pod 实例。

让我们逐行解释这个配置文件的内容:

  • apiVersion: apps/v1 指定了使用的 Kubernetes API 版本。
  • kind: Deployment 表示这是一个 Deployment 资源的定义。
  • metadata 部分包含了 Deployment 的元数据,如名称和标签。
  • spec 部分定义了 Deployment 的规范。
    • replicas: 3 指定了要创建的 Pod 实例数量为 3。
    • selector 部分定义了用于选择要管理的 Pod 的标签。
      • matchLabels 部分定义了要匹配的标签。这里使用了 app: nginx 标签来选择所有具有该标签的 Pod。
    • template 部分定义了要创建的 Pod 的模板
      • metadata 部分定义了 Pod 的元数据,包括标签。
      • spec 部分定义了 Pod 的规范。
        • containers 部分定义了 Pod 中的容器。
          • name: nginx 指定了容器的名称为 nginx
          • image: nginx:1.14.2 指定了要使用的容器镜像为 nginx:1.14.2
          • ports 部分定义了容器暴露的端口。
            • containerPort: 80 指定了容器监听的端口为 80。

这个配置文件描述了一个名为 nginx-deployment 的 Deployment,它将创建 3 个 Pod 实例,每个实例运行一个名为 nginx 的容器,使用 nginx:1.14.2 镜像,并将容器的端口 80 暴露出来。

[root@master pod]# kubectl apply -f nginx-deployment.yaml 
deployment.apps/nginx-deployment created
[root@master pod]# kubectl get pod
NAME                                READY   STATUS              RESTARTS   AGE
nginx                               1/1     Running             0          20m
nginx-deployment-66b6c48dd5-6j6tg   0/1     ContainerCreating   0          7s
nginx-deployment-66b6c48dd5-dcbk2   1/1     Running             0          7s
nginx-deployment-66b6c48dd5-k8n5d   1/1     Running             0          7s
[root@master pod]# 
[root@master pod]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           2m26s
[root@master pod]# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-66b6c48dd5   3         3         3       2m32s
[root@master pod]# 
[root@master pod]# kubectl get pod
NAME                                READY   STATUS    RESTARTS   AGE
nginx                               1/1     Running   0          23m
nginx-deployment-66b6c48dd5-6j6tg   1/1     Running   0          3m
nginx-deployment-66b6c48dd5-dcbk2   1/1     Running   0          3m
nginx-deployment-66b6c48dd5-k8n5d   1/1     Running   0          3m
[root@master pod]# 

名字是有层次效果的

3.3.3、删除部署控制器

方法1:

[root@master pod]# kubectl get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           4m54s
[root@master pod]# kubectl delete deploy nginx-deployment
deployment.apps "nginx-deployment" deleted
[root@master pod]# kubectl get pod
NAME                                READY   STATUS        RESTARTS   AGE
nginx                               1/1     Running       0          26m
nginx-deployment-66b6c48dd5-dcbk2   0/1     Terminating   0          5m20s
nginx-deployment-66b6c48dd5-k8n5d   0/1     Terminating   0          5m20s
[root@master pod]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          26m
[root@master pod]# 

方法2:

[root@master pod]# kubectl delete -f nginx-deployment.yaml 
deployment.apps "nginx-deployment" deleted
[root@master pod]# kubectl get pod
NAME                                READY   STATUS        RESTARTS   AGE
nginx                               1/1     Running       0          27m
nginx-deployment-66b6c48dd5-bbvcj   0/1     Terminating   0          19s
nginx-deployment-66b6c48dd5-ddxwl   0/1     Terminating   0          19s
nginx-deployment-66b6c48dd5-mdlg9   0/1     Terminating   0          19s
[root@master pod]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          27m
[root@master pod]# 

4、部署控制器和副本控制器直接的关系

部署控制器和副本控制器是 Kubernetes 中两个不同的概念,它们之间存在一种从属关系

  • 部署控制器(Deployment Controller)是 Kubernetes 中的一个资源对象,用于管理应用程序的部署。它定义了所需的副本数量和期望状态,并负责确保系统中运行的副本数与所需的副本数保持一致。部署控制器还可以实现滚动更新、回滚和自动修复等功能。

  • 副本控制器(ReplicaSet Controller)是 Kubernetes 中的另一个资源对象,用于确保指定数量的 Pod 副本正在运行。副本控制器定义了应该创建和维护的 Pod 副本数量,并根据需要进行扩展或收缩。它通过监视 Pod 的状态并采取必要的操作,以确保所需的副本数与实际运行的副本数一致。

因此,可以说部署控制器是副本控制器的一种高级抽象。部署控制器使用副本控制器来实现对应用程序部署的管理。部署控制器可以创建和管理副本控制器,并在需要时自动进行滚动更新或回滚操作,以确保应用程序的可用性和稳定性。

简而言之,部署控制器是用于管理应用程序部署的高级控制器,而副本控制器是用于确保指定数量的 Pod 副本正在运行的基础控制器。

  • 即:部署控制器去控制副本控制器,副本控制器去控制管理pod

  • 如果把副本控制器删了,部署控制器会帮我们去重一个副本控制器,然后重启副本控制器下边的pod

  • 删除了副本控制器,会把副本控制器下面的pod删了

  • 删除部署控制器,不会重新去创建副本控制器和pod了

5、一些命令

kubectl get pod -o wide

[root@master ~]# kubectl get pod -o wide
NAME                         READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
k8s-nginx-75f95db655-gkbqs   1/1     Running   0          13m   10.244.247.4    node-2   <none>           <none>
k8s-nginx-75f95db655-rkzxv   1/1     Running   0          13m   10.244.84.133   node-1   <none>           <none>
[root@master ~]# 

kubectl get pod -o wide 命令用于获取当前集群中所有Pod的详细信息,包括它们的名称、状态、所在的节点、IP地址等。

具体作用如下:

  • kubectl get pod:获取当前集群中所有Pod的摘要信息,包括名称、状态、重启次数等。
  • -o wide:使用"wide"输出格式,该格式会显示更多的列,包括所在的节点、IP地址、节点选择器等。

通过执行 kubectl get pod -o wide 命令,将获得一个详细的列表,其中包含了所有Pod的信息,以便更好地了解它们在集群中的状态和位置。

kubectl get deployment(查看部署控制器)—>kubectl get deploy

[root@master ~]# kubectl get deployment
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
k8s-nginx   2/2     2            2           5m56s

kubectl get deployment 命令用于获取当前集群中所有部署(Deployment)的摘要信息,包括它们的名称、就绪副本数、最新副本数、可用副本数等。

具体作用如下:

  • kubectl get deployment:获取当前集群中所有部署的摘要信息,包括名称、就绪副本数、最新副本数、可用副本数等。
  • 默认情况下,输出的信息包括部署的名称、就绪副本数、最新副本数、可用副本数和创建时间。

通过执行 kubectl get deployment 命令,将获得一个部署的列表,其中包含了所有部署的信息,以便了解它们在集群中的状态和可用性。在示例中,部署名称为 “k8s-nginx”,它有2个就绪副本、2个最新副本和2个可用副本,已经运行了5分钟56秒。

kubectl delete pod pod的名字

[root@master ~]# kubectl delete pod test-pod
pod "test-pod" deleted

kubectl delete pod test-pod 命令用于删除名为 “test-pod” 的Pod。

具体作用如下:

  • kubectl delete pod:删除指定名称的Pod。
  • test-pod:要删除的Pod的名称。

执行该命令后,Kubernetes将会删除名为 “test-pod” 的Pod。请注意,删除Pod将导致Pod被终止并从集群中移除。

kubectl get replicaset(查看副本控制器)—>kubectl get rs

[root@master ~]# kubectl get replicaset
NAME                   DESIRED   CURRENT   READY   AGE
k8s-nginx-75f95db655   2         2         2       19m
[root@master ~]# 

kubectl get replicaset 命令用于获取当前集群中所有副本集(ReplicaSet)的摘要信息,包括它们的名称、期望副本数、当前副本数、就绪副本数等。

就是说kubectl get replicaset用来查看副本控制器的

kubectl get replicaset 可以简写为:kubectl get rs

具体作用如下:

  • kubectl get replicaset:获取当前集群中所有副本集的摘要信息,包括名称、期望副本数、当前副本数、就绪副本数等。
  • 默认情况下,输出的信息包括副本集的名称、期望副本数、当前副本数、就绪副本数和创建时间。

通过执行 kubectl get replicaset 命令,将获得一个副本集的列表,其中包含了所有副本集的信息,以便了解它们在集群中的状态和可用性。在示例中,副本集名称为 “k8s-nginx-75f95db655”,它有2个期望副本、2个当前副本和2个就绪副本,已经存在了19分钟。

kubectl delete rs 类型名字

 kubectl delete rs k8s-nginx-75f95db655

这是删除副本控制器

删除了副本控制器,部署控制器会再次启动副本控制器

kubectl apply -f yaml文件

利用yaml文件去启pod

[root@master pod]# kubectl apply -f simple-pod.yaml 
pod/nginx created
[root@master pod]# kubectl get pod
NAME                         READY   STATUS    RESTARTS   AGE
nginx                        1/1     Running   0          29s

这个命令 kubectl apply -f simple-pod.yaml 用于创建一个 Pod,它会根据提供的配置文件 simple-pod.yaml 中的定义来创建 Pod。

  • kubectl apply 是一个命令行工具,用于向 Kubernetes 集群提交资源配置文件并进行创建或更新操作。
  • -f simple-pod.yaml 参数指定了要使用的配置文件,这里是 simple-pod.yaml
  • pod/nginx created 是命令的输出结果,表示 Pod nginx 创建成功。

接下来,您使用 kubectl get pod 命令来获取 Pod 的列表。输出结果中的各列含义如下:

  • NAME 列显示 Pod 的名称。
  • READY 列显示 Pod 当前的就绪状态,即容器是否已经启动并就绪。
  • STATUS 列显示 Pod 的当前状态,如 Running(运行中)、Pending(等待中)等。
  • RESTARTS 列显示容器重启的次数。
  • AGE 列显示 Pod 创建的时间距离现在的时长。

在输出中,Pod 名称为 nginx,它的 READY 列显示为 1/1,表示该 Pod 中的容器已经启动并且就绪,STATUS 列显示为 Running,表示该 Pod 正在运行且正常。

查看pod的详细信息

[root@master pod]# kubectl describe pod nginx
Name:         nginx
Namespace:    default
Priority:     0
Node:         node-1/192.168.182.134
Start Time:   Tue, 05 Mar 2024 22:02:41 +0800
Labels:       <none>
Annotations:  cni.projectcalico.org/podIP: 10.244.84.134/32
              cni.projectcalico.org/podIPs: 10.244.84.134/32
Status:       Running
IP:           10.244.84.134
IPs:
  IP:  10.244.84.134
Containers:
  nginx:
    Container ID:   docker://0af57985c5ca8512cfb91264add1d08613bf7c09873dfc2fe885d468cf47a15b
    Image:          nginx:1.14.2
    Image ID:       docker-pullable://nginx@sha256:f7988fb6c02e0ce69257d9bd9cf37ae20a60f1df7563c3a2a6abe24160306b8d
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 05 Mar 2024 22:02:58 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-zdvg8 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-zdvg8:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-zdvg8
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  49m   default-scheduler  Successfully assigned default/nginx to node-1
  Normal  Pulling    49m   kubelet            Pulling image "nginx:1.14.2"
  Normal  Pulled     49m   kubelet            Successfully pulled image "nginx:1.14.2" in 16.01565299s
  Normal  Created    49m   kubelet            Created container nginx
  Normal  Started    49m   kubelet            Started container nginx
[root@master pod]# 

6、资源类型有哪些

  • node
  • pod
  • 控制器:部署控制器,副本控制器
  • 命名空间:namespace

7、pod有多少种状态

  • Pending: Pod没有调度到节点上。----》资源不够,cpu,内存 或者污点
  • Running: Pod中至少一个容器正在运行。
  • Succeeded: 停止pod成功。
  • Failed: 停止pod失败。
  • Unknown: Pod的状态无法确定。
  • Terminating: Pod正在被终止,可能由于删除请求或其他终止操作。
  • ContainerCreating: Pod中的容器正在被创建。
  • ContainerRunning: Pod中的容器正在运行。
  • ContainerTerminated: Pod中的容器已经终止。
  • completed: pod里的容器主进程已经退出,容器没有退出。
  • OOMKilled: pod进入了循环启动被杀死,然后又启动又被杀死。—》使用的内存超过我们的限制就会被杀死。
  • CrashLoopBackOff: 是一个表示容器在启动后立即崩溃并进入循环重启的状态。这通常是由于容器在启动过程中遇到了问题或崩溃而导致的。
  • ErrImagePull: 拉取镜像拉不下来。

8、各种控制器

8.1、deployment-部署控制器

部署pod

  • 作用: Deployment的主要目的是提供一种机制,用于定义、创建和更新Pod副本。它包含一个Pod模板,定义了所需的容器和其他相关配置,以及一个副本数的定义。Deployment确保所需的副本数一直在运行,同时支持滚动更新、回滚和扩缩容等功能。
  • 使用场景:
    • 应用部署和升级: 通过定义Deployment,用户可以轻松地部署应用程序,并在需要时进行滚动更新。Deployment会逐步替换现有的Pod,确保应用程序在升级期间保持可用性。
    • 回滚操作: 如果升级后发现问题,可以通过回滚到先前的版本来还原。Deployment会管理这个过程,确保回滚是平滑而可控的。
    • 故障恢复: 如果某个Pod异常终止,Deployment会自动启动新的Pod,确保系统中的副本数达到所需的状态。
    • 扩缩容: 通过调整Deployment的副本数,可以实现应用程序的扩缩容,以适应变化的负载。

通过使用Deployment,用户不需要直接操作Pod,而是通过声明性的方式描述所需的状态和配置。Kubernetes系统会根据用户定义的Deployment规范来自动管理和维护应用程序的运行状态。这种抽象层简化了应用程序的部署和维护,提高了操作的可靠性和可重复性。

8.2、ReplicaSet-副本控制器

控制pod个数的

  • 作用: 保持指定数量的Pod副本运行。如果有Pod异常终止或删除,副本控制器将启动新的Pod,以确保达到所需的副本数。
  • 使用场景: 适用于水平扩展应用程序,确保在任何时候都有指定数量的相同Pod在运行。

8.3、daemonSet-守护进程控制器

  • 作用: 确保在集群中的每个节点上运行一个副本的Pod。当新节点加入集群时,守护进程控制器会自动在新节点上启动Pod。
  • 使用场景: 适用于在每个节点上运行后台守护进程,如日志收集、监控等。

8.4、job-批处理工作器

  • 作用: 用于一次性执行任务或作业。Pod运行完任务后会被删除。
  • 使用场景: 适用于需要执行一次性任务的场景,如数据处理、批量作业等。

8.5、cronjob-计划任务控制器

  • 作用: 基于时间调度周期性运行的任务。类似于Job,但是可以定期执行。
  • 使用场景: 适用于需要按照预定的时间表执行任务的场景,如定时备份、定期清理等。

8.6、statefullSet

  • 作用: 维护有状态应用程序的稳定标识。确保每个Pod都有唯一的标识和持久存储,以便支持有状态应用程序的运行。
  • 使用场景: 适用于需要持久化存储、有序部署和唯一标识的应用程序,如数据库。

9、调度器有哪些调度算法

根据pod调度策略和方法:

  1. deployment: 全自动调度算法 --》根据每台节点服务器的综合算力
  2. nodename 节点名字
  3. node selector:定向调度算法–>根据node的标签去调度
  4. nodeaffinity 节点亲和性算法 --》尽量把不同的pod放到一台node上
  5. podaffinity pod亲和性算法–》尽量把相同的pod放到一起
  6. taintstolerations 污点和容忍度

10、pod的资源限制

k8s集群的总算力是固定的,所以得通过命名空间去限制资源

10.1、对内存的限制—>通过命名空间

https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/

1.创建命名空间

[root@master pod]# kubectl create namespace default-mem-example
namespace/default-mem-example created
[root@master pod]# kubectl get namespace|grep default-mem
default-mem-example   Active   20s
[root@master pod]# 

2.写yaml文件

[root@master pod]# vim default-mem.yaml 
apiVersion: v1
kind: LimitRange
metadata:
  name: mem-limit-range
  namespace: default-mem-example
spec:
  limits:
  - default:
      memory: 512Mi
    defaultRequest:
      memory: 256Mi
    type: Container

[root@master pod]# 

3.执行yaml文件

[root@master pod]# kubectl apply -f default-mem.yaml 
limitrange/mem-limit-range created
[root@master pod]# 

4.查看资源限制

[root@master pod]# kubectl get limitrange
NAME              CREATED AT
mem-limit-range   2024-03-06T12:26:34Z
[root@master pod]# 

kubectl get limitrange 是 Kubernetes 命令行工具中的一个命令,用于获取集群中定义的资源限制范围(LimitRange)的信息。

在 Kubernetes 中,LimitRange 是一种资源对象,用于定义容器中的资源限制。它可以限制容器的 CPU 使用量、内存使用量、存储资源等。通过定义 LimitRange,可以确保容器在运行时不会超出指定的资源限制,从而保证集群的稳定性和资源的公平分配。

运行 kubectl get limitrange 命令会列出集群中所有已定义的 LimitRange 对象的名称和创建时间。在你的输出中,只显示了一个 LimitRange 对象,名称为 mem-limit-range,创建时间为 2024-03-06T12:26:34Z

如果想获取更详细的关于某个 LimitRange 对象的信息,可以使用 kubectl describe limitrange <limitrange-name> 命令,将 <limitrange-name> 替换为想要查看的 LimitRange 对象的名称。

5.启pod

[root@master pod]# vim memory-defaults-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: default-mem-demo
  namespace: default-mem-example
spec:
  containers:
  - name: default-mem-demo-ctr
    image: nginx
[root@master pod]# 

这是一个名为 memory-defaults-pod.yaml 的 YAML 文件,用于创建一个 Kubernetes Pod 对象。下面是文件内容的解释:

  • apiVersion: v1: 指定使用的 Kubernetes API 版本为 v1。
  • kind: Pod: 定义要创建的资源类型为 Pod。
  • metadata: 定义资源的元数据,包括名称和命名空间等。
    • name: default-mem-demo: 指定 Pod 的名称为 default-mem-demo
    • namespace: default-mem-example: 指定 Pod 所属的命名空间为 default-mem-example
  • spec: 定义 Pod 的规格,包括容器和其他配置。
    • containers: 定义 Pod 中的容器列表。
      • - name: default-mem-demo-ctr: 定义容器的名称为 default-mem-demo-ctr
      • - image: nginx: 指定容器使用的镜像为 nginx

这个 YAML 文件描述了一个简单的 Pod,其中包含一个名为 default-mem-demo-ctr 的容器,使用 nginx 镜像。这个 Pod 的名称是 default-mem-demo,所属的命名空间是 default-mem-example

你可以使用 kubectl apply -f memory-defaults-pod.yaml 命令将这个 YAML 文件应用到 Kubernetes 集群中,从而创建该 Pod 对象。

6.继续启动pod(查看pod要指定命名空间)

[root@master pod]# kubectl apply -f memory-defaults-pod.yaml 
pod/default-mem-demo created
[root@master pod]# kubectl get pod -n default-mem-example  #这里要指定命名空间
NAME               READY   STATUS    RESTARTS   AGE
default-mem-demo   1/1     Running   0          57s
[root@master pod]# 

7.查看pod的详细信息

[root@master pod]# kubectl describe pod default-mem-demo -n default-mem-example
Name:         default-mem-demo
Namespace:    default-mem-example
Priority:     0
Node:         node-2/192.168.182.135
Start Time:   Wed, 06 Mar 2024 20:36:37 +0800
Labels:       <none>
Annotations:  cni.projectcalico.org/podIP: 10.244.247.13/32
              cni.projectcalico.org/podIPs: 10.244.247.13/32
Status:       Running
IP:           10.244.247.13
IPs:
  IP:  10.244.247.13
Containers:
  default-mem-demo-ctr:
    Container ID:   docker://c2c5eaecd0d1d8f814d1de0c19b526ddb0d0336f20a42587871dfd3b889cc63d
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:0d17b565c37bcbd895e9d92315a05c1c3c9a29f762b011a10c54a66cd53c9b31
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Wed, 06 Mar 2024 20:36:53 +0800
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-rx2hs (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  default-token-rx2hs:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-rx2hs
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  3m22s  default-scheduler  Successfully assigned default-mem-example/default-mem-demo to node-2
  Normal  Pulling    3m22s  kubelet            Pulling image "nginx"
  Normal  Pulled     3m6s   kubelet            Successfully pulled image "nginx" in 15.68468529s
  Normal  Created    3m6s   kubelet            Created container default-mem-demo-ctr
  Normal  Started    3m6s   kubelet            Started container default-mem-demo-ctr
[root@master pod]# 

8.查看命名空间的资源限制

[root@master pod]# kubectl describe limitrange mem-limit-range
Name:       mem-limit-range
Namespace:  default
Type        Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
----        --------  ---  ---  ---------------  -------------  -----------------------
Container   memory    -    -    256Mi            512Mi          -
[root@master pod]# 
[root@master pod]# kubectl describe namespace default-mem-example
Name:         default-mem-example
Labels:       <none>
Annotations:  <none>
Status:       Active

No resource quota.

Resource Limits
 Type       Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
 ----       --------  ---  ---  ---------------  -------------  -----------------------
 Container  memory    -    -    256Mi            512Mi          -
[root@master pod]# 

10.2、直接限制pod的资源,不对命名空间进行限制

1.创建命名空间

[root@master pod]# kubectl create namespace mem-example
namespace/default-mem-example created
[root@master pod]# kubectl get namespace|grep mem-example
mem-example           Active   41m
[root@master pod]# 

2.编写yaml文件

[root@master pod]# vim limit-pod-2.yaml
apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
  namespace: mem-example
spec:
  containers:
  - name: memory-demo-ctr
    image: polinux/stress
    resources:
      requests:
        memory: "100Mi"
      limits:
        memory: "200Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

[root@master pod]# 

3.启动pod

[root@master pod]# kubectl apply -f limit-pod-2.yaml 
pod/memory-demo created
[root@master pod]# kubectl get pod -n mem-example
NAME          READY   STATUS    RESTARTS   AGE
memory-demo   1/1     Running   0          16s
[root@master pod]# 

4.查看资源限制

[root@master pod]# kubectl describe pod memory-demo -n mem-example
    State:          Running
      Started:      Wed, 06 Mar 2024 21:00:21 +0800
    Ready:          True
    Restart Count:  0
    Limits:
      memory:  200Mi
    Requests:
      memory:     100Mi

10.3、对cpu的限制—>命名空间

https://kubernetes.io/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/

10.4、对pod的内存和cpu限制

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/
https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/

10.5、总的来说对pod的资源限制有两种方式

  1. 通过限制命名空间的cpu和内存来限制pod的大小—>pod要去绑定这个命名空间

    • 命名空间和limitrange进行绑定限制条件

      e5ea372048b5c15c9abc4696e4701bd

  2. 不对命名空间进行资源限制,而是直接限制pod的cpu和内存

11、查看cpu资源

  • top 1
  • lscpu
  • cat /proc/cpuinfo

image-20240307105511274

CPU 单位

CPU 资源以 CPU 单位度量。Kubernetes 中的一个 CPU 等同于:

  • 1 个 AWS vCPU
  • 1 个 GCP核心
  • 1 个 Azure vCore
  • 裸机上具有超线程能力的英特尔处理器上的 1 个超线程

小数值是可以使用的。一个请求 0.5 CPU 的容器保证会获得请求 1 个 CPU 的容器的 CPU 的一半。 你可以使用后缀 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 精度不能超过 1m。

CPU 请求只能使用绝对数量,而不是相对数量。0.1 在单核、双核或 48 核计算机上的 CPU 数量值是一样的。

12、查看内存资源

  • top m
  • free -h

image-20240307105816142

内存单位

内存资源的基本单位是字节(byte)。你可以使用这些后缀之一,将内存表示为 纯整数或定点整数:E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如,下面是一些近似相同的值:

128974848, 129e6, 129M, 123Mi

13、理解k8s中cpu和内存资源限制参数中cpu计量单位

https://cloud.tencent.com/developer/article/1903034

  • requests:代表容器启动请求的资源限制,分配的资源必须要达到此要求。

  • limits:代表最多可以请求多少资源。

  • 单位m:CPU的计量单位叫毫核(m)。一个节点的CPU核心数量乘以1000,得到的就是节点总的CPU总数量。如,一个节点有两个核,那么该节点的CPU总量为2000m。

  • 25
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

不冤不乐

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值