Tạo nguyên mẫu hạ tầng Network tại chỗ cho Workloads chạy trên Kubernetes Clusters: Phần 4

cloudFun

Phần cuối của loạt blog 4 bài này sẽ phân tích scenarios thứ 2 trong 2 scenarios có sẵn cho việc triển khai Calico và Kubernetes, trong đó Calico được cấu hình để peer với Giao thức cổng biên (BGP) bằng IP Fabric và không gói inter-pod traffic vào VXLAN. Nếu quan tâm đến việc triển khai Calico bằng VXLAN encapsulation, vui lòng xem bài viết ở blog trước.

Tìm hiểu thêm về data centre networking trong Phần 1 và cách phát triển data centre network trong Phần 2.

Hy vọng rằng loạt bài này sẽ hữu ích với người dùng đang ở giai đoạn thứ 3 của chuyển đổi Cloud Native, được gọi là Build, các hệ thống được tạo ra để giúp tổ chức có thể cạnh tranh và phát triển hơn.

Trong trường hợp muốn đưa toàn bộ môi trường lên workstation, tất cả scripts và playbook được sử dụng trong bài này có thể tìm trong kho lưu trữ GitLab

Nếu theo dõi loạt bài này, thì hiện tại người đọc đã có Kubernetes cluster hoạt động nhưng tất cả nodes bị kẹt ở trạng thái NotReady bởi vì thiếu thành phần networking sắp triển khai.

Kubernetes Inter-Workload giao tiếp mà không có Overlay Network

Trong trường hợp này, các thành phần Calico networking không sử dụng bất kỳ hình thức traffic encapsulation nào. Có nghĩa là network phải có nhận thức về IP addressing được sử dụng trong Kubernetes cluster.


Tương tự như scenario trước đã khám phá trong loạt bài này, có kiến trúc IP Fabric chạy eBGP giữa các spine và leaf switches, nhưng ở trường hợp này, BGP peering được mở rộng đến Kubernetes cluster bằng iBGP. Mỗi Kubernetes cluster node sẽ peer với một leaf switch được kết nối trực tiếp với iBGP để trao đổi thông tin định tuyến giữa IP Fabric và Kubernetes cluster nodes. Đây là cách Kubernetes networking kết nối với BGP peering, control plane và data plane như sau:
PS19_10_21_Prototyping_on_premises_architecture_blogpost_Part4-diagram_1 copy.png


Mỗi leaf switch có một AS number duy nhất được gán và được chia sẻ trên tất cả nodes được kết nối trực tiếp với switch cụ thể đó. Trong thiết lập này, cần chạy BGP route reflecto trên mỗi leaf switch sẽ phản ánh tất cả tuyến được báo bởi các nodes trong cùng một AS.

Trong scenario này, 10.64.0.0/12 và 10.80.0.0/12 prefixes sẽ được sử dụng tương ứng cho các pods và services.

Triển khai network sử dụng BGP peering với IP Fabric network, bên cạnh tệp kê khai Calico cơ bản, các tệp kê khai có chứa BGPPeer và cấu hình node-specific cho Kubernetes nodes. Tất cả tệp kê khai được sử dụng trong scenario này có thể tìm từ kho GitLab.

Để cho phép Calico hỗ trợ scenario này, cần xử lý một số yêu cầu sau:
Calico phải sử dụng bird as calico_backend trong tệp calico.yaml, sẽ kích hoạt chức năng BGP trong Calico thông qua BIRD , đây là IP routing daemon.

Cấu hình BGP peering phải được cung cấp cho Calico để báo cho Kubernetes nodes biết leaf switches nào peer.

Cần cung cấp cấu hình Node để báo cho Kubernetes nodes biết số IP và AS sẽ sử dụng khi peer leaf switches.

BGPPeer và Node manifests tận dụng việc gắn thẻ node để đẩy cấu hình chính xác đến những nodes cụ thể. Ví dụ, nodes kết nối với leaf1 được gắn nhãn asnum đặt thành 65101. Tương tự, các nodes được kết nối với leaf2 gắn nhãn asnum đặt thành 65102.

