Joohwan

K8s工作负载-Job 基于1.25 什么是JobJob会创建一个或多个Pod，并持续重试Pod的执行，直至指定数量的Pod成功终止 随着Pod成功终止，Job会记录成功的Pod个数，Pod到达指定数量，Job终止 删除Job，会删除Job的所有Pod JobSpec Ref:https://github.com/kubernetes/api/blob/f7b7ea4f0fcc6cb8c8dd42eb46a94c7e163d1b9d/batch/v1/types.go#L206 // JobSpec describes how the job execution will look like.type JobSpec struct { // Specifies the maximum desired number of pods the job should // run at any given time. The actual number of pods running in steady state will // be less than this numb ...

K8s工作负载-DaemonSet 基于1.25 什么是DaemonSetDaemonSet 控制器确保所有（或一部分）的节点都运行了一个指定的 Pod 副本，缩写DS 使用场景 在每个节点上运行集群的存储守护进程，例如 glusterd、ceph 在每个节点上运行日志收集守护进程，例如 fluentd、logstash 在每个节点上运行监控守护进程，例如 Prometheus Node Exporter (opens new window)、Sysdig Agent (opens new window)、collectd、Dynatrace OneAgent (opens new window)、APPDynamics Agent (opens new window)、Datadog agent (opens new window)、New Relic agent (opens new window)、Ganglia gmond、Instana Agent (opens new window)等 DaemonSetSpec Ref:https://github.com/kuber ...

K8s工作负载-StatefulSet 基于1.25 什么是StatefulSetStatefulSet负责管理有状态应用，缩写sts 要求管理的Pod具有稳定的网络标识符和存储卷，实现又状态应用的数据持久化和数据访问 管理Pod，会对Pod有一个按照顺序增大的ID 使用场景 具有稳定、唯一的网络标识符（DNS Name） 每个Pod是中对应各自的存储路径（PersistVolumeClaimTempleate） 按照顺序增加副本、减少副本，并且在减少副本的时执行清理 按照顺序执行滚动更新 限制 Pod存储的要么由Storage Class的PVC提供，要么事先创建 删除或缩容一个StatefulSet不会删除对应的数据卷，确保数据安全 在删除StatefulSet，无法确保Pod的终止的正常的 如果需要，需要使用优雅的终止，需要先Scale Down到0 在使用默认的Pod Management Policy（OraderReady）进行滚动更新，可能会进入到错误状态，需要人工介入 ⚠️：不要时强制删除StatefulSet管理的Pod，本身机制，只会最多提供一个对外 ...

K8s工作负载-ReplicaSet 基于1.25 什么是ReplicaSetReplicaSet的为指定Pod维护一个副本数量的集合，缩写RS 一般新版本，用户不直接操作RS 通过Deployment的生命周期，来管理RS ReplicaSetSpec Ref：https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/pkg/apis/apps/types.go#L818 // ReplicaSetSpec is the specification of a ReplicaSet.// As the internal representation of a ReplicaSet, it must have// a Template set.type ReplicaSetSpec struct { // Replicas is the number of desired replicas. // 期望副本数量 Replicas int32 // Min ...

K8s工作负载-Deployment 基于1.25 什么是DeploymentDeployment 最常见就是部署无状服务，缩写Deploy Deployment实现声明的方法控制Pod和ReplicaSet 支持滚定升级和回滚应用 支持扩容和缩容 暂停和继续Deployment DeploymentSpec Ref：https://github.com/kubernetes/api/blob/271c79cac830e76e5e563330b3ec60d46948464e/apps/v1/types.go#L377 // DeploymentSpec is the specification of the desired behavior of the Deployment.type DeploymentSpec struct { // Number of desired pods. This is a pointer to distinguish between explicit // zero and not specified. Defaults to 1. ...

