10 diagrams of K8S CNI Calico network model principles and functional practices

1. Overview

Calico is a networking and network strategy provider. Calico supports a flexible set of network options so you can choose what works best for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy at the service mesh layer for hosts, pods, and (if using Istio and Envoy) applications. Calico is known for its performance, flexibility. Calico is more comprehensive and complex. It not only provides network connectivity between hosts and pods, but also involves network security and management. The Calico CNI plug-in encapsulates Calico’s functionality within the CNI (container network interface) framework.

GitHub address:

https://github.com/projectcalico/calico

Official documentation:

https://projectcalico.docs.tigera.io/about/about-calico

Friends who want to know about flannel can refer to this article: Kubernetes (k8s) CNI (flannel) network model principle

https://www.cnblogs.com/liugp/p/16388870.html

For other CNI plug-ins, you can check the k8s official website:

https://kubernetes.io/docs/concepts/cluster-administration/addons/

2. Calico architecture and core components

Calico does not use overlay networks such as flannel and libnetwork overlay network drivers. It is a pure three-layer method that uses virtual routing instead of virtual switching. Each virtual router passes BGP The protocol propagates reachability information (routing) to the remaining data centers; Calico uses the Linux Kernel to implement an efficient vRouter on each computing node to be responsible for data forwarding, and each vRouter is responsible for routing information of the workload running on it through the BGP protocol. Like propagation within the entire Calico network – small-scale deployments can be directly interconnected, and large-scale deployments can be completed through designated BGP route reflectors.

Picture

Calico’s core components:

  • Felix: The agent process running on each Host is mainly responsible for network interface management and monitoring, routing, ARP management, ACL management and synchronization, status reporting, etc.
  • etcd: Distributed key-value storage, mainly responsible for network metadata consistency, ensuring the accuracy of Calico network status, and can be shared with kubernetes;
  • BGP Client (BIRD): Calico deploys a BGP Client for each Host, using BIRD. BIRD is a separate and continuously developed project that implements many dynamic routing protocols such as BGP, OSPF, and RIP. wait. Calico’s role is to monitor the routing information injected by Felix on the Host, and then broadcast it to the remaining Host nodes through the BGP protocol to achieve network interoperability.
  • BGP Route Reflector: In large-scale networks, if you only use BGP client to form a mesh-wide interconnection solution, it will lead to scale limitations, because N^2 connections are required to interconnect all nodes. In order to solve this scale problem, BGP’s Router Reflector method can be used to enable all BGP Clients to interconnect only with specific RR nodes and perform route synchronization, thus greatly reducing the number of connections.

3. What is BGP?

Border Gateway Protocol (BGP)is an autonomous system routing protocol running on TCP and is also a core decentralized autonomous routing protocol on the Internet. Network reachability information includes information about listed autonomous systems (AS). This information effectively constructs the topology diagram of AS interconnection and thereby clears routing loops, while policy decisions can be implemented at the AS level. In the Internet, an autonomous system (AS) is a small unit that has the authority to independently decide which routing protocol should be used in the system.

  • BGP is a communication protocol between routers and is mainly used for interconnection between AS (Autonomous System).
  • There are multiple BGP speakers inside the AS, which are divided into ibgp and ebgp. ebgp establishes BGP connections with ebgp in other ASs.
  • The BGP speakers within the AS exchange routing information through the BGP protocol. Finally, each BGP speaker has the routing information of the entire AS.

The node node in calico can be regarded as an AS, and the container in the node node is the router in the AS. calico uses BGP analysis to draw the routing table of the container address in the entire network.

Picture

  • IBGP (Internal BGP): When BGP runs within the same autonomous system, it is called IBGP.
  • EBGP (External BGP): When BGP runs between different autonomous systems, it is called EBGP.

BGP two modes:

  • Full interconnection mode (node-to-node mesh): Full interconnection mode, each BGP Speaker needs to establish a BGP connection with other BGP Speakers, so the total number of BGP connections is N ^2, if the number is too large, it will consume a lot of connections. If the number of clusters exceeds 100, this mode is not officially recommended.
  • Route Reflection Mode Router Reflection (RR): RR mode specifies one or more BGP Speakers as RouterReflection, which establishes connections with other Speakers in the network. Each Speaker only needs By establishing BGP with Router Reflection, you can obtain the routing information of the entire network. In calico, RR mode can be implemented through Global Peer.

3. Calico two network modes

1) IPIP mode

  • To understand it literally, it means to put an IP data packet into another IP packet, that is, to encapsulate the IP layer into a tunnel of the IP layer. It seems to be a waste, but in fact it is not.
  • Its function is basically equivalent to a network bridge based on the IP layer!
  • Generally speaking, ordinary network bridges are based on the mac layer and do not require IP at all. However, this ipip uses the routing at both ends to create a tunnel to connect two originally unreachable networks through point-to-point.
  • The source code for ipip can be found in the kernel net/ipv4/ipip.c.

The working principle of Calico’s IPIP mode is as follows:

Image

The tunl0 device used by Calico is an IP tunnel (IP tunnel) device

