03 - 部署K8S v1.28 + Docker Engine v24.0.5

kubeadm安装部署K8S v1.28 + Docker Engine v24.0.5

朱小胖的幸福生活

1044人浏览 · 2024-01-03 14:30:55

朱小胖的幸福生活 · 2024-01-03 14:30:55 发布

1 部署环境确认

1.1 机器环境

序号	ip	主机名	配置
1	192.168.217.129	master-01	4c4g
2	192.168.217.128	slave-01	4c4g

本次是测试部署，单点部署，且资源较少，如果是生产环境一般要高可用部署，且是16c32g或者32c64g的资源规格，具体看情况而定。

1.2 端口信息

1.2.1 master节点

协议	端口	监听者
TCP	6443、8080	apiserver
TCP	10251	scheduler
TCP	10252	controll-manager
TCP	2379、2380	Etcd

小知识1：

api server是k8s集群的入口，默认有两个端口：6443、8080

localhost:8080 非安全端口（不需要认证，没有加入认证机制），执行kubectl的话默认先连接8080，如果你配置了kubeconfig（.kube/config）就直接走这个配置连接的安全端口（如果在master上没有8080端口，那么就直接走kubeconfig指定的地址）
masterip:6443 安全端口，提供了内部授权的机制，比如登入网站想要输入用户名密码才能登入。

另外要知道，kubeadm安装的默认禁用了8080端口，二进制安装默认是启用的。关闭8080端口就是希望你使用配置文件去连接安全端口，这样是安全的，非安全端口是绝对不能对外提供服务的，如果对外提供服务别人扫描到你api做一些恶意的操作，整个集群可能就挂了，即使有这个端口也是监听在本地，也就是只能这台机器去连接。

小知识2：

ETCD默认监听的两个端口：2379、2380，它们之间的区别如下：

2379：这是用于etcd和客户端通信的端口，用于处理客户端的读取和写入请求。比如当apiserver程序与etcd通信就是使用的这个端口。
2380：这是在etcd集群环境中，etcd节点之间互相通信的端口。在etcd集群中，各个节点之间需要进行通信，像数据的复制和同步操作就是使用的这个端口。

因此，端口2379主要用于应用程序与etcd之间的通信，而端口2380主要用于etcd集群内部节点之间的通信和数据同步。这两个端口在etcd集群中发挥着不同但同样重要的作用。

1.2.2 slave节点

协议	端口	监听者	备注
TCP	10250	kubelet
TCP	30000-32767	NodePort

2 准备环境

2.0 配置主机网络 - 所有节点

# Centos7中，可以使用network（静态）或者NetworkManager（动态）来管理宿主机网络，但两者不能同时存在，否则会带来一些冲突报错，因此如果你选择使用network的话，就要把NetworkManager给关闭掉。
# 再多说一点，在Centos8中，官方默认只能通过NetworkManager.service(简称NM)进行网络配置（依然支持network.service,只是默认没有安装）。

# 关闭NetworkManager
[root@localhost ~]# systemctl stop NetworkManager
[root@localhost ~]# systemctl disable NetworkManager 

