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

This article mainly explains "what is the Kubernetes network strategy". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the Kubernetes network strategy".

NetworkPolicy concept

Network policy NetworkPolicy replaces firewall devices in data center environments as you know them-such as pod Pod to computing instances, network plug-ins to routers and switches, and volumes to storage area networks (SAN).

By default, the Kubernetes network policy allows the pod Pod to receive traffic from anywhere. If you are not worried about the safety of the pods, this may not be a problem. However, if you are running a critical workload, you need to protect the pods. The control of traffic within the cluster (including ingress and egress traffic) can be achieved through network policies.

To enable network policy, you need a network plug-in that supports network policy. Otherwise, any rules you apply will become useless.

Different network plug-ins are listed on Kubernetes.io:

CNI plug-ins: follow

Container network interface Container Network Interface

(CNI) specification, designed to achieve interoperability.

Kubernetes follows the v0.4.0 version of the CNI specification.

Kubernetes plug-ins: use bridges and host local CNI plug-ins to implement basic cbr0.

Apply network strategy

To apply network policies, you need a working Kubernetes cluster and network plug-ins that support network policies.

But first, you need to know how to use network strategies in a Kubernetes environment. The Kubernetes network policy allows pods to receive traffic from anywhere. This is not an ideal situation. For pod safety, you must understand that pods are endpoints that can communicate within the Kubernetes architecture.

1. Use podSelector to communicate between pods:

-namespaceSelector: matchLabels: project: myproject

2. Use the combination of namespaceSelector and / or podSelector and namespaceSelector to communicate between namespaces and from namespace to pods. :

-namespaceSelector: matchLabels: project: myproject-podSelector: matchLabels: role: frontend

3. For IP block communication in pods, ipBlock is used to define which IP CIDR blocks determine the source and destination.

-ipBlock: cidr: 172.17.0.0 except 16:-172.17.1.0 Universe 24

Note the differences between pods, namespaces, and IP-based policies. For pod and namespace-based network policies, selectors are used to control traffic, while for IP-based network policies, IP blocks (CIDR ranges) are used to define controls.

Put them together, and a network policy should look like this:

ApiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: test-network-policy namespace: defaultspec: podSelector: matchLabels: app: backend policyTypes:-Ingress-Egress ingress:-from:-ipBlock: cidr: 172.17.0.0backend policyTypes 16 except:-192.168.1.0 Egress ingress 24-namespaceSelector: matchLabels: project: myproject-podSelector: matchLabels: Role: frontend ports:-protocol: TCP port: 6379 egress:-to:-ipBlock: cidr: 10.0.0.0 cidr 24 ports:-protocol: TCP port: 5978

Refer to the network policy above and pay attention to the spec section. In this section, the podSelector with the label app=backend is the goal of our network strategy. In short, network policies protect applications called backend within a given namespace.

This section also has a definition of policyTypes. This field indicates whether the given policy applies to the ingress flow of the selected pod, the exit flow of the selected pod, or both.

Spec: podSelector: matchLabels: app: backend policyTypes:-Ingress-Egress

Now, look at the Ingress (ingress) and Egress (egress) sections. This definition defines the control of network policies.

First, check the ingress from section.

In this example, the network policy allows pod connections from the following locations:

IpBlock allows 172.17.0. IpBlock 16 to deny 192.168.1.0/24namespaceSelectormyproject: all pods from this namespace with the same label project=myproject are allowed. PodSelectorfrontend: pods that match the label role=frontend are allowed. Ingress:-from:-ipBlock: cidr: 172.17.0.0 except 16 except:-192.168.1.0 project 24-namespaceSelector: matchLabels: project: myproject-podSelector: matchLabels: role: frontend

Now, check the egress to section. This determines the connection out of the pod:

IpBlock10.0.0.0/24: allow connections to this CIDRPorts: allow connections using TCP and port 5978 egress:-to:-ipBlock: cidr: 10.0.0.0Unip 24 ports:-protocol: TCP port: 5978 restrictions on network policy

Network policies alone cannot completely protect your Kubernetes cluster. You can use operating system components or layer 7 network technology to overcome known limitations. You need to keep in mind that network policy can only address security issues at the IP address and port level-layer 3 or layer 4 in Open Systems Interconnection (OSI).

In order to address security requirements that network policies cannot handle, you need to use other security solutions. Here are some use cases you need to know, in which network policy needs to be enhanced by other technologies.

Thank you for your reading, the above is the content of "what is the Kubernetes network strategy", after the study of this article, I believe you have a deeper understanding of what the Kubernetes network strategy is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.