xuebo1129927648的博客

原理：CoreDNS 通过插件化架构集成 K8s API，实时同步集群资源，提供 Service/Pod 的域名解析，同时转发外部域名查询，配合缓存提升性能。解析过程：Pod 发起查询→CoreDNS 接收→根据域名类型（集群内 / 外）调用对应插件（kubernetesforward）→查询 K8s API 或上游 DNS→返回结果。CoreDNS 是 K8s 网络通信的核心组件，确保了集群内服务发现的可靠性和灵活性。

服务名是 DNS 解析的核心，直接定义在的services字段下，每个键名即为可被解析的服务名。操作步骤进入 Harbor 部署目录（通常包含的目录，如查看中的services部分：bashcat docker-compose.yml | grep -A 1 "services:" # 快速定位服务定义# 或直接查看完整服务列表输出示例（Harbor 核心服务名）：plaintextnginxregistrypostgresqlredisclair。

场景取值要求作用新建集群（首次启动）new必须包含所有初始节点的信息初始化集群，建立成员关系和 leader 选举机制加入现有集群existing只需包含至少一个已存在的集群节点信息新节点通过现有节点同步集群状态并加入错误使用的后果若向现有集群添加节点时误用new，新节点会尝试初始化一个新集群，可能与原有集群冲突，导致脑裂或启动失败。若新建集群时误用existing，节点会因找不到已存在的集群而启动失败（无法发现集群成员）。

这个错误的原因是你在 Kubernetes Deployment 资源中使用了字段，但。是资源的特有字段，用于为有状态应用创建稳定的、按顺序的存储卷声明（PVC）。Deployment 主要用于无状态应用，不具备这个特性，因此会报 "未知字段" 的错误。

Docker 镜像的 “第一层” 通常指最底层的基础，即scratch（空镜像）。所有官方基础镜像（如alpineubuntu）都是在scratch之上添加文件系统和工具形成的。分层结构的优势是共享层、减少存储空间，以及高效的镜像传输。

docker登录Harbor时或者docker push时报：查看docker日志也报同样的错。

对比维度newexisting核心目标创建新集群加入现有集群集群 ID 来源新生成继承现有集群依赖配置完整的初始成员列表至少一个现有成员地址操作顺序首次部署时使用集群创建后扩容时使用错误影响配置不一致导致集群创建失败未预先添加成员或地址错误导致加入失败通过正确设置，可以确保 etcd 集群的初始化和扩容过程安全、有序地进行，避免因配置错误导致的集群故障。

在 Kubernetes 1.28 版本中，默认情况下是不允许拉取 HTTP 协议的镜像的，因为 HTTP 不安全。

CVE-2020-13794CVE-2020-13788CVE-2019-3990CVE-2019-19030CVE-2019-19029：影响 Harbor 1.7.、1.8.、1.9.* 版本，1.8.6 和 1.9.3 版本也受影响。通过用户组进行 SQL 注入，具有项目管理功能的用户可利用此漏洞从底层数据库读取机密信息或进行权限提升。CVE-2019-19026：影响 Harbor 1.7.、1.8.、1.9.* 版本，1.8.6 和 1.9.3 版本也受影响。Harbor API 的 q

以上指标覆盖了 etcd 的集群可用性、存储容量、性能延迟、业务操作、资源使用等维度。其中，标为 “必须告警” 的指标（如、磁盘容量 / 延迟）直接关联集群核心功能，需优先配置告警；调试类指标（含debugging前缀）则用于问题排查，无需日常告警。实际监控中需结合业务场景（如 etcd 在 K8s 中的角色）调整阈值，确保覆盖关键风险点。

虽然不推荐用 Base64 编码密码本身，但 Kubernetes Secret。这样既保证了密码的安全性，又符合 Node Exporter 的认证要求。在 Kubernetes 中配置认证时，

在 Kubernetes（k8s）里，Secret 资源可用于安全存放敏感信息，像密码、令牌、密钥等。

是 Kubernetes 集群搭建的 “起点”，它通过自动化流程简化了控制平面的初始化复杂度。理解初始化流程：环境检查 → 证书 / 配置生成 → 组件启动 → 输出指引。（网络插件兼容）、（高可用必备）、（国内镜像源）。初始化后必做操作：配置kubectl、安装网络插件、记录节点加入命令。掌握的细节，能帮助你更高效地搭建和排查 Kubernetes 集群问题。

通过 Admission Webhook 实现自定义安全策略：yaml。

在 Kubernetes 中，是一种用于存储敏感信息（如密码、API 密钥、证书等）的资源对象，其设计目标是，从而增强集群的安全性。本文将详细解析其核心机制、使用方式及最佳实践。

在 Kubernetes 中，是用于为 Pod 内的进程提供身份标识的机制，是集群安全体系的重要组成部分。本文将详细解析其核心概念、工作原理及最佳实践。

内置插件无法满足复杂需求时，可通过。