# 手动修改网络配置文件
[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens33 
TYPE="Ethernet"
BOOTPROTO=static
DEFROUTE="yes"
NAME="ens33"
DEVICE="ens33"
ONBOOT="yes"
IPADDR=192.168.217.129
NETMASK=255.255.255.0
GATEWAY=192.168.217.2
DNS1=8.8.8.8   # 需要添加dns，否则coredns等可能会报错；

# 重启
[root@localhost ~]# systemctl restart network

2.1 修改主机名及配置解析 - 所有节点

# hostnamectl set-hostname 主机名
# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.217.129 master-01
192.168.217.128 slave-01

2.2 关闭selinux - 所有节点

# sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config      # 永久
# setenforce 0       # 临时

2.3 关闭firewalld+安装iptables服务并保存为空规则 - 所有节点

# systemctl stop firewalld && systemctl disable firewalld

# yum install iptables-services -y   #安装iptables工具
# systemctl restart iptables  && systemctl enable iptables

# iptables -F && iptables -F -t nat && iptables -F -t mangle  && iptables -F -t raw

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[  OK  ]

2.4 时间同步 - 所有节点

2.5 准备yum源 - 所有节点

在centos默认源的基础上再加上以下两个yum源：

# vim /etc/yum.repos.d/kubernetes.repo
[k8s]
name=k8s
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=0

# wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo

2.6 关闭swap - 所有节点

kubernetes1.8开始，不关闭swap无法启动：

# 临时关闭
# swapoff -a   

# 打开fstab文件将swap那一行注释保存
# vim /etc/fstab
UUID=38182b36-9be4-45f8-9b3f-f9b3605fcdf0 /                       xfs     defaults        0 0
UUID=6b69e04f-4a85-4612-b1c0-24939fd84962 /boot                   xfs     defaults        0 0
#UUID=9ba6a188-d8e1-4983-9abe-ba4a29b1d138 swap                    swap    defaults        0 0

2.7 开启流量转发功能 - 所有节点

Linux系统出于安全考虑，默认是禁止数据包转发的，但如果不开启的话，我们部署的k8s集群会出现流量路由不通的问题，因此，所有节点需要做如下操作：

# modprobe可以加载指定的模块，lsmod用于检测模块儿是否启用
# modprobe br_netfilter
# lsmod |grep br_netfilter

# cat > /etc/sysctl.d/k8s.conf <<EOF    #或者加到/etc/sysctl.conf主配置文件中
net.ipv4.ip_forward = 1
vm.swappiness = 0
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF


# sysctl -p /etc/sysctl.d/k8s.conf

点击这里，了解br_netfiler与net.bridge.bridge-nf-call-iptables的作用。

2.8 设置kube-proxy开启ipvs的前置条件 - 所有节点

由于ipvs已经加入到了内核的主干，所以为kube-proxy开启ipvs的前提是需要加载以下的内核模块：

# cat > /etc/sysconfig/modules/ipvs.modules <<EOF
modprobe ip_vs
modprobe ip_vs_rr
modprobe ip_vs_wrr
modprobe ip_vs_sh
modprobe nf_conntrack_ipv4
EOF

# chmod 755 /etc/sysconfig/modules/ipvs.modules
# sh /etc/sysconfig/modules/ipvs.modules
# lsmod |egrep 'ip_vs|nf_conntrack'

3 安装软件

3.1 安装docker - 所有节点

# yum -y install docker-ce-24.0.5-1.el7
# systemctl start docker && systemctl enable docker

3.2 安装cri-dockerd - 所有节点

因为 dockershim 组件在 Kubernetes v1.24 之后的发行版本中已被移除，因此，如果想在新版本 Kubernetes 集群中继续使用 Docker Engine 的话，需要安装一个三方的替代品 cri-dockerd ，该组件会实现 dockershim 的能力。

点击这里，查看 cri-dockerd 官方地址。

# wget https://github.com/Mirantis/cri-dockerd/releases/download/v0.3.4/cri-dockerd-0.3.4-3.el7.x86_64.rpm
# rpm -ivh cri-dockerd-0.3.4-3.el7.x86_64.rpm


# 启动之前，先修改pause镜像地址，默认的镜像地址"registry.k8s.io/pause:3.6" 可能会拉取报错。
# cat /usr/lib/systemd/system/cri-docker.service
ExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd:// --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.9


# 启动cri-dockerd
# systemctl daemon-reload 
# systemctl enable cri-docker.socket cri-docker 
# systemctl start cri-docker.socket cri-docker 
# systemctl status cri-docker.socket

3.3 配置加速器-所有节点

# vim /etc/docker/daemon.json
{
   "registry-mirrors": ["https://42h8kzrh.mirror.aliyuncs.com"],
   "exec-opts": ["native.cgroupdriver=systemd"]
}

# 重启docker服务
# systemctl daemon-reload
# systemctl restart docker

3.4 安装kubelet、kubeadm、kubectl - 所有节点

安装好之后，enable kubelet服务（注意：不要start启动）。

# yum install kubelet-1.28.1-0 kubeadm-1.28.1-0 kubectl-1.28.1-0 -y
# systemctl enable kubelet

注释：

管理节点：apiserver、scheduler，controller-manager（这三个组件都是pod部署，也就是封装在kubeadm里面了）
工作节点：kubelet、kube-proxy（kube-proxy也是pod部署，kubelet需要单独部署并且由systemd管理）

3.5 初始化集群 - master节点

[root@master-01 ~]# kubeadm init \
--kubernetes-version=1.28.1 \
--apiserver-advertise-address=192.168.217.129 \
--image-repository registry.aliyuncs.com/google_containers \
--service-cidr=10.2.0.0/16 \
--pod-network-cidr=10.3.0.0/16 \
--cri-socket unix:///var/run/cri-dockerd.sock

注释：
– apiserver-advertise-address # 指定API Server组件的地址；
–image-repository # 指定阿里的镜像仓库地址，因为管理节点和工作节点的部分组件是封装到kubeadm工具中的，等会启动的时候，它默认会从国外的源下载镜像，所以这里为了加快速度指定为国内源；
–kubernetes-version # 指定k8s的版本，你刚才yum安装的什么版本，你就指定什么版本；
–service-cidr # svc网段，可以选择一个本机网络和PodCIDR都没有用到的私网地址段；
–pod-network-cidr # pod网段，可以选择一个本机网络和service-cidr都没有用到的私网地址段；

下面，分析下kubeadm init执行了哪些操作：

[root@master-01 ~]# kubeadm init --kubernetes-version=1.28.1 --apiserver-advertise-address=192.168.217.129 --image-repository registry.aliyuncs.com/google_containers --service-cidr=10.2.0.0/16 --pod-network-cidr=10.3.0.0/16 --cri-socket unix:///var/run/cri-dockerd.sock
[init] Using Kubernetes version: v1.28.1
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local master-01] and IPs [10.2.0.1 192.168.217.129]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost master-01] and IPs [192.168.217.129 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost master-01] and IPs [192.168.217.129 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 6.013322 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node master-01 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node master-01 as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: fjhqux.4jdbz5y6xg2qv5xk
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

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/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.217.129:6443 --token fjhqux.4jdbz5y6xg2qv5xk \
        --discovery-token-ca-cert-hash sha256:cf314fd4e2f85b2e3a4fd56e6235c2828cee8ef55b4a8b757722747549638819

对kubeadm init 反馈的信息，进行逐行分析：
1、[preflight] 检查环境是否满足条件，比如swap分区有没有关闭等等
2、[certs] /etc/kubernetes/pki 生成apiserver和etcd两套证书（二进制部署也需要这两套证书，如果kubeadm工具部署的话就直接帮你做了）；
3、[kubeconfig] 生成连接api server的配置文件，记住，只要是[kubeconfig]，那里面一定是用于连接apiserver的配置文件，所以，你在初始化信息中可以看到，生成的admin.conf、kubelet.conf、controller-manager.conf、scheduler.conf配置文件，就是用来让其他组件连接API Server组件使用的，配置文件里面包含了连接API Server组件需要用到的认证信息等，连接API Server组件不是谁想连就能连的，所以也可以说生成的*.conf是连接API Server组件用的授权文件。
4、[etcd] 创建etcd的静态pod并启动etcd；
5、[control-plane] 控制平面的静态Pod管理，/etc/kubernetes/manifests 是静态Pod 的路径，静态Pod 是由 kubelet 组件管理的，它不受 k8s管理节点的控制，kubelet 组件会去监控/etc/kubernetes/manifests目录下你有没有创建静态pod 的需求，如果有的话kubelet组件就会去管理。所以前面我们说，管理节点的组件：apiserver、scheduler，controller-manager，和工作节点的组件：kubelet（systemd）、kube-proxy这些，除了kubelet 组件没有封装在 kubeadm 工具中，其他的几个组件都是封装在kubeadm工具中使用静态pod启动的，静态pod能启动的前提必须有kubelet组件的管理，所以，就不能把 kubelet 组件也做成静态 pod 的形式去部署了，kubelet组件启动之后，将其他组件由指定的yaml放在 /etc/kubernetes/manifests/ 目录下，kubelet 就会根据这个 yaml文件去启动这些 pod ，让这些组件都起来。
6、[kubelet-start] 生成配置文件，并启动kubelet（所以前面我们不能直接启动）
7、[wait-control-plane] 等待kubelet启动控制面的静态pod。
8、[apiclient] 控制平面的所有组件均已启动。
9、[upload-config] 将kubeadm配置文件存放到kube-system这个命名空间下的configmap里，所以其他工作节点去连接的时候，都会把配置文件发送给那些工作节点，然后去启动；
10、[kubelet] 将kubelet配置文件存放到kube-system这个命名空间下的configmap里；
11、[mark-control-plane] node-role.kubernetes.io/master=‘’ 这个字段意思是给master节点打上了污点，pod如果不定义容忍这个污点，那么pod就不会被调度器分配到这个node，也就是说明master节点不调度业务pod；我们使用kubeadm搭建的集群默认就给 master 节点添加了一个污点标记，把 Master 节点保留给 Kubernetes 系统组件使用了，所以我们看到我们平时部署的业务 pod 都没有被调度到 master 上去；
12、[bootstrap-token] 为kubelet自动颁发证书的一个机制；
13、[addons] 安装两个插件 CoreDNS、kube-proxy；CoreDNS是用于k8s内部dns解析的，kube-proxy是负责pod网络的；
14、提示信息，你需要拷贝kubectl管理员的配置文件到用户的默认家路径下，然后你才能使用当前这个用户执行kubectl 命令来管理集群；
15、提示信息，在其他工作节点执行系统提示的命令加入k8s集群中；

3.6 添加工作节点

[root@slave-01 ~]# kubeadm join 192.168.217.129:6443 \
> --token fjhqux.4jdbz5y6xg2qv5xk         
> --discovery-token-ca-cert-hash sha256:cf314fd4e2f85b2e3a4fd56e6235c2828cee8ef55b4a8b757722747549638819 
> --cri-socket unix:///var/run/cri-dockerd.sock

3.7 验证

查看node状态，可以看到均处于NotReady状态；

[root@master-01 ~]# kubectl get node -owide
NAME        STATUS     ROLES           AGE     VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION           CONTAINER-RUNTIME
master-01   NotReady   control-plane   5d16h   v1.28.1   192.168.217.129   <none>        CentOS Linux 7 (Core)   3.10.0-1127.el7.x86_64   docker://24.0.5
slave-01    NotReady   <none>          5d16h   v1.28.1   192.168.217.128   <none>        CentOS Linux 7 (Core)   3.10.0-1127.el7.x86_64   docker://24.0.5
[root@master-01 ~]#

这是怎么回事呢？我们看下系统日志/var/log/messages：
在这里插入图片描述
如上，我们可以看到，系统信息有报错，显示网络插件未准备，CNI 配置文件没有初始化。是这样，网络插件提供了容器的网络解决方案，这些插件配置容器网络则通过CNI定义的接口来完成，也就是CNI定义的是容器运行环境与网络插件之间的接口规范；这个接口只关心容器的网络连接，创建容器就分配网络，删除容器就移除网络，插件就是对CNI规范的具体实现。

下面，我们安装一下pod的网络插件（CNI）。

3.8 安装flannel网络插件

# 部署CNI插件之前，我们可以看到，集群中并没有CNI 配置文件(/etc/cni/net.d/），也没有二进制命令（/opt/cni/bin/）
[root@master-01 ~]# ls /opt/cni/bin/
bandwidth  bridge  dhcp  dummy  firewall  host-device  host-local  ipvlan  loopback  macvlan  portmap  ptp  sbr  static  tuning  vlan  vrf
[root@master-01 ~]# 
[root@master-01 ~]# ls /etc/cni/net.d/


# 现在，开始下载、安装CNI插件
[root@master-01 ~]# wget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
[root@master-01 ~]# vim kube-flannel.yml
  net-conf.json: |
    {
      "Network": "10.3.0.0/16",  # 修改方法见第4章的问题记录
      "Backend": {
        "Type": "vxlan"
      }
    }
#安装过程中，会去docker.io拉取flannel的镜像，可能会比较慢
[root@master-01 ~]# kubectl apply -f kube-flannel.yml


# CNI网络插件安装完成之后，再来看下，可以看到flannel的配置文件和二进制命令；
[root@master-01 ~]# ls /etc/cni/net.d/
10-flannel.conflist
[root@master-01 ~]# ls /opt/cni/bin/
bandwidth  bridge  dhcp  dummy  firewall  flannel  host-device  host-local  ipvlan  loopback  macvlan  portmap  ptp  sbr  static  tuning  vlan  vrf

3.9 再次验证

# 如下，可以看到，集群pod和集群节点均已正常；
[root@master-01 ~]# kubectl get po -A
NAMESPACE      NAME                                READY   STATUS    RESTARTS   AGE
kube-flannel   kube-flannel-ds-kz46b               1/1     Running   0          40s
kube-flannel   kube-flannel-ds-wqbrb               1/1     Running   0          40s
kube-system    coredns-66f779496c-2xjnv            1/1     Running   0          5d21h
kube-system    coredns-66f779496c-v5k2t            1/1     Running   0          5d21h
kube-system    etcd-master-01                      1/1     Running   0          5d21h
kube-system    kube-apiserver-master-01            1/1     Running   0          5d21h
kube-system    kube-controller-manager-master-01   1/1     Running   0          5d21h
kube-system    kube-proxy-gkmxh                    1/1     Running   0          5d20h
kube-system    kube-proxy-ms67j                    1/1     Running   0          5d21h
kube-system    kube-scheduler-master-01            1/1     Running   0          5d21h

[root@master-01 ~]# kubectl get node
NAME        STATUS   ROLES           AGE     VERSION
master-01   Ready    control-plane   5d21h   v1.28.1
slave-01    Ready    <none>          5d20h   v1.28.1

4 问题记录

4.1 为什么要修改docker的Cgroup Driver？

4.1.1 cgroups是什么？

cgroups(Control Groups) 是 linux 内核提供的一种机制，它可以限制、记录任务组所使用的物理资源。（它是内核附加在程序上的 hook，使程序运行时对资源的调度触发相应的钩子，达到资源追踪和限制资源使用的目的）

4.1.2 cgroupfs是什么?

docker 默认的 Cgroup Driver 是 cgroupfs，cgroupfs 是 cgroup 为给用户提供的操作接口而开发的虚拟文件系统类型，它和 sysfs，proc 类似，可以向用户展示 cgroup 的等级制度，通知 kernel 用户对 cgroup 改动，对 cgroup 的查询和修改只能通过 cgroupfs 文件系统来进行。

4.1.3 为什么要修改为使用systemd?

Kubernetes 推荐使用 systemd 来代替 cgroupfs ，因为 systemd 是Kubernetes 自带的 cgroup 管理器，负责为每个进程分配 cgroups ，但docker的 cgroup driver 默认是 cgroupfs ，这样就同时运行有两个 cgroup 控制管理器，当资源有压力的情况时，有可能出现不稳定的情况。

# 如果不修改配置，会在kubeadm init时有提示:
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. 
The recommended driver is "systemd". 
Please follow the guide at

4.2 如何修改flannel原生的yaml文件

在应用我们直接从github下载的kube-flannel.yml文件之前，有两处地方可能需要调整：

[root@master-01 ~]# vim kube-flannel.yml
net-conf.json: |
{
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "vxlan"
  }
}

