K8s工作负载-DaemonSet
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/ku...
K8s工作负载-StatefulSet
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
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 1234567891011121314151617181920212223242526272829// 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 o...
K8s工作负载-Deployment
K8s工作负载-Deployment 基于1.25 什么是DeploymentDeployment 最常见就是部署无状服务，缩写Deploy Deployment实现声明的方法控制Pod和ReplicaSet 支持滚定升级和回滚应用 支持扩容和缩容 暂停和继续Deployment DeploymentSpec Ref：https://github.com/kubernetes/api/blob/271c79cac830e76e5e563330b3ec60d46948464e/apps/v1/types.go#L377 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455// DeploymentSpec is the specification of the desired behavior of the Deployment.type DeploymentSpec struct { // Number of de...
K8s核心资源对象-Pod（状态以及原地升级）
K8s核心资源对象-Pod（状态以及原地升级） 基于1.25 Pod的PodStatus Ref：https://github.com/kubernetes/kubernetes/blob/88e994f6bf8fc88114c5b733e09afea339bea66d/pkg/apis/core/types.go#L3365 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061// 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 Pod...
K8s核心资源对象-Pod（健康检查）
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 Sto...
K8s核心资源对象-Pod（静态Pod）
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/88e994f6bf8fc88114c5b733e09afea339b...
K8s核心资源对象-Pod（QoS与驱逐顺序）
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，通过...
K8s核心资源对象-Pod（资源配额与cgroup）
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...
Alertmanger-深入理解告警原理
Alertmanger-深入理解告警原理AlertManager架构图 Alert Provider：API收到来自Prometheus的告警，存储到Alert Provider 原理是内置了Map Dispatcher组件: 这是一个单独的goroutine，不断地通过订阅的方式从Alert Provider获取新的告警，并且根据YAML配置的Routing Tree将告警通过Label路由到不同的分组中，以实现告警信息的分组处理 Notification Pipeline组件:顾名思义，这是一个责任链模式的组件，它通过一系列逻辑(如抑制、静默、去重等)来优化告警质量。 在源码中，它是通过一个个实现Stage接口的具有不同功能的实例串联 起来得到的 Silence Provider组件:API层将来自Prometheus服务端的告警信息 存储到Silence Provider上，然后由这个组件实现去重逻辑处理。静默规 则用来关闭部分告警的通知 Notify Provider组件:它是Silence Provider组件的下游，会在本地记录日志，Peers的方式将日...