控制平台组件（master 组件）#

• 控制平台中的组件对集群进行全局决策（比如：调度），并且监控和应对集群事件（比如：当 deployment 中的 replicas 字段发生变化时，创建/删除 pod）。
• 控制平台组件可以运行在集群中的任何一台机器上，但是为了简单，通常会在同一台物理机上部署所有的控制平台组件，同时要求用户的容器不能部署在控制平台组件所在的物理机上。

# kube-apiserver#

• API server 是 kubernetes 平台组件之一，它将 kubernetes API 暴露给用户，用户就是通过和 kube-apiserver 交互实现控制集群的。在一个集群中可以部署多个 kube-apiserver，并在他们之间执行“负载均衡”。

# etcd#

• 集群的所有数据都存储在 etcd 中，如果你选用 etcd 作为 kubernetes 的后端存储，请不要忘记对这些存储的数据做备份（back up）。 etcd 的更深入的信息可以参看官方文档：documentation

# kube-scheduler#

• 控制平台组件监控新创建但还没有为其分配 node 的 pod，之后选择一个适合的 node为 pod 分配，这就是 调度器（scheduler）负责干的事情。
• 在做调度决策是所考虑的因素有：individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines。

# kube-controller-manager#

• 控制平台组件中运行着许多控制器进程（controller processes）。理论上来说，每一个控制器都是一个独立的进程，但为了降低复杂性，将所有的控制器进程都编译到同一个二进制文件中并且运行在用一个进程中。

# 节点组件（Node Components）#

• 节点组件在集群中的每个节点上都有运行，维护运行中的 pod，并提供 kubernetes 运行时环境。

# kubelet#

• 集群中的每个 node 上都运行着一个代理（agent），它确保 pod 中的 container 是正在运行的。
• kubelet 读取一组 pod说明书（PodSpec），并确保 PodSpec中描述的 container 正在运行且运行状况良好。kubelet 只能管理 Kubernetes 创建的 container。

# kube-proxy#

• kube-proxy 是个网络代理，集群中的每个 node 上都运行着它。kube-proxy 维护节点上的网络规则，这些网络规则允许集群内部或外部的网络会话与 pod 进行网络通信。

# Container runtime#

• 这个组件是个软件，它负责跑 container，Kubernetes 支持的 container runtimes 有：Docker，containerd-CRI-O，和任何 Kubernetes CRI 的实现。

# 插件 （Addons）#

• 插件（也被叫做附加组件）使用 Kubernetes 资源（比如：DamonSet、Deployment）来实现集群功能（当恰当的附加组件出现时，kubernetes 集群才能提供正常的集群功能）。因为这些插件提供集群功能，所以这些插件都在 kube-system命名空间中。Kubernetes中可以使用的插件。

什么是 VXLAN?#

• VXLAN，即 Virtual Extensible LAN（虚拟可扩展局域网），是 Linux 本身支持的一种网络虚拟化技术。VXLAN 可以完全在内核态实现封装和解封装工作，从而通过 “隧道” 机制，构建出覆盖网络（Overlay Network）
• 基于三层的 “二层” 通信，层即 vxlan 包封装在 udp 数据包中，要求 udp 在 k8s 节点间三层可达；二层即 vxlan 封包的源 mac 地址和目的 mac 地址是自己的 vxlan 设备 mac 和对端 vxlan 设备 mac 实现通讯。

IPIP#

➤ Linux 原生内核支持

➤ IPIP 隧道的工作原理是将源主机的 IP 数据包封装在一个新的 IP 数据包中，新的 IP 数据包的目的地址是隧道的另一端。在隧道的另一端，接收方将解封装原始 IP 数据包，并将其传递到目标主机。IPIP 隧道可以在不同的网络之间建立连接，例如在 IPv4 网络和 IPv6 网络之间建立连接。

下载ikuai#

建议选择32位的。因为虚拟机要求的硬件低，只需要，一核一G。生成环境还是64位的好

虚拟机配置#

虚拟机都选择其他，硬件要求看上图。网卡选择主机模式。剩下的磁盘什么的都默认。

退出，给他再加上一个可以连外网的网卡nat模式，就是后面的wan口

进入ikuai配置#

（1）先配置LAN口，192.168.66.200/255.255.255.0，这个是vm里面设置好的虚拟网卡，在66网段，我的Nat虚拟网卡是44网段的。后面会看到

（2）主机输入192.168.66.200 进如ikuai的web管理界面

进入设置wan口，使得这个可以上网。自动获取就行了（DHCP）

这里就看见我设置的vm里面设置的虚拟网卡了，44网段的，就是通过这个Nat在通过主机转发上网的

给三个虚拟机都设置网关#