定义权限，策略基于用户属性（如用户名、组）和请求属性（如资源名称、标签）。

在 Kubernetes（k8s）中，API Server 是集群的核心入口，所有操作（如创建 Pod、部署服务等）都需通过 API Server 完成。** 认证管理 ** 是 API Server 的第一道安全防线，其核心作用是验证请求者的身份，确保只有 “可信的实体” 能发起请求。

Kubernetes 从 1.16 版本开始试验性支持 IPv4/IPv6 双栈网络，1.23 版本起转为正式 GA 特性。双栈网络允许 Pod 同时分配 IPv4 和 IPv6 地址，实现双协议栈通信。通过合理配置，Kubernetes 双栈网络可无缝支持 IPv4/IPv6 混合环境，为集群迁移提供平滑过渡方案。需使用支持双栈的 Flannel 版本，并添加。

网络策略通过资源对象定义，核心字段包括：yamlmetadata:name: example-policy # 策略名称namespace: default # 策略所属命名空间（影响范围）spec:podSelector: # 选择受策略影响的目标 Pod（标签匹配）role: dbpolicyTypes: # 策略类型：Ingress（入站）、Egress（出站）或两者- Ingress- Egressingress: # 入站规则列表- from: # 允许的源流量。

Flannel 是 Kubernetes 中最基础的网络插件之一，通过 Overlay 网络技术实现跨节点 Pod 通信。其 VXLAN 模式在性能和兼容性上取得了较好的平衡，适合中小型集群和测试环境。若需要更高级的功能（如网络策略），建议与其他插件（如 Calico）组合使用。介绍一下flannel插件的特点在Kubernetes中使用flannel插件需要注意哪些问题？如何在Kubernetes中部署flannel插件？

CNM 作为 Docker 主导的容器网络模型，通过 Sandbox、Endpoint、Network 三大组件的抽象，以及驱动机制的设计，实现了容器网络的标准化和可扩展性。它为单机和跨主机容器通信提供了统一的接口，推动了容器网络生态的发展（如 overlay 网络、网络隔离、第三方插件集成等）。尽管 CNI 在 Kubernetes 生态中更为主流，但 CNM 的设计思想（如网络隔离、端点管理）对理解容器网络的本质仍具有重要参考意义。

同一命名空间内：直接使用 Service 名称（如）即可访问。跨命名空间：必须使用完整域名（如：DNS 查询直接返回 Pod IP，而非虚拟 IP。Endpoint 动态更新：当 Pod 重建时，Endpoint 会自动更新，确保 Service 始终指向正确的 Pod。确认 Pod 状态为Running且 READY=1/1。使用检查 Pod 的事件和 IP 地址。验证 Service 的标签选择器是否正确匹配 Pod 的标签。使用检查 Endpoint 是否包含正确的 Pod IP。

CNI 插件：实现 Pod 的网络配置和跨节点通信；Service 与 kube-proxy：提供稳定访问点和负载均衡；Ingress：管理外部 HTTP/HTTPS 流量的路由；：控制 Pod 间的流量隔离；CoreDNS：提供域名解析服务。不同组件协同工作，最终实现了 “Pod 间直接通信、服务稳定访问、外部灵活接入” 的网络能力场景通信方式核心依赖特点同一 Pod 内的容器localhost+ 端口 / 共享 Volume共享网络命名空间 / 共享存储性能高，无网络开销。

Helm是 Kubernetes 的官方包管理器，用于简化 Kubernetes 应用的部署、管理和升级。它通过Chart（应用描述文件）定义、安装和更新复杂的 Kubernetes 应用，解决了手动部署时配置繁琐、版本管理困难、依赖处理复杂等问题。核心价值应用封装：将复杂的 Kubernetes 资源（Deployment、Service、ConfigMap 等）打包为可复用的 Chart版本管理：支持应用的版本控制和回滚，确保部署的可追溯性环境配置。

Docker Swarm 是 Docker 原生的集群管理和编排工具，它可以将多台 Docker 主机组合成一个单一的虚拟主机，便于管理和部署容器化应用。通过 Swarm，用户能够轻松实现容器服务的规模化、高可用性以及负载均衡，是 Docker 生态中进行容器编排的重要组件。Docker Swarm 提供了轻量级的容器集群解决方案，无需额外学习复杂框架即可实现服务编排、负载均衡和高可用性。

Docker 原生网络在简单场景下表现良好，但在大规模集群、跨主机通信、高性能需求或复杂网络策略场景中存在明显局限性。企业级应用通常需要结合编排工具和第三方网络方案，以弥补这些不足并满足生产环境的需求。查看Docker启动后的CPU和内存使用情况如何查看Docker容器的日志信息？如何监控Docker容器的网络流量？如何查看容器内部的网络配置信息？怎样查看Docker容器的IP地址？有没有其他工具可以查看Docker容器的网络配置？

