想在网上做设计接单有没有网站,服装设计投稿平台有哪些,关于开展全县中小学校网站群建设的请示报告,网站备案幕布申请目录 什么是PodPod与容器不同Pod如何管理多个容器Pod的管理-工作负载K8s中的资源清单创建使用Pod直接创建Pod使用 Deployment 创建Pod 环境变量重启策略镜像拉取策略访问 DNS 的策略资源限制初始化容器临时容器#xff08;了解#xff09; 什么是Pod
Pod 是可以在 Kubernete… 目录 什么是PodPod与容器不同Pod如何管理多个容器Pod的管理-工作负载K8s中的资源清单创建使用Pod直接创建Pod使用 Deployment 创建Pod 环境变量重启策略镜像拉取策略访问 DNS 的策略资源限制初始化容器临时容器了解 什么是Pod
Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。
Pod是在K8s集群中运行部署应用或服务的最小单元它是可以支持多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。Pod对多容器的支持是K8s最基础的设计理念。比如你运行一个操作系统发行版的软件仓库一个Nginx容器用来发布软件另一个容器专门用来从源仓库做同步这两个容器的镜像不太可能是一个团队开发的但是他们一块儿工作才能提供一个微服务这种情况下不同的团队各自开发构建自己的容器镜像在部署的时候组合成一个微服务对外提供服务。
Pod是K8s集群中所有业务类型的基础可以看作运行在K8s集群中的小机器人不同类型的业务就需要不同类型的小机器人去执行。目前K8s中的业务主要可以分为长期伺服型long-running、批处理型batch、节点后台支撑型node-daemon和有状态应用型stateful application分别对应的小机器人控制器为Deployment、Job、DaemonSet和StatefulSet本文后面会一一介绍。
Pod与容器不同
前面我们知道容器是 Pod 中实际运行应用程序的载体。
那为什么不直接使用容器还要有Pod这个东西呢
主要有以下几个方面的考虑
多容器协同一个 Pod 中可以运行多个容器这些容器可以共享同一个网络命名空间、存储卷等资源。这使得在一个 Pod 内部的多个容器之间实现通信和数据共享变得更加方便。比如你可以在同一个 Pod 中运行一个应用程序容器和一个辅助容器用于收集日志或处理数据。共享网络和存储命名空间在同一个 Pod 中的容器可以共享相同的 IP 地址和端口空间这对于容器之间的通信非常有用。此外它们还可以共享同一份存储卷这意味着它们可以在相同的文件系统中读写数据从而实现数据共享。调度和伸缩K8s 通常按照 Pod 来进行调度和伸缩。当你定义一个 Deployment 或者 Replication Controller 时你实际上是在定义 Pod 的副本数量。K8s 会自动创建和管理这些 Pod 的实例确保它们按照所需的数量在集群中运行。生命周期管理Pod 提供了更高级别的生命周期管理。当一个 Pod 被创建时它的生命周期与其内部的所有容器密切相关。这意味着如果一个容器失败整个 Pod 可能会重新启动。此外Pod 还提供了一些钩子lifecycle hooks可以在容器启动之前或之后执行特定的操作以便实现更复杂的初始化或清理逻辑。资源共享和限制Pod 允许你在多个容器之间共享资源比如 CPU 和内存。你可以设置资源请求和限制以确保 Pod 中的容器不会相互干扰从而实现更好的资源管理。
Pod如何管理多个容器
Pod 中可以同时运行多个容器。同一个 Pod 中的容器会自动的分配到同一个 node 上。同一个 Pod 中的容器共享资源、网络环境它们总是被同时调度在一个 Pod 中同时运行多个容器是一种比较高级的用法只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如你有一个容器作为 web 服务器运行需要用到共享的 volume有另一个“sidecar”容器来从远端获取资源更新这些文件。
一些 Pod 有 init 容器和应用容器。 在应用程序容器启动之前运行初始化容器。
Pod 天生地为其成员容器提供了两种共享资源网络和存储。
Pod的管理-工作负载
通常不需要直接创建 Pod而是使用诸如 Deployment 或 Job这类工作负载资源来创建 Pod。
工作负载是运行的 Kubernetes 上的一个应用程序。
一个应用很复杂可能由单个组件或者多个组件共同完成。我们可以用一组 Pod 来描述一个应用也就是一个工作负载而 Pod 是一组容器。
换言之工作负载控制一组 Pod Pod 控制一组容器如Deployment【工作负载】部署 3 个副本的 nginx-pod 每个 nginx-pod 里面是真正的 nginx 容器。
工作负载能让 Pod 拥有自愈能力。我们主要研究不同的工作负载如何控制 Pod 的行为。
K8s中的资源清单
在 K8s 中所有的资源都可以使用一个 yaml 文件来创建。下面是资源对应的yaml的配置项
参数名类型字段说明apiVersionStringK8S APl 的版本可以用 kubectl api versions 命令查询kindStringyam 文件定义的资源类型和角色metadataObject元数据对象下面是它的属性metadata.nameString元数据对象的名字比如 pod 的名字metadata.namespaceString元数据对象的命名空间SpecObject详细定义对象spec.containers[]list定义 Spec 对象的容器列表spec.containers[].nameString为列表中的某个容器定义名称spec.containers[].imageString为列表中的某个容器定义需要的镜像名称spec.containers[].imagePullPolicystring定义镜像拉取策略有 Always、Never、IfNotPresent 三个值可选 - Always默认意思是每次都尝试重新拉取镜像 - Never表示仅适用本地镜像 - IfNotPresent如果本地有镜像就使用本地镜像没有就拉取在线镜像。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默认值为 TCPspec.containers[].env[]list指定容器运行前需设置的环境变量列表spec.containers[].env[].namestring指定环境变量名称spec.containers[].env[].valuestring指定环境变量值spec.containers[].resourcesObject指定资源限制和资源请求的值这里开始就是设置容器的资源上限spec.containers[].resources.limitsObject指定设置容器运行时资源的运行上限spec.containers[].resources.limits.cpustring指定 CPU 的限制单位为 Core 数将用于 docker run –cpu-shares 参数spec.containers[].resources.limits.memorystring指定 mem 内存的限制单位为 MIB、GiBspec.containers[].resources.requestsObject指定容器启动和调度时的限制设置spec.containers[].resources.requests.cpustringCPU请求单位为core数容器启动时初始化可用数量spec.containers[].resources.requests.memorystring内存请求单位为MIB、GiB容器启动的初始化可用数量spec.restartPolicystring定义 pod 的重启策略可选值为 Always、OnFailure、Never默认值为 Always。 - Alwayspod 一旦终止运行则无论容器是如何终止的kubelet 服务都将重启它。 - OnFailure只有 pod 以非零退出码终止时kubelet 才会重启该容器。如果容器正常结束退出码为0则 kubectl 将不会重启它。 - NeverPod 终止后kubelet 将退出码报告给 master不会重启该 podspec.nodeSelectorObject定义 Node 的 label 过滤标签以 keyvalue 格式指定spec.imagePullSecretsObject定义 pull 镜像时使用 secret 名称以 namesecretkey 格式指定spec.hostNetworkBoolean定义是否使用主机网络模式默认值为 false。设置 true 表示使用宿主机网络不使用 docker 网桥同时设置了 true将无法在同一台宿主机上启动第二个副本
创建使用Pod
可以使用 Deployment 等各种工作负载的 yaml 文件创建 Pod 也可以直接创建 Pod实际生产中不推荐 。
创建 Pod 也可以使用 yaml 配置文件。或者使用 kubectl run 在命令行创建 Pod不常用。
直接创建Pod
首先创建一个yaml文件来定义Pod用来创建一个nginx服务yaml如下
apiVersion: v1 # api 文档版本
kind: Pod # 资源对象类型也可以配置为像Deployment、StatefulSet这一类的对象
metadata: # Pod 相关的元数据用于描述 Pod 的数据name: nginx-demo # Pod 的名称labels: # 定义 Pod 的标签type: app # 自定义 label 标签名字为 type值为 apptest: 1.0.0 # 自定义 label 标签描述 Pod 版本号namespace: default # 命名空间的配置
spec: # 期望 Pod 按照这里面的描述进行创建containers: # 对于 Pod 中的容器描述- name: nginx # 容器的名称image: nginx:1.7.9 # 指定容器的镜像imagePullPolicy: IfNotPresent # 镜像拉取策略指定如果本地有就用本地的如果没有就拉取远程的command: # 指定容器启动时执行的命令- nginx- -g- daemon off; # nginx -g daemon off;workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录ports:- name: http # 端口名称containerPort: 80 # 描述容器内要暴露什么端口protocol: TCP # 描述该端口是基于哪种协议通信的env: # 环境变量- name: JVM_OPTS # 环境变量名称value: -Xms128m -Xmx128m # 环境变量的值resources:requests: # 最少需要多少资源cpu: 100m # 限制 cpu 最少使用 0.1 个核心memory: 128Mi # 限制内存最少使用 128兆limits: # 最多可以用多少资源cpu: 200m # 限制 cpu 最多使用 0.2 个核心memory: 256Mi # 限制 最多使用 256兆restartPolicy: OnFailure # 重启策略只有失败的情况才会重启创建完文件后执行如下命令创建pod
kubectl apply -f nginx-demo.yaml
# 创建成功时打印如下
# pod/nginx-demo created创建成功后可以查看Pod
kubectl get po结果如下
NAME READY STATUS RESTARTS AGE
nginx-demo 1/1 Running 0 29s注意只有READY了这个pod才是真正可用的。
还可以查看更多信息
kubectl get po -o wide结果如下
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-demo 1/1 Running 0 12m 10.1.0.10 docker-desktop none none同时我们可以使用discribe查看pod的详细信息
kubectl describe po nginx-demo结果如下
Name: nginx-demo
Namespace: default
Priority: 0
Service Account: default
Node: docker-desktop/192.168.65.4
Start Time: Thu, 10 Aug 2023 21:40:07 0800
Labels: test1.0.0typeapp
Annotations: none
Status: Running
IP: 10.1.0.10
IPs:IP: 10.1.0.10
Containers:nginx:Container ID: docker://0e3d50bbaab39c6f34f0bdbbdfc8edea7e40a0d2b7650701bb656b90606ef973Image: nginx:1.7.9Image ID: docker-pullable://nginxsha256:e3456c851a152494c3e4ff5fcc26f240206abac0c9d794affb40e0714846c451Port: 80/TCPHost Port: 0/TCPCommand:nginx-gdaemon off;State: RunningStarted: Thu, 10 Aug 2023 21:40:25 0800Ready: TrueRestart Count: 0Limits:cpu: 200mmemory: 256MiRequests:cpu: 100mmemory: 128MiEnvironment:JVM_OPTS: -Xms128m -Xmx128mMounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-hxd9m (ro)
Conditions:Type StatusInitialized TrueReady TrueContainersReady TruePodScheduled True
Volumes:kube-api-access-hxd9m:Type: Projected (a volume that contains injected data from multiple sources)TokenExpirationSeconds: 3607ConfigMapName: kube-root-ca.crtConfigMapOptional: nilDownwardAPI: true
QoS Class: Burstable
Node-Selectors: none
Tolerations: node.kubernetes.io/not-ready:NoExecute opExists for 300snode.kubernetes.io/unreachable:NoExecute opExists for 300s
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 4m55s default-scheduler Successfully assigned default/nginx-demo to docker-desktopNormal Pulling 4m55s kubelet Pulling image nginx:1.7.9Normal Pulled 4m37s kubelet Successfully pulled image nginx:1.7.9 in 17.155282967s (17.155348675s including waiting)Normal Created 4m37s kubelet Created container nginxNormal Started 4m37s kubelet Started container nginx最下面有这个pod发生的事件Events可以看到整个pod创建的过程。主要有如下几步
第1行default-scheduler为我们分配节点Successfully assigned default/nginx-demo to docker-desktop第2行kubelet执行拉取镜像Pulling image “nginx:1.7.9”第3行kubelet成功拉取了镜像第4行kubelet执行创建容器Created container nginx第5行kubelet启动了容器
这个事件对我们后面学习和排错非常重要。
使用 Deployment 创建Pod
创建如下nginx-deployment-demo.yaml文件内容如下
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-testlabels:app: nginx-deploy
spec:selector:matchLabels:app: nginxreplicas: 2 # 指定副本数template:metadata:labels:app: nginx # 标签用来选择资源使用spec:containers:- name: my-nginx # 容器名字image: nginx # 镜像名imagePullPolicy: IfNotPresentports:- containerPort: 80执行命令
kubectl apply -f nginx-deployment-demo.yaml创建成功后打印如下
deployment.apps/nginx-test created我们可以看下创建的资源
kubectl get deploy打印如下
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-test 2/2 2 2 99s查看我们创建的pod可使用我们yaml里定义的标签选择来过滤 kubectl get pods -o wide -l appnginx如下
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-test-b65fff6d9-jhcgj 1/1 Running 0 10m 10.1.0.17 docker-desktop none none
nginx-test-b65fff6d9-qkmgl 1/1 Running 0 10m 10.1.0.16 docker-desktop none none同时我们在yaml里定义了副本数是2如果我们删除一个如下
kubectl delete pod nginx-test-b65fff6d9-qkmgl再次查询pod结果如下
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-test-b65fff6d9-j7n24 1/1 Running 0 28s 10.1.0.18 docker-desktop none none
nginx-test-b65fff6d9-jhcgj 1/1 Running 0 14m 10.1.0.17 docker-desktop none none可以看到有重新创建了一个pod name为nginx-test-b65fff6d9-j7n24。因此可以知道通过 deployment 管理的 pod可以确保 pod 始终维持在指定副本数量并且使用两个pod效果是一样的。
环境变量
环境变量为容器提供了一些重要的资源包括容器和 Pod 的基本信息以及集群中服务的信息等
(1) hostname
HOSTNAME 环境变量保存了该 Pod 的 hostname。
2容器和 Pod 的基本信息
Pod 的名字、命名空间、IP 以及容器的计算资源限制等可以以 Downward API 的方式获取并存储到环境变量中。
apiVersion: v1
kind: Pod
metadata:name: test
spec:containers:- name: test-containerimage: gcr.io/google_containers/busyboxcommand: [sh, -c]args:- envresources:requests:memory: 32Micpu: 125mlimits:memory: 64Micpu: 250menv:- name: MY_NODE_NAMEvalueFrom:fieldRef:fieldPath: spec.nodeName- name: MY_POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: MY_POD_NAMESPACEvalueFrom:fieldRef:fieldPath: metadata.namespace- name: MY_POD_IPvalueFrom:fieldRef:fieldPath: status.podIP- name: MY_POD_SERVICE_ACCOUNTvalueFrom:fieldRef:fieldPath: spec.serviceAccountName- name: MY_CPU_REQUESTvalueFrom:resourceFieldRef:containerName: test-containerresource: requests.cpu- name: MY_CPU_LIMITvalueFrom:resourceFieldRef:containerName: test-containerresource: limits.cpu- name: MY_MEM_REQUESTvalueFrom:resourceFieldRef:containerName: test-containerresource: requests.memory- name: MY_MEM_LIMITvalueFrom:resourceFieldRef:containerName: test-containerresource: limits.memoryrestartPolicy: Never(3) 集群中服务的信息
容器的环境变量中还可以引用容器运行前创建的所有服务的信息比如默认的 kubernetes 服务对应以下环境变量
KUBERNETES_PORT_443_TCP_ADDR10.0.0.1
KUBERNETES_SERVICE_HOST10.0.0.1
KUBERNETES_SERVICE_PORT443
KUBERNETES_SERVICE_PORT_HTTPS443
KUBERNETES_PORTtcp://10.0.0.1:443
KUBERNETES_PORT_443_TCPtcp://10.0.0.1:443
KUBERNETES_PORT_443_TCP_PROTOtcp
KUBERNETES_PORT_443_TCP_PORT443由于环境变量存在创建顺序的局限性环境变量中不包含后来创建的服务推荐使用 DNS 来解析服务。
重启策略
支持三种 RestartPolicy
Always当容器失效时由Kubelet自动重启该容器。RestartPolicy的默认值。OnFailure当容器终止运行且退出码不为0时由Kubelet重启。Never无论何种情况下Kubelet都不会重启该容器。
注意这里的重启是指在 Pod 所在 Node 上面本地重启并不会调度到其他 Node 上去。
镜像拉取策略
支持三种 ImagePullPolicy
Always不管本地镜像是否存在都会去仓库进行一次镜像拉取。校验如果镜像有变化则会覆盖本地镜像否则不会覆盖。Never只是用本地镜像不会去仓库拉取镜像如果本地镜像不存在则Pod运行失败。IfNotPresent只有本地镜像不存在时才会去仓库拉取镜像。ImagePullPolicy的默认值。
注意
默认为 IfNotPresent但 :latest 标签的镜像默认为 Always。拉取镜像时 docker 会进行校验如果镜像中的 MD5 码没有变则不会拉取镜像数据。生产环境中应该尽量避免使用 :latest 标签而开发环境中可以借助 :latest 标签自动拉取最新的镜像。
访问 DNS 的策略
通过设置 dnsPolicy 参数设置 Pod 中容器访问 DNS 的策略
ClusterFirst优先基于 cluster domain 如 default.svc.cluster.local 后缀通过 kube-dns 查询 (默认策略)Default优先从 Node 中配置的 DNS 查询
资源限制
Kubernetes 通过 cgroups 限制容器的 CPU 和内存等计算资源包括 requests请求调度器保证调度到资源充足的 Node 上如果无法满足会调度失败和 limits上限等
spec.containers[].resources.limits.cpuCPU 上限可以短暂超过容器也不会被停止spec.containers[].resources.limits.memory内存上限不可以超过如果超过容器可能会被终止或调度到其他资源充足的机器上spec.containers[].resources.limits.ephemeral-storage临时存储容器可写层、日志以及 EmptyDir 等的上限超过后 Pod 会被驱逐spec.containers[].resources.requests.cpuCPU 请求也是调度 CPU 资源的依据可以超过spec.containers[].resources.requests.memory内存请求也是调度内存资源的依据可以超过但如果超过容器可能会在 Node 内存不足时清理spec.containers[].resources.requests.ephemeral-storage临时存储容器可写层、日志以及 EmptyDir 等的请求调度容器存储的依据
比如 nginx 容器请求 30% 的 CPU 和 56MB 的内存但限制最多只用 50% 的 CPU 和 128MB 的内存
apiVersion: v1
kind: Pod
metadata:labels:app: nginxname: nginx
spec:containers:- image: nginxname: nginxresources:requests:cpu: 300mmemory: 56Milimits:cpu: 500mmemory: 128Mi注意
CPU 的单位是 CPU 个数可以用 millicpu (m) 表示少于 1 个 CPU 的情况如 500m 500millicpu 0.5cpu而一个 CPU 相当于 AWS 上的一个 vCPUGCP 上的一个 CoreAzure 上的一个 vCore物理机上开启超线程时的一个超线程 内存的单位则包括 E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki 等。从 v1.10 开始可以设置 kubelet ----cpu-manager-policystatic 为 Guaranteed即 requests.cpu 与 limits.cpu 相等Pod 绑定 CPU通过 cpuset cgroups。
初始化容器
Pod 能够具有多个容器应用运行在容器里面但是它也可能有一个或多个先于应用容器启动的 Init 容器。Init 容器在所有容器运行之前执行run-to-completion常用来初始化配置。
如果为一个 Pod 指定了多个 Init 容器那些容器会按顺序一次运行一个。 每个 Init 容器必须运行成功下一个才能够运行。 当所有的 Init 容器运行完成时Kubernetes 初始化 Pod 并像平常一样运行应用容器。
初始化容器有很多的应用场景下面列出的是最常见的几个
提供主容器镜像中不具备的工具程序或自定义代码。初始化容器要先于应用容器串行启动并运行完成因此可用于延后应用容器的启动直至其依赖的条件得到满足。
下面是一个 Init 容器的示例
apiVersion: v1
kind: Pod
metadata:name: init-demo
spec:containers:- name: nginximage: nginxports:- containerPort: 80volumeMounts:- name: workdirmountPath: /usr/share/nginx/html# These containers are run during pod initializationinitContainers:- name: installimage: busyboxcommand:- wget- -O- /work-dir/index.html- http://kubernetes.iovolumeMounts:- name: workdirmountPath: /work-dirdnsPolicy: Defaultvolumes:- name: workdiremptyDir: {}因为 Init 容器具有与应用容器分离的单独镜像使用 init 容器启动相关代码具有如下优势
它们可以包含并运行实用工具出于安全考虑是不建议在应用容器镜像中包含这些实用工具的。它们可以包含使用工具和定制化代码来安装但是不能出现在应用镜像中。例如创建镜像没必要 FROM 另一个镜像只需要在安装过程中使用类似 sed、 awk、 python 或 dig 这样的工具。它们在应用容器启动之前运行完成然而应用容器并行运行所以 Init 容器提供了一种简单的方式来阻塞或延迟应用容器的启动直到满足了一组先决条件。它们使用 Linux Namespace所以对应用容器具有不同的文件系统视图。因此它们能够具有访问 Secret 的权限而应用容器不能够访问。
临时容器了解
临时容器是一种特殊的容器该容器可以在现有的 Pod 中临时运行以便完成我们发起的操作比如故障排查。我们应该使用临时容器来检查服务而不是用临时容器来构建应用程序。
Pod 是 Kubernetes 集群进行管理的最小单元由于 Pod 是一次性且可以替换的因此 Pod 一旦被创建就无法将容器加入到Pod 中。而且我们通常使用 Deployment 来删除并替换Pod。但是有的时候我们需要检查现有 Pod 的状态比如对难以复现的故障进行排查。在这些场景中可以在现有 Pod 中运行临时容器来检查其状态并运行任意命令。 临时容器在目前的 Kubernetes 版本是 beta 。 和常规容器一样将临时容器添加到Pod后不能更改或删除临时容器。
