Shulou(Shulou.com)06/03 Report--

Calico concept

After the micro-service of the system, the dubbo framework is used to develop and deploy to solve the internal call relationship between modules. The producer component in the Dubbo framework automatically starts a service port. In the process of adopting auto scaling in the DCOS platform, it is necessary to consider the service component port conflicts and cross-container access to the network. So the calico network scheme is introduced to solve the service invocation problem of dubbo framework.

Calico is a pure 3-layer data center network solution and seamlessly integrates IaaS cloud architecture like OpenStack to provide controllable IP communication among VM, containers, and bare metal.

The principle of Calico is to modify the iptables and routing table rules on each host node to achieve inter-container data routing and access control, and to coordinate node configuration information through Etcd. So the Calico service itself, like many distributed services, needs to run on every node of the cluster.

Common CNI network plug-ins include the following:

Flannel: provides network plug-in for overlay network for Kubernetes. Based on TUN/TAP tunnel technology, it uses UDP to encapsulate IP packets to create an overlay network, and maintains the distribution of the network with the help of etcd. Disadvantages: it can not support network policy access control.

Calico: a three-layer network plug-in based on BGP, which also supports network policies to achieve network access control; it runs a virtual route on each host, uses the Linux kernel to forward network packets, and implements firewall functions with iptables. In fact, the final implementation of Calico is to turn each host into a router, connecting each network to achieve the function of cross-host communication.

Canal: a unified network plug-in jointly released by Flannel and Calico that provides CNI network plug-ins and supports network policy implementation.

Others include Weave Net, Contiv, OpenContrail, Romana, NSX-T, kube-router and so on. Flannel and Calico are the most popular options at present.

1. Reject all apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all-egress namespace: cs1 # to cs1 namespaces, and apply spec: podSelector: {} ingress: egress: # to default without writing namespaces to define outbound rules. No policy is written here, which means reject all. PolicyTypes:-Egress-Ingress # Egress means to define outbound rules. If you don't write Egress, you will default traffic. Ingress is the same principle as inbound. It is recommended that you write both of them and use "podSelector:" to control whether you can pass 2. All allowed apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: allow-all-egress namespace: cs1spec: podSelector: {} ingress:-{} # this means all allowed traffic in the "ingress" direction egress:-{} # this means all allowed traffic in the "egress" direction policyTypes:-Egress-Ingress

This network policy only works for namespaces, and the host can still access it.

3. Scope apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-all namespace: default # only works on the default namespace spec: podSelector: # matches the pod range if it matches all POD inputs in that namespace "{}" matchLabels: access: "true" # matches the tag policyTypes:-Ingress-Egress ingress: egress:4. Restrict IP policy

# IP of each cs container shown above

ApiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: deny-allspec: podSelector: {} policyTypes:-Egress-Ingress ingress: egress:-to: # Note: egress uses to Ingress uses from-ipBlock: cidr: 192.168.0.0Universe 16 # to release the 192.168.0.0amp16 network except:-192.168.94.134Univer 32 # but does not include this ip

When exec enters pod, he can see ping192.168.94.134. This IP doesn't make sense.

5. Restrict apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: namespace-allow namespace: defaultspec: policyTypes: ["Ingress"] podSelector: {} ingress:-from:-namespaceSelector: matchLabels: name: cs1 # based on namespace label means that only namespaces with "name=cs1" are allowed. Meet multiple conditions based on namespace label restrictions apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: namespace-allow namespace: defaultspec: policyTypes: ["Ingress", "Egress"] podSelector: {} ingress:-from:-namespaceSelector: matchExpressions:-key: name operator: In values: ["cs1" "cs2"] # in parentheses can communicate with the default namespace ingress # means Namespaces with labels name=cs1,name=cs2 can communicate with default namespaces

7 based on pod label

ApiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: namespace-allow namespace: defaultspec: policyTypes: ["Ingress"] podSelector: {} ingress:-from:-podSelector: matchLabels: access: "true" # allows pod notes to have access to access=true

# I don't know what's wrong with the failure of the experiment based on pod label

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.