创建自定义 Bridge 网络bash# 创建名为my-network的bridge网络# 启动容器并加入网络网络隔离与互联不同网络的容器默认无法通信可通过动态连接容器到多个网络网络驱动插件bridge：默认桥接模式host：主机网络模式overlay：跨主机网络（需 Docker Swarm）macvlan：虚拟 MAC 地址模式第三方插件：Calico、Weave、Flannel命名空间（Namespaces）

一、故障分类与排查优先级1. 网络问题的常见分类故障类型表现现象可能原因Pod 网络不通Pod 间无法 ping 通或服务无法访问CNI 插件异常、IP 地址冲突、网络策略限制、节点路由问题Service 不可用通过 Service IP / 域名无法访问服务kube-proxy 异常、Endpoint 未生成、Service 配置错误DNS 解析失败Pod 内无法解析域名（如失败）CoreDNS 故障、DNS 配置错误、节点 DNS 设置冲突跨节点通信问题。

在 Kubernetes 中，用于管理有状态应用（如数据库、分布式存储），其核心特性是为每个 Pod 提供。是 StatefulSet 特有的字段，用于为每个 Pod 实例，确保每个 Pod 拥有专属的持久化存储，且存储随 Pod 生命周期保持绑定关系。

CSI（Container Storage Interface）是 Kubernetes 引入的标准接口，用于将任意存储系统暴露给容器化应用。它解决了早期存储插件需要修改 Kubernetes 核心代码的问题，使存储供应商能够在不依赖 Kubernetes 代码库的情况下开发存储插件。CSI 是 Kubernetes 存储生态系统的重要演进，它提供了标准化的存储接口，使存储供应商能够更轻松地集成到 Kubernetes 环境中。

PersistentVolume（PV）是 Kubernetes 中对底层存储的抽象，它将存储资源与 Pod 解耦，使应用无需关心底层存储的具体实现。

Kubernetes 的 Volume 机制通过抽象存储资源，屏蔽了底层存储实现的复杂性，使应用能够以统一方式使用不同类型的存储。从本地临时存储到分布式共享存储，再到云厂商专属存储，Volume 类型的多样性满足了容器化应用在数据持久化、配置管理、跨节点共享等场景下的需求，是 Kubernetes 构建有状态应用的核心基础。Kubernetes（K8s）的存储机制是其核心功能之一，用于管理容器化应用的数据持久化。一、核心概念：PV 与 PVC 的逻辑抽象。

kube-proxy 是 Kubernetes 集群中负责服务发现与网络流量转发的核心组件，运行在每个节点上。其核心功能是将集群内部服务的虚拟 IP（Cluster IP）映射到具体 Pod 的 IP 地址，实现服务的负载均衡和网络连通性。kube-proxy 作为 Kubernetes 网络模型的关键组件，通过不同模式实现了服务到 Pod 的高效转发。从早期的 userspace 到主流的 iptables/ipvs，再到实验性的 kernelspace 模式，其演进始终围绕性能优化和稳定性提升。

kubelet 是运行在 Kubernetes 集群每个工作节点（Worker Node）上的核心组件，承担着节点与集群控制平面的交互任务，是 Pod 生命周期管理的直接执行者。

通过修改参数指定自定义策略文件。使用 Scheduler Framework 开发插件，实现更灵活的调度逻辑（如基于业务优先级的调度）。K8s Scheduler 通过预选 - 优选的两阶段模型，结合灵活的策略配置和扩展框架，实现了高效的 Pod 调度。理解其原理有助于优化集群资源分配、自定义调度逻辑，并解决调度相关的问题（如 Pod 长时间处于 Pending 状态）。在实际应用中，可通过监控调度延迟、节点资源利用率等指标，持续优化调度策略。

Kubernetes Controller Manager 体现了声明式系统与控制理论声明式 API 优先：用户只需定义目标状态，无需关心具体实现过程最终一致性：通过持续调和确保状态收敛，而非强一致性实时更新插件化架构：支持灵活扩展，适配不同场景需求故障容错设计：通过 Leader Election、重试机制等保证系统可用性理解 Controller Manager 的工作原理，是深入掌握 Kubernetes 自动化运维能力的关键，也是开发自定义控制器、优化集群性能的基础。

唯一支持的 Deployment API 版本是apps/v1所有旧的 API 版本 () 都已被移除任何使用旧 API 版本的 Helm Chart 或 YAML 文件都需要更新才能在该版本上工作。

Ingress 是 Kubernetes 中的一种资源类型，用于定义如何将外部 HTTP (S) 请求路由到集群内的服务。Ingress 是 Kubernetes 中管理外部访问的核心组件，通过集中化的路由规则简化了服务暴露。合理配置 Ingress 控制器和规则，可以实现高性能、安全的应用访问网关。Kubernetes Ingress 是一种 API 对象，用于管理集群外部对集群内部服务的 HTTP 和 HTTPS 访问。如何为Kubernetes Ingress配置TLS以实现安全的HTTPS流量？