k8s的pod的管理和优化

已于 2025-01-14 11:33:31 修改
阅读量1.4k 收藏 26
点赞数 26
文章标签： kubernetes 容器 云原生
于 2024-10-06 19:19:16 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/maoqiwei/article/details/142715056
版权

目录

资源管理介绍

查看版本

查看私有节点状态

常用资源类型

常见的命令操作

一切的示例演示的前提是你的hub仓库有这些镜像

基本命令

创建一个类型为deployment,名字为web的控制器，并指定有3个

查看控制器

查看pod

查看某个pod的详细信息显示

编辑控制器的配置，如把数量该为一个

此时在查看pod就会发现只有一个了

或者查看控制器

也可以用命令修改，此时该为6个

查看

如果删除pod，控制器会再自动创建新的pod

如果要删除，删除资源,

此时在查看就会提示没有了

运行和调试

运行一个pod

查看

端口暴露（即创建一个微服务），把微服务80端口映射到容器内的80端口

查看

此时就可以进行访问

可以查看pod的web的详细信息，要指定pod名称

可以查看日志，指定pod的名称

删除微服务

运行一个交互的pod

当同时安装下CTRL和pq时会退出pod，但不会停止运行

重新进入

如果删除交互示的pod较慢时可以加--force

在已经运行的pod中运行指定命令，此时就会在名为web的pod中运行了一个一个 bash shell 会话

也可以加-it进入交互查看

把文件复制到pod里

此时进入容器查看，就会看到在/下多出一个mqw的文件

可以把pod里的文件复制到本机中

此时就会在mnt的目录下有home的目录

高级命令演示

生成yml模板

此时可以查看，vim web.yml

启用

查看

因为控制器的原因，即使你删了pod，控制器会自动再开启新的pod

​编辑

收回资源

版本更新

用控制器创建pod，并暴露端口，

访问，此时是v1版本的

查看历史版本

命令修改

查看版本

此时再次访问，就会变成v2版本

版本回滚

此时就会变为v1版本了

利用yaml文件部署

资源参数介绍

示例

获取yaml模板

查看文件

运行

资源回收

注意如果多个容器运行在一个pod中，资源共享的同时在使用相同资源时也会干扰，比如端口

示例

启动之后查看,此时有一个会启动不了

在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰

示例

此时两个容器都运行了

同在一个pod中的容器公用一个网络

示例

运行

在同一pod下的容器进行测试

可以看到查看到了另一个容器的内容

端口映射

示例

运行

此时就可以访问了

设定环境变量

示例

运行，并测试

资源限制

示例

查看

容器启动管理

示例

选择节点管理

示例

运行，可以看到在节点2上运行了

共享宿主机网络

示例

运行，测试

pod的生命周期

INIT 容器的功能

示例

启动之后容器并没有运行，因为没有满足在容器内有mqw这个文件

此时在容器内创建mqw的文件后，就可以运行了

探针

存活探针演示

解释

运行

就绪探针

此时启动后，但还是处于准备状态

端口启动微服务

此时查看详细信息，但端口没暴露，不满足条件

添加

查看,此时条件满足，已经运行了

查看详细信息

资源管理介绍

  • 在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。

  • kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务

  • 所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。

  • kubernetes的最小管理单元是pod而不是容器，只能将容器放在Pod中，

  • kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。

  • Pod中服务服务的访问是由kubernetes提供的Service资源来实现。

  • Pod中程序的数据需要持久化是由kubernetes提供的各种存储系统来实现

# 查看所有pod
kubectl get pod 

# 查看某个pod
kubectl get pod pod_name

# 查看某个pod,以yaml格式展示结果
kubectl get pod pod_name -o yaml

#查看某个pod的详细信息
kubectl get pod_name -o wide

查看版本

[root@k8s-master ~]# kubectl version

查看私有节点状态

[root@k8s-master ~]# kubectl get nodes 

NAME         STATUS   ROLES           AGE     VERSION
k8s-1        Ready    <none>          3d20h   v1.30.5
k8s-2        Ready    <none>          3d20h   v1.30.5
k8s-master   Ready    control-plane   3d21h   v1.30.5

常用资源类型

常见的命令操作

一切的示例演示的前提是你的hub仓库有这些镜像

基本命令

创建一个类型为deployment,名字为web的控制器，并指定有3个