K8s核心资源对象-Pod（状态以及原地升级） 基于1.25 Pod的PodStatus Ref：https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/pkg/apis/core/types.go#L3365 // PodStatus represents information about the status of a pod. Status may trail the actual// state of a system.type PodStatus struct { // +optional // Pod生命周期，包含Pending、Running、Succeeded、Failed和Unknown Phase PodPhase // +optional // Pod的多个状态条件，包含ContainersReady、PodInitalized、PodReady Conditions []PodCondition // A human read ...

K8s核心资源对象-Pod（健康检查） 基于1.25 什么是健康检查K8s支持三种健康检查： livenessProbe：存活探针 表示容器是否在运行，是否需要重启 如果liveness探测为Failure，kubelete会终止容器，按照策略重启 readinessProbe：就绪探针 表示容器是准备好接受请求 如果readiness探测失败，从Endpoint控制器种移除改PodIP startupProbe：启动探针 设置了启动探针，其他的被暂时禁用，直至启动探针成功 启动探针失败，按照策略重启 对于启动时间长的场景 ProbeManagerProbeManager负责管理Pod探针，是一个Manager的接口声明。 当执行AddPod func，会为Pod每一个容器创建一个探测的worker worker会对分配的容器，定期周期性探测，并且缓存探测结果 执行UpdatePodStatus func，Manager会使用缓存结果把PodStatus设置类似Ready状态 相关接口说明： AddPod：为Pod每个容器添加对应的探测worker StopLi ...

K8s核心资源对象-Pod（静态Pod） 基于1.25 什么是静态PodStatic Pod在指定Node由kubelet守护进程之间管理，不需要kube-apiserver监管。 kubelete监视每个static Pod（失败之后重启） static Pod只允许在某一个节点上 节点上运行Pod ，API Server是可见的，但是不受到kube-apiserver控制 创建静态Pod有俩种模式：配置文件和HTTP 配置文件：定义标准的Pod，用JSON或者YAML格式存储在指定目录 使用kubelet的”staticPodPath:“ kubelet定期扫描目录，实现Pod 的CRUD 扫描忽略已点号开头的文件 静态Pod的创建流程有三种func： NewSourceFile NewSourceURL NewSourceApiserver 最终通过m.merger.Merge最终合并 Ref:https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea6 ...

K8s核心资源对象-Pod（QoS与驱逐顺序） 基于1.25 什么是QoSQos的三个选值： Guaranteed：最严格的最不可怜面临驱逐，保证它们不会退出，直到超过它们的限制或没有可以从节点抢占的低优先级Pod 要求每一个Pod容器都要有limits和requests limits和requests必须相等 Burstable：Pod基于一些请求的下限保证，不需要特定的限制 不指定，使用None，允许Pod可用时候灵活增加资源 当Node资源压力导致Pod被驱逐，只有在所有的BestEffort类型的Pod被驱逐之后，Burstable才会被驱逐 要求至少有一个Pod有CPU requests和limits BestEffort：如果节点面临资源压力，kubelete更愿意驱逐BestEffort的Pod 所有容器都没有limits和requests QoS的计算参与QoS：普通容器和Init容器，临时容器不参与。 流程如下： 把普通容器、Init容器追加到allContainers中 遍历Pod中所有参与计算的容器，获取requets，通过isS ...

K8s核心资源对象-Pod（资源配额与cgroup） 基于1.25 Pod的资源配额Pod主要通过requetsts和limits设置配额： requests.cpu=250m后，实际上是把cgroup的cpu.shares的值设置了（250/1000）*1024，默认值是1024 limits.cpu=500m，实际上把cgroup的cpu.cfs_quota_us的值设置为（500/1000）*100ms，而cpu.cfs_period_us始终是100ms limits.memory=128Mi,相当于cgroup的memory.limit_in_bytes设置为128 * 1024 * 1024，调度时，只会使用requests.memory=64Mi判断 如果值设置了limits，没指定requests,没有应用准入时机制，requests的值同样会设置limits 生成cgroup资源的流程如下： 初始化Pause容器和其他容器都用调用calculateLinux Resource Func来计算 ...