Khi tất cả các nodes được gán nhãn, BGPPeer manifest cần được áp dụng cho Kubernetes cluster. Cấu hình mẫu cho tất cả nodes nên peer với leaf1 có thể xem dưới đây. BGPPeer sử dụng nodeSelector để chọn nodes và cho BIRD daemon biết IP và AS nên peer với nó.
Mã:
apiVersion: projectcalico.org/v3
kind: BGPPeer
metadata:
name: as65101-k8s-nodes-to-leaf1
spec:
peerIP: 10.0.101.1
asNumber: 65101
nodeSelector: "asnum == '65101'"
Tệp cấu hình node chứa thông tin về AS number mà một node cụ thể sẽ sử dụng và IP address nào sẽ được dùng cho iBGP peering. Một đoạn trích từ tệp cấu hình node được liệt kê dưới đây, áp dụng cho k8s-node-l1-2:
Mã:
apiVersion: projectcalico.org/v3
kind: Node
metadata:
name: k8s-node-l1-2
spec:
bgp:
asNumber: 65101
ipv4Address: 10.0.101.102/24
Một đoạn trích từ tệp cấu hình node được liệt kê dưới đây, cụ thể dành cho k8s-node-l1-2:
Mã:
apiVersion: projectcalico.org/v3
kind: Node
metadata:
name: k8s-node-l1-2
spec:
bgp:
asNumber: 65101
ipv4Address: 10.0.101.102/24
Hai tệp này trong số những tệp khác liên quan đến BGPPeer và Node được triển khai với tập lệnh bên dưới cùng các Calico manifests cơ bản:
Mã:
$ sh vagrant.calico-with-peering.sh
node/k8s-master-l1-1 labeled
Connection to 127.0.0.1 closed.
node/k8s-node-l1-1 labeled
Connection to 127.0.0.1 closed.
node/k8s-node-l1-2 labeled
Connection to 127.0.0.1 closed.
node/k8s-node-l2-1 labeled
Connection to 127.0.0.1 closed.
node/k8s-node-l2-2 labeled
Connection to 127.0.0.1 closed.
serviceaccount/calicoctl created
pod/calicoctl created
clusterrole.rbac.authorization.k8s.io/calicoctl created
clusterrolebinding.rbac.authorization.k8s.io/calicoctl created
Connection to 127.0.0.1 closed.
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
serviceaccount/calico-node created
deployment.apps/calico-kube-controllers created
serviceaccount/calico-kube-controllers created
Connection to 127.0.0.1 closed.
Successfully applied 5 'Node' resource(s)
Connection to 127.0.0.1 closed.
Successfully applied 3 resource(s)
Connection to 127.0.0.1 closed.
BGP sessions cần được thiết lập giữa IP Fabric leaf switches và Kubernetes nodes được kết nối trực tiếp của chúng. Sử dụng các lệnh trong đoạn trích dưới đây để xác minh xem BGP peerings cần thiết liệu đã có mặt và được thiết lập hay không.
Mã:
$ vagrant ssh leaf1 -c "sudo net show bgp sum"
show bgp ipv4 unicast summary
=============================
BGP router identifier 172.16.255.101, local AS number 65101 vrf-id 0
BGP table version 10
RIB entries 15, using 2280 bytes of memory
Peers 5, using 96 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.0.101.10 4 65101 40 45 0 0 0 00:01:50 2
*10.0.101.101 4 65101 40 45 0 0 0 00:01:50 1
*10.0.101.102 4 65101 40 45 0 0 0 00:01:50 1
spine-sw1.lab.local(172.16.0.0) 4 65001 753 755 0 0 0 00:37:14 4
spine-sw2.lab.local(172.16.0.4) 4 65002 753 755 0 0 0 00:37:14 4
$ vagrant ssh leaf2 -c "sudo net show bgp sum"
show bgp ipv4 unicast summary
=============================
BGP router identifier 172.16.255.102, local AS number 65102 vrf-id 0
BGP table version 9
RIB entries 15, using 2280 bytes of memory
Peers 4, using 77 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
*10.0.102.101 4 65102 43 49 0 0 0 00:02:00 1
*10.0.102.102 4 65102 43 49 0 0 0 00:01:59 1
spine-sw1.lab.local(172.16.0.2) 4 65001 756 758 0 0 0 00:37:23 5
spine-sw2.lab.local(172.16.0.6) 4 65002 756 758 0 0 0 00:37:23 5
Lưu ý rằng mỗi BGP Neighbor được định cấu hình đã thiết lập thành công peering và các BGP messages đang được trao đổi (MsgRcvd/MsgSent columns), có thể thấy từ các outputs ở trên.