也就是刚进来给ikuai设置的LAN口，三个虚拟机和ikuai可以相互通信，上网就通过ikuai的WAN口

给所有虚拟机里面第二个Nat网卡设置开机不自启#

1
[root@k8s-master01 ~]# vi /etc/NetworkManager/system-connections/ens192.nmconnection

现在就全部靠路由上网了

ens192 网卡就没有启动

1
[root@k8s-master01 ~]# ip a
2
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
3
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
4
    inet 127.0.0.1/8 scope host lo
5
       valid_lft forever preferred_lft forever
6
    inet6 ::1/128 scope host
7
       valid_lft forever preferred_lft forever
8
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
9
    link/ether 00:0c:29:31:d5:3e brd ff:ff:ff:ff:ff:ff
10
    altname enp3s0
11
    inet 192.168.66.11/24 brd 192.168.66.255 scope global noprefixroute ens160
12
       valid_lft forever preferred_lft forever
13
    inet6 fe80::20c:29ff:fe31:d53e/64 scope link noprefixroute
14
       valid_lft forever preferred_lft forever
15
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
16
    link/ether 00:0c:29:31:d5:48 brd ff:ff:ff:ff:ff:ff
17
    altname enp11s0
18
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
19
    link/ether 86:bc:9b:71:e4:a2 brd ff:ff:ff:ff:ff:ff
20
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
21
       valid_lft forever preferred_lft forever

换主机名，方便后面操作#

（1）hostnamectl set-hostname k8s-master01

（2）hostnamectl set-hostname k8s-node01

（3）hostnamectl set-hostname k8s-node02

主机名ip映射#

• vi /etc/hosts # 添加到末尾, m1 是缩写

1
192.168.66.11 k8s-master01 m1
2
192.168.66.12 k8s-node01 n1
3
192.168.66.13 k8s-node02 n2

安装cri-docker#

1
# 安装 cri-docker
2
wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.9/cri-dockerd-0.3.9.amd64.tgz
3
tar -xf cri-dockerd-0.3.9.amd64.tgz
4
cp cri-dockerd/cri-dockerd /usr/bin/
5
chmod +x /usr/bin/cri-dockerd
6

7
# 配置cri-docker服务 加入到systemctl中
8
cat <<"EOF" > /usr/lib/systemd/system/cri-docker.service
9
[Unit]
10
Description=CRI Interface for Docker Application Container Engine
11
Documentation=https://docs.mirantis.com
12
After=network-online.target firewalld.service docker.service
13
Wants=network-online.target
14
Requires=cri-docker.socket
15

16
[Service]
17
Type=notify
18
ExecStart=/usr/bin/cri-dockerd --network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.8
19
ExecReload=/bin/kill -s HUP $MAINPID
20
TimeoutSec=0
21
RestartSec=2
22
Restart=always
23
StartLimitBurst=3
24
StartLimitInterval=60s
25
LimitNOFILE=infinity
26
LimitNPROC=infinity
27
LimitCORE=infinity
28
TasksMax=infinity
29
Delegate=yes
30
KillMode=process
31

32
[Install]
33
WantedBy=multi-user.target
34
EOF
35

36
# 添加 cri-docker 套接字
37
cat <<"EOF" > /usr/lib/systemd/system/cri-docker.socket
38
[Unit]
39
Description=CRI Docker Socket for the API
40
PartOf=cri-docker.service
41

42
[Socket]
43
ListenStream=%t/cri-dockerd.sock
44
SocketMode=0660
45
SocketUser=root
46
SocketGroup=docker
47

48
[Install]
49
WantedBy=sockets.target
50
EOF
51

52
# 启动 cri-docker 对应服务
53
systemctl daemon-reload
54
systemctl enable cri-docker
55
systemctl start cri-docker
56
systemctl is-active cri-docker

开始安装 kubelet kubectl kubeadm，初始化master节点#

1
# 添加 kubeadm yum 源
2
cat <<EOF > /etc/yum.repos.d/kubernetes.repo
3
[kubernetes]
4
name=Kubernetes
5
baseurl=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/
6
enabled=1
7
gpgcheck=1
8
gpgkey=https://pkgs.k8s.io/core:/stable:/v1.29/rpm/repodata/repomd.xml.key
9
exclude=kubelet kubeadm kubectl cri-tools kubernetes-cni
10
EOF
11

12
# 安装 kubeadm 1.29 版本
13
yum install -y kubelet-1.29.0 kubectl-1.29.0 kubeadm-1.29.0 --disableexcludes=kubernetes
14
systemctl enable kubelet.service

1
# 初始化主节点
2
kubeadm init \
3
  --apiserver-advertise-address=192.168.66.11 \
4
  --image-repository registry.aliyuncs.com/google_containers \
5
  --kubernetes-version 1.29.2 \