[root@k8s-master ~]# kubectl create deployment web --image nginx/nginx --replicas 3

查看控制器

[root@k8s-master ~]# kubectl get deployments.apps 

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    3/3     3            3           5s

查看pod

[root@k8s-master ~]# kubectl get pod

NAME                READY   STATUS    RESTARTS   AGE
web-78bcbff-pssd6   1/1     Running   0          49s
web-78bcbff-qlq2v   1/1     Running   0          49s
web-78bcbff-w6dqt   1/1     Running   0          49s

查看某个pod的详细信息显示

[root@k8s-master ~]# kubectl get pod web-78bcbff-pssd6 -o wide 

NAME                READY   STATUS    RESTARTS   AGE   IP           NODE    NOMINATED NODE   READINESS GATES
web-78bcbff-pssd6   1/1     Running   0          86s   10.244.1.4   k8s-1   <none>           <none>

编辑控制器的配置，如把数量该为一个

[root@k8s-master ~]# kubectl edit deployments.apps web

此时在查看pod就会发现只有一个了

[root@k8s-master ~]# kubectl get pod

NAME                READY   STATUS    RESTARTS   AGE
web-78bcbff-qlq2v   1/1     Running   0          5m36s

或者查看控制器

[root@k8s-master ~]# kubectl get deployments.apps 

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
web    1/1     1            1           6m45s

也可以用命令修改，此时该为6个

[root@k8s-master ~]# kubectl scale deployment web --replicas 6

查看

如果删除pod，控制器会再自动创建新的pod

如果要删除，删除资源,

[root@k8s-master ~]# kubectl delete deployments.apps web

此时在查看就会提示没有了

[root@k8s-master ~]# kubectl get pod

No resources found in default namespace.

运行和调试

运行一个pod

[root@k8s-master ~]# kubectl run web --image nginx/nginx

查看

[root@k8s-master ~]# kubectl get pod

NAME   READY   STATUS    RESTARTS   AGE
web    1/1     Running   0          12s

端口暴露（即创建一个微服务），把微服务80端口映射到容器内的80端口

[root@k8s-master ~]# kubectl expose pod web --port 80 --target-port 80

查看

此时就可以进行访问

可以查看pod的web的详细信息，要指定pod名称

可以查看日志，指定pod的名称

删除微服务

[root@k8s-master ~]# kubectl delete service web

运行一个交互的pod

[root@k8s-master ~]# kubectl run -it test --image busybox/busybox
If you don't see a command prompt, try pressing enter.
/ # 
/ #

当同时安装下CTRL和pq时会退出pod，但不会停止运行

重新进入

[root@k8s-master ~]# kubectl attach pods/test -it

如果删除交互示的pod较慢时可以加--force

[root@k8s-master ~]# kubectl delete pod test --force

在已经运行的pod中运行指定命令，此时就会在名为web的pod中运行了一个一个 bash shell 会话

[root@k8s-master ~]# kubectl exec pods/web -- /bin/bash

也可以加-it进入交互查看

把文件复制到pod里

[root@k8s-master ~]# mkdir mqw

[root@k8s-master ~]# kubectl cp mqw web:/

此时进入容器查看，就会看到在/下多出一个mqw的文件

可以把pod里的文件复制到本机中

[root@k8s-master mnt]# kubectl cp web:/home home

此时就会在mnt的目录下有home的目录

高级命令演示

生成yml模板

[root@k8s-master ~]# kubectl create deployment --image nginx/nginx web --dry-run=client -o yaml > web.yml

此时可以查看，vim web.yml

启用

[root@k8s-master ~]# kubectl apply -f web.yml

查看

因为控制器的原因，即使你删了pod，控制器会自动再开启新的pod

收回资源

[root@k8s-master ~]# kubectl delete -f web.yml

版本更新

用控制器创建pod，并暴露端口，

访问，此时是v1版本的

查看历史版本



命令修改

[root@k8s-master ~]# kubectl set image deployments/test myapp=myapp:v2

查看版本

此时再次访问，就会变成v2版本

版本回滚

[root@k8s-master ~]# kubectl rollout undo deployment test --to-revision 1

此时就会变为v1版本了

利用yaml文件部署

资源参数介绍

