1. kubernetes 三种接口
- CRI：容器运行时接口（Docker、Containerd、Podman、Cri-o）
- CNI：容器网络接口（Flannel、Calico、Cilium）
- CSI：容器存储接口（NFS、Ceph、GFS、OSS、S3、Minio）
2. kubernetes 网络
2.1 k8s 三种网络
- 节点网络：物理服务器网卡，网卡IP。每个主机网卡的组成，集群节点的网络通信。
- Pod网络：PodIP 提供给Docker容器使用的IP地址，虚拟IP地址。一个Pod中只有一个IP地址，一个Pod中会共享一个IP地址出去，Pod之间通讯要加网络。Pod与Pod之间可以通过PodIP相互通信。
- Service网络：ClusterIP Service-IP地址，虚拟IP地址，给Pod提供载体。在K8S集群内可通过Service资源的ClusterIP实现对Pod集群的网络代理转发。
2.2 K8S 中 Pod 网络通信：
（1）Pod 内容器与容器之间的通信
在同一个 Pod 内的容器（Pod 内的容器是不会跨宿主机的）共享同一个网络命令空间，相当于它们在同一台机器上一样，可以用 localhost 地址访问彼此的端口。
（2）同一个 Node 内 Pod 之间的通信
每个 Pod 都有一个真实的全局 IP 地址，同一个 Node 内的不同 Pod 之间可以直接采用对方 Pod 的 IP 地址进行通信，Pod1 与 Pod2 都是通过 Veth 连接到同一个 docker0 网桥，网段相同，所以它们之间可以直接通信。
（3）不同 Node 上 Pod 之间的通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行。
要想实现不同 Node 上 Pod 之间的通信，就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件：Pod 的 IP 不能冲突；将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信。
Overlay Network：
叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来（类似于VPN）。
VXLAN：
将源数据包封装到UDP中，并使用基础网络的IP/MAC作为外层报文头进行封装，然后在以太网上传输，到达目的地后由隧道端点解封装并将数据发送给目标地址。
2.3 VLAN 和 VXLAN 比较
2.3.1 VLAN
做资源的隔离和安全，使用Vlan，资源不够用的时候，使用VLAN，防止广播风暴
2.3.2 VXLAN
VXLAN：虚拟网络技术，将每个电脑作为一个网络标识，都做一个虚拟化的划分，可以划分几万个标识，将每台电脑绑定固定的标识。假设从一楼到三楼的数据通信，VXLAN会将数据包进行封装，将标识符和收件人和寄件人信息封装好，通过网络传给对面。相当于建立了虚拟隧道，不需要借助设备进行。
2.3.3 区别
2.3.3.1 作用不同
- VLAN主要用作于在交换机上逻辑划分广播域，还可以配合STP生成树协议阻塞路径接口，避免产生环路和广播风暴。
- VXLAN可以将数据帧封装成UDP报文，再通过网络层传输给其它网络，从而实现虚拟大二层网络的通信
2.3.3.2 vxlan支持更多的二层网络
- vlan使用12位bit表示vlanID，因此最多支持2^12=4094个vlan
- vxlan使用的ID使用24位bit，最多可以支持2^24个个vlan
2.3.3.3 已有的网络路径利用效率更高
- vlan使用spanning tree protocol避免环路，会将一半的网络路径阻塞
- vxlan的数据包封装成UDP通过网络层传输，可以使用所有的网络路径
2.3.3.4 防止物理交换机mac表耗尽
- vlan需要在交换机的Mac表中记录Mac物理地址
- vxlan采用隧道机制，Mac物理地址不需记录在交换机
2.3.3.5 相对VLAN技术，VXLAN技术具有以下优势
- 24位长度的VNI字段值可以支持更多数量的虚拟网络，解决了VLAN数目上限为4094的局限性的问题。
- VXLAN技术通过隧道技术在物理的三层网络中虚拟二层网络，处于VXLAN网络的终端无法察觉到VXLAN的通信过程，这样也就使得逻辑网络拓扑和物理网络拓扑实现了一定程度的解耦，网络拓扑的配置对于物理设备的配置的依赖程度有所降低，配置更灵活更方便。
- VLAN技术仅仅解决了二层网络广播域分割的问题，而VXLAN技术还具有多租户支持的特性，通过VXLAN分割，各个租户可以独立组网、通信，地址分配方面和多个租户之间地址冲突的问题也得到了解决。
3. Flannel 插件
Flannel 的功能是让集群中的不同节点主机创建的 Docker 容器都具有全集群唯一的虚拟 IP 地址。
Flannel 是 Overlay 网络的一种，也是将 TCP 源数据包封装在另一种网络包里面进行路由转发和通信，目前支持 udp、vxlan、 host-GW 3种数据转发方式。
- UDP（默认方式，基于应用转发，配置简单，性能最差）
- VXLAN（基于内核转发）
- Host-gw（性能最好、配置麻烦）
3.1 Flannel UDP 模式 （端口 8285）
udp模式的工作原理：（基于应用进行转发，Flannel提供路由表，Flannel封装、解封装）
数据从 node01 上 Pod 的源容器中发出后，经由所在主机的 docker0 虚拟网卡转发到 flannel0 虚拟网卡，flanneld 服务监听在 flannel0 虚拟网卡的另外一端。
Flannel 通过 Etcd 服务维护了一张节点间的路由表。源主机 node01 的 flanneld 服务将原本的数据内容封装到 UDP 中后根据自己的路由表通过物理网卡投递给目的节点 node02 的 flanneld 服务，数据到达以后被解包，然后直接进入目的节点的 flannel0 虚拟网卡，之后被转发到目的主机的 docker0 虚拟网卡，最后就像本机容器通信一样由 docker0 转发到目标容器。
ETCD 之 Flannel 提供说明：
- 存储管理 Flannel 可分配的IP地址段资源
- 监控 ETCD 中每个 Pod 的实际地址，并在内存中建立维护 Pod 节点路由表
3.2 vxlan 模式（端口4789）
vxlan 是一种 overlay（虚拟隧道通信）技术，通过三层网络搭建虚拟的二层网络，跟 udp 模式具体实现不太一样：
1）udp模式是在用户态实现的，数据会先经过tun网卡，到应用程序，应用程序再做隧道封装，再进一次内核协议栈，而vxlan是在内核当中实现的，只经过一次协议栈，在协议栈内就把vxlan包组装好。
2）udp模式的tun网卡是三层转发，使用tun是在物理网络之上构建三层网络，属于ip in udp，vxlan模式是二层实现， overlay是二层帧，属于mac in udp。
3）vxlan由于采用mac in udp的方式，所以实现起来会涉及mac地址学习，arp广播等二层知识，udp模式主要关注路由
Flannel VXLAN模式跨主机的工作原理：（Flannel提供路由表，由内核封装、解封装）
1、数据帧从主机A上Pod的源容器中发出后，经由所在主机的docker0/cni0 网络接口转发到flannel.1 接口
2、flannel.1 收到数据帧后添加VXLAN 头部，封装在UDP报文中
3、主机A通过物理网卡发送封包到主机B的物理网卡中
4、主机B的物理网卡再通过VXLAN 默认端口8472转发到flannel.1 接口进行解封装
（官方给出的预设接口为4789，而实际运用的其实为8472端口）
5、解封装以后，内核将数据帧发送到Cni0， 最后由Cni0 发送到桥接到此接口的容器B中。
3.3 UDP和VXLAN的区别
由于UDP模式是在用户态做转发（即基于应用进行转发，由应用程序进行封装和解封装），会多一次报文隧道封装，因此性能上会比在内核态做转发的VXLAN模式差。
UDP和VXLAN的区别：
- UDP基于应用程序进行转发，由应用程序进行封装和解封装；VXLAN由内核进行封装和解封装，内核效率比应用程序要高，所以VXLAN比UDP要快。
- UDP是数据包，VXLAN是数据帧。
- UDP的网卡Flannel0，VXLAN的网卡Flannel.1。
4. Calico 组件
4.1 k8s组网方案对比
1）flannel 方案：
需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod上。数据通信性能则大受影响。
2）calico方案：
Calico不使用隧道或NAT来实现转发，而是把Host当作Internet中的路由器，使用BGP同步路由，并使用iptables来做安全访问策略，完成跨Host转发来。
采用直接路由的方式，这种方式性能损耗最低，不需要修改报文数据，但是如果网络比较复杂场景下，路由表会很复杂，对运维同事提出了较高的要求。
4.2 Calico 的组成和工作原理
基于三层路由表进行转发，不需要封装和解封装。
Calico主要由三个部分组成：
- Calico CNI插件：主要负责与kubernetes对接，供kubelet 调用使用。
- Felix：负责维护宿主机上的路由规则、FIB转发信息库等。
- BIRD：负责分发路由规则，类似路由器。
- Confd：配置管理组件。
Calico工作原理：
- Calico是通过路由表来维护每个pod的通信。
- Calico 的CNI插件会为每个容器设置一个 veth pair设备，然后把另一端接入到宿主机网络空间，由于没有网桥，CNI插件还需要在宿主机上为每个容器的veth pair设备配置一条路由规则，用于接收传入的IP包。
- 有了这样的veth pair设备以后，容器发出的IP包就会通过veth pair设备到达宿主机，然后宿主机根据路由规则的下一跳地址，发送给正确的网关，然后到达目标宿主机，再到达目标容器
- 这些路由规则都是Felix 维护配置的，而路由信息则是Calico BIRD 组件基于BGP（动态路由协议，可以选路）分发而来。
- calico实际上是将集群里所有的节点都当做边界路由器来处理，他们一起组成了一个全互联的网络，彼此之间通过BGP交换路由，这些节点我们叫做BGP Peer。
5. flannel 和 calico 对比
flannel
- 配置方便，功能简单，是基于overlay叠加网络实现的（在原有数据包中再封装一层），由于要进行封装和解封装的过程对性能会有一定的影响，同时不具备网络策略配置能力。
- 三种模式：UDP、 VXLAN、HOST-GW
- 默认网段是：10.244.0.0/16
calico
- 功能强大，基于路由表进行转发，没有封装和解封装的过程，对性能影响较小，具有网络策略配置能力，但是路由表维护起来较为复杂。
- 模式：BGP、IPIP
- 默认网段192 .168.0.0/16
目前比较常用的CNI网络组件是flannel和calico，flannel的功能比较简单，不具备复杂的网络策略配置能力，calico是比较出色的网络管理插件，但具备复杂网络配置能力的同时，往往意味着本身的配置比较复杂，所以相对而言，比较小而简单的集群使用flannel，考虑到日后扩容，未来网络可能需要加入更多设备，配置更多网络策略，则使用calico更好。
（flannel在封装和解封装的过程中，会有性能损耗。calico没有封装解封装过程，没有性能损耗）
6. 部署网络组件
6.1 部署 flannel
//在node1节点上操作
#上传 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目录中
cd /opt/
docker load -i flannel.tar
mkdir /opt/cni/bin -p
tar zxvf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin
//在node2节点上操作
#上传 cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目录中
cd /opt/
docker load -i flannel.tar
mkdir /opt/cni/bin -p
tar zxvf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin
//在 master01 节点上操作
#上传 kube-flannel.yml 文件到 /opt/k8s 目录中，部署 CNI 网络
cd /opt/k8s
kubectl apply -f kube-flannel.yml
kubectl get pods -n kube-system
kubectl get nodes6.2 部署 Calico
该网络插件和flannel插件 选择其一部署即可（由于yaml文件过于复杂，本次就不再展示）
//在 master01 节点上操作
#上传 calico.yaml 文件到 /opt/k8s 目录中，部署 CNI 网络
cd /opt/k8s
vim calico.yaml
#修改里面定义Pod网络（CALICO_IPV4POOL_CIDR），与前面kube-controller-manager配置文件指定的cluster-cidr网段一样
- name: CALICO_IPV4POOL_CIDR
value: "192.168.0.0/16"
kubectl apply -f calico.yaml
kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-659bd7879c-4h8vk 1/1 Running 0 58s
calico-node-nsm6b 1/1 Running 0 58s
calico-node-tdt8v 1/1 Running 0 58s
#等 Calico Pod 都 Running，节点也会准备就绪
kubectl get nodes7. 部署 CoreDNS
CoreDNS：可以为集群中的 service 资源创建一个域名与 IP 的对应关系解析。
service发现是k8s中的一个重要机制，其基本功能为：在集群内通过服务名对服务进行访问，即需要完成从服务名到ClusterIP的解析。
k8s主要有两种service发现机制：环境变量和DNS。没有DNS服务的时候，k8s会采用环境变量的形式，但一旦有多个service，环境变量会变复杂，为解决该问题，我们使用DNS服务。
//在所有 node 节点上操作
#上传 coredns.tar 到 /opt 目录中
cd /opt
docker load -i coredns.tar
//在 master01 节点上操作
#上传 coredns.yaml 文件到 /opt/k8s 目录中，部署 CoreDNS
cd /opt/k8s
kubectl apply -f coredns.yaml
kubectl get pods -n kube-system
#DNS 解析测试
kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
/ # nslookup kubernetes8. 本次部署使用的脚本
8.1 node 节点上的部署脚本
① kubelet.sh
#!/bin/bash
NODE_ADDRESS=$1
DNS_SERVER_IP=${2:-"10.0.0.2"}
#创建 kubelet 启动参数配置文件
cat >/opt/kubernetes/cfg/kubelet <<EOF
KUBELET_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--hostname-override=${NODE_ADDRESS} \\
--network-plugin=cni \\
--kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \\
--bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \\
--config=/opt/kubernetes/cfg/kubelet.config \\
--cert-dir=/opt/kubernetes/ssl \\
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
EOF
#--hostname-override：指定kubelet节点在集群中显示的主机名或IP地址，默认使用主机hostname；kube-proxy和kubelet的此项参数设置必须完全一致
#--network-plugin：启用CNI
#--kubeconfig：指定kubelet.kubeconfig文件位置，当前为空路径，会自动生成，用于如何连接到apiserver，里面含有kubelet证书，master授权完成后会在node节点上生成 kubelet.kubeconfig 文件
#--bootstrap-kubeconfig：指定连接 apiserver 的 bootstrap.kubeconfig 文件
#--config：指定kubelet配置文件的路径，启动kubelet时将从此文件加载其配置
#--cert-dir：指定master颁发的kubelet证书生成目录
#--pod-infra-container-image：指定Pod基础容器（Pause容器）的镜像。Pod启动的时候都会启动一个这样的容器，每个pod之间相互通信需要Pause的支持，启动Pause需要Pause基础镜像
#----------------------
#创建kubelet配置文件（该文件实际上就是一个yml文件，语法非常严格，不能出现tab键，冒号后面必须要有空格，每行结尾也不能有空格）
cat >/opt/kubernetes/cfg/kubelet.config <<EOF
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: ${NODE_ADDRESS}
port: 10250
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
- ${DNS_SERVER_IP}
clusterDomain: cluster.local
failSwapOn: false
authentication:
anonymous:
enabled: true
EOF
#PS：当命令行参数与此配置文件（kubelet.config）有相同的值时，就会覆盖配置文件中的该值。
#----------------------
#创建 kubelet.service 服务管理文件
cat >/usr/lib/systemd/system/kubelet.service <<EOF
[Unit]
Description=Kubernetes Kubelet
After=docker.service
Requires=docker.service
[Service]
EnvironmentFile=/opt/kubernetes/cfg/kubelet
ExecStart=/opt/kubernetes/bin/kubelet \$KUBELET_OPTS
Restart=on-failure
KillMode=process
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable kubelet
systemctl restart kubelet② proxy.sh
#!/bin/bash
NODE_ADDRESS=$1
#创建 kube-proxy 启动参数配置文件
cat >/opt/kubernetes/cfg/kube-proxy <<EOF
KUBE_PROXY_OPTS="--logtostderr=true \\
--v=4 \\
--hostname-override=${NODE_ADDRESS} \\
--cluster-cidr=172.17.0.0/16 \\
--proxy-mode=ipvs \\
--kubeconfig=/opt/kubernetes/cfg/kube-proxy.kubeconfig"
EOF
#--hostnameOverride: 参数值必须与 kubelet 的值一致，否则 kube-proxy 启动后会找不到该 Node，从而不会创建任何 ipvs 规则
#--cluster-cidr：指定 Pod 网络使用的聚合网段，Pod 使用的网段和 apiserver 中指定的 service 的 cluster ip 网段不是同一个网段。 kube-proxy 根据 --cluster-cidr 判断集群内部和外部流量，指定 --cluster-cidr 选项后 kube-proxy 才会对访问 Service IP 的请求做 SNAT，即来自非 Pod 网络的流量被当成外部流量，访问 Service 时需要做 SNAT。
#--proxy-mode：指定流量调度模式为ipvs模式，可添加--ipvs-scheduler选项指定ipvs调度算法（rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）
#--kubeconfig: 指定连接 apiserver 的 kubeconfig 文件
#----------------------
#创建 kube-proxy.service 服务管理文件
cat >/usr/lib/systemd/system/kube-proxy.service <<EOF
[Unit]
Description=Kubernetes Proxy
After=network.target
[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-proxy
ExecStart=/opt/kubernetes/bin/kube-proxy \$KUBE_PROXY_OPTS
Restart=on-failure
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable kube-proxy
systemctl restart kube-proxy③ kubeconfig.sh
#!/bin/bash
#example: kubeconfig 192.168.73.105 /opt/k8s/k8s-cert/
#创建bootstrap.kubeconfig文件
#该文件中内置了 token.csv 中用户的 Token，以及 apiserver CA 证书；kubelet 首次启动会加载此文件，使用 apiserver CA 证书建立与 apiserver 的 TLS 通讯，使用其中的用户 Token 作为身份标识向 apiserver 发起 CSR 请求
BOOTSTRAP_TOKEN=$(awk -F ',' '{print $1}' /opt/kubernetes/cfg/token.csv)
APISERVER=$1
SSL_DIR=$2
export KUBE_APISERVER="https://$APISERVER:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=$SSL_DIR/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=bootstrap.kubeconfig
#--embed-certs=true：表示将ca.pem证书写入到生成的bootstrap.kubeconfig文件中
# 设置客户端认证参数，kubelet 使用 bootstrap token 认证
kubectl config set-credentials kubelet-bootstrap \
--token=${BOOTSTRAP_TOKEN} \
--kubeconfig=bootstrap.kubeconfig
# 设置上下文参数
kubectl config set-context default \
--cluster=kubernetes \
--user=kubelet-bootstrap \
--kubeconfig=bootstrap.kubeconfig
# 使用上下文参数生成 bootstrap.kubeconfig 文件
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#----------------------
#创建kube-proxy.kubeconfig文件
# 设置集群参数
kubectl config set-cluster kubernetes \
--certificate-authority=$SSL_DIR/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=kube-proxy.kubeconfig
# 设置客户端认证参数，kube-proxy 使用 TLS 证书认证
kubectl config set-credentials kube-proxy \
--client-certificate=$SSL_DIR/kube-proxy.pem \
--client-key=$SSL_DIR/kube-proxy-key.pem \
--embed-certs=true \
--kubeconfig=kube-proxy.kubeconfig
# 设置上下文参数
kubectl config set-context default \
--cluster=kubernetes \
--user=kube-proxy \
--kubeconfig=kube-proxy.kubeconfig
# 使用上下文参数生成 kube-proxy.kubeconfig 文件
kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig④ kube-flannel.yml
---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: psp.flannel.unprivileged
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
spec:
privileged: false
volumes:
- configMap
- secret
- emptyDir
- hostPath
allowedHostPaths:
- pathPrefix: "/etc/cni/net.d"
- pathPrefix: "/etc/kube-flannel"
- pathPrefix: "/run/flannel"
readOnlyRootFilesystem: false
# Users and groups
runAsUser:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
fsGroup:
rule: RunAsAny
# Privilege Escalation
allowPrivilegeEscalation: false
defaultAllowPrivilegeEscalation: false
# Capabilities
allowedCapabilities: ['NET_ADMIN', 'NET_RAW']
defaultAddCapabilities: []
requiredDropCapabilities: []
# Host namespaces
hostPID: false
hostIPC: false
hostNetwork: true
hostPorts:
- min: 0
max: 65535
# SELinux
seLinux:
# SELinux is unused in CaaSP
rule: 'RunAsAny'
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: flannel
rules:
- apiGroups: ['extensions']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames: ['psp.flannel.unprivileged']
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: flannel
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: flannel
subjects:
- kind: ServiceAccount
name: flannel
namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: flannel
namespace: kube-system
---
kind: ConfigMap
apiVersion: v1
metadata:
name: kube-flannel-cfg
namespace: kube-system
labels:
tier: node
app: flannel
data:
cni-conf.json: |
{
"name": "cbr0",
"cniVersion": "0.3.1",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "vxlan"
}
}
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kube-flannel-ds
namespace: kube-system
labels:
tier: node
app: flannel
spec:
selector:
matchLabels:
app: flannel
template:
metadata:
labels:
tier: node
app: flannel
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
hostNetwork: true
priorityClassName: system-node-critical
tolerations:
- operator: Exists
effect: NoSchedule
serviceAccountName: flannel
initContainers:
- name: install-cni
image: quay.io/coreos/flannel:v0.14.0
command:
- cp
args:
- -f
- /etc/kube-flannel/cni-conf.json
- /etc/cni/net.d/10-flannel.conflist
volumeMounts:
- name: cni
mountPath: /etc/cni/net.d
- name: flannel-cfg
mountPath: /etc/kube-flannel/
containers:
- name: kube-flannel
image: quay.io/coreos/flannel:v0.14.0
command:
- /opt/bin/flanneld
args:
- --ip-masq
- --kube-subnet-mgr
resources:
requests:
cpu: "100m"
memory: "50Mi"
limits:
cpu: "100m"
memory: "50Mi"
securityContext:
privileged: false
capabilities:
add: ["NET_ADMIN", "NET_RAW"]
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
volumeMounts:
- name: run
mountPath: /run/flannel
- name: flannel-cfg
mountPath: /etc/kube-flannel/
volumes:
- name: run
hostPath:
path: /run/flannel
- name: cni
hostPath:
path: /etc/cni/net.d
- name: flannel-cfg
configMap:
name: kube-flannel-cfg9. 加入node02节点
9.1 准备文件
在node01节点操作
将node01节点中的kubelet.sh文件与proxy.sh文件以及部署cni有关文件的目录，拷贝到node02节点当中
[root@node01 opt]#scp kubelet.sh node02:/opt
[root@node01 opt]#scp proxy.sh node02:/opt
[root@node01 opt]#scp -r cni node02:/opt9.2 启动kubelet
在node02节点上操作
[root@node02 opt]#./kubelet.sh 192.168.44.50
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /usr/lib/systemd/system/kubelet.service.9.3 通过CSR请求
在master节点上操作
[root@master01 k8s]#kubectl get csr #查看请求信息
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q 31s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending
[root@master01 k8s]#kubectl certificate approve node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q #通过请求
certificatesigningrequest.certificates.k8s.io/node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q approved
[root@master01 k8s]#kubectl get csr 查看请求状态
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q 57s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Approved,Issued9.4 加载ipvs模块
在node02节点上操作
[root@node02 opt]#for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i >/dev/null 2>&1 && /sbin/modprobe $i;done
ip_vs_dh
ip_vs_ftp
ip_vs
ip_vs_lblc
ip_vs_lblcr
ip_vs_lc
ip_vs_nq
ip_vs_pe_sip
ip_vs_rr
ip_vs_sed
ip_vs_sh
ip_vs_wlc
ip_vs_wrr
[root@node02 opt]#9.5 启动proxy服务
[root@node02 opt]#./proxy.sh 192.168.44.50
Created symlink from /etc/systemd/system/multi-user.target.wants/kube-proxy.service to /usr/lib/systemd/system/kube-proxy.service.9.6 查看集群节点信息
[root@master01 ~]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.44.50 Ready <none> 8h v1.20.11
192.168.44.60 Ready <none> 7d6h v1.20.1110. 部署CoreDNS
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.44.70 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.44.60 | node01 | kubelet kube-proxy docker etcd集群节点2 flannel coredns | 4G |
| 192.168.44.50 | node02 | kubelet kube-proxy docker etcd集群节点3 flannel coredns | 4G |
CoreDNS：可以为集群中的 service 资源创建一个域名 与 IP 的对应关系解析
1.生成镜像文件
在所有 node 节点上操作
上传 coredns.tar 到 /opt 目录中
[root@node01 opt]#ls coredns.tar
coredns.tar
[root@node01 opt]#docker load -i coredns.tar
#生成镜像文件k8s.gcr.io/coredns
2.部署CoreDNS
在master01节点上操作
上传coredns.yaml文件到 /opt/k8s 目录中，部署 CoreDNS
[root@master01 k8s]#ls coredns.yaml
coredns.yaml
[root@master01 k8s]#kubectl apply -f coredns.yaml
serviceaccount/coredns created
clusterrole.rbac.authorization.k8s.io/system:coredns created
clusterrolebinding.rbac.authorization.k8s.io/system:coredns created
configmap/coredns created
deployment.apps/coredns created
service/kube-dns created
-------------------------------命令行--------------------------------
kubectl
#这是 Kubernetes 的命令行工具，用于与 Kubernetes 集群进行交互。
apply
#这是 kubectl 的一个子命令，用于应用或更新 Kubernetes 集群中的资源。
#与 create 命令不同，apply 命令会尝试应用你提供的定义，但如果资源已经存在并且其配置没有更改，
#那么它通常不会采取任何操作。但如果资源的定义发生了更改，apply 命令会更新该资源以匹配新的定义。
-f coredns.yaml：
-f #这是一个标志，表示你希望从文件中读取资源定义。
coredns.yaml
#这是你希望从中读取资源定义的 YAML 文件的名称。coredns.yaml文件内容
# __MACHINE_GENERATED_WARNING__
apiVersion: v1
kind: ServiceAccount
metadata:
name: coredns
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
kubernetes.io/bootstrapping: rbac-defaults
addonmanager.kubernetes.io/mode: Reconcile
name: system:coredns
rules:
- apiGroups:
- ""
resources:
- endpoints
- services
- pods
- namespaces
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
addonmanager.kubernetes.io/mode: EnsureExists
name: system:coredns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:coredns
subjects:
- kind: ServiceAccount
name: coredns
namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
labels:
addonmanager.kubernetes.io/mode: EnsureExists
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: coredns
#与node节点操作生成的镜像名称一致
namespace: kube-system
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
kubernetes.io/name: "CoreDNS"
spec:
# replicas: not specified here:
# 1. In order to make Addon Manager do not reconcile this replicas parameter.
# 2. Default is 1.
# 3. Will be tuned in real time if DNS horizontal auto-scaling is turned on.
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
selector:
matchLabels:
k8s-app: kube-dns
template:
metadata:
labels:
k8s-app: kube-dns
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
priorityClassName: system-cluster-critical
serviceAccountName: coredns
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values: ["kube-dns"]
topologyKey: kubernetes.io/hostname
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
nodeSelector:
kubernetes.io/os: linux
containers:
- name: coredns
image: k8s.gcr.io/coredns:1.7.0
imagePullPolicy: IfNotPresent
resources:
limits:
memory: 170Mi
requests:
cpu: 100m
memory: 70Mi
args: [ "-conf", "/etc/coredns/Corefile" ]
volumeMounts:
- name: config-volume
mountPath: /etc/coredns
readOnly: true
ports:
- containerPort: 53
name: dns
protocol: UDP
- containerPort: 53
name: dns-tcp
protocol: TCP
- containerPort: 9153
name: metrics
protocol: TCP
livenessProbe:
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:
httpGet:
path: /ready
port: 8181
scheme: HTTP
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- NET_BIND_SERVICE
drop:
- all
readOnlyRootFilesystem: true
dnsPolicy: Default
volumes:
- name: config-volume
configMap:
name: coredns
items:
- key: Corefile
path: Corefile
---
apiVersion: v1
kind: Service
metadata:
name: kube-dns
namespace: kube-system
annotations:
prometheus.io/port: "9153"
prometheus.io/scrape: "true"
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
kubernetes.io/name: "CoreDNS"
spec:
selector:
k8s-app: kube-dns
clusterIP: 10.0.0.2
#DNS解析地址
ports:
- name: dns
port: 53
protocol: UDP
- name: dns-tcp
port: 53
protocol: TCP
- name: metrics
port: 9153
protocol: TCP获取在 kube-system命名空间中的 Pods 的列表
kubectl get pods -n kube-system
3. DNS解析测试
3.1 角色授权
需要添加rbac的权限。直接使用kubectl绑定 clusteradmin 管理员集群角色 ，权操作权限
[root@master01 k8s]#kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous
clusterrolebinding.rbac.authorization.k8s.io/cluster-system-anonymous created #创建成功3.2 解析测试
[root@master01 k8s]#kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
If you don't see a command prompt, try pressing enter.
/ # nslookup kubernetes #解析kubernetes,这是
Server: 10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: kubernetes
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local解释：
kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
#这个命令是在 Kubernetes 集群中运行一个临时的 Pod，并立即连接到它的一个容器来执行一个命令
#kubectl run: 这是 kubectl 的一个子命令，用于在集群中运行一个新的容器化的应用
#-it: 这两个标志组合在一起。-i 表示“交互式”
#--rm: 这个标志告诉 Kubernetes 在 Pod 退出后自动删除它
#dns-test: 自定义Pod名称
#--image=busybox:1.28.4: 指定要运行的容器的镜像和版本。BusyBox 是一个非常小的 Linux 实用程序集，通常用于嵌入式系统或作为 Docker 容器的基础镜像。
#sh: 这是你希望在容器内部执行的命令
3.3 查看地址
[root@master01 k8s]#kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 41h解释：
- NAME：服务的名称。
- TYPE：服务的类型，如 ClusterIP、NodePort、LoadBalancer、ExternalName 等。
- CLUSTER-IP：服务的集群内部 IP 地址（仅当服务类型为 ClusterIP 或 LoadBalancer 时显示）。
- EXTERNAL-IP：服务的外部 IP 地址（仅当服务类型为 LoadBalancer 时显示）。
- PORT(S)：服务暴露的端口。
- AGE：服务自创建以来已经存在的时间。
11. 部署master02节点
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.44.70 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.44.10 | master02 | kube-apiserver kube-controller-manager kube-scheduler | 4G |
| 192.168.44.60 | node01 | kubelet kube-proxy docker etcd集群节点2 flannel coredns | 4G |
| 192.168.44.50 | node02 | kubelet kube-proxy docker etcd集群节点3 flannel coredns | 4G |
1.准备文件
在master01节点上操作
将有关配置文件，全部拷贝到master02节点上
[root@master01 k8s]#scp -r /opt/etcd/ master02:/opt
#etcd相关文件
[root@master01 k8s]#scp -r /opt/kubernetes/ master02:/opt
#kubernetes相关文件，包含执行文件与配置文件
[root@master01 k8s]#scp -r /root/.kube master02:/root
#kubernetes集群配置文件。在执行admin.sh脚本生成
[root@master01 k8s]#scp /usr/lib/systemd/system/{kube-apiserver,kube-controller-manager,kube-scheduler}.service master02:/usr/lib/systemd/system/
#system管理文件2. 修改配置文件
在master02节点上操作
修改配置文件kube-apiserver中的IP
[root@master02 opt]#vim /opt/kubernetes/cfg/kube-apiserver
1 KUBE_APISERVER_OPTS="--logtostderr=false \
2 --v=2 \
3 --log-dir=/opt/kubernetes/logs \
4 --etcd-servers=https://192.168.44.70:2379,https://192.168.44.60:2379,https://192.168.44.50:2379 \
5 --bind-address=192.168.44.10 \ #修改为本机IP
6 --secure-port=6443 \
7 --advertise-address=192.168.44.10 \ #修改为本机IP
8 --allow-privileged=true \
9 --service-cluster-ip-range=10.0.0.0/24 \
.......3.启动服务
在 master02 节点 上启动各服务并设置开机自启
[root@master02 opt]#systemctl start kube-apiserver.service
[root@master02 opt]#systemctl enable kube-apiserver.service
[root@master02 opt]#systemctl start kube-controller-manager.service
[root@master02 opt]#systemctl enable kube-controller-manager.service
[root@master02 opt]#systemctl start kube-scheduler.service
[root@master02 opt]#systemctl enable kube-scheduler.service4.查看node节点状态
[root@master02 opt]#ln -s /opt/kubernetes/bin/* /usr/local/bin/
[root@master02 opt]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.44.60 Ready <none> 37h v1.20.11
192.168.44.50 Ready <none> 23h v1.20.11
[root@master02 opt]#
[root@master02 opt]#kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
192.168.44.60 Ready <none> 37h v1.20.11 192.168.83.50 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://26.1.2
192.168.44.50 Ready <none> 23h v1.20.11 192.168.83.60 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://26.1.2
#-o=wide：输出额外信息；对于Pod，将输出Pod所在的Node名12. 负载均衡
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.44.70 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.44.10 | master02 | kube-apiserver kube-controller-manager kube-scheduler | 4G |
| 192.168.44.60 | node01 | kubelet kube-proxy docker etcd集群节点2 flannel coredns | 4G |
| 192.168.44.50 | node02 | kubelet kube-proxy docker etcd集群节点3 flannel coredns | 4G |
| 192.168.44.40 | nginx01 | nginx-1.18.0 keepalived | 2G |
| 192.168.44.30 | nginx02 | nginx-1.18.0 keepalived | 2G |
| 192.168.44.200 | VIP |
此时在master02节点查到的node节点状态仅是从etcd查询到的信息，而此时node节点实际上并未与master02节点建立通信连接，因此需要使用一个VIP把node节点与master节点都关联起来
通过nignx服务进行负载关联
注意：在生成master公私钥以及证书的时候，指定了nignx的地址与VIP地址，在安装nginx服务时，需要在对应地址上进行安装，以及使用的VIP地址也是设置为指定的IP地址
1.安装nginx
可以通过搭建nginx的yum仓库、使用epel源或者编译安装的方式安装nginx
首先在nginx01上进行操作
脚本编译安装nginx
#/bin/bash
systemctl start nginx >>/dev/null
if [ $? -eq 0 ];then
echo "nginx服务已安装"
else
useradd -M -s /sbin/nologin nginx
cd /opt
wget http://nginx.org/download/nginx-1.18.0.tar.gz >>/dev/null
echo "正在安装，请耐心等待"
tar xf nginx-1.18.0.tar.gz
cd /opt/nginx-1.18.0
yum -y install gcc pcre-devel openssl-devel zlib-devel openssl openssl-devel &>>/dev/null
./configure --prefix=/usr/local/nginx \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-pcre \
--with-stream \ #编译steram模块
--with-stream_ssl_module \
--with-stream_realip_module
make -j `lscpu|sed -n '4p'|awk '{print $2}'`&>>/dev/null
make install &>>/dev/null
ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/
cat > /usr/lib/systemd/system/nginx.service <<EOF
[Unit]
Description=nginx
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/bin/kill -1 $MAINPID
ExecStop=/bin/kill -3 $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target
EOF
chown -R nginx.nginx /usr/local/nginx
systemctl daemon-reload &>>/dev/null
systemctl enable --now nginx
echo "nginx服务已开启"
fi2.添加代理信息
[root@nginx01 opt]#vim /usr/local/nginx/conf/nginx.conf
......
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status
$upstream_bytes_sent';
#自定义日志格式
access_log /usr/local/nginx/logs/k8s-access.log main;
#自定义日志存放路径
upstream kubernetes {
server 192.168.44.70:6443;
server 192.168.44.10:6443;
}
#定义代理目标，为两台master的6443端口，即apiserver的监听端口
server {
listen 6443;
proxy_pass kubernetes;
}
}
http {
include mime.types;
......
[root@nginx01 opt]#systemctl restart nginx.service
#重启服务
[root@nginx01 opt]#netstat -natp | grep nginx #查看监听端口
tcp 0 0 0.0.0.0:6443 0.0.0.0:* LISTEN 6731/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6731/nginx: master 在nginx02机器上同样操作
[root@nginx02 opt]#bash nginx.sh #安装nginx服务
[root@nginx02 opt]#vim /usr/local/nginx/conf/nginx.conf
......
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status
$upstream_bytes_sent';
access_log /usr/local/nginx/logs/k8s-access.log main;
upstream kubernetes {
server 192.168.44.70:6443;
server 192.168.44.10:6443;
}
server {
listen 6443;
proxy_pass kubernetes;
}
}
[root@nginx02 opt]#systemctl restart nginx3.实现nginx高可用
首先在nginx01机器上进行操作
做高可用之前，首先需要停止nginx服务
[root@nginx01 opt]#systemctl stop nginx3.1 下载keepalived
[root@nginx01 opt]#yum install keepalived -y3.2 修改keepalived配置文件
[root@nginx01 opt]#vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
notification_email_from [email protected]
smtp_server 127.0.0.1 #邮箱地址设置为本地IP地址
smtp_connect_timeout 30
router_id nginx01 #自定义名称，主备不同相同
vrrp_skip_check_adv_addr
# vrrp_strict #注释或者删除
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_script nginx_test { #使用script模块，并自定义名称为nginx_test
script "/usr/loca/nginx/conf/nginx_test.sh"
#指定要执行的shell脚本路径，通过脚本，判断nginx状态。
#这个脚本应该返回0表示成功，意味着nginx服务停止；非零值表示失败，nginx服务正常运行
interval 1 #设置每隔1秒执行一次该脚本以检查服务状态
timeout 30 #如果脚本在30秒内没有响应（即超时），则认为它执行失败
weight -50 #当脚本执行成功时，VRRP实例的优先级权重减50
fall 3 #当连续3次检查失败后，将触发VRRP实例状态变更，可能导致主备切换
rise 3 #当连续3次检查成功后，恢复VRRP实例到正常状态
}
vrrp_instance VI_1 {
state MASTER #设置为MASTER表示为主
interface ens33 #指定心跳报文从ens33网卡发送
virtual_router_id 51 #实例表示符，默认即可，BACKUP与其一致
priority 100 #设置优先级，其值需要比BACKUP高
advert_int 1 #每间隔一秒发送一次VRRP报文
authentication { #定义密码认证方式，并设置密码，BACKUP需要与其一致
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.44.200/24 #设置集群VIP地址
}
track_script {
nginx_test.sh #调用脚本模块nginx_test.sh
}
} 3.3 添加脚本文件
[root@nginx01 opt]#vim /usr/local/nginx/conf/nginx_test.sh
#注意文件要与keepalived配置文件中script定义的路径、名称一致
[root@nginx01 opt]#cat /usr/local/nginx/conf/nginx_test.sh
#!/bin/bash
killall -0 nginx
#脚本表示使用killall -0，
#这是Linux命令行中用于检查指定进程名是否存在且至少有一个实例在运行的命令。
#这里的参数 -0 具有特殊含义，它不会发送任何信号给进程，而是仅仅测试这些进程是否存在
[root@nginx01 opt]#chmod +x /usr/local/nginx/conf/nginx_test.sh
#给脚本添加执行权限将脚本文件以及配置文件远程复制到nginx02机器上，并进行修改
[root@nginx01 opt]#scp /etc/keepalived/keepalived.conf 192.168.44.30:/etc/keepalived/keepalived.conf
[root@nginx01 opt]#scp /usr/local/nginx/conf/nginx_test.sh 192.168.44.30:/usr/local/nginx/conf/在nginx02上操作
另一台nginx02服务器与其配置一致，需要修改优先级、state、router_id信息
[root@nginx02 opt]#vim /etc/keepalived/keepalived.conf
.......
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id nginx02 #修改为与MASTER不同的标识符
vrrp_skip_check_adv_addr
# vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_script nginx_test {
script "/usr/local/nginx/conf/nginx_test.sh"
interval 1
timeout 30
weight -50
fall 3
rise 3
}
vrrp_instance VI_1 {
state BACKUP #设置状态为BACKUP，表示此主机为备
interface ens33
virtual_router_id 51
priority 80
#设置优先为80，需要比MASTER的优先级低
#且在MASTER的测试脚本执行成功，减去设定的优先级数值，此数值需要比它大
advert_int 1
.......3.4 启动服务
在两台nginx的服务器上进行操作
nginx01启动服务
[root@nginx01 opt]#systemctl start nginx #先启动nginx服务
[root@nginx01 opt]#systemctl start keepalived.service #再启动keepalived服务
[root@nginx02 opt]#systemctl enable keepalived查看VIP是否生成
ip a #查看nginx02启动服务
[root@nginx02 opt]#systemctl start nginx
[root@nginx02 opt]#systemctl start keepalived.service
[root@nginx02 opt]#systemctl enable keepalived4.修改node节点文件
修改node节点上的bootstrap.kubeconfig,kubelet.kubeconfig配置文件为VIP
首先再node01服务器上操作
[root@node01 opt]#vim /opt/kubernetes/cfg/bootstrap.kubeconfig
[root@node01 opt]#sed -n '5p' /opt/kubernetes/cfg/bootstrap.kubeconfig
server: https://192.168.44.200:6443
#修改kubelet初次加入集群引导kubeconfig文件,即bootstrap.kubeconfig
[root@node01 opt]#vim /opt/kubernetes/cfg/kubelet.kubeconfig
[root@node01 opt]#sed -n '5p' /opt/kubernetes/cfg/kubelet.kubeconfig
server: https://192.168.44.200:6443
#修改kubelet配置文件
[root@node01 opt]#vim /opt/kubernetes/cfg/kube-proxy.kubeconfig
[root@node01 opt]#sed -n '5p' /opt/kubernetes/cfg/kube-proxy.kubeconfig
server: https://192.168.44.200:6443
#修改proxy配置文件修改完毕后重新启动服务
[root@node01 opt]#systemctl restart kubelet.service
[root@node01 opt]#systemctl restart kube-proxy.service在node02节点上操作
[root@node02 opt]#vim /opt/kubernetes/cfg/bootstrap.kubeconfig
[root@node02 opt]#sed -n '5p' /opt/kubernetes/cfg/bootstrap.kubeconfig
server: https://192.168.44.200:6443
[root@node02 opt]#vim /opt/kubernetes/cfg/kubelet.kubeconfig
[root@node02 opt]#sed -n '5p' /opt/kubernetes/cfg/kubelet.kubeconfig
server: https://192.168.44.200:6443
[root@node02 opt]#vim /opt/kubernetes/cfg/kube-proxy.kubeconfig
[root@node02 opt]#sed -n '5p' /opt/kubernetes/cfg/kube-proxy.kubeconfig
server: https://192.168.44.200:64435.查看连接状态
在nginx01节点操作
在nginx01节点上，即master，查看nginx和 node 、master节点的连接状态
[root@nginx01 opt]#netstat -natp | grep nginx6.进行测试
在master01节点上操作
6.1 测试创建pod
[root@master01 k8s]#kubectl run nginx --image=nginx
pod/nginx created6.2 查看pod状态
[root@master01 k8s]#kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 0/1 ContainerCreating 0 8s
#ContainerCreating表示正在创建
[root@master01 k8s]#kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 66s
#Running表示创建成功并正在运行
[root@master01 k8s]#kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 3m29s 10.244.0.2 192.168.44.60 <none> <none>
#NAME：表示Pod的名称是nginx
#READY：Pod中的容器数量与期望运行的容器数量之比，1/1表示Pod中有一个容器，并且这个容器已经准备好了
#STATUS：Pod的当前状态是Running，表示Pod正在运行
#RESTARTS：Pod中的容器已经重启的次数。这里显示为0，表示容器没有重启过
#AGE：Pod已经运行的时长
#IP：Pod 在集群中的IP地址是10.244.0.2，通常用于集群内部的服务发现和通信
#NODE：Pod正在运行的节点IP地址是 192.168.44.60。这表示Pod被调度到了IP地址为 192.168.44.60的 Kubernetes节点上
#NOMINATED NODE：这里显示为 <none>，表示没有为 Pod 指定备选的节点。在某些情况下，例如当 Pod 调度失败时，调度器可能会选择一个备选的节点，并在稍后的时间尝试重新调度 Pod 到这个备选的节点上。
#READINESS GATES：这里也显示为 <none>，表示没有设置就绪门控（Readiness Gates）。就绪门控是一种用于控制 Pod 就绪性的机制，它允许你根据自定义的条件来决定 Pod 是否被视为就绪6.3 访问pod
在对应网段的node节点上进行访问
6.4 查看日志
在master01节点上使用kubectl logs 指令查看你信息
在master02节点上同样可以进行操作
13. 部署Dashboard
1.基本介绍
Kubernetes Dashboard 是一个基于Web的交互式界面，用于管理和监控Kubernetes集群。它是Kubernetes官方提供的组件之一，可以帮助用户更轻松地管理和操作Kubernetes集群中的各种资源和服务。
Kubernetes Dashboard提供了一种直观的方式来查看和管理Kubernetes集群的状态和资源。它提供了一个集中式的仪表板，可以显示集群中的节点、部署、服务、副本集等各种资源的信息。通过这个仪表板，用户可以方便地进行资源的创建、删除、修改等操作，以及监控资源的运行状态和性能指标
关于Kubernetes Dashboard的部署和使用
部署Kubernetes Dashboard：通过执行相应的命令（如使用kubectl apply命令和Dashboard的YAML文件）来部署Dashboard。
启动Kubernetes Dashboard：使用kubectl proxy命令启动Dashboard的代理服务
访问Kubernetes Dashboard：通过浏览器访问Dashboard的URL（通常是localhost的某个端口），并使用相应的令牌进行登录。
2.部署Dashboard
2.1 准备文件
上传recommended.yaml 文件到master01节点/opt/k8s 目录中
[root@master01 k8s]#ll -h recommended.yaml
-rw-r--r-- 1 root root 7.5K 11月 8 2021 recommended.yaml上传 dashboard.tar 与 metrics-scraper.tar 包到node01节点与node02节点的/opt/目录下,用于生成镜像文件
dashboard:
Kubernetes Dashboard 是一个基于 Web 的用户界面，用于管理 Kubernetes 集群。通过 Dashboard，用户可以查看集群的状态、管理资源（如部署、Pod、服务等）、以及查看集群的日志和事件。
metrics-scraper:
在 Kubernetes Dashboard 中，Metrics Scraper 是一个用于从 Kubernetes 集群中收集度量数据（如 Pod 和节点的 CPU、内存使用情况）的组件。这些数据然后可以在 Dashboard 中显示，帮助用户更好地了解集群的状态和性能。
[root@node01 opt]#ll -h dashboard.tar metrics-scraper.tar
-rw-r--r--. 1 root root 215M 1月 17 2022 dashboard.tar
-rw-r--r--. 1 root root 36M 1月 17 2022 metrics-scraper.tar2.2 生成镜像
在node01节点上操作
[root@node01 opt]#docker load -i dashboard.tar
69e42300d7b5: Loading layer [==================================================>] 224.6MB/224.6MB
Loaded image: kubernetesui/dashboard:v2.0.0
[root@node01 opt]#docker load -i metrics-scraper.tar
57757cd7bb95: Loading layer [==================================================>] 238.6kB/238.6kB
14f2e8fb1e35: Loading layer [==================================================>] 36.7MB/36.7MB
52b345e4c8e0: Loading layer [==================================================>] 2.048kB/2.048kB
Loaded image: kubernetesui/metrics-scraper:v1.0.4
[root@node01 opt]#docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest e784f4560448 11 days ago 188MB
quay.io/coreos/flannel v0.14.0 8522d622299c 2 years ago 67.9MB
k8s.gcr.io/coredns 1.7.0 bfe3a36ebd25 3 years ago 45.2MB
kubernetesui/dashboard v2.0.0 8b32422733b3 4 years ago 222MB
kubernetesui/metrics-scraper v1.0.4 86262685d9ab 4 years ago 36.9MB
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64 3.0 99e59f495ffa 8 years ago 747kB在node02节点上操作
[root@node02 opt]#docker load -i dashboard.tar
69e42300d7b5: Loading layer [==================================================>] 224.6MB/224.6MB
Loaded image: kubernetesui/dashboard:v2.0.0
[root@node02 opt]#docker load -i metrics-scraper.tar
57757cd7bb95: Loading layer [==================================================>] 238.6kB/238.6kB
14f2e8fb1e35: Loading layer [==================================================>] 36.7MB/36.7MB
52b345e4c8e0: Loading layer [==================================================>] 2.048kB/2.048kB
Loaded image: kubernetesui/metrics-scraper:v1.0.4
[root@node01 opt]#docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest e784f4560448 11 days ago 188MB
quay.io/coreos/flannel v0.14.0 8522d622299c 2 years ago 67.9MB
k8s.gcr.io/coredns 1.7.0 bfe3a36ebd25 3 years ago 45.2MB
kubernetesui/dashboard v2.0.0 8b32422733b3 4 years ago 222MB
kubernetesui/metrics-scraper v1.0.4 86262685d9ab 4 years ago 36.9MB
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64 3.0 99e59f495ffa 8 years ago 747kB2.3 修改yaml文件
在master01节点上操作
修改 recommended.yaml文件
默认Dashboard只能集群内部访问，修改Service为NodePort类型，暴露到外部
apiVersion: v1
kind: Namespace
metadata:
name: kubernetes-dashboard
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
ports:
- port: 443
targetPort: 8443
nodePort: 30001 #自定义对外端口
type: NodePort #修改类型
selector:
k8s-app: kubernetes-dashboard
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-certs
namespace: kubernetes-dashboard
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-csrf
namespace: kubernetes-dashboard
type: Opaque
data:
csrf: ""
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-key-holder
namespace: kubernetes-dashboard
type: Opaque
---
kind: ConfigMap
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-settings
namespace: kubernetes-dashboard
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
rules:
# Allow Dashboard to get, update and delete Dashboard exclusive secrets.
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs", "kubernetes-dashboard-csrf"]
verbs: ["get", "update", "delete"]
# Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["kubernetes-dashboard-settings"]
verbs: ["get", "update"]
# Allow Dashboard to get metrics.
- apiGroups: [""]
resources: ["services"]
resourceNames: ["heapster", "dashboard-metrics-scraper"]
verbs: ["proxy"]
- apiGroups: [""]
resources: ["services/proxy"]
resourceNames: ["heapster", "http:heapster:", "https:heapster:", "dashboard-metrics-scraper", "http:dashboard-metrics-scraper"]
verbs: ["get"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
rules:
# Allow Metrics Scraper to get metrics from the Metrics server
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: kubernetes-dashboard
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: kubernetes-dashboard
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kubernetes-dashboard
template:
metadata:
labels:
k8s-app: kubernetes-dashboard
spec:
containers:
- name: kubernetes-dashboard
image: kubernetesui/dashboard:v2.0.0
imagePullPolicy: Always
ports:
- containerPort: 8443
protocol: TCP
args:
- --auto-generate-certificates
- --namespace=kubernetes-dashboard
# Uncomment the following line to manually specify Kubernetes API server Host
# If not specified, Dashboard will attempt to auto discover the API server and connect
# to it. Uncomment only if the default does not work.
# - --apiserver-host=http://my-address:port
volumeMounts:
- name: kubernetes-dashboard-certs
mountPath: /certs
# Create on-disk volume to store exec logs
- mountPath: /tmp
name: tmp-volume
livenessProbe:
httpGet:
scheme: HTTPS
path: /
port: 8443
initialDelaySeconds: 30
timeoutSeconds: 30
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 1001
runAsGroup: 2001
volumes:
- name: kubernetes-dashboard-certs
secret:
secretName: kubernetes-dashboard-certs
- name: tmp-volume
emptyDir: {}
serviceAccountName: kubernetes-dashboard
nodeSelector:
"kubernetes.io/os": linux
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: dashboard-metrics-scraper
name: dashboard-metrics-scraper
namespace: kubernetes-dashboard
spec:
ports:
- port: 8000
targetPort: 8000
selector:
k8s-app: dashboard-metrics-scraper
---
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: dashboard-metrics-scraper
name: dashboard-metrics-scraper
namespace: kubernetes-dashboard
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: dashboard-metrics-scraper
template:
metadata:
labels:
k8s-app: dashboard-metrics-scraper
annotations:
seccomp.security.alpha.kubernetes.io/pod: 'runtime/default'
spec:
containers:
- name: dashboard-metrics-scraper
image: kubernetesui/metrics-scraper:v1.0.4
ports:
- containerPort: 8000
protocol: TCP
livenessProbe:
httpGet:
scheme: HTTP
path: /
port: 8000
initialDelaySeconds: 30
timeoutSeconds: 30
volumeMounts:
- mountPath: /tmp
name: tmp-volume
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 1001
runAsGroup: 2001
serviceAccountName: kubernetes-dashboard
nodeSelector:
"kubernetes.io/os": linux
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
volumes:
- name: tmp-volume
emptyDir: {}2.4 创建资源
[root@master01 k8s]#kubectl apply -f recommended.yaml
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created
----------------------------命令行-------------------------------
kubectl #Kubernetes 命令行工具，用于与 Kubernetes 集群进行交互。
apply #该子命令用于应用或更新一个或多个资源。
#apply 命令使用资源定义文件来确定资源的最终状态。
#如果资源已存在，apply会更新它以匹配文件中定义的状态；如果资源不存在，apply会创建它
-f recommended.yaml:
-f #标志后面跟着的是资源定义文件的路径
recommended.yaml #资源定义文件。包含Kubernetes资源的定义，如Deployments、Services、Pods、ConfigMaps等。2.5 创建服务账户
创建service account并绑定默认cluster-admin管理员集群角色
kubectl create serviceaccount dashboard-admin -n kube-system
#kubectl create：创建
#ServiceAccount：创建类型为服务账号
#dashboard-admin：创建服务账号名称，一般为dashboard-admin，具有管理员权限的服务账号
#-n kube-system：指定命名空间kube-system
'命令含义'
#在kube-system命名空间中创建了一个名为dashboard-admin的ServiceAccount(服务账号)
#ServiceAccount是Kubernetes中用于Pod访问API资源的身份。
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
#kubectl create：创建资源
#clusterrolebinding：用于将ClusterRole绑定到一个或多个服务账号、用户或者组，从而授予它们对集群中资源的访问权限
#dashboard-admin：创建的ClusterRoleBinding的自定义名称，在整个集群中必须是唯一的
#--clusterrole=cluster-admin：标志，用于指定要绑定的ClusterRole的名称
#--serviceaccount=kube-system:dashboard-admin：标志，用于指定服务账号的名称和命名空间
'命令含义'
#这个命令创建了一个ClusterRoleBinding，将cluster-admin这个ClusterRole绑定到kube-system命名空间中的dashboard-admin这个ServiceAccount上。
#cluster-admin是一个预定义的ClusterRole，它拥有集群中几乎所有的权限。这意味着与dashboard-admin这个ServiceAccount关联的Pod将能够执行集群中的任何操作。2.6 列出令牌的详细信息
列出令牌详细信。获取token输出的内容，用于登录dashboard
kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')
#kubectl -n kube-system get secret：列出kube-system命名空间中的所有secrets。
'Secret 是 Kubernetes 中的一个资源对象，用于存储敏感信息，如密码、OAuth令牌和SSH密钥。
这些信息可以以明文或加密的形式存储在Secret中，通常它们会被Base64编码以符合Secret的数据格式'
#awk '/dashboard-admin/{print $1}'：
使用awk命令过滤输出，只打印与dashboard-adminServiceAccount相关的secret的名称
#默认是dashboard-admin-token-xxxxx，其中xxxxx是一个随机字符串。
kubectl describe secrets -n kube-system $(...)：
#使用上一步得到的secret名称，描述这个secret的详细信息。
#这通常包括secret的类型（在这种情况下是kubernetes.io/service-account-token），
#以及与ServiceAccount关联的token（这个token通常用于身份验证和授权）。3.登录Dashboard
3.1 访问界面
使用浏览器访问https://NodeIP:30001
https://192.168.44.60:30001/
3.2 创建pod
在shell环境使用命令查看
