networking.md (4389B)
1 +++ 2 title = 'Networking' 3 +++ 4 # Networking 5 Switches: operate at data link layer (layer 2) 6 - can see available interfaces with `ip link` 7 - can see IP address of every interface with `ip addr` 8 9 Routers: operate at layer 3 10 - can route packets across different networks 11 - show routing table with `ip route` 12 - add new route with `ip route add <target-subnet-cidr> via <ip-addr>` 13 14 Create and list network namespaces with `ip netns`. 15 16 Linux Bridge lets you connect all namespaces to an interface that works like a vritual switch: 17 - `sudo ip link add my-bridge type bridge` 18 - `sudo ip link set dev my-bridge up` 19 20 ## Kubernetes network model 21 Constraints: 22 - every pod has own IP address 23 - containers within pod share pod IP, can communicate with each other via localhost 24 - pods on node can communicate with all pods on all nodes without NAT 25 - agents on a node can communicate with all pods on that node 26 27 You may impose restrictions on the model using Kubernetes Network Policies. 28 29 Container Network Interface (CNI): formalises responsibilities of Container Runtime (creating network namespace and running plugins) 30 31 Pods can be: 32 - routable: pod IP known outside of cluster, so unique on broader network 33 - not routable: IP not know outside of cluster, connection to outside requires SNAT to change source IP to IP address of node, return packets mapped automatically 34 - no connections from outside cluster to pod possible, except with Kubernetes Services or Ingress 35 36 ### Kubernetes Services 37 - each pod has own IP, pods are not permanent so that IP may change over time 38 - services define logical set of pods (maybe with selector based on labels) and specify how to access them 39 40 You can access a service: 41 - using environment variables (client pod creates identifying environment variables automatically, check with `printenv`) 42 - using CoreDNS 43 44 #### ClusterIP 45 Service only reachable within cluster, default 46 - defines IP only visible inside cluster, and port it listens on 47 - requests to this port and ClusterIP forwarded to `targetPort` of pods that the service defines as targets 48 - good for e.g. making backend pods accessible to frontend pods 49 - load balances incoming requests to all target pods 50 51 Example definition using selector: 52 53 ```yaml 54 apiVersion: v1 55 kind: Service 56 57 metadata: 58 name: fancy-api-service 59 60 spec: 61 type: ClusterIP 62 ports: 63 - protocol: TCP 64 port: 8081 65 targetPort: 80 66 selector: 67 app: fancy-api 68 ``` 69 70 Apply with `kubectly apply -f filename.yaml`, then check with `kubectl get svc`. 71 72 Creating a service using a selector _also_ automatically adds an Endpoint object. 73 74 You can create a service without a pod selector, e.g. if you need to target a pod in a different cluster. 75 76 #### NodePort 77 exposes service on each Node's IP at static port, automatically creates ClusterIP 78 79 Multiple pods: 80 - if in same node, NodePort acts as load balancer and distributes incoming traffic 81 - if in multiple nodes, NodePort listens on same nodePort on each node IP address 82 83 #### LoadBalancer 84 exposes service externally using external load balancer, automatically creates NodePort and ClusterIP 85 - on public cloud, implementation provided by service. if not, can use e.g. MetaLB 86 87 ### Ingress 88 Layer 7 load balancer, operates at app layer using HTTP, can route decision based on full content of message. 89 Useful when you have multiple services you want to expose externally. 90 91 To use it: 92 1. Install Ingress Controller 93 - e.g. NGINX Ingress controller, Google HTTPS Load Balancer 94 2. Create Ingress Resources 95 96 ### CoreDNS 97 Provides nameserver for Kubernetes. 98 Nameserver can be referenced from Unix machine if it has an entry in `/etc/resolv.conf` 99 100 To resolve a hostname, use `nslookup` and `dig`. 101 102 In microk8s, run `microk8s enable dns` to add CoreDNS. 103 104 Stores its config in a file called `Corefile`; in Kubernetes, it's a ConfigMap. 105 106 107 ## Network Policies 108 Implemented by Network Plugin (e.g. Calico). 109 110 By default, pods accept traffic from any source in Cluster. 111 With Network Policies that select a Pod, the Pod is restricted by the union of the policies' ingress and egress rules (order of application of policies doesn't matter, it's a union). 112 113 ## Calico 114 Two types of CNI plugins: 115 - CNI network plugins: responsible for adding/deleting pods to/from Kubernetes pod network 116 - CNI IPAM plugins: responsible for allocating and releasing IPs for pods as they are created/deleted