参数名称类型参数说明
versionString这里是指的是K8S API的版本，目前基本上是v1，可以用kubectl api-versions命令查询
kindString这里指的是yaml文件定义的资源类型和角色，比如:Pod
metadataObject元数据对象，固定值就写metadata
metadata.nameString元数据对象的名字，这里由我们编写，比如命名Pod的名字
metadata.namespaceString元数据对象的命名空间，由我们自身定义
SpecObject详细定义对象，固定值就写Spec
spec.containers[]list这里是Spec对象的容器列表定义，是个列表
spec.containers[].nameString这里定义容器的名字
spec.containers[].imagestring这里定义要用到的镜像名称
spec.containers[].imagePullPolicyString定义镜像拉取策略，有三个值可选： (1) Always: 每次都尝试重新拉取镜像 (2) IfNotPresent:如果本地有镜像就使用本地镜像 (3) )Never:表示仅使用本地镜像
spec.containers[].command[]list指定容器运行时启动的命令，若未指定则运行容器打包时指定的命令
spec.containers[].args[]list指定容器运行参数，可以指定多个
spec.containers[].workingDirString指定容器工作目录
spec.containers[].volumeMounts[]list指定容器内部的存储卷配置
spec.containers[].volumeMounts[].nameString指定可以被容器挂载的存储卷的名称
spec.containers[].volumeMounts[].mountPathString指定可以被容器挂载的存储卷的路径
spec.containers[].volumeMounts[].readOnlyString设置存储卷路径的读写模式，ture或false，默认为读写模式
spec.containers[].ports[]list指定容器需要用到的端口列表
spec.containers[].ports[].nameString指定端口名称
spec.containers[].ports[].containerPortString指定容器需要监听的端口号
spec.containers[] ports[].hostPortString指定容器所在主机需要监听的端口号，默认跟上面containerPort相同，注意设置了hostPort同一台主机无法启动该容器的相同副本(因为主机的端口号不能相同，这样会冲突)
spec.containers[].ports[].protocolString指定端口协议，支持TCP和UDP，默认值为 TCP
spec.containers[].env[]list指定容器运行前需设置的环境变量列表
spec.containers[].env[].nameString指定环境变量名称
spec.containers[].env[].valueString指定环境变量值
spec.containers[].resourcesObject指定资源限制和资源请求的值(这里开始就是设置容器的资源上限)
spec.containers[].resources.limitsObject指定设置容器运行时资源的运行上限
spec.containers[].resources.limits.cpuString指定CPU的限制，单位为核心数，1=1000m
spec.containers[].resources.limits.memoryString指定MEM内存的限制，单位为MIB、GiB
spec.containers[].resources.requestsObject指定容器启动和调度时的限制设置
spec.containers[].resources.requests.cpuStringCPU请求，单位为core数，容器启动时初始化可用数量
spec.containers[].resources.requests.memoryString内存请求，单位为MIB、GIB，容器启动的初始化可用数量
spec.restartPolicystring定义Pod的重启策略，默认值为Always. (1)Always: Pod-旦终止运行，无论容器是如何 终止的，kubelet服务都将重启它 (2)OnFailure: 只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束(退出码为0)，则kubelet将不会重启它 (3) Never: Pod终止后，kubelet将退出码报告给Master，不会重启该
spec.nodeSelectorObject定义Node的Label过滤标签，以key:value格式指定
spec.imagePullSecretsObject定义pull镜像时使用secret名称，以name:secretkey格式指定
spec.hostNetworkBoolean定义是否使用主机网络模式，默认值为false。设置true表示使用宿主机网络，不使用docker网桥，同时设置了true将无法在同一台宿主机 上启动第二个副本

示例

获取yaml模板

[root@k8s-master ~]# cd mqw/
[root@k8s-master mqw]# ls
[root@k8s-master mqw]# kubectl run test --image myapp:v1 --dry-run=client -o yaml > pod.yml

查看文件

[root@k8s-master mqw]# vim pod.yml

运行

资源回收

[root@k8s-master mqw]# kubectl delete -f pod.yml

注意如果多个容器运行在一个pod中，资源共享的同时在使用相同资源时也会干扰，比如端口

示例

[root@k8s-master mqw]# vim pod.yml

启动之后查看,此时有一个会启动不了

在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰

示例

[root@k8s-master mqw]# vim pod1.yml 


apiVersion: v1
kind: Pod 
metadata:
  labels:
    run: timing
  name: timinglee