In the above example, after the IP packet enters the IP tunnel device, it will be taken over by the IPIP driver of the Linux kernel. The IPIP driver will directly encapsulate this IP packet in a host network IP packet, as shown below:

Image

2) BGP mode

  • Border Gateway Protocol (BGP) is a core decentralized autonomous routing protocol on the Internet.
  • It achieves reachability between autonomous systems (AS) by maintaining IP routing tables or ‘prefix’ tables, and is a vector routing protocol.
  • Instead of using traditional Interior Gateway Protocol (IGP) metrics, BGP uses path-based, network policy, or rule sets to determine routing. Therefore, it is more appropriately called a vectoring protocol than a routing protocol.
  • BGP, in layman’s terms, is about integrating multiple lines (such as China Telecom, China Unicom, China Mobile, etc.) connected to the computer room into one to realize multi-line single IP. The advantages of BGP computer room: the server only needs to set one IP address for optimal access. Routing is determined by the backbone routers on the network according to routing hops and other technical indicators, and will not occupy any system of the server.
  • Compared with IPIP network, the biggest difference between BGP network is no tunnel device tunl0. As mentioned above, the traffic between pods on the IPIP network is sent to tunl0, and then tunl0 is sent to the peer device. In the BGP network, the traffic between pods is directly sent to the destination from the network card, reducing the link of tunl0.

Image

4. Install Calico plug-in

1) Install Calico through helm

Official documentation:

https://projectcalico.docs.tigera.io/getting-started/kubernetes/helm

# add source
helm repo add projectcalico https://projectcalico.docs.tigera.io/charts

# helm repo update

# download
helm pull projectcalico/tigera-operator --version v3.24.5
# unzip
tar -xf tigera-operator-v3.24.5.tgz

# Installation, default namespace: calico-system
helm install calico ./tigera-operator --namespace tigera-operator --create-namespace

# Check all resources of tigera-operator
kubectl get all -n tigera-operator

2) Install through yaml file

wget https://docs.projectcalico.org/manifests/calico.yaml
kubectl apply -f calico.yaml

# Check
kubectl get all -n kube-system|grep calico

3) k8s flannel network switching calico

1. Uninstall the flannel plugin

### 1. Check the installed flannel information
cat /etc/cni/net.d/10-flannel.conflist

### 2. Delete flannel deployment resources
kubectl delete -f kube-flannel.yml

### 3. Clear the remaining information of flannel, and clean up the remaining files of the flannel network on each node of the cluster
ifconfig cni0 down
ip link delete cni0
ifconfig flannel.1 down
ip link delete flannel.1
rm -rf /var/lib/cni
rm -rf /etc/cni/net.d

2. Start installing the Calico plugin

# download
wget https://docs.projectcalico.org/manifests/calico.yaml

# Install
kubectl apply -f calico.yaml

# Check
kubectl get all -n kube-system|grep calico

# If the node is NotReady, restart the following container or kubelet to try
systemctl restart containerd docker

image

5. Network Policy

For network policy, you can refer to this article: [Cloud Native] Explanation and actual operation of hostNetwork and NetworkPolicy (network policy) in k8s

https://www.cnblogs.com/liugp/p/16905725.html

6. Simple to use

Official documentation:

https://projectcalico.docs.tigera.io/security/kubernetes-policy

1) Network policy example

1. Allow ingress traffic from Pods in the same namespace

Allow ingress traffic from pods in the same namespace, in the following example passing in pods with label color: red, only if they come from pods with label color: red, it is allowed to go to port 80.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
  namespace: default
spec:
  podSelector:
    matchLabels:
      color: blue
  ingress:
  -from:
    - podSelector:
        matchLabels:
          color: red
    ports:
      - port: 80

2. Allow ingress traffic from Pods in different namespaces

In the following example, incoming traffic is allowed only if it comes from a Pod with the label color: red, in a namespace with the label shape: square, on port 80.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
  namespace: default
spec:
  podSelector:
    matchLabels:
      color: blue
  ingress:
  -from:
    - podSelector:
        matchLabels:
          color: red
      namespaceSelector:
        matchLabels:
          shape: square
    ports:
    - port: 80

2) Fixed Pod IP

[Example 1] pod
Using the annotation cni.projectcalico.org/ipAddrs

# vi fixed-ip-test-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
  annotations:
    cni.projectcalico.org/ipAddrs: "["10.244.1.200"]"
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! & amp; & amp; sleep 3600']

Picture

[Example 2] Controller single pod
Utilize the annotation cni.projectcalico.org/ipAddrs

# vi fixed-ip-test-deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fixed-ip-test
  namespace: default
  labels:
    k8s-app: cloudnativer-test
spec:
  replicas: 1
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  selector:
    matchLabels:
      k8s-app: cloudnativer-test
  template:
    metadata:
      labels:
        k8s-app: cloudnativer-test
      annotations:
        cni.projectcalico.org/ipAddrs: "["10.244.1.220"]"
    spec:
      containers:
      - name: fixed-ip-test
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

[Example 3] Controller multi-pod fixed IP pool

