作者介绍:简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我,下面的思维导图也是预计更新的内容和当前进度(不定时更新)。
我们上一章介绍了Docker基本情况,目前在规模较大的容器集群基本都是Kubernetes,但是Kubernetes涉及的东西和概念确实是太多了,而且随着版本迭代功能在还增加,笔者有些功能也确实没用过,所以只能按照我自己的理解来讲解。
我们上一小节介绍了CNI插件,而我们使用比较常多的插件就是Flannel,并且也是最简单的网络插件。当集群部署完成以后,第一个要做的就是引入网络插件,只有引入了网络插件以后 ,不同节点的Pod才能进行通信。集群才算正常可用集群。
在Kubernetes里面使用比较广泛的网络插件主要是Flannel和Calico,当然还有使用最新的eBPF技术的Cilium。本小节我们讲解Flannel。
Flannel 是一个简单而轻量级的网络插件,广泛用于 Kubernetes 集群中来提供 Pod 之间的网络通信。它的主要目标是为每个节点分配一个子网,并确保所有 Pod 可以通过这个子网进行相互通信。Flannel 支持多种后端(如 VXLAN、UDP、Host-GW 等)来实现跨节点的 Pod 网络连接。
Flannel 的核心特点
-
简单易用:
-
Flannel 的配置非常简单,通常只需要几行命令就可以完成安装和配置。
-
它没有复杂的依赖关系,适合快速部署和小型到中型集群。
-
-
轻量级:
-
Flannel 的资源消耗较少,对 CPU 和内存的影响较小。
-
它专注于基本的 Pod 网络需求,而不添加额外的功能或复杂性。
-
-
多种后端支持:
-
VXLAN:使用虚拟扩展局域网技术,适用于大多数环境。
-
UDP:基于用户数据报协议,适用于某些特定场景。
-
Host-GW (Host Gateway):直接路由流量,性能较好,但需要所有节点位于同一二层网络。
-
-
二层网络模型:
-
Flannel 使用简单的二层网络模型,每个节点上的 Pod 分配一个唯一的子网 IP 地址。
-
所有 Pod 之间可以通过这些子网 IP 地址直接通信,而不需要额外的 NAT 或代理。
-
-
集成良好:
-
Flannel 与 Kubernetes 集成良好,默认情况下被许多 Kubernetes 发行版(如 kubeadm)所采用。
-
它能够自动检测并适应不同的基础设施环境。
-
Flannel 的工作原理
-
分配子网:Flannel 会从预定义的 IP 地址池中为每个节点分配一个子网段。例如,整个集群可能使用
10.244.0.0/16
这个 CIDR 范围,每个节点可能会获得10.244.1.0/24
、10.244.2.0/24
等子网段。 -
网络通信:Pod 之间的通信通过节点的子网进行。如果两个 Pod 位于同一节点,则可以直接通过本地网络接口通信;如果位于不同节点,则根据选择的后端机制(如 VXLAN 或 Host-GW)进行跨节点通信。
-
后端选择:Flannel 提供了多种后端选项来处理跨节点通信。默认情况下,它使用 VXLAN 后端,但如果所有节点在同一个二层网络中,Host-GW 后端可以提供更好的性能。
---
kind: Namespace
apiVersion: v1
metadata:
name: kube-flannel
labels:
k8s-app: flannel
pod-security.kubernetes.io/enforce: privileged
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
labels:
k8s-app: flannel
name: flannel
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- nodes/status
verbs:
- patch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
labels:
k8s-app: flannel
name: flannel
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: flannel
subjects:
- kind: ServiceAccount
name: flannel
namespace: kube-flannel
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: flannel
name: flannel
namespace: kube-flannel
---
kind: ConfigMap
apiVersion: v1
metadata:
name: kube-flannel-cfg
namespace: kube-flannel
labels:
tier: node
k8s-app: flannel
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",
"EnableNFTables": false,
"Backend": {
##就是这里决定他采用什么后端机制
"Type": "vxlan"
}
}
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: kube-flannel-ds
namespace: kube-flannel
labels:
tier: node
app: flannel
k8s-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-plugin
image: docker.io/flannel/flannel-cni-plugin:v1.6.0-flannel1
command:
- cp
args:
- -f
- /flannel
- /opt/cni/bin/flannel
volumeMounts:
- name: cni-plugin
mountPath: /opt/cni/bin
- name: install-cni
image: docker.io/flannel/flannel:v0.26.2
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: docker.io/flannel/flannel:v0.26.2
command:
- /opt/bin/flanneld
args:
- --ip-masq
- --kube-subnet-mgr
resources:
requests:
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
- name: EVENT_QUEUE_DEPTH
value: "5000"
volumeMounts:
- name: run
mountPath: /run/flannel
- name: flannel-cfg
mountPath: /etc/kube-flannel/
- name: xtables-lock
mountPath: /run/xtables.lock
volumes:
- name: run
hostPath:
path: /run/flannel
- name: cni-plugin
hostPath:
path: /opt/cni/bin
- name: cni
hostPath:
path: /etc/cni/net.d
- name: flannel-cfg
configMap:
name: kube-flannel-cfg
- name: xtables-lock
hostPath:
path: /run/xtables.lock
type: FileOrCreate
解析这个文件
1.首先是创建了一个新的命名空间:kube-flannel
2.其次是RBAC信息,申请一定的权限最终把权限给予ServiceAccount:flannel,然后DS的Pod会来使用这个ServiceAccount。
3.定义了一个ConfigMap,里面准备了2个配置文件,其中一个文件定义了容器的CIDR,需要和你创建集群定义的一致,默认是10.244.0.0/16。
4.定义了一个DaemonSet,这里使用2个InitContainers容器,其中需要把镜像自带的flannel进程文件复制到主机的/opt/cni/bin目录里面。
[root@master01 bin]# ls -l /opt/cni/bin/ |grep flannel
-rwxr-xr-x 1 root root 2342446 Jan 16 19:06 flannel
[root@master01 bin]#
另外一个InitContainers容器则是把ConfigMap里面生成的cni-conf.json文件复制到了主机的/etc/cni/net.d/10-flannel.conflist,供kubelet读取。
上面是我互联网网找来的,简单解释下这个图。
1.2个节点:Node1的ip是10.168.0.2,Node2的ip地址是10.168.0.3。
2.Node1节点的容器ip是10.244.0.2,Node2节点的容器ip是10.244.1.3。
3.如果是到本机的其他容器,则直接走CNI网桥接入,CNI起到了类似交换机的作用。
5.如果是到其他主机,则到CNI网桥以后,还需要经过Flannel.1的封装,然后到了目的主机以后再经过Flannel.1解封。
运维小路
一个不会开发的运维!一个要学开发的运维!一个学不会开发的运维!欢迎大家骚扰的运维!
关注微信公众号《运维小路》获取更多内容。