spec:
  containers:
    - image: nginx/nginx:latest
      name: web1

    - image: busybox/busybox:latest
      name: busybox
      command: ["/bin/sh","-c","sleep 1000000"]
~

此时两个容器都运行了

同在一个pod中的容器公用一个网络

示例

[root@k8s-master mqw]# vim pod2.yml

运行

在同一pod下的容器进行测试

可以看到查看到了另一个容器的内容

端口映射

示例

[root@k8s-master mqw]# vim pod3.yml

运行

此时就可以访问了

设定环境变量

示例

[root@k8s-master mqw]# vim pod4.yml

运行，并测试

资源限制

示例

[root@k8s-master mqw]# vim pod5.yml


 limits是设置pod使用资源的最高限制	
 requests是设置pod期望使用资源量，不能大于limits

查看

容器启动管理

示例

[root@k8s-master mqw]# vim pod6.yml

选择节点管理

示例

[root@k8s-master mqw]# vim pod7.yml


apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timinglee
  name: test
spec:
  nodeSelector:
    kubernetes.io/hostname: k8s-2  #选择在节点2上运行
  restartPolicy: Always
  containers:
    - image: myapp:v1
      name: myapp
~

运行，可以看到在节点2上运行了

共享宿主机网络

示例

[root@k8s-master mqw]# vim pod8.yml


apiVersion: v1
kind: Pod
metadata:
  labels:
    run: timinglee
  name: test
spec:
  hostNetwork: true      #打开
  restartPolicy: Always
  containers:
    - image: busybox/busybox:latest
      name: busybox
      command: ["/bin/sh","-c","sleep 100000"]
~

运行，测试

[root@k8s-master mqw]# kubectl apply -f pod8.yml 


[root@k8s-master mqw]#  kubectl exec -it pods/test -c busybox -- /bin/s

pod的生命周期

  • Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

  • Init 容器与普通的容器非常像，除了如下两点：

    • 它们总是运行到完成

    • init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。

  • 如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动

INIT 容器的功能

  • Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。

  • Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。

  • 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

  • Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。

  • 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

示例

[root@k8s-master mqw]# vim pod9.yml

启动之后容器并没有运行，因为没有满足在容器内有mqw这个文件

此时在容器内创建mqw的文件后，就可以运行了

探针

探针是由 kubelet 对容器执行的定期诊断:

  • ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

  • TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。

  • HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

  • 成功：容器通过了诊断。

  • 失败：容器未通过诊断。

  • 未知：诊断失败，因此不会采取任何行动。

Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

  • livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。

  • readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。

  • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

ReadinessProbe 与 LivenessProbe 的区别

  • ReadinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。

  • LivenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施

StartupProbe 与 ReadinessProbe、LivenessProbe 的区别

  • 如果三个探针同时存在，先执行 StartupProbe 探针，其他两个探针将会被暂时禁用，直到 pod 满足 StartupProbe 探针配置的条件，其他 2 个探针启动，如果不满足按照规则重启容器。

  • 另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而 StartupProbe 探针只是在容器启动后按照配置满足一次后，不在进行后续的探

存活探针演示

[root@k8s-master mqw]# vim pod10.yml

解释

  tcpSocket作用：检测端口存在性
 initialDelaySeconds: 3		#容器启动后要等待多少秒后就探针开始工作，默认是 0
 periodSeconds: 1			#执行探测的时间间隔，默认为 10s
timeoutSeconds: 1			#探针执行检测请求后，等待响应的超时时间，默认为 1s

运行

就绪探针

[root@k8s-master mqw]# vim pod11.yml

此时启动后，但还是处于准备状态

端口启动微服务

[root@k8s-master mqw]# kubectl expose pod readiness --port 80 --target-port 80

此时查看详细信息，但端口没暴露，不满足条件

添加

[root@k8s-master mqw]# kubectl exec pods/readiness -c myapp -- /bin/sh -c "echo test > /usr/share/nginx/html/test.html"

查看,此时条件满足，已经运行了

查看详细信息

