K8S中的pod资源之资源限制与重启策略

本文详细介绍了 Kubernetes 中 Pod 和 Container 的资源请求与限制设置,以及健康检查(Probe)的使用,包括 livenessProbe 和 readinessProbe。通过示例展示了如何配置资源限制以确保服务稳定性和效率,并探讨了不同重启策略对容器的影响。此外,还讨论了通过 httpGet、exec 和 tcpSocket 方式的健康检查实现。

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

一、资源限制

https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

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

(一)、Pod和Container的资源请求和限制:

spec.containers[].resources.limits.cpu     //cpu上限 
spec.containers[].resources.limits.memory   //内存上限
spec.containers[].resources.requests.cpu   //创建时分配的基本CPU资源
spec.containers[].resources.requests.memory  //创建时分配的基本内存资源

(二)、示例1

1、创建资源限制的yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

[root@localhost demo]# kubectl apply -f pod2.yaml 
pod/frontend created

2、查看具体事件

[root@localhost demo]# kubectl describe pod frontend
[root@localhost demo]# kubectl describe nodes 192.168.195.150

Namespace                  Name                                     CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------                  ----                                     ------------  ----------  ---------------  -------------
  default                    frontend                                 500m (50%)    1 (100%)    128Mi (3%)       256Mi (6%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource  Requests    Limits
  --------  --------    ------
  cpu       550m (55%)  1100m (110%)
  memory    228Mi (5%)  556Mi (14%)

3、成功部署好后查看状态

[root@localhost demo]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
frontend                          2/2     Running   1          3m21s

4、查看node节点资源状态

[root@localhost demo]# kubectl describe nodes 192.168.195.151

5、查看命名空间

[root@localhost demo]# kubectl get ns
NAME          STATUS   AGE
default       Active   17d
kube-public   Active   17d
kube-system   Active   17d

6、重启策略:Pod在遇到故障之后重启的动作

1:Always:当容器终止退出后,总是重启容器,默认策略
2:OnFailure:当容器异常退出(退出状态码非0)时,重启容器
3:Never:当容器终止退出,从不重启容器。
(注意:k8s中不支持重启Pod资源,只有删除重建)

[root@localhost demo]# kubectl edit deploy
......
 restartPolicy: Always
......

//示例2

[root@localhost demo]# vim pod3.yaml
apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 30; exit 3
[root@localhost demo]# kubectl apply -f pod3.yaml 
pod/foo created

//查看重启次数加1
[root@localhost demo]# kubectl get pods
NAME                              READY   STATUS             RESTARTS   AGE
foo                               1/1     Running            1          50s


[root@localhost demo]# vim pod3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep 10;exit 3
  restartPolicy: Never
//跟container同一个级别
//完成状态不会进行重启
[root@localhost demo]# kubectl get pods
NAME                              READY   STATUS      RESTARTS   AGE
foo                               0/1     Completed   0          29s

二、健康检查:又称为探针(Probe)

(注意:)规则可以同时定义
livenessProbe 如果检查失败,将杀死容器,根据Pod的restartPolicy来操作。
ReadinessProbe 如果检查失败,kubernetes会把Pod从service endpoints中剔除。

Probe支持三种检查方法:
httpGet 发送http请求,返回200-400范围状态码为成功。
exec 执行Shell命令返回状态码是0为成功。
tcpSocket 发起TCP Socket建立成功

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

示例1:exec方式
在这里插入图片描述

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy;sleep 30
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

[root@localhost demo]# kubectl get pods
liveness-exec                     1/1     Running     4          4m11s

示例2:httpGet方式
在这里插入图片描述

示例3:tcpSocket方式

在这里插入图片描述

### 实现 Kubernetes Pod 中 OSPF 协议的配置 要在 Kubernetes (k8s) 集群中的 Pod 上运行 OSPF(Open Shortest Path First)协议,需要解决几个关键的技术挑战。OSPF 是一种基于 IP 的动态路由协议,通常用于传统的路由器和交换机环境中。然而,在容器化环境(如 k8s),由于网络架构的不同以及 Overlay 和 Underlay 网络的区别,直接运行 OSPF 并不简单。 以下是实现这一目标的关键步骤和技术要点: #### 1. **选择合适的网络模式** 在 Kubernetes 中,默认情况下使用的通常是 Overlay 网络模型[^3]。这种模型通过虚拟隧道封装流量,使得 Pod 可以跨节点通信。然而,Overlay 网络会隐藏实际的物理网络拓扑结构,这 OSPF 对真实链路状态的要求相冲突。因此,为了支持 OSPF,建议使用 Underlay 网络模型或类似的解决方案。 可以通过 CNI 插件(如 MAC VLAN 或 Direct Routing)来实现 Underlay 网络配置[^3]。这些插件允许 Pod 使用宿主机的真实网络接口,从而能够参真实的二层或三层网络通信。 #### 2. **Pod 网络命名空间调整** 当新的 Pod 创建时,CNI 插件负责为其分配网络资源,包括 veth pair 的创建和配置[^1]。要使 Pod 支持 OSPF,可能需要手动修改其网络命名空间,以便将其绑定到特定的物理网络接口上。 可以参考以下命令将 Pod 绑定到宿主机上的某个物理网卡: ```bash ip link add veth0 type veth peer name eth0 netns $(docker inspect -f '{{ .State.Pid }}' <container-id>) ``` 此操作的具体细节取决于所选的 CNI 插件及其配置方式。 #### 3. **安装和支持 OSPF 的软件包** 为了让 Pod 运行 OSPF,可以在其中部署专门的支持工具,例如 Quagga/Zebra 或 FRRouting(Free Range Router)。这些工具提供了完整的 OSPF 功能集,并能其他路由器交互。 下面是一个简单的 Dockerfile 示例,展示如何在一个基础镜像中集成 FRRouting 工具: ```Dockerfile FROM ubuntu:latest RUN apt-get update && \ apt-get install -y frr && \ rm -rf /var/lib/apt/lists/* CMD ["frr"] ``` 构建完成后,可将该自定义镜像作为 Pod 的基础镜像使用。 #### 4. **配置 OSPF 参数** 启动包含 FRRouting 的 Pod 后,进入容器内部完成必要的 OSPF 配置工作。典型的配置文件路径为 `/etc/frr/ospfd.conf`,内容如下所示: ```plaintext router ospf network 192.168.1.0/24 area 0 redistribute connected log file /var/log/frr/ospfd.log informational ! line vty ! end ``` 保存更改后重启 `ospfd` 服务即可生效。 #### 5. **处理 iptables 和网络安全策略** 需要注意的是,Kubernetes 默认的安全机制可能会阻止某些类型的流量传输。特别是 NetworkPolicy 资源的作用范围仅限于同一名称空间内的对象[^2],而 OSPF 流量往往涉及多个子网间的广播或多播行为。此时应适当放宽相关限制条件或者禁用不必要的过滤规则。 可通过编辑 YAML 文件的方式显式声明例外情况,例如: ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-ospf spec: podSelector: {} ingress: - from: - ipBlock: cidr: 0.0.0.0/0 ports: - protocol: UDP port: 89 ``` 以上片段表示允许所有外部来源访问端口号为 89 的 UDP 数据流,这是标准 OSPF 协议所需的通讯通道之一。 --- ### 总结 综上所述,虽然理论上能够在 Kubernetes Pod 内部启用并维护 OSPF 协议栈,但实际上仍面临诸多复杂性和潜在风险。推荐的做法是从整体设计角度重新评估需求场景,考虑采用更贴近云原生理念的服务发现方法替代传统静态路由方案;但如果确实无法绕开,则务必遵循上述指导原则逐步推进实施过程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

清风~

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

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

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

打赏作者

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

抵扣说明:

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

余额充值