1）Network：用于指定Flannel地址池，也就是Pod IP分配的网段，与controller-manager配置的保持一样
--allocate-node-cidrs=true
--cluster-cidr=10.244.0.0/16

controller-manager配置查看

kubeadm部署 # /etc/kubernetes/manifests/kube-controller-manager.yaml
二进制部署 # /opt/kubernetes/cfg/kube-controller-manager.conf

2）Backend：指定工作模式，也就是指定数据包以什么方式转发；Flannel支持多种工作模式：

udp # 最早支持的一种方式，由于性能最差，目前已经弃用。
vxlan # Overlay Network方案，源数据包封装在另一种网络包里面进行路由转发和通信(隧道方案)。
host-gw # Flannel通过在各个节点上的Agent进程，将容器网络的路由信息写到主机的路由表上，这样一来所有的主机都有整个容器网络的路由数据了(路由方案)。
directrouting # 同时支持vxlan和host-gw工作模式。
公有云VPC # ALIYUN，AWS

其他参数：
3）SubnetLen: 用于指定分配给单个宿主机的docker0的ip段的子网掩码的长度，默认值是24位。
4）SubnetMin: 用于指定最小能够分配的ip段。
5）SudbnetMax: 用于指定最大能够分配的ip段；如：

{
"NetWork":"10.0.0.0/16",
"SubnetMin":"10.0.1.0";
"SubnetMax":"10.0.20.0";
"Backend":
  {"Type": "vxlan"}
}