小毛002
关注
K8s（十一）：Pod 的 Node Selector详解
✨ 欢迎来到【Seal ^_^ 的优快云博客】！✨
04-06 1万+
🔴 K8s（十一）：Pod 的 Node Selector详解
K8s服务管理service、Dashboard、角色与授权
m0_73770890的博客
01-14 467
K8S服务管理、Ingress安装与配置、Dashboard安装、创建用户与角色授权
k8s之pod
weixin_41927873的博客
07-20 268
概念： Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。 一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。 Kubernetes中的Pod使用可分两种主要方式： Pod中运行一个容器。“one-container-per-Pod”模式是Kubernetes最常见的用法...
知识积累：kubernetes直接删除Pod后自动重建问题解决
最新发布
蓝色的鱼的专栏
02-28 394
在 Kubernetes 中，直接删除 Pod 后 Pod 自动重建，是因为Pod被更高层的控制器（如 Deployment、StatefulSet、DaemonSet、ReplicaSet或 Job/CronJob）管理。要彻底删除 Pod 并阻止重建，需找到并删除或修改对应的控制器。引子，接手一个kubernetes环境，查看所有pod时，发现一个pod未正常运行，经过业务熟悉可以进行删除。至此，处理完成，再次查看所有Pod，需要删除的已经正常删除。查看 Pod 的详细信息，找到其所属的控制器。
[云原生专题-33]：K8S - 核心概念 - 服务Service管理、服务发现、负载均衡
热门推荐
文火冰糖（王文兵）的博客
02-08 2万+
作者主页(文火冰糖的硅基工坊)：文火冰糖（王文兵）的博客_文火冰糖的硅基工坊_优快云博客 本文网址： 目录 前言： 第1章 服务Service管理概述 1.1 为什么需要服务? 1.2 什么是服务 1.3Service与Deployment的关系 1.4 总体的网络架构 第2章Service的类型与架构 2.1 ClusterIP Sevice 2.2 NodePort Sevice： 2.3 LoadBalancer Sevice： 第3章 Service相关的主要..
K8s-----pod详解
weixin_46254171的博客
10-31 462
Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象，一个pod代表着集群中运行的一个进程。kubernetes中其它大多数组件都是围绕着pod来进行支持和扩展pod功能的。例如，用于管理pod运行的statefulset和deployment 等控制器对象，用于暴露应用的service和ingress对象，为pod提供存储的persistentVolumes存储资源对象。在kubernetes集群中Pod有如下两种使用方式一个Pod中运行一个容器，
k8s实践(12)--K8s service服务详解
黄规速博客:学如逆水行舟，不进则退
06-30 1万+
一、集群的服务分类 在K8S运行的服务，从简单到复杂可以分成三类：无状态服务、普通有状态服务和有状态集群服务。下面分别来看K8S是如何运行这三类服务的。 1、无状态服务（Stateless Service）： 1）定义：是指该服务运行的实例不会在本地存储需要持久化的数据，并且多个实例对于同一个请求响应的结果是完全一致的。 2）随意扩容和缩容：这些节点可以随意扩容或者缩容，只要简单的增...
k8s的pod的管理
weixin_57304642的博客
10-10 1663
Kubernetes允许用户为Pod中的容器设置资源请求和限制，以确保容器在运行时有足够的资源。Pod的基本配置包括定义Pod的名称、容器镜像、端口、环境变量等。在这个示例中，我们定义了两个端口：80和443，分别用于HTTP和HTTPS通信。的Deployment，确保集群中始终运行3个Pod副本，并支持滚动更新和回滚。在这个示例中，我们使用StatefulSet管理Pod，并设置了Pod管理策略为。Pod中的容器可以暴露多个端口，以便与其他服务通信。Pod中的容器可以设置环境变量，以便在运行时使用。
kmem问题造成K8S中pod内存溢出
01-20
在Kubernetes(K8S)集群中，当遇到“kmem问题造成K8S中pod内存溢出”的情况，这通常意味着内核内存(kernel memory)的使用超过了预期限制，导致了Pod无法正常运行或者性能下降。内核内存是操作系统用于内部数据结构和...
K8s Pod 配置之 hostNetwork、hostPort、hostPID
Linux运维老纪的博客
02-15 946
在 Kubernetes 中，了解 Pod 如何与主机系统交互对于配置高级用例和确保最佳安全性至关重要。hostNetwork、hostPort、hostPID 和 hostIPC 等功能使 Pod 能够与主机共享命名空间和资源，从而实现更大的控制和灵活性。然而，这些配置也伴随着固有的风险和权衡，必须仔细评估。 本文详细解析了这些参数，探讨了它们的功能、用例和安全影响。无论我们是优化网络性能、排查应用程序问题，还是设置复杂的调试环境，这篇短文都可以帮助您了解如何有效地利用这些主机级配置。
k8s pod-infrastructure.tgz 软件包，用于 k8s部署基础包
03-26
《K8s Pod基础设施软件包详解》 在现代云计算领域，Kubernetes（简称K8s）作为容器编排的领头羊，已经成为管理和部署应用程序的标准工具。...理解这些文件的作用和相互关系，对于有效地管理和优化K8s集群至关重要。
Kubernetes之服务的基本管理
memory_hahaha的博客
02-25 420
Kubernetes之服务的基本管理
k8s资源管理
p1049990866的博客
09-05 1359
1. 基础 # 可以查看资源分配情况 kubectl describe node # 全局资源情况查看 kubectl api-resources 1.1 apply apply 命令可以使用配置文件创建资源 -f 使用yaml或json创建资源, 也是比较常用的方式 kubectl apply -f ./my1.yaml # 创建资源 kubectl apply -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建 kubectl
Kubernetes服务发现入门：如何高效管理服务？
Rancher
12-20 1179
愈发复杂的应用程序正在依靠微服务来保持可扩展性和提升效率。Kubernetes为微服务提供了完美的环境，并能够让其与Kubernetes的工具组件和功能兼容。当应用程序的每个部分放置在一个容器中，整个系统就会更具可伸缩性。 微服务和容器的运作方式也适合当下的CI/CD工作流程，即无需关闭整个系统进行更新，因为可以分别更新每个微服务（容器）。但是，这会使容器或pod的生命周期缩短，其IP地址会发生变...
k8s实践(12)--K8s service服务详解_kubernetes 中的service支持什么协议(1)
2301_82243078的博客
04-17 1264
为mywebsite.com定义Ingress，设置到后端Service的转发规则：metadata:spec:rules:http:paths:backend:这个Ingress的定义说明对目标http://mywebsite.com/web的访问将被转发到kubernetes的一个Service上 webapp:80创建该Ingress创建后登陆nginx-ingress Pod，查看自动生成的nginx.conf内容。
Kubernetes--Pod概述
GaoChuang_的博客
11-07 1148
一、Pod调度 在kubernetes平台上，很少会直接创建一个Pod，大多数情况下会通过RC(ReplicationController)、Deployment、DaemonSet、Job等控制器完成对一组Pod副本的创建，调用以及生命周期管理的自动控制任务。 在最早的kubernetes版本里面没有这么多的Pod副本控制器，只有一个Pod副本控制器RC(ReplicationController)，其实现方式: RC独立于所控制的Pod，并通过Label标签这个松耦合关联关系控制目...
云原生之k8s服务管理
随便写写
11-21 2244
Dashboard 是什么？Dashboard 是基于网页的 Kubernetes 用户界面。Dashboard 同时展示了 Kubernetes 集群中的资源状态信息和所有报错信息。你可以使用 Dashboard 将应用部署到集群中，也可以对容器应用排错，还能管理集群资源。例如，你可以对应用弹性伸缩、发起滚动升级、重启等等。
Pod详解-端口设置
Leon_Jinhai_Sun的博客
09-12 2127
首先看下ports支持的子选项： [root@k8s-master01 ~]# kubectl explain pod.spec.containers.ports KIND: Pod VERSION: v1 RESOURCE: ports <[]Object> FIELDS: name <string> # 端口名称，如果指定，必须保证name在pod中是唯一的 containerPort<integer> # 容器要监听的
k8s pod亲和 topologyKey
12-09
在Kubernetes (k8s) 中，Pod 的亲和性和拓扑键（Topology Key）是一种策略，它允许管理员将Pod 部署到特定的集群节点上，基于这些节点具有的某些特性，比如物理位置、网络接近度等。`TopologyKey` 是一个用于指定Pod 关联到特定拓扑域的键名，常见的拓扑域有 `kubernetes.io/hostname` (主机名)、`kubernetes.io/zone` (区域) 或 `kubernetes.io/cluster` (集群分区) 等。 当你设置 Pod 的亲和性（Affinity）规则，并指定了 `topologyKey`，例如： ```yaml affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "my-app" operator: In topologyKey: "kubernetes.io/zone" ``` 这意味着Pod 只能在与它具有匹配标签 `my-app` 的其他Pod 在同一区域（zone）的节点上运行，从而优化了资源使用和网络性能。
评论 4
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值