To create additional IP pools (in addition to the default IP pool), use the annotation cni.projectcalico.org/ipv4pools.

Here first install a client tool calicoctl

wget https://github.com/projectcalico/calico/releases/download/v3.24.5/calicoctl-linux-amd64
mv calicoctl-linux-amd64 /usr/local/bin/calicoctl
chmod +x /usr/local/bin/calicoctl

arrangement

# vi fixed-ip-test-deployment2.yaml
# apiVersion: projectcalico.org/v3
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  name: new-pool1
spec:
  blockSize: 31
  cidr: 10.244.3.220/24
  ipipMode: Never
  natOutgoing: true
---
# apiVersion: projectcalico.org/v3
apiVersion: crd.projectcalico.org/v1
kind: IPPool
metadata:
  name: new-pool2
spec:
  blockSize: 31
  cidr: 10.244.4.221/24
  ipipMode: Never
  natOutgoing: true
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: fixed-ip-test2
  namespace: default
  labels:
    k8s-app: cloudnativer-test
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  selector:
    matchLabels:
      k8s-app: cloudnativer-test
  template:
    metadata:
      labels:
        k8s-app: cloudnativer-test
      annotations:
        # [Note] Single quotes cannot be used
        "cni.projectcalico.org/ipv4pools": "["new-pool1","new-pool2"]"
    spec:
      containers:
      - name: fixed-ip-test
        image: nginx:1.7.9
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

Check

# View ip pool
calicoctl get ippool
kubectl get pods -owide

Picture

[Tips] To change the default IP range used for Pods, please modify the CALICO_IPV4POOL_CIDR section in the calico.yaml manifest file.

7. Calico VS Flannel

Currently, the more commonly used ones are flannel and calico. The function of flannel is relatively simple, it does not have the ability to configure complex networks and does not support network policies; calico is an excellent network management plug-in. , while having complex network configuration capabilities, it often means that the configuration itself is relatively complex, so relatively speaking, smaller and simpler clusters use flannel. Considering future expansion, the network may need to add more devices and configure more in the future. strategy, it is better to use calico.

1) Flannel

  • Advantages: Simple deployment, average performance.
  • Disadvantages: There is no way to achieve fixed IP container drift, no subnet isolation, high dependence on upper-layer design, no IPAM, waste of IP addresses, and binding to the Docker startup method.

2) Calico

  • Calico is also known for its advanced networking capabilities. Network Policy is one of its most sought-after features.
  • Support for fixed IP configuration.
  • Additionally, Calico can integrate with service mesh Istio to interpret and enforce policies for intra-cluster workloads in the service mesh layer and network infrastructure layer. This means users can configure powerful rules describing how Pods should send and receive traffic, improving security and controlling the network environment.

Both plug-ins are widely used. If you need to set network policies, plan more complex networks, fix IPs, etc., it is recommended to use Calico; if you simply use the communication function of the network plug-in, choose Flannel.

Digression

In this first year of fast-growing technology, programming is like a ticket to a world of infinite possibilities for many people. In the star lineup of programming languages, Python is like the leading superstar. With its concise and easy-to-understand syntax and powerful functions, Python stands out and becomes one of the most popular programming languages in the world.


The rapid rise of Python is extremely beneficial to the entire industry, but “people are popular” has caused it to add a lot of criticism, but it still cannot stop its popularity momentum of development.

Will Python remain relevant and intact for the rest of the next decade? Today, we’re going to analyze the facts and dispel some misconceptions.

If you are interested in Python and want to get a higher salary by learning Python, then the following set of Python learning materials must be useful to you!

Materials include: Python installation package + activation code, Python web development, Python crawler, Python data analysis, artificial intelligence, machine learning and other learning tutorials. Even beginners with 0 basics can understand and understand. Follow the tutorial and take you to learn Python systematically from zero basics!
?

1. The learning route of Python in all directions

The route of all directions in Python is to organize the commonly used technical points of Python to form a summary of knowledge points in various fields. Its usefulness lies in that you can find corresponding learning resources according to the above knowledge points to ensure that you learn more comprehensively.

2. Python learning software

If a worker wants to do a good job, he must first sharpen his tools. The commonly used development software for learning Python is here!

Three, Python introductory learning video

There are also many learning videos suitable for beginners. With these videos, you can easily get started with Python~

4. Python exercises

After each video lesson, there are corresponding practice questions, you can test the learning results haha!

5. Python actual combat case

Optical theory is useless. You have to learn to type codes along with it, and then you can apply what you have learned in practice. At this time, you can learn from some practical cases. This information is also included~

6. Python interview materials

After we have learned Python, we can go out and find a job with the skills! The following interview questions are all from top Internet companies such as Ali, Tencent, Byte, etc., and some Ali bosses have given authoritative answers. After reading this set of interview materials, I believe everyone can find a satisfactory job.


VII. Data collection

The above-mentioned full version of the full set of Python learning materials has been uploaded to the official CSDN, and those who need it can scan the QR code of the CSDN official certification below on WeChat to get it for free
?

syntaxbug.com © 2021 All Rights Reserved.