pod
在k8s中,最小单元就是pod了,程序运行部署在容器中,而容器必须存在于pod中
pod可以认为是容器的封装,一个pod可以存放一个或者多个容器:
root@master:/home/tioncico# kubectl get pods NAME READY STATUS RESTARTS AGE go-deployment-86f769995d-frw28 1/1 Running 0 38s nginx-7cbb8cd5d8-w9tn2 1/1 Running 4 (12d ago) 18d
查看pod详细信息
root@master:/home/tioncico# kubectl describe pod go-deployment Name: go-deployment-86f769995d-frw28 Namespace: default Priority: 0 Node: node-1/192.168.192.10 Start Time: Mon, 26 Sep 2022 05:56:03 +0000 Labels: app=go pod-template-hash=86f769995d Annotations: <none> Status: Running IP: 10.244.1.10 IPs: IP: 10.244.1.10 Controlled By: ReplicaSet/go-deployment-86f769995d Containers: go: Container ID: docker://fa6cfef2511074866a6b626295314cb4b9dc275894ec7d137616d800e1a84bae Image: tioncico/go:v1.0.1 Image ID: docker-pullable://tioncico/go@sha256:08271bc1b9ac9317c577bf2888f36c0897996f5bae1085e941dcee62a21a8776 Port: 8080/TCP Host Port: 0/TCP Command: ./main -v v1.0.1 State: Running Started: Mon, 26 Sep 2022 05:56:11 +0000 Ready: True Restart Count: 0 Environment: <none> Mounts: /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-7fcwk (ro) Conditions: Type Status Initialized True Ready True ContainersReady True PodScheduled True Volumes: kube-api-access-7fcwk: Type: Projected (a volume that contains injected data from multiple sources) TokenExpirationSeconds: 3607 ConfigMapName: kube-root-ca.crt ConfigMapOptional: <nil> DownwardAPI: true 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 8m4s default-scheduler Successfully assigned default/go-deployment-86f769995d-frw28 to node-1 Normal Pulling 8m1s kubelet Pulling image "tioncico/go:v1.0.1" Normal Pulled 7m57s kubelet Successfully pulled image "tioncico/go:v1.0.1" in 4.542296147s Normal Created 7m57s kubelet Created container go Normal Started 7m56s kubelet Started container go root@master:/home/tioncico#
可以看到pod有着以下几个关键信息
pod-label
pod-label的作用就是在pod中添加标识,用来对资源进行区分和选择,例如上面的 app=go
同样可以添加版本,环境,架构等等标签 version:"1.0.1" environment:"dev"
通过label,可以对资源进行筛选,区分
root@master:/home/tioncico# kubectl get pod -l app=go NAME READY STATUS RESTARTS AGE go-deployment-86f769995d-frw28 1/1 Running 0 13m root@master:/home/tioncico#
pod-namespace
Namespace是kubernetes系统中的一种非常重要资源,它的主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。
默认情况下,kubernetes集群中的所有的Pod都是可以相互访问的。但是在实际中,可能不想让两个Pod之间进行互相的访问,那此时就可以将两个Pod划分到不同的namespace下。kubernetes通过将集群内部的资源分配到不同的Namespace中,可以形成逻辑上的"组",以方便不同的组的资源进行隔离使用和管理。
可以通过kubernetes的授权机制,将不同的namespace交给不同租户进行管理,这样就实现了多租户的资源隔离。此时还能结合kubernetes的资源配额机制,限定不同租户能占用的资源,例如CPU使用量、内存使用量等等,来实现租户可用资源的管理。
查看列表
root@master:/home/tioncico# kubectl get namespace NAME STATUS AGE default Active 18d //默认的命名空间,没有声明的都会在默认 kube-flannel Active 18d //k8s flannel插件 kube-node-lease Active 18d //集群节点心跳维护 kube-public Active 18d //k8s公共资源你,可以被所有人访问 kube-system Active 18d //k8s系统创建的资源 kubernetes-dashboard Active 18d //k8s dashboard root@master:/home/tioncico#
查看详情
root@master:/home/tioncico# kubectl describe ns default Name: default Labels: kubernetes.io/metadata.name=default Annotations: <none> Status: Active No resource quota. No LimitRange resource.
创建
root@master:/home/tioncico# kubectl create ns dev-test namespace/dev-test created
删除
root@master:/home/tioncico# kubectl delete ns dev-test namespace "dev-test" deleted
yaml配置
可通过 kubectl get ns default -o yaml 输出yaml格式的配置项
root@master:/home/tioncico# kubectl get ns default -o yaml apiVersion: v1 kind: Namespace metadata: creationTimestamp: "2022-09-07T08:11:59Z" labels: kubernetes.io/metadata.name: default name: default resourceVersion: "205" uid: d1f23d3c-ed99-41e8-83b3-366e203d2384 spec: finalizers: - kubernetes status: phase: Active root@master:/home/tioncico#
pod-controller
Pod是kubernetes的最小管理单元,在kubernetes中,按照pod的创建方式可以将其分为两类:
- 自主式pod:kubernetes直接创建出来的Pod,这种pod删除后就没有了,也不会重建
- 控制器创建的pod:kubernetes通过控制器创建的pod,这种pod删除了之后还会自动重建
什么是Pod控制器
Pod控制器是管理pod的中间层,使用Pod控制器之后,只需要告诉Pod控制器,想要多少个什么样的Pod就可以了,它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障,它会基于指定策略重新编排Pod。
在kubernetes中,有很多类型的pod控制器,每种都有自己的适合的场景,常见的有下面这些:
- ReplicationController:比较原始的pod控制器,已经被废弃,由ReplicaSet替代
- ReplicaSet:保证副本数量一直维持在期望值,并支持pod数量扩缩容,镜像版本升级
- Deployment:通过控制ReplicaSet来控制Pod,并支持滚动升级、回退版本
- Horizontal Pod Autoscaler:可以根据集群负载自动水平调整Pod的数量,实现削峰填谷
- DaemonSet:在集群中的指定Node上运行且仅运行一个副本,一般用于守护进程类的任务
- Job:它创建出来的pod只要完成任务就立即退出,不需要重启或重建,用于执行一次性任务
- Cronjob:它创建的Pod负责周期性任务控制,不需要持续后台运行
- StatefulSet:管理有状态应用
在我之前的文章中,基本是deployment控制器,然后控制replicaSet来控制pod的,其他控制器可以自行了解试试