概述重点（分几个部分学习k8s的笔记）
第一部分（主要重点）
理解k8s是什么，有什么作用？（理解）
容器运行时（理解）
安装k8s方式（练习）
k8s的架构和组件（重要）
k8s的命令 （练习）
笔记结构
一.k8s是什么？它到底能“干嘛”Docker 和 K8s 的区别？
1，k8s是什么 ？
总结：K8s 本质上是一个 容器编排系统（平台）。注意：他是相当于管理容器的，
K8s（Kubernetes）是用来自动管理容器应用的一套系统，让你不再手动部署、扩容、重启服务，省心省力，自动高可用。
2，它到底能“干嘛”？
总结：他的作用：
1，自动部署（我们只需要编辑服务所需的yaml文件，再用apply生成运行 这点-----对应----docker-compose 文件 ）
2，自动伸缩：服务忙了自动加容器，闲了自动缩（就是根据业务对系统资源弹性的扩缩容）这个是有HPA（Horizontal Pod Autoscaler ）实现的
3，服务发现 & 负载均衡：自动给容器分配 IP 和 DNS（是由 server 和 kubeproxy 实现的负载均衡 ，coreDNS 实现的服务发现）这点---对应---我们的 nginx配置的反向代理
4，自愈能力：（是由deployment 的控制器实现的 ）
5，滚动更新 / 回滚：（是由deployment 实现的） --- 对应这--- CICD 流程的 滚动更新版本切换
6，统一资源调度：（是由kube-scheduler实现的）
想象你公司开发了 20 个微服务，每个都打成 Docker 容器，要部署上云：
如果你不用 K8s，那你可能要：
- 用脚本
docker run一堆命令启动容器； - 手动配置 Nginx 负载均衡；
- 某个服务挂了要远程登录重启；
- 想加机器？自己搞配置、分发代码、环境...
🙁 这就像一个人用手管理 100 个机器人，随时掉链子。
✅ 有了 K8s，你就可以：
能力 |
举例 |
自动部署 |
写个 Yaml 文件一发，服务就部署好了 |
自动伸缩 |
服务忙了自动加容器，闲了自动缩 |
服务发现 & 负载均衡 |
自动给容器分配 IP 和 DNS |
自愈能力 |
某个容器挂了自动重启 |
滚动更新 / 回滚 |
发布新版本不影响在线用户，出问题自动回滚 |
统一资源调度 |
不管几台服务器，K8s 都能帮你智能安排运行 |
3. Docker 和 K8s 的区别？
项目 |
Docker |
K8s |
是什么 |
容器运行工具 |
容器管理平台 |
作用 |
构建和运行容器 |
管理、调度大量容器 |
管理能力 |
单机 |
集群（多台机器） |
自动化程度 |
手动操作为主 |
自动化运维能力强 |
👉一句话：Docker 负责“造容器”，K8s 负责“管容器”。
二，k8s的容器运行时是什么意思用的那些容器运行时
CRI 接口是 k8s 提供的， 可以 使k8s 的kubelet 连接 容器运行时对容器进行管理的接口
总结：（通俗来讲Docker 是造容器的，Kubernetes（K8s）是管理容器的，造容器只是他的一小部分功能）
Docker是一个容器化平台，而Kubernetes是一个容器编排系统
其实，K8s 一开始就是“基于 Docker”来跑容器的，它通过调用 Docker API 启动 Pod 里的容器。
✅ 所以是 并不是选谁的问题，而是：K8s 是管理 Docker 容器的一种方式。
不过现在（K8s v1.20+）K8s 已经不用默认的 Docker 运行时了，而是用 containerd（Docker 的核心组件）或 CRI-O，Docker 被“拆分”了。
🧠 但这不影响你的理解，你只要记住一句话：
Docker 是容器运行环境，K8s 是容器的集群管理系统，它可以用 Docker 或 containerd 运行容器。
1，有哪些容器运行时
Kubernetes 的容器运行时接口（Container Runtime Interface，CRI）使得 kubelet 能够与多种容器运行时进行交互。以下是一些常见的支持 CRI 的容器运行时：
- containerd：一个高性能的容器运行时，最初由 Docker 开发，后捐赠给 CNCF。它直接实现了 CRI，无需额外的插件，专注于提供简单、健壮的容器生命周期管理。
- CRI-O：专为 Kubernetes 设计的轻量级容器运行时，直接实现了 CRI，旨在运行符合 Open Container Initiative（OCI）标准的容器。
- Docker Engine（通过 cri-dockerd）：虽然 Kubernetes 在 v1.24 版本中移除了对 Dockershim 的支持，但可以使用 Mirantis 提供的
cri-dockerd来继续通过 CRI 与 Docker Engine 集成。
三种 容器运行时的路径
2，什么是 CRI接口
总结：CRI 接口是 k8s 提供的， 可以 使k8s 的kubelet 连接 容器运行时对容器进行管理的接口
CRI（容器运行时接口，Container Runtime Interface）是 Kubernetes 提供的一个接口规范，它允许 Kubernetes 与不同的容器运行时进行交互。CRI 的主要目的是为 Kubernetes 提供一个标准化的接口，以便支持多种容器运行时，而不需要依赖特定的实现，比如 Docker。
CRI 接口的作用
1. 容器生命周期管理：CRI 负责容器的创建、启动、停止、删除等基本操作。
2. 镜像管理：CRI 允许 Kubernetes 通过接口管理容器镜像的拉取和存储。
3. 容器监控：CRI 提供容器的健康检查和日志访问功能。
4. 资源管理：CRI 可以与 Kubernetes 调度器协作，以便合理分配资源，进行资源限制等操作。
4，kubelet 是怎么 控制 pod 的 ，怎么用看的是什么容器运行时
3，kubelet 是怎么 控制 pod 的 ，怎么用看的是什么容器运行时
先了解一下：kubelet 是怎么控制 Pod 的？🔧 kubelet 是什么？
kubelet 是运行在每台 Kubernetes 节点上的 核心代理组件，它的作用是：
监听并执行 Kubernetes 下发的 Pod 管理指令，然后调用底层容器运行时创建/删除容器，让 Pod 真正“跑”起来。
🔄 kubelet 控制 Pod 的流程：
- APIServer 下发 Pod 信息
-
- 控制面（如 scheduler）调度出某个 Pod 要跑在某台节点上
- kubelet 会通过 API Server watch 到这个 Pod 的定义
- kubelet 收到 Pod 定义后开始“执行”
-
- 检查本地有没有这个 Pod 的容器镜像
- 没有就通过镜像仓库拉取
- kubelet 调用 容器运行时（container runtime）接口创建容器
-
- 这一步就是通过 CRI（容器运行时接口）
- kubelet 不直接调用 Docker、containerd，而是调用标准的 CRI gRPC 接口
- 容器运行时启动容器（一个 Pod 至少有一个容器）
-
- 比如调用 containerd → 再由它调用 runC → 创建命名空间、挂载文件系统、执行 init → 启动进程
- 一个 Pod 里所有容器会跑在同一个网络和 IPC namespace 里
- kubelet 定期检查容器状态
-
- 会调用 runtime 接口获取容器运行状态、健康状况，做自愈、日志采集、重启策略等管理
❓kubelet 是怎么看自己用的是什么容器运行时的？
它是通过你启动 kubelet 时传入的参数来决定的：
--container-runtime=remote
--container-runtime-endpoint=unix:///run/containerd/containerd.sock--container-runtime通常设置为remote，代表使用 CRI 协议--container-runtime-endpoint指定容器运行时的 gRPC Socket 路径
-
- 如果是 containerd：就是
/run/containerd/containerd.sock - 如果是 CRI-O：就是
/var/run/crio/crio.sock - 早期如果用 Docker，则是
/var/run/dockershim.sock（现在已弃用）
- 如果是 containerd：就是
方式一：查看 kubelet 进程参数（最通用）
ps aux | grep kubelet你会看到类似这样的输出：
root 1001 0.3 1.2 123456 65432 ? Ssl 09:01 0:01 /usr/bin/kubelet \
--container-runtime=remote \
--container-runtime-endpoint=unix:///run/containerd/containerd.sock \
--kubeconfig=/etc/kubernetes/kubelet.conf ...🧠 简单类比
角色 |
类比对象 |
kubelet |
管理员/调度员 |
Pod 定义 |
工作任务说明书 |
容器运行时 |
实际干活的工人 |
CRI |
管理员与工人交流的电话 |
runC |
造容器的工具机器 |
三，什么方式安装k8s
1. kubeadm(contained或docker)（官方推荐，适合练手和生产小集群）
✅ 优点：
- 官方工具，文档多
- 灵活，便于学习 K8s 组件结构
- 可用于生产环境部署（需要搭配系统工具运维）
🚀 安装步骤（简化版）：
- 环境准备
-
- 至少 2 台 Linux 服务器（建议使用 CentOS 7+ 或 Ubuntu 20.04）
- 禁用 swap、设置主机名、时间同步等基础环境配置
- 总结有：1，主机名 2，时间同步 3，防火墙 4，禁用swap 设备 5，内核参数 6，docker 仓库 和 keepalive 高可用和 haproxy 的反向代理 7. k8s-1.24以后 CRI - dockerd的安装 8，所有节点的kubeadm的安装包和辅助命令 9，kubeadm init 的安装集群（这个很重要 注意标准输出的join 信息） 8，网络插件
9，将master主机加集群 将worker主机加集群
- 安装依赖组件
-
- Docker（或 containerd）
- kubeadm、kubelet、kubectl
- 初始化主节点
kubeadm init --pod-network-cidr=10.244.0.0/16- 配置 kubectl 权限
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config- 安装网络插件（例如 flannel 或 calico）
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml- 加入 worker 节点
kubeadm join <MasterIP>:6443 --token <TOKEN> --discovery-token-ca-cert-hash sha256:xxxx案例了解：基于docker安装 k8s
ubuntu 系统 安装
基础环境
hostnamectl set-hostname “其他节点名”
*********主机名并实现主机名解析********
所有主机都配置
cat >> /etc/hosts <<EOF
10.0.0.100 kubeapi.wang.org #####客户端要访问的域名
10.0.0.101 master1 master1.wang.org
10.0.0.102 master2 master2.wang.org
10.0.0.103 master3 master3.wang.org
10.0.0.104 node1 node1.wang.org
10.0.0.105 node2 node2.wang.org
10.0.0.106 node3 node3.wang.org
10.0.0.107 ha1 ha1.wang.org
10.0.0.108 ha2 ha2.wang.org
10.0.0.109 harbor harbor.wang.org
EOF
*********主机时间同步*********
所有主机都配置
[root@master1 ~]#timedatectl set-timezone Asia/Shanghai
******关闭防火墙*****
所有主机都配置
#如果安装ufw
~# ufw disable
#确认关闭
~# ufw status
#如果安装firewalld
~# systemctl disable --now firewalld
********* 禁用 Swap 设备*******
所有主机都配置
~# systemctl disable --now swap.img.swap
~# systemctl mask swap.img.swap 或者 systemctl mask swap.target
~# reboot
#确认是否禁用swap
~# systemctl -t swap
~# swapon -s
*******内核优化*******
所有主机都配置
根据硬件和业务需求,对内核参数做相应的优化
注意:安装docker时会自动修改内核参数
*********部署 harbor 仓库和高可用反向代理 ( 可选)*********
公司里会有的 先不做
*******实现高可用的反向代理******
ha1 和 ha2 keepalive 高可用 和 haproxy
[root@ubuntu2204 ~]#apt update && apt -y install keepalived
[root@ha1 ~]#cp /usr/share/doc/keepalived/samples/keepalived.conf.vrrp /etc/keepalived/keepalived.conf
master 的ha1安装 注意脚本测试haproxy 最后在测试
[root@ubuntu2204 ~]#cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id ha1.wang.org
}
vrrp_script check_haproxy {
script "/etc/keepalived/check_haproxy.sh"
interval 1
weight -30
fall 3
rise 2
timeout 2
}
vrrp_instance VI_1 {
state MASTER
interface eth0
garp_master_delay 10
smtp_alert
virtual_router_id 66
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
10.0.0.100/24 dev eth0 label eth0:1
}
track_script {
check_haproxy
}
}
****************脚本*****************
[root@ubuntu2204 ~]#cat /etc/keepalived/check_haproxy.sh
/usr/bin/killall -0 haproxy || systemctl restart haproxy
[root@ha1 ~]#chmod +x /etc/keepalived/check_haproxy.sh
******* ha2 的配置*********
[root@ubuntu2204 ~]#cat /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
router_id ha2.wang.org
}
vrrp_instance VI_1 {
state BACKUP
interface eth0
garp_master_delay 10
smtp_alert
virtual_router_id 66
priority 80
advert_int 1
authentication {
auth_type PASS
auth_pass 123456
}
virtual_ipaddress {
10.0.0.100/24 dev eth0 label eth0:1
}
}
haproxy的配置两台主机上
[root@ha1 ~]#cat /etc/haproxy/haproxy.cfg
.............最底下添加...........
listen stats
mode http
bind 0.0.0.0:8888
stats enable
log global
stats uri /status
stats auth admin:123456
listen kubernetes-api-6443
bind 10.0.0.100:6443
mode tcp
server master1 10.0.0.101:6443 check inter 3s fall 3 rise 3
server master2 10.0.0.102:6443 check inter 3s fall 3 rise 3
server master3 10.0.0.103:6443 check inter 3s fall 3 rise 3
********安装 docker******* （基于docker安装采用）
不要求版本 用apt安装即可
******* 修改Cgroup Driver为systemd(新版无需执行)******
新版本可以跳过
[root@master3 ~]#docker info
Client:
Version: 24.0.5
Context: default
Debug Mode: false
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 24.0.5
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd **************已经是systemd了**************
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
**********所有主机配置 cri-dockerd(v1.24以后版本)*********** （在1.24之前 docker是主导地位 不用cri ）
https://github.com/Mirantis/cri-dockerd/
所有主机都配置
[root@ubuntu2204 ~]#wget https://mirror.ghproxy.com/https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.13/cri-dockerd_0.3.13.3-0.ubuntu-jammy_amd64.deb
[root@ubuntu2204 ~]#apt install ./cri-dockerd_0.3.13.3-0.ubuntu-jammy_amd64.deb
[root@ubuntu2204 ~]#vim /lib/systemd/system/cri-docker.service
添加———— --pod-infra-container-image registry.aliyuncs.com/google_containers/pause:3.9
ExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd:// --pod-infra-container-image registry.aliyuncs.com/google_containers/pause:3.9
[root@ubuntu2204 ~]#systemctl daemon-reload
[root@ubuntu2204 ~]#systemctl restart cri-docker.service
*******所有 master 和 node 节点安装kubeadm等相关包*******
所有主机都配置
[root@master1 ~]#apt-get update && apt-get install -y apt-transport-https
[root@ubuntu2204 ~]#curl -fsSL https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.30/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.30/deb/ /" | tee /etc/apt/sources.list.d/kubernetes.list
[root@ubuntu2204 ~]#apt-get update
[root@ubuntu2204 ~]#apt-get install -y kubelet kubeadm kubectl （这个kubeadm 只是master 节点需要安装）
******** 在第一个 master 节点准备安装 kubernetes 所需的相关镜像 (可选)*******
安装辅助命令
[root@ubuntu2204 ~]#kubeadm completion bash > /etc/profile.d/kubeadm_completion.sh
[root@ubuntu2204 ~]#source /etc/profile.d/kubeadm_completion.sh
错误：
******** 在第一个 master 节点准备安装 kubernetes 所需的相关镜像 (可选)*******
重点单独写
kubeadm init 安装集群
重点 在第一个 master 节点运行 kubeadm init 初始化命令 （最重要 这步不成功没必要在做） 重点
在第一台 master 初始化集群
在第一个单独做配置
注意：这步是创建
--control-plane-endpoint 后面是创建 高可用的基础 --kubernetes-version= 指定版本
大部分的网络默认是pod，service （ip 够大 ） --image-repository 镜像地址不用去外网
--token 设置过期时间（工作用短时间安全） --upload-certs 证书
--cri-socket=unix:///run/cri-dockerd.sock #注意：v1.24版本需要添加此项才能支持docker
[root@ubuntu2204 ~]#kubeadm init --control-plane-endpoint kubeapi.wang.org --kubernetes-version=v1.30.0 --pod-network-cidr 10.244.0.0/16 --service-cidr 10.96.0.0/12 --image-repository registry.aliyuncs.com/google_containers --token-ttl=0 --upload-certs --cri-socket=unix:///run/cri-dockerd.sock
......................安装后................................
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
export KUBECONFIG=/etc/kubernetes/admin.conf
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of the control-plane node running the following command on each as root:
kubeadm join kubeapi.wang.org:6443 --token vkfke8.zm2vtnftdhtqg89v \
--discovery-token-ca-cert-hash sha256:b1ec79486726199f497fb76d0fc2bedb26ee6e6d9f4ad12e8b2f1a72db1f1e14 \
--control-plane --certificate-key 623c4212d1cba88592410f1bd46d3a1f82b505a54d4943adf82c589d0437f201
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join kubeapi.wang.org:6443 --token vkfke8.zm2vtnftdhtqg89v \
--discovery-token-ca-cert-hash sha256:b1ec79486726199f497fb76d0fc2bedb26ee6e6d9f4ad12e8b2f1a72db1f1e14
生成 kubectl命令的 kube-config 授权文件 （这是前面初始化 生成的）
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
生成好了用 kubectl 工具查看 集群情况
[root@master1 ~]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
master1 NotReady control-plane 26m v1.30.0
没起来status是pending的状态 装网络插件（用flannel ）
另一种查看
[root@master1 ~]#kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-7b5944fdcf-cbrnc 0/1 Pending 0 28m
kube-system coredns-7b5944fdcf-nw4sp 0/1 Pending 0 28m
kube-system etcd-master1 1/1 Running 0 28m
kube-system kube-apiserver-master1 1/1 Running 0 28m
kube-system kube-controller-manager-master1 1/1 Running 0 28m
kube-system kube-proxy-gzpd2 1/1 Running 0 28m
kube-system kube-scheduler-master1 1/1 Running 0 28m
安装装网络插件（用flannel ）********************************
用flannel 下面是官网地址
https://github.com/flannel-io/flannel#deploying-flannel-manually
[root@master1 ~]#wget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
...............................................................................
kube-flannel.yml 100%[===============================================================================================
2024-04-25 21:56:19 (1.84 KB/s) - 已保存 ‘kube-flannel.yml’ [4468/4468])
[root@master1 ~]#kubectl apply -f kube-flannel.yml
namespace/kube-flannel created
serviceaccount/flannel created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
*******查看已经添加了 kube-flannel 网络组件******* 等待它加载完成 状态变runing
[root@master1 ~]#kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-lqzxb 0/1 PodInitializing 0 38s
kube-system coredns-7b5944fdcf-cbrnc 0/1 Pending 0 42m
kube-system coredns-7b5944fdcf-nw4sp 0/1 Pending 0 42m
kube-system etcd-master1 1/1 Running 0 42m
kube-system kube-apiserver-master1 1/1 Running 0 42m
kube-system kube-controller-manager-master1 1/1 Running 0 42m
kube-system kube-proxy-gzpd2 1/1 Running 0 42m
kube-system kube-scheduler-master1 1/1 Running 0 42m
发现 status 从 not Ready 变成 Ready 就证明网路通了
（添加别的 master主机 和 worker 主机 就都能通讯了）
[root@master1 ~]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
master1 Ready control-plane 51m v1.30.0
添加其它的master 节点到集群(可选)
将master主机加集群 将worker主机加集群
用安装好的初始环境 加主机命令
这是加master主机的 注意：因为是基于daoker安装的所以要加 --cri-socket=unix:///run/cri-dockerd.sock
kubeadm join kubeapi.wang.org:6443 --token vkfke8.zm2vtnftdhtqg89v \
--discovery-token-ca-cert-hash sha256:b1ec79486726199f497fb76d0fc2bedb26ee6e6d9f4ad12e8b2f1a72db1f1e14 \
--control-plane --certificate-key 623c4212d1cba88592410f1bd46d3a1f82b505a54d4943adf82c589d0437f201 --cri-socket=unix:///run/cri-dockerd.sock
这是加worker主机的命令
kubeadm join kubeapi.wang.org:6443 --token vkfke8.zm2vtnftdhtqg89v \
--discovery-token-ca-cert-hash sha256:b1ec79486726199f497fb76d0fc2bedb26ee6e6d9f4ad12e8b2f1a72db1f1e14 --cri-socket=unix:///run/cri-dockerd.sock
检查
已经加载完成
[root@master1 ~]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
master1 Ready control-plane 3h45m v1.30.0
master2 Ready control-plane 174m v1.30.0
master3 Ready control-plane 173m v1.30.0
node1 Ready <none> 172m v1.30.0
node2 Ready <none> 171m v1.30.0
node3 Ready <none> 171m v1.30.0
[root@master1 ~]#kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-flannel kube-flannel-ds-8x9pp 1/1 Running 0 171m
kube-flannel kube-flannel-ds-9ph7t 1/1 Running 0 172m
kube-flannel kube-flannel-ds-b2xj9 1/1 Running 0 174m
kube-flannel kube-flannel-ds-gtvgx 1/1 Running 0 173m
kube-flannel kube-flannel-ds-lqzxb 1/1 Running 0 3h3m
kube-flannel kube-flannel-ds-rl22v 1/1 Running 0 171m
kube-system coredns-7b5944fdcf-cbrnc 1/1 Running 0 3h45m
kube-system coredns-7b5944fdcf-nw4sp 1/1 Running 0 3h45m
kube-system etcd-master1 1/1 Running 0 3h45m
kube-system etcd-master2 1/1 Running 0 174m
kube-system etcd-master3 1/1 Running 0 173m
kube-system kube-apiserver-master1 1/1 Running 0 3h45m
kube-system kube-apiserver-master2 1/1 Running 0 174m
kube-system kube-apiserver-master3 1/1 Running 0 173m
kube-system kube-controller-manager-master1 1/1 Running 0 3h45m
kube-system kube-controller-manager-master2 1/1 Running 0 174m
kube-system kube-controller-manager-master3 1/1 Running 0 173m
kube-system kube-proxy-7d59h 1/1 Running 0 174m
kube-system kube-proxy-g2qrd 1/1 Running 0 171m
kube-system kube-proxy-gzpd2 1/1 Running 0 3h45m
kube-system kube-proxy-hj8f9 1/1 Running 0 172m
kube-system kube-proxy-qhnqm 1/1 Running 0 173m
kube-system kube-proxy-vqhx8 1/1 Running 0 171m
kube-system kube-scheduler-master1 1/1 Running 0 3h45m
kube-system kube-scheduler-master2 1/1 Running 0 174m
kube-system kube-scheduler-master3 1/1 Running 0 173m
安装成功的截图：在第一台 master 初始化集群
安装方法二 基于containd 的方式 安装
和上面基本一致 了解 有这种方法即可
2.安装方法2:Kubeasz 利用 Ansible 部署 Kubernetes（二进制）
了解 有这种方法即可
四，k8s的架构以及每个组件的作用
1， 公司k8s的架构是什么
可以是 三个master 和 多个 node 。 去查一下，了解一下。
2，k8s有什么组件，组件的作用
Kubernetes 架构通过 contorl控制平面 和 工作节点 的协作实现容器编排：
master （控制平面）
控制整个集群的决策、调度、状态管理等。
总结：kube-apiserver （对外暴露的api，负责处理的API 的请求和调用，以及协调其他组件工作）
etcd（保存集群的所有配置信息、状态数据）
scheduler （监听apiserver的信息,负责把未调度的 Pod 分配给合适的 Node）
controller-manager （控制器管理器，每个资源都有自己的控制器，例如：Node Controller：处理节点的状态变化，等不同控制器的功能）
1. kube-apiserver（API 服务器）
- 核心组件，所有操作的唯一入口。
- 提供 REST API 接口，供用户、命令行（kubectl）、控制器等交互。
- 是集群安全控制和认证的门槛。
2. etcd（分布式键值数据库）
- 保存集群的所有配置信息、状态数据。
- 是 Kubernetes 的“脑子”，数据一旦丢失，集群状态将丢失。
- 支持高可用部署（集群模式）。
3. kube-scheduler（调度器）
- 负责把未调度的 Pod 分配给合适的 Node。
- 调度依据资源使用率、亲和性、污点与容忍等策略。
4. kube-controller-manager（控制器管理器）
- 运行各种控制器逻辑，如：
-
- Node Controller：处理节点状态变化；
- Replication Controller：维持 Pod 副本数量；
- Endpoints Controller：更新 Service 与 Pod 的对应关系；
- Job Controller、DaemonSet Controller、Deployment Controller 等。
- 本质上是多个控制器的集合体。
node （工作节点）
实际运行容器应用的地方。
kubelet ：（接收API server 分配的 Pod的信息，通过容器运行时进行对容器创建删除等操作。监控 Pod运行与状态上报）
kube-proxy （管理 Node 上的网络规则，实现服务发现和负载均衡）
container runtime （负责具体容器的运行）
1. kubelet
- 每个 Node 上的主守护进程。
- 负责接收 API Server 分配的 Pod，保证容器运行与状态上报。
- 通过 Container Runtime 启动容器。
2. kube-proxy
- 实现服务发现和负载均衡。
- 管理 Node 上的网络规则，转发 Service 请求至正确的 Pod。
3. Container Runtime（容器运行时）
- 负责具体容器的运行。
- 例如 Docker、containerd、CRI-O 等。
附加组件（Addons）
虽然不是核心架构，但为集群提供增强功能：
- CoreDNS：集群内服务发现与 DNS 解析。
- Ingress Controller：管理外部访问（如 Nginx、Traefik）。
- Metrics Server：收集资源监控数据。
- Dashboard：提供 Web 管理界面。
总结一句话记忆：
控制平面4大核心：API（门面）、etcd（大脑）、scheduler（调度）、controller（控制器）
工作节点3个重点：kubelet（管理Pod）、kube-proxy（网络转发）、Container Runtime（运行容器）。了解：
组件 |
作用 |
|
最小部署单元，包着容器 |
|
管理一组 Pod 的副本数、更新策略等 |
|
暴露 Pod 的统一访问入口 |
|
集群中实际运行容器的服务器 |
|
在每台 Node 上运行，负责启动/监控 Pod |
|
资源调度器，决定 Pod 放哪台机器上 |
|
自动控制器，比如发现挂了就补 |
3，k8sYAML 清单 的内容
总结： 围绕着四个字段
主要内容有：1，apiversion 填好填正确 kubernetes API （服务接口）的版本 ，后面处理全靠API 请求提交资源对象（填那个版本就意味着，我这份资源 YAML 属于哪个 API 接口版本，怎么处理它，apiVersion 决定了你的资源交给哪个版本的 API 去处理， ）
简洁来说：
✅ apiVersion 用来告诉 Kubernetes：
👉 “我这个资源，要用哪个 API 版本去解析和处理。”
也就是说：K8s 内部有很多组件和资源版本的演进，而 apiVersion 就像是“声明接口版本”的门牌号码 🏷️，告诉系统我要创建的是哪个版本的对象、由哪个控制器去接管它。
2，kind 的资源类型
3，metadata: # 元数据：资源名称、标签、命名空间等
4，spec: # 属于具体资源类，型具体的规格（核心配置最重要的），每种资源的内容不同
注意：
|
描述你想要的状态（desired state） |
由你来写 |
|
描述系统当前实际的状态（current state） |
由 K8s 控制器自动更新 |
a.YAML 清单的基本结构
一个标准的 Kubernetes YAML 文件，基本包含以下几个核心字段：
apiVersion: v1 # 使用的 Kubernetes API 版本
kind: Pod # 要创建的资源类型（比如 Pod、Service、Deployment）
metadata: # 元数据：资源名称、标签、命名空间等
name: my-pod
labels:
app: myapp
spec: # 具体的规格（核心配置），每种资源的内容不同
containers: # 以 Pod 为例：定义容器
- name: my-container
image: nginx:1.25
ports:
- containerPort: 80
🧱 b、常见资源类型及示例内容
我给你列一些我们工作中最常用的 K8s 资源清单格式，让你对每类清单的结构有感性认识👇
1️⃣ Pod（最基本的运行单元）
apiVersion: v1
kind: Pod
metadata:
name: redis-pod
spec:
containers:
- name: redis
image: redis:7.2
ports:
- containerPort: 63792️⃣ Deployment（用来管理 Pod 的副本和滚动更新）
apiVersion: apps/v1
kind: Deployment
metadata:
name: redis-deploy
spec:
replicas: 3
selector:
matchLabels:
app: redis
template:
metadata:
labels:
app: redis
spec:
containers:
- name: redis
image: redis:7.2
ports:
- containerPort: 63793️⃣ Service（集群内/外部访问 Pod 的入口）
apiVersion: v1
kind: Service
metadata:
name: redis-svc
spec:
selector:
app: redis
ports:
- port: 6379
targetPort: 6379
type: ClusterIP # 也可以是 NodePort / LoadBalancer4️⃣ ConfigMap（配置注入）
apiVersion: v1
kind: ConfigMap
metadata:
name: redis-config
data:
redis.conf: |
bind 0.0.0.0
maxmemory 256mb
maxmemory-policy allkeys-lru5️⃣ Secret（用于保存密码、证书）
apiVersion: v1
kind: Secret
metadata:
name: redis-secret
type: Opaque
data:
password: cmVkaXMxMjM= # base64 编码后的字符串（"redis123"）6️⃣ Ingress（HTTP 路由转发入口）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: redis.mycompany.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: redis-svc
port:
number: 6379🎯 YAML 编写技巧 & 建议
- 缩进必须使用空格（不能用 Tab！）
- 一个 YAML 文件里可以写多个资源，使用
---分隔 - 建议使用
kubectl apply -f而不是create，方便更新 - 使用 IDE 插件（比如 VSCode 的 kube tools）能高亮和自动补全
- 写多了以后可以试试把 YAML 模板转成 Helm Chart（更灵活）
4.对上面yaml清单的 apiversion 解释
apiVersion: v1 # 使用的 Kubernetes API 版本 用命令可以看到 kubectl api-resources 版本
🧠 一、什么是 Kubernetes 的 API？
✅ 简单定义：
Kubernetes API 就是一个服务接口，它是整个 Kubernetes 的“大脑和中枢神经”，提供了创建、读取、更新、删除（CRUD）资源的标准入口。
所有的操作（无论你用命令、Web UI、Operator 还是 YAML 文件）最终都要通过 Kubernetes API Server 才能落地。
📡 二、整个 Kubernetes 是围绕 API 运作的！
Kubernetes 的架构核心是控制器模型：
你的 YAML 文件 → 提交给 API Server → 存入 etcd → 控制器监控状态 → 调度 & 执行也就是说：
kubectl apply -f redis.yaml👉 实际上是通过 API 请求提交资源对象- 控制器（如 Deployment Controller）监听这些资源，通过 API 获取当前状态
- 然后驱动调度器、网络、容器运行时等，让资源达到你设定的目标
💡 整个系统的协调就是靠 API Server 来调度和通讯的。
📦 三、那 apiVersion 到底起了什么作用？
Kubernetes 中每种资源都有对应的 API 组（Group）和版本（Version）：
比如 Deployment：
apiVersion: apps/v1
kind: Deployment这里：
apps是 API 组v1是版本号
不同的资源，由不同 API 组负责，比如：
资源 |
apiVersion |
API 组 |
Pod、Service |
|
core（核心）组 |
Deployment |
|
apps 组 |
Ingress |
|
networking 组 |
CronJob |
|
batch 组 |
👉 你写的 apiVersion 就是告诉 Kubernetes：“我这份资源 YAML 属于哪个 API 接口版本，怎么处理它”。
🛠️ 四、API 在实际操作中的体现
你用 kubectl 执行的每个命令，其实都是对 API 的调用：
kubectl get pods → GET /api/v1/namespaces/default/pods
kubectl apply -f xxx.yaml → POST /apis/apps/v1/namespaces/default/deployments你甚至可以直接用 curl 调用 API（例如连 kube-apiserver）：
curl https://<apiserver>/api/v1/pods（当然要带 token 验证，一般用在自定义脚本或监控场景中）
🔐 五、为什么会有多个 API 版本？
因为 Kubernetes 不断演进，一些资源在不同版本中变得更成熟或有新特性：
比如：
Deployment最早是extensions/v1beta1，后来变成apps/v1（推荐用）Ingress也是从extensions/v1beta1升级为networking.k8s.io/v1
如果你的 apiVersion 写错了或者用了已废弃的版本，系统会直接报错！
🧭 六、小结
项目 |
含义 |
Kubernetes API |
整个系统的“通信中枢”，所有资源都要通过它来管理 |
字段 |
声明该资源使用哪个 API 接口进行处理 |
没有它会怎样？ |
系统无法识别你要干什么，YAML 会报错或失败 |
5，k8s YAML 有几种核心结构，什么时候该用什么结构,我在编辑 yaml 文件时要注意哪些
总结： 结构和怎么用： 1.字段（其实就是一对一对的键值对 例：key: value规定是用键值对表示就用这种结构）
2.映射：（一个单字段下面要有键值对就是映射或者 字段在嵌套映射 注意缩进的键值对 ）
例： metadata: # 映射（包含多个字段） 单字段下面要有键值对就是映射 是映射（可以理解为爷，爸，）
name: mypod
metadata: # 映射（包含多个字段）
name: mypod
labels:
app: demo # 嵌套映射 单字段下面在嵌套映射（单字段下面还是单字段下有键值对，可以理解为爷，爸，儿）
3，序列（同类多个配置项，例如：多个容器、端口、标签等 注意：-开头的列表）
例：
spec:
containers: # 序列（多个容器）
- name: nginx # 映射（容器对象）
image: nginx:1.25
- name: redis
image: redis:7
🧱 一、K8s YAML 的 三大核心结构
Kubernetes 的 YAML 文件本质上是由 YAML 语言的三种基本结构组成的：
核心结构 |
表现形式 |
用途说明 |
例子 |
字段（Field） |
|
定义单个配置项 |
|
映射（Map） |
缩进的键值对 |
表示嵌套对象 |
下的内容 |
序列（List） |
|
同类多个配置项 |
多个容器、端口、标签等 |
✅ 示例快速理解：
apiVersion: v1 # 字段
kind: Pod # 字段
metadata: # 映射（包含多个字段）
name: mypod
labels:
app: demo # 嵌套映射
spec:
containers: # 序列（多个容器）
- name: nginx # 映射（容器对象）
image: nginx:1.25
- name: redis
image: redis:7🧭 二、什么时候用什么结构？
场景 |
使用结构 |
举例 |
简单属性，如名称、版本 |
字段（Field） |
|
对象嵌套，比如 metadata、spec |
映射（Map） |
|
一组值，如多个容器、卷、端口 |
序列（List） |
|
✅ 口诀记忆：
复制编辑
单项写字段，嵌套用映射；
一组多配置，序列最合适。🛠 三、编辑 YAML 文件时必须注意的事项
项目 |
说明 |
建议 |
✅ 缩进 |
YAML 通过缩进表示层级，通常用 2 个空格 |
绝对不能用 Tab |
✅ 字段对齐 |
同一层级字段必须对齐 |
使用 IDE 自动格式化 |
✅ List 项必须加 |
多个容器、端口、规则都需要 |
|
✅ 字段大小写敏感 |
≠ |
错写会被识别为无效字段 |
✅ 注意冒号后空格 |
中冒号后要加空格 |
|
✅ 多资源用 分隔 |
在一个文件写多个资源对象时 |
必须顶头写 |
💥 常见错误示例（容易踩坑）
metadata:
name: mypod ❌ 错误，name 应该缩进在 metadata 下面
containers:
- name: nginx
image: nginx:1.25
- name: redis
image: redis:7 ❌ 错误，image 缩进不对，跟 name 要对齐
kind: pod ❌ 错误，应该是 Pod（大小写敏感）✅ 建议使用工具：
- ✅ VS Code + Kubernetes 插件：支持 YAML 自动缩进、语法校验、字段提示。
- ✅ kubectl explain 命令：查看字段含义和结构，如：
kubectl explain deployment.spec.template.spec.containers🧠 总结一句话：
K8s YAML 文件由 字段、映射、序列三种结构构成，正确使用结构 + 注意缩进规范，是写好 YAML 的基本功。
6，写yaml清单文件的技巧
1，kubectl explain ........
kubectl explain 是 Kubernetes 提供的一个非常实用的命令，用于快速查看资源对象及其字段的结构和说明，可以说是写 YAML 文件的“查字典神器”📘。
🧠 一句话解释：
kubectl explain 能告诉你某个 Kubernetes 资源有哪些字段、这些字段是什么意思、是否必填，以及层级结构。
✅ 基本语法：
kubectl explain <资源类型> [字段路径]🔍 示例用法：
1️⃣ 查看某个资源对象的结构
kubectl explain pod结果：
KIND: Pod
VERSION: v1
DESCRIPTION:
Pod is a collection of containers...
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object>2️⃣ 查看某个字段的结构（如：查看 Pod 的 spec）
kubectl explain pod.spec结果：
FIELD: spec <Object>
DESCRIPTION:
Specification of the desired behavior of the pod.
FIELDS:
containers <[]Object>
volumes <[]Object>
restartPolicy <string>
...3️⃣ 查看深层字段（如：容器的 image 字段）
kubectl explain pod.spec.containers.image结果：
FIELD: image <string>
DESCRIPTION:
Docker image name. Example: nginx:1.25.3🚀 使用场景举例：
场景 |
命令 |
不记得 Deployment 里该怎么写 containers？ |
|
不知道 Service 的 port 字段写法？ |
|
想查 ConfigMap 的字段结构？ |
|
💡 小技巧
- 加
--recursive参数可以一次展开所有字段：
kubectl explain pod --recursive🔧 总结
优点 |
说明 |
📚 内置文档 |
无需上网查文档，命令行直接查看 |
✅ 实时对版本准确 |
与你当前 K8s 集群版本一致 |
🚀 快速查字段语法 |
特别适合写 YAML 时用 |
2,利用dry-run模拟运行指令式命令生成清单文件
了解 一下即可
3,利用现有资源生成清单文件再修改为新的清单文件
了解 一下即可
四，常见命令用法
kubectl 是 Kubernetes 的命令行工具，用于与 Kubernetes 集群交互。它提供了丰富的子命令来管理集群资源。以下是一些常用的 kubectl 子命令及其功能：
总结：
kubectl 管理get/describe/logs/exec 创建更新apply/create/edit/detele 调试与诊断cp/top/port-forward 高级管理命令config/set/rollout/1. 基础管理命令
kubectl get
-
- 用于获取资源列表。
- 示例：
kubectl get pods、kubectl get nodes、kubectl get svc（获取服务）。
kubectl describe
-
- 用于查看资源的详细信息。
- 示例：
kubectl describe pod <pod-name>。
kubectl logs
-
- 用于查看 Pod 的日志。
- 示例：
kubectl logs <pod-name>。
kubectl exec
-
- 用于在 Pod 中执行命令。
- 示例：
kubectl exec -it <pod-name> -- /bin/bash。
2. 资源创建与更新
kubectl apply
-
- 用于创建或更新资源（基于 YAML/JSON 配置文件）。
- 示例：
kubectl apply -f deployment.yaml。
kubectl create
-
- 用于创建资源（通常用于一次性创建，不推荐与 YAML 文件结合使用）。
- 示例：
kubectl create deployment my-deployment --image=nginx。
kubectl edit
-
- 用于编辑现有资源。
- 示例：
kubectl edit pod <pod-name>。
kubectl delete
-
- 用于删除资源。
- 示例：
kubectl delete pod <pod-name>。
3. 调试与诊断
kubectl cp
-
- 用于在本地与 Pod 之间复制文件。
- 示例：
kubectl cp <pod-name>:/path/to/file /local/path。
kubectl port-forward
-
- 用于将本地端口转发到 Pod 的端口。
- 示例：
kubectl port-forward pod/<pod-name> 8080:80。
kubectl top
-
- 用于查看资源使用情况（需要 Metrics Server）。
- 示例：
kubectl top pod。
4. 高级管理命令
kubectl config
-
- 用于管理
kubectl的上下文配置（如集群、用户、命名空间等）。 - 示例：
kubectl config view。
- 用于管理
kubectl rollout
-
- 用于管理 Deployment 的滚动更新。
- 示例：
kubectl rollout status deployment/<deployment-name>。
kubectl set
-
- 用于更新资源的特定字段（如镜像、环境变量等）。
- 示例：
kubectl set image deployment/<deployment-name> <container-name>=<new-image>。
5. 资源类型
kubectl 支持多种资源类型，常见的包括：
- Pod：
kubectl get pods - Node：
kubectl get nodes - Service：
kubectl get svc - Deployment：
kubectl get deployments - ReplicaSet：
kubectl get replicasets - ConfigMap：
kubectl get configmaps - Secret：
kubectl get secrets
示例：综合使用
# 查看所有 Pod
kubectl get pods
# 查看某个 Pod 的详细信息
kubectl describe pod <pod-name>
# 进入 Pod 的交互式 Shell
kubectl exec -it <pod-name> -- /bin/bash
# 更新 Deployment 的镜像
kubectl set image deployment/<deployment-name> <container-name>=<new-image>
# 滚动更新 Deployment
kubectl rollout status deployment/<deployment-name>补充说明
- 命令模式：几乎所有命令都支持
kubectl <操作> <资源类型> [名称] [参数]的格式。 - 帮助文档：使用
kubectl --help或kubectl <command> --help查看详细帮助。 - 资源缩写：如
po（Pod）、deploy（Deployment）、svc（Service）等，可简化输入。 - YAML 文件优先：生产环境建议通过 YAML 文件管理资源，确保可追溯性和版本控制。