如上，表示每个宿主机可以分配一个24位掩码长度的子网，可以分配的子网从10.0.1.0/24到10.0.20.0/24，也就意味着在这个网段中，最多只能有20台宿主机。

4.3 如果初始化不成功，解决方法

># 该命令用于还原通过”kubeadm init“或”kubeadm join“操作对主机所做的更改，然后解决配置或环境问题后，重新初始化；
>[root@master ~]# kubeadm  reset --cri-socket unix:///var/run/cri-dockerd.sock

K8S/Kubernetes

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐

【深度】阿里巴巴万级规模 K8s 集群全局高可用体系之美

作者 | 韩堂、柘远、沉醉来源 | 阿里巴巴云原生公众号前言台湾作家林清玄在接受记者采访的时候，如此评价自己 30 多年写作生涯：“第一个十年我才华横溢，‘贼光闪现’，令周边黯然失色；第二个十年，我终于‘宝光现形’，不再去抢风头，反而与身边的美丽相得益彰；进入第三个十年，繁华落尽见真醇，我进入了‘醇光初现’的阶段，真正体味到了境界之美”。长夜有穷，真水无香。领略过了 K8s“身在江

K8S/Kubernetes

如何基于 K8s 构建下一代 DevOps 平台？

作者 | 孙健波（天元）导读：当前云原生 DevOps 体系现状如何？面临哪些挑战？如何通过 OAM 解决云原生 DevOps 场景下的诸多问题？云原生开发应用模型 OAM(Open Application Model) 社区核心成员孙健波将为大家一一解答，并分享如何基于 OAM 和 Kubernetes 打造无限能力的下一代 DevOps 平台。什么是 DevOps？为什么基于 Kub