Từ giờ có thể chuyển sang kiểm tra cluster theo cách tương tự như đã làm trong bài trước. Đăng nhập vào Kubernetes master node (k8s-master-l1-1 ) kiểm tra trạng thái của Kubernetes nodes bằng lệnh kubectl. Tất cả nodes sẽ chuyển sang trạng thái Ready vì networking component đã được triển khai. Cũng cần kiểm tra xem tất cả Calico pods cần thiết đã được triển khai thành công trên tất cả nodes hay chưa. Sẽ như thế này:
Mã:
$ vagrant ssh k8s-master-l1-1
[[email protected] ~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master-l1-1 Ready master 17m v1.15.3
k8s-node-l1-1 Ready <none> 16m v1.15.3
k8s-node-l1-2 Ready <none> 16m v1.15.3
k8s-node-l2-1 Ready <none> 16m v1.15.3
k8s-node-l2-2 Ready <none> 16m v1.15.3
[[email protected] ~]$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-59f54d6bbc-wlmwb 1/1 Running 0 15m
calico-node-8zj5k 1/1 Running 0 15m
calico-node-br862 1/1 Running 0 15m
calico-node-lsh6c 1/1 Running 0 15m
calico-node-n64l2 1/1 Running 0 15m
calico-node-r2csj 1/1 Running 0 15m
calicoctl 1/1 Running 0 15m
coredns-5c98db65d4-bcjtq 1/1 Running 0 17m
coredns-5c98db65d4-zgpv8 1/1 Running 0 17m
etcd-k8s-master-l1-1 1/1 Running 0 16m
kube-apiserver-k8s-master-l1-1 1/1 Running 0 16m
kube-controller-manager-k8s-master-l1-1 1/1 Running 0 16m
kube-proxy-fsrcv 1/1 Running 0 16m
kube-proxy-j2xd7 1/1 Running 0 16m
kube-proxy-jsxlb 1/1 Running 0 16m
kube-proxy-kp2j6 1/1 Running 0 17m
kube-proxy-tdlxs 1/1 Running 0 16m
kube-scheduler-k8s-master-l1-1 1/1 Running 0 16m
Nếu tất cả nodes ở trạng thái Ready và calico pods ở trạng thái Running, nghĩa là control plane của Calico đã hoạt động. Để kiểm tra data plane, thì một triển khai mẫu với service trong namespace riêng có thể triển khai đến cluster. Triển khai Nginx đơn giản có thể tìm thấy và áp dụng từ thư mục demo, như bên dưới. Một pod đơn với Nginx sẽ được triển khai vào cluster trong namespace space1.
Mã:
[[email protected] ~]$ kubectl apply -f demo/namespace.yaml
namespace/space1 created
[[email protected] ~]$ kubectl apply -f demo/deployment.yaml
deployment.extensions/nginx-deployment created
[[email protected] ~]$ kubectl apply -f demo/service.yaml
service/nginx-service created
[[email protected] ~]$ kubectl get pods -n space1
NAME READY STATUS RESTARTS AGE
nginx-deployment-55457b9d87-rldn7 1/1 Running 0 54s
Việc triển khai Nginx phải được chia tỷ lệ thành 4 pods để triển khai pods trên các pods khác để kiểm tra khả năng tiếp cận inter-pod IP.
Mã:
[[email protected] ~]$ kubectl scale deployment/nginx-deployment --replicas=4 -n space1
deployment.extensions/nginx-deployment scaled
outlet được thấy ở đây, 4 pods được triển khai trên 4 pods riêng biệt:
Mã:
[[email protected] ~]$ kubectl get pods -n space1 -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-55457b9d87-655sm 1/1 Running 0 28s 10.65.76.192 k8s-node-l1-2 <none> <none>
nginx-deployment-55457b9d87-ghfxl 1/1 Running 0 28s 10.76.172.128 k8s-node-l2-2 <none> <none>
nginx-deployment-55457b9d87-jzcbh 1/1 Running 0 28s 10.68.86.128 k8s-node-l2-1 <none> <none>
nginx-deployment-55457b9d87-rldn7 1/1 Running 0 96s 10.67.209.0 k8s-node-l1-1 <none> <none>
Trong terminal riêng biệt, cần xác minh xem liệu pod routes đã được truyền từ Kubernetes nodes sang IP Fabric leaf switches và thông qua IP Fabric hay chưa bằng các lệnh từ code snippets bên dưới (một số output được lược bỏ):
Mã:
$ vagrant ssh leaf1 -c "sudo net show bgp"
*>i10.64.213.128/26 10.0.101.10 100 0 i
*>i10.65.76.192/26 10.0.101.102 100 0 i
*>i10.67.209.0/26 10.0.101.101 100 0 i
* 10.68.86.128/26 172.16.0.4 0 65002 65102 i
*> 172.16.0.0 0 65001 65102 i
* 10.76.172.128/26 172.16.0.4 0 65002 65102 i
*> 172.16.0.0 0 65001 65102 i
$ vagrant ssh leaf2 -c "sudo net show bgp "
*> 10.64.213.128/26 172.16.0.2 0 65001 65101 i
* 172.16.0.6 0 65002 65101 i
* 10.65.76.192/26 172.16.0.6 0 65002 65101 i
*> 172.16.0.2 0 65001 65101 i
* 10.67.209.0/26 172.16.0.6 0 65002 65101 i
*> 172.16.0.2 0 65001 65101 i
*>i10.68.86.128/26 10.0.102.101 100 0 i
*>i10.76.172.128/26 10.0.102.102 100 0 i
Có thể thấy trong các snippets, mỗi node đang báo route của nó với /26 prefix, là một phần của 10.64.0.0/12 CIDR block. Block này được xác định trong tệp Calico configuration. Sau đó, các routes này đang được truyền đi trên IP Fabric và hiển thị trên leaf switches từ xa với AS_PATH được giữ với AS numbers của leaf và spine switches.

Giờ sẽ trở lại với console trước đó, chạy SSH session tới k8s-master-l1-1 và đăng nhập vào container đang chạy trên k8s-node-l2-1. Tiếp theo, cài đặt utility. Sau đó, triển khai ping về phía Nginx container đang chạy trên k8s-node-l1-2 (10.65.76.192), được kết nối với leaf1 switch. Nó sẽ như sau (output được lược bỏ)
Mã:
[[email protected] ~]$ kubectl exec -it nginx-deployment-55457b9d87-jzcbh -n space1 -- bash
[email protected]:/# apt update && apt install iputils-ping
[email protected]:/# ping 10.65.76.192
PING 10.65.76.192 (10.65.76.192) 56(84) bytes of data.
64 bytes from 10.65.76.192: icmp_seq=1 ttl=59 time=1.06 ms
64 bytes from 10.65.76.192: icmp_seq=2 ttl=59 time=1.20 ms
64 bytes from 10.65.76.192: icmp_seq=3 ttl=59 time=1.15 ms
Mở tab mới trong terminal và SSH vào k8s-node-l2-1 . Cần cài đặt tcpdump utility trên node để kiểm tra traffic. Vì không có encapsulation, nên ICMP traffic thuần túy sẽ bị thu nạp. Sự thu nạp traffic cần được thực hiện trên interface eth0, kết nối với IP Fabric network. Đây là cách thực hiện (output được lược bỏ):
Mã:
$ vagrant ssh k8s-node-l2-1
[[email protected] ~]$ sudo yum install -y tcpdump
[[email protected] ~]$ sudo tcpdump -i eth0 -ne icmtcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
13:06:23.248977 08:00:27:33:fa:f7 > 08:00:27:74:be:4a, ethertype IPv4 (0x0800), length 98: 10.68.86.128 > 10.65.76.192: ICMP echo request, id 336, seq 1, length 64
13:06:23.249970 08:00:27:74:be:4a > 08:00:27:33:fa:f7, ethertype IPv4 (0x0800), length 98: 10.65.76.192 > 10.68.86.128: ICMP echo reply, id 336, seq 1, length 64
13:06:24.250824 08:00:27:33:fa:f7 > 08:00:27:74:be:4a, ethertype IPv4 (0x0800), length 98: 10.68.86.128 > 10.65.76.192: ICMP echo request, id 336, seq 2, length 64
13:06:24.251957 08:00:27:74:be:4a > 08:00:27:33:fa:f7, ethertype IPv4 (0x0800), length 98: 10.65.76.192 > 10.68.86.128: ICMP echo reply, id 336, seq 2, length 64
13:06:25.253033 08:00:27:33:fa:f7 > 08:00:27:74:be:4a, ethertype IPv4 (0x0800), length 98: 10.68.86.128 > 10.65.76.192: ICMP echo request, id 336, seq 3, length 64
13:06:25.254121 08:00:27:74:be:4a > 08:00:27:33:fa:f7, ethertype IPv4 (0x0800), length 98: 10.65.76.192 > 10.68.86.128: ICMP echo reply, id 336, seq 3, length 64
Sự thu nạp packet đã cho thấy một số ethernet frames được trao đổi giữa pod chạy trên k8s-node-l2-1 và pod chạy trên k8s-node-l1-2. payload với ICMP echo requestICMP echo reply được trao đổi giữa pod có IP là 10.68.86.128 và pod có IP là 10.65.76.192. Không có encapsulation bổ sung liên quan đến scenario này, vì vậy packet được gửi bởi pod là packet on wire.

Phản hồi thành công cho lệnh ping xác nhận rằng khả năng tiếp cận IP đã đạt được, bằng BGP peering giữa các pods chạy trên 2 nodes riêng biệt mà không cần đến encapsulation bổ sung

Nguồn: blog.container-solutions.com
 
Top