6
  --service-cidr=10.10.0.0/12 \
7
  --pod-network-cidr=10.244.0.0/16 \
8
  --ignore-preflight-errors=all \
9
  --cri-socket unix:///var/run/cri-dockerd.sock
10
# 创建配置文件
11
mkdir -p $HOME/.kube
12
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
13
sudo chown $(id -u):$(id -g) $HOME/.kube/config
14

15
# 其他节点 加入到主节点 如果是docker就必须加上最后的参数 --cri-socket unix
16
kubeadm join 192.168.66.11:6443 --token xpr121.elrcxawcf9ouext9 \
17
    --discovery-token-ca-cert-hash sha256:e5547eb91684b068ee77d7f3f474a251a4c405f8723ce2ca723abfa3d6eef7d5 \
18
    --cri-socket unix:///var/run/cri-dockerd.sock

1
# work token 过期后，重新申请
2
kubeadm token create --print-join-command
3

4
# worker 加入
5
kubeadm join 192.168.66.11:6443 --token a6xh07.yg9wh2vru2gr1uwb \
6
  --discovery-token-ca-cert-hash sha256:7cd8499abae48c8403800152cc0f655ac704ea00ae30a549acd9bbac7b26dca4 \
7
  --cri-socket unix:///var/run/cri-dockerd.sock

初始化失败重新来

1
# 重置 kubeadm
2
kubeadm reset -f --cri-socket unix:///var/run/cri-dockerd.sock
3

4
# 清理残留目录（这些残留常会导致证书或配置错误）
5
rm -rf /etc/kubernetes/
6
rm -rf /var/lib/etcd/
7
rm -rf /var/lib/kubelet/
8
rm -rf $HOME/.kube/
9
rm -rf /etc/cni/net.d/

安装网络插件#

1
# Calico 官方文档地址：
2
# https://docs.tigera.io/calico/latest/getting-started/kubernetes/self-managed-onprem/onpremises#install-calico-with-kubernetes-api-datastore-more-than-50-nodes
3

4
# 下载 Calico 清单文件
5
curl https://raw.githubusercontent.com/projectcalico/calico/v3.26.3/manifests/calico-typha.yaml -o calico.yaml
6

7
# 关键点：修改 CALICO_IPV4POOL_CIDR 为你集群的 Pod 网段
8
# 修改为 BGP 模式：关闭 IPIP 隧道
9
# 找到配置项：
10
- name: CALICO_IPV4POOL_IPIP
11
  value: "Always"  # 改成 "Off"

1
# 依次拉取 4 个核心镜像
2
docker pull calico/cni:v3.26.3
3
docker pull calico/node:v3.26.3
4
docker pull calico/kube-controllers:v3.26.3
5
docker pull calico/typha:v3.26.3
6

7
# 在 Master 节点上执行：
8
kubectl apply -f calico.yaml

概念#

k8s中所有的内容都抽象为资源，资源实例化之后，叫做对象

分类#

结构#

如何查看 接口组/版本

1
[root@k8s-master01 ~]# kubectl explain pod
2
KIND:       Pod
3
VERSION:    v1
4

5
DESCRIPTION:
6
    Pod is a collection of containers that can run on a host. This resource is
7
    created by clients and scheduled onto hosts.
8

9

10
[root@k8s-master01 ~]# kubectl explain deployment
11
GROUP:      apps
12
KIND:       Deployment
13
VERSION:    v1
14

15
DESCRIPTION:
16
    Deployment enables declarative updates for Pods and ReplicaSets.

所以 第一个pod的是 v1

第一个是 apps/v1

demo#

1
apiVersion: v1
2
kind: Pod
3
metadata:
4
  name: pod-demo
5
  namespace: default
6
  labels:
7
    app: myapp
8
spec:
9
  containers:
10
  - name: myapp-1
11
    # 换成这个版本的 Nginx，格式更新，兼容性好
12
    image: registry.aliyuncs.com/google_containers/nginx-slim:0.20
13
  - name: busybox-1
14
    # 保持这个，因为你刚才已经拉取成功了
15
    image: registry.aliyuncs.com/google_containers/busybox:1.27
16
    command:
17
    - "/bin/sh"
18
    - "-c"
19
    - "sleep 3600"

initC#

init 容器与普通的容器非常像，除了如下两点：

• init 容器总是运行到成功完成为止

• 每个 init 容器都必须在下一个 init 容器启动之前成功完成，所以init容器是线性启动的

如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。

然而，如果 Pod 对应的 restartPolicy 为 Never，它不会重新启动

探针#

kubectl create、apply、replace#

create

创建资源对象

• 1
  -f

  通过基于文件的创建，但是如果此文件描述的对象存在，那么哪怕文件描述的信息发生了改变，再次提交时也不会应用

