kubernetes의 Flannel 네트워크 플러그인 배치와 세 가지 작업 모드 설명
12742 단어 flannel
Flannel VXLAN 모드 구성 Flannel은 k8s 클러스터가 설치된 즉시 Flannel을 배치합니다.
공식 yaml 파일을 직접 적용하려면:
root@k8s-master:~# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/bc79dd1505b0c8681ece4de4c0d86c5cd2643275/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
출력은 다음과 같이 정상적으로 작동합니다.
root@k8s-master:~# kubectl get ds -n kube-system
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
kube-flannel-ds-amd64 2 2 2 2 2 beta.kubernetes.io/arch=amd64 98s
kube-flannel-ds-arm 0 0 0 0 0 beta.kubernetes.io/arch=arm 98s
kube-flannel-ds-arm64 0 0 0 0 0 beta.kubernetes.io/arch=arm64 98s
kube-flannel-ds-ppc64le 0 0 0 0 0 beta.kubernetes.io/arch=ppc64le 98s
kube-flannel-ds-s390x 0 0 0 0 0 beta.kubernetes.io/arch=s390x 98s
정상적으로 실행되면 flanneld는 호스트의/etc/cni/net에 있습니다.d 디렉터리에 자신의 프로필을 생성하면 kubelet에서 호출합니다.
Node 상태는 네트워크 플러그인이 성공적으로 실행된 후에만 Ready
root@k8s-master:~# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master Ready master 18m v1.13.1
k8s-node01 Ready <none> 16m v1.13.1
flannel이 실행되면 Node 숙박 호스트에 네트워크 인터페이스가 하나 더 추가됩니다.
root@k8s-master:~# ifconfig
flannel.1 Link encap:Ethernet HWaddr 6a:43:8c:e4:2a:77
inet addr:10.244.0.0 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::6843:8cff:fee4:2a77/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
root@k8s-node01:~# ifconfig
flannel.1 Link encap:Ethernet HWaddr 7a:a1:2e:85:a9:1c
inet addr:10.244.1.0 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::78a1:2eff:fe85:a91c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
위의 결과에서 알 수 있듯이
flannel은 기본적으로 VXLAN 모드, 즉 Overlay Network입니다.flanneld에서 flannel을 만듭니다.1 인터페이스, 터널 프로토콜을 봉인하는 데 사용되는 것으로 집단에 나누어지는 Pod 세그먼트는 기본적으로 10.244.0.0/16이다.flannel이 k8s-master 노드에 설정한 Pod 네트워크는 10.244.0.0세그먼트이고 k8s-node01 노드에 설정한 Pod 네트워크는 10.244.1.0세그먼트입니다. 더 많은 노드가 있으면 이런 식으로 추정합니다.복사본이 3인 nginx 컨테이너를 시작합니다.
root@k8s-master:~# kubectl run nginx --image=nginx:1.10 --port=80 --replicas=3
pod를 보려면:
root@k8s-master:~# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-6b647cb88-24j29 1/1 Running 0 23m 10.244.0.3 k8s-master <none> <none>
nginx-6b647cb88-ft8wc 1/1 Running 0 23m 10.244.0.2 k8s-master <none> <none>
nginx-6b647cb88-g4mqt 1/1 Running 0 33m 10.244.1.4 k8s-node01 <none> <none>
그 중에서 두 개의 Pod는 노드 k8s-master에서 실행되고 그 중 한 개의 Pod가 설정한 IP는 10.244.0.2이다.
현재, 이 node에서 네트워크 인터페이스를 보십시오
root@k8s-master:~# ifconfig
cni0 Link encap:Ethernet HWaddr 0a:58:0a:f4:01:01
inet addr:10.244.0.1 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::c048:c9ff:fe09:f54e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:3316 errors:0 dropped:0 overruns:0 frame:0
TX packets:3387 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
용기가 실행된 후 노드 위에 가상 인터페이스 cni0이 하나 더 생겼는데 그 IP는 10.244.0.1이다. 이것은 flanneld가 만든 가상 브리지인 cni0이고Pod 로컬 통신에서 사용된다.
flanneld는 모든 Pod에 한 쌍의veth 가상 장치를 만들고 한 쌍은 용기 인터페이스에 놓고 한 쌍은 cni0 다리에 놓는다.
브릿지를 보려면 brctl을 사용하십시오.
root@k8s-master:~# brctl show cni0
bridge name bridge id STP enabled interfaces
cni0 8000.0a580af40001 no veth0fda9673
veth6388ea61
# cni0 。
일반 액세스 테스트:
#
root@k8s-master:~# ping 10.244.0.2
PING 10.244.1.4 (10.244.1.4) 56(84) bytes of data.
64 bytes from 10.244.1.4: icmp_seq=1 ttl=63 time=2.01 ms
기존의 flannel VXLAN 네트워크에서 두 호스트의pod 간 통신은 틀림없이 가능할 것이다. 아래와 같은pod:
# Pod
root@k8s-master:~# kubectl exec -it nginx-6b647cb88-ft8wc -- /bin/sh
# ping 10.244.1.4
PING 10.244.1.4 (10.244.1.4): 56 data bytes
64 bytes from 10.244.1.4: icmp_seq=0 ttl=62 time=2.587 ms
64 bytes from 10.244.1.4: icmp_seq=1 ttl=62 time=3.880 ms
컨테이너가 호스트 간에 어떻게 통신되는지 라우팅 정보를 확인합니다.
root@k8s-master:~# ip route
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink
10.244.1.0/24 네트워크의 데이터 패키지로 본 컴퓨터의 플래너에게 보냅니다.1 인터페이스, 즉 2층 터널에 들어간 다음에 VXLAN 패키지를 봉하여 목표 Node에 도착한 후 목표 Node의 flannel.포장을 풀다.
Node가 시작하고 Flannel 네트워크에 가입하면 다른 Node의 flanneld에 이와 같은 루트 규칙이 추가됩니다. 이것이 기본 VXLAN 네트워크입니다.
k8s-master에서 다른 사람의 것을 핑하기 때문에 k8s-master는 VXLAN 패키지를 봉한 적이 있습니다. 클러치:
#k8s-master
tcpdump -i ens33 -nn host 10.3.1.20
16:46:09.302335 IP 10.3.1.20.53051 > 10.3.1.21.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.0.2 > 10.244.1.4: ICMP echo request, id 20, seq 360, length 64
16:46:09.302395 IP 10.3.1.20.59519 > 10.3.1.21.8472: OTV, flags [I] (0x08), overlay 0, instance 1
IP 10.244.1.4 > 10.244.0.2: ICMP echo reply, id 20, seq 360, length 64
보시다시피 오버레이 안에는 위에 핑한 ICMP 가방이 있습니다.
VXLAN은 Linux 내부 핵 자체가 지원하는 네트워크 가상화 기술로 내부 핵의 한 모듈로 내부 핵 상태에서 봉인 해제와 봉인을 실현하고 커버 네트워크를 구축하는데 사실은 각 숙박 호스트의 Flannel이다.1 장치로 구성된 가상 2층 네트워크.
VXLAN은 추가적인 패키지 해제로 인해 성능이 떨어지기 때문에 Flannel에는host-gw 모드가 생겼다. 즉, 숙박 호스트를 스위치로 하고 로컬 루트를 제외하고는 추가 비용이 없고 성능과calico의 차이가 많지 않다. 중첩되어 메시지 전송을 실현하지 않았기 때문에 루트 테이블이 방대하게 될 수 있다.하나의 노드가 하나의 네트워크에 대응하고, 또한 하나의 루트 항목에 대응하기 때문이다.
host-gw는 VXLAN 네트워크의 성능이 훨씬 강하지만,그러나 한 가지 방식은 결함이 있다. 각 물리 노드가 반드시 같은 2층 네트워크에 있어야 한다는 것이다.물리적 노드는 동일한 세그먼트에 있어야 합니다.이렇게 하면 한 네트워크 구간의 호스트 양이 매우 많아서 만일 라디오 메시지를 보내면 방해가 생길 수 있다.개인 클라우드 장면에서 숙박 호스트가 같은 네트워크에 있지 않은 것은 매우 흔한 상태이기 때문에host-gw를 사용할 수 없다.
VXLAN은 또 다른 기능이 있다. VXLAN도 host-gw와 유사한 게임 방법을 지원한다. 만약에 두 노드가 같은 구역에 있을 때host-gw 통신을 사용하고 같은 구역에 있지 않으면 현재pod가 있는 노드와 목표pod가 있는 노드 사이에 공유기가 있으면 VXLAN과 같은 방식으로 중첩 네트워크를 사용한다.Host-gw와 VXLAN을 결합시켰는데 이것이 바로 VXLAN의 Directrouting 모델이다. 그래서 Flnnel의 VXLAN 모델은 두 가지가 있다.
VXLAN: 기본 VXLAN, 즉 확장된 가상 LAN Directrouting: 직접 라우팅
Flannel VXLAN의 Directrouting 모드 설정 수정 다운로드한kube-flannel.yml, flannel의 configmap 객체를 다음과 같이 변경합니다.
net-conf.json: |
{
"Network": "10.244.0.0/16", #
"Backend": {
"Type": "VXLAN",
"Directrouting": true #
}
}
그리고 원래의 flannel을 삭제하고 다시 apply:
root@k8s-master:~# kubectl apply -f kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created
삭제 재배치는 원래의 Flannel을 삭제해야 하기 때문에 처음부터 Flannel을 계획해야 합니다.라우트를 다시 보려면 다음과 같이 하십시오.
root@k8s-master:~# ip route show
default via 10.3.1.1 dev ens33 onlink
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1
10.244.1.0/24 via 10.3.1.21 dev ens33
10.244.1.0/24 네트워크로 가는 다음 점프는 10.3.1.21로 본 컴퓨터의 물리적 인터페이스인ens33에서 나간다.이것이 Directrouting입니다.두 노드가 네트워크 세그먼트에 걸쳐 있는 경우 flannel은 자동으로 VXLAN 모드로 다운그레이드됩니다.Flannel host-gw 구성
net-conf.json: |
{
"Network": "10.244.0.0/16",
"Backend": {
"Type": "host-gw" #
}
}
라우팅 정보는 Directrouting과 동일하게 표시됩니다.이것이 바로 flannel의 설정 방식입니다.
좋은 웹페이지 즐겨찾기
