通过 kubeadm 安装的 etcd 单节点环境，和 kubernetes 二进制文件部署的多 etcd节点环境，分别进行 etcd 的备份与还原操作。快照备份后，恢复到/var/lib/etcd--restore 目录里，不将默认的/var/lib/etcd 的目录进行覆盖。以下展示操作过程：

概述 通过 CA 双向认证方式因为需要基于根 CA 证书、根 CA 私钥进行证书签发，一般需要在集群的 master 节点上进行配置，用户不一定有权限进入到 master 节点中。但是一般情况都能拿到对应的一个 kubeconfig 文件用来访问 kubernetes集群，基于 kubeconfig

HTTPS双向认证流程 Kubernetes集群的访问权限控制由 API Server 负责，除了 Token 认证外，还支持 CA 证书 Kubernetes CA 认证也叫HTTPS证书认证，执行 ApiServer CA 认证过滤器链逻辑的前提是客户端和服务端完成 HTTPS 双向认证，下面着

什么是服务账号？ 服务账号是在 Kubernetes 中一种用于非人类用户的账号，在 Kubernetes 集群中提供不同的身份标识。 应用 Pod、系统组件以及集群内外的实体可以使用特定 ServiceAccount 的凭据来将自己标识为该 ServiceAccount。 这种身份可用于许多场景，

KubePi 支持 Bearer Token、证书、kubeconfig 文件方式进行登录。以 Bearer Token 方式介绍如何登录。 前提条件 kube-apiserver 需要设置--enable-bootstrap-token-auth=true启动 Bootstrap Token 身份

以 nginx 为例，找到待抓包的 pod 及分布在哪个节点上： # kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE

在 pod 运行的时候，除了可以通过kubectl describe pod查看 pod 的事件信息，或者通过kubectl exec外，还可以通过临时容器来进行调试。 使用临时容器来调试 可以使用 kubectl debug 命令来给正在运行中的 Pod 增加一个临时容器。 首先，像示例一样创建一

ingress-nginx 部署 defaultbackend 介绍 defaultBackend 是一种默认后端服务，用于处理 ingress-nginx 控制器无法理解的所有 URL 路径和主机（即所有未映射 Ingress 的请求）。 部署 部署 defaultbackend 有几种方法。如果

配置 containerd 编辑 /etc/containerd/config.toml 文件： [plugins."io.containerd.grpc.v1.cri".registry.configs] # 内部私有仓库认证信息 [plugins.

Service 和 Headless Servic 的区别 普通的 Service，只能通过解析 service 的 DNS 返回 service 的 Cluster IP。 headless service作为service的一种类型，顾名思义无头服务，无头 Service 不会获得集群 IP，k