apply

创建资源对象、修改资源对象

• 1
  -f

  基于文件创建，如果目标对象与文件本身发生改变，那么会根据文件的指定一一修改目标对象的属性（部分更新）

replace

创建资源对象、修改资源对象

• 1
  -f

  基于文件创建，如果目标对象与文件本身发生改变，那么会重建此对象（替换）

Deployment - 常用命令#

$ kubectl create -f deployment.yaml —record

—record 参数可以记录命令，我们可以很方便的查看每次 revision 的变化

$ kubectl scale deployment nginx-deployment —replicas 10

为 nginx-deployment 配置水平自动扩缩容，最小副本数 10、最大副本数 15，当 Pod CPU 使用率超过 80% 时自动扩容。

$ kubectl autoscale deployment nginx-deployment —min=10 —max=15 —cpu-percent=80

在线更新 Deployment 中容器的镜像版本，会自动触发滚动更新，不中断服务。

$ kubectl set image deployment/nginx-deployment nginx-deployment-container=wangyanglinux/myapp.0

$ kubectl rollout undo deployment/nginx-deployment

1
# 可以直接创建一个资源清单模版文件来，--dry-run 白干
2
kubectl create deployment myapp --image=nginx:latest --dry-run -o yaml > deployment.yaml.tmp

DaemonSet#

• 核心作用：确保集群中每一个（或指定的）节点上都运行一个相同的 Pod 副本
• 适用场景：节点级组件部署，如日志采集、监控代理、网络插件等

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。

Job/CronJob#

• Job：一次性任务控制器，保证 Pod 成功执行一次后自动退出，适合一次性计算、批量处理
• CronJob：定时任务控制器，基于 Cron 表达式周期性执行 Job，适合定时备份、定时报表等场景

cluserIP#

公司内部的内线电话

• 只有公司内部员工（集群内 Pod / 节点）能打，外面的人（集群外）打不通
• 号码固定不变，哪怕员工（Pod）调岗、换工位，内线号码永远不变
• 打内线时，会自动帮你转接到对应的员工，不用记每个人的分机号

nodePort#

NodePort: 在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 <NodeIP>:NodePort 来访问该服务

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-nodeport-svc
5
spec:
6
  # 指定模式为 NodePort
7
  type: NodePort
8
  ports:
9
  # Service 内部端口
10
  - port: 80
11
    # 后端 Pod 的端口
12
    targetPort: 80
13
    # 可选：手动指定 NodePort 端口，不写则自动分配
14
    nodePort: 30080
15
  # 标签选择器，匹配后端 Pod
16
  selector:
17
    app: nginx

有标签选择器的 Service（自动模式）#

这是最常用的标准用法，也是 Kubernetes 原生的自动服务发现模式。

核心规则

1. 当你创建一个定义了 spec.selector 标签选择器的 Service 时，Kubernetes 会自动创建一个同名的 Endpoints 资源对象，完全无需人工干预。
2. Endpoints 资源的匹配逻辑严格遵循以下规则：
   • 匹配范围：和 Service 在同一个 Namespace 内的 Pod（跨 Namespace 的 Pod 无法被自动匹配）
   • 匹配条件：Pod 的标签是 Service 标签选择器的子集（即 Pod 必须包含 Service 选择器里的所有标签，多出来的标签不影响匹配）
   • 健康检查：仅匹配处于「就绪（Ready）」状态的 Pod（未就绪、正在启动、异常退出的 Pod 不会被加入 Endpoints）
3. 自动维护：当符合条件的 Pod 发生创建、销毁、标签变更、就绪状态变化时，Kubernetes 会实时自动更新 Endpoints 列表，确保流量只会转发到健康的后端 Pod。

无标签选择器的 Service（手动模式）#

这是用于「自定义后端」的高级用法，适合后端不在 Kubernetes 集群内、或需要手动控制流量目标的场景。

核心规则

1. 当你创建没有定义 spec.selector 字段的 Service 时，Kubernetes 不会自动创建同名的 Endpoints 资源，完全需要集群管理员手动创建和维护 Endpoints 对象。
2. 匹配逻辑：Endpoints 里的后端地址，完全由管理员手动填写，支持：
   • 集群外部的物理机、云服务器地址
   • 其他 Namespace 内的 Pod 地址
   • 异构系统的服务端点（比如数据库、中间件、外部 API 等）
3. 流量转发：Service 会把收到的流量，直接转发到你手动在 Endpoints 里填写的所有端点，不会自动检查后端状态，需要你自己维护端点的健康。

配置内部流量策略#

配置内部流量策略，二选一

internalTrafficPolicy: Local # 仅转发到同节点Pod

internalTrafficPolicy: Cluster # 转发到集群所有Pod（默认）