Basics of Kubernetes Networking

1. ­ Networking
Giragadurai Vallirajan
CTO@Bluemeric
@Girag

2. Agenda
● Docker Networking?
● Kube ­ Basics
● Application Topology
● Networking in&out of Kube
● Q&A

3. Docker Networking
192.168.1.0/24
mysql
172.16.1.2
tomcat
172.16.1.1
192.168.2.0/24
tomcat02
172.16.1.1
192.168.3.0/24
nginx
172.16.1.1

4. Docker Networking
192.168.1.0/24
mysql
172.16.1.2
tomcat
172.16.1.1
192.168.2.0/24
tomcat02
172.16.1.1
192.168.3.0/24
nginx
172.16.1.1
NAT
NAT
NAT
NAT

5. Kubernetes
● Cluster / Node
● Name & Namespaces
● Pods
● Labels & Selectors
● Replication Controllers
● Services
● Volumes

6. Kubernetes
● Cluster / Node
● Name & Namespaces
● Pods
● Labels & Selectors
● Replication Controllers
● Services
● Volumes

7. Cluster
API Server
Scheduler
kubelet
kubelet
kubelet
UI
Client
API
USER Master
Nodes

8. Pod
API Server
Scheduler
kubelet
kubelet
kubelet
API
USER Master
Nodes
replica:2
name:nginx
cpu:1
memory:2gb

9. Pod
API Server
Scheduler
kubelet
kubelet
kubelet
USER Master
Nodes

10. Pod
API Server
Scheduler
kubelet
kubelet
kubelet
USER Master
Nodes

11. Pod
API Server
Scheduler
kubelet
kubelet
kubelet
USER Master
Nodes
Success

12. Concept :: Pod
● Small Collection of Containers
● Run togather in same machine
– Share resources
– fate
● Assigned an IP
● Share Network Namespace
– IP Address
– localhost
pod
tomcat
mysql
API

13. Concept :: Pod
● Small Collection of Containers
● Run togather in same machine
– Share resources
– fate
● Assigned an IP
● Share Network Namespace
– IP Address
– localhost
pod
tomcat
mysql
API

14. Networking :: Pod
● Pod can reach eachother without NAT
– Even across machines
● Pod IPs routable
● Assigned an IP
● Pods can egress traffic
– If firewalls allows
● No brokering of Port numbers
– Never deal with mapping

15. Networking
● all containers can communicate with all other containers without
NAT
● all nodes can communicate with all containers (and vice­versa)
without NAT
● the IP that a container sees itself as is the same IP that others see it
as
Kubernetes imposes the following fundamental requirements on
any networking implementation (barring any intentional network
segmentation policies):

16. Networking : RC
$ cat tcrc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
name: my-tc
spec:
replicas: 3
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: dockerfile/tomcat
ports:
- containerPort: 8080

17. Application Topology : RC
$ kubectl create -f ./tcrc.yaml
$ kubectl get pods -l app=tomcat -o wide
my-tc-6wsf4 1/1 Running 0 2h e2e-test-node-92mo
my-tc-tr6zt 1/1 Running 0 2h e2e-test-node-92mo
my-tc-mz1ap 1/1 Running 0 2h e2e-test-node-92mo
Check your pods ips:
$ kubectl get pods -l app=tomcat -o json | grep podIP
"podIP": "10.240.1.1",
"podIP": "10.240.1.2",
"podIP": "10.240.1.3",
10.240.1.1:8080 10.240.1.2:8080 10.240.1.3:8080

18. Networking :: Service
● Pod are ephemeral
– Follow lifecycle
● Services are group of pod act as one
– Sits behind load balancers
● Gets Stable Virtual IP
● Ports
VIP

19. Networking : Service
$ cat tcsvc.yaml
apiVersion: v1
kind: Service
metadata:
name: tcsvc
labels:
app: tomcat
spec:
ports:
- port: 8080
protocol: TCP
selector:
app: tomcat
$kubectl get svc
NAME LABELS SELECTOR IP(S) PORT(S)
tcsvc app=tomcat app=tomcat 10.0.116.146 8080/TCP

20. Application Topology : Service
$ kubectl describe svc tcvc
Name: tcsvc
Namespace: default
Labels: app=tomcat
Selector: app=tomcat
Type: ClusterIP
IP: 10.0.116.146
Port: <unnamed> 8080/TCP
Endpoints: 10.240.1.1:8080,10.240.1.2:8080,10.240.1.3:8080
Session Affinity: None
No events.
$ kubectl get ep
NAME ENDPOINTS
Tcsvc 10.240.1.1:8080,10.240.1.2:8080,10.240.1.3:8080
$ curl 10.0.116.146:8080
........

21. Networking :: Service
10.0.116.146:8080
10.240.1.1:8080
Kube-proxy
10.240.1.2:8080 10.240.1.3:8080
api-server

22. Networking :: Service
10.0.116.146:8080
10.240.1.1:8080
Kube-proxy
10.240.1.2:8080 10.240.1.3:8080
api-server
TCP /
UDP
iptable
DNAT
iptable
DNAT

23. Networking : DNS
$ kubectl get services kube-dns –namespace=kube-system
NAME LABELS SELECTOR IP(S) PORT(S)
kube-dns <none> k8s-app=kube-dns 10.0.0.10 53/UDP
53/TCP
$ cat curlpod.yaml
apiVersion: v1
kind: Pod
metadata:
name: curlpod
spec:
containers:
- image: radial/busyboxplus:curl
command:
- sleep
- "3600"
imagePullPolicy: IfNotPresent
name: curlcontainer
restartPolicy: Always

24. Networking : DNS
And perform a lookup of the tomcat Service
$ kubectl create -f ./curlpod.yaml
default/curlpod
$ kubectl get pods curlpod
NAME READY STATUS RESTARTS AGE
curlpod 1/1 Running 0 18s
$ kubectl exec curlpod -- nslookup tcsvc
Server: 10.0.0.10
Address 1: 10.0.0.10
Name: tcsvc
Address 1: 10.0.116.146

25. Types Service
● Headless Service
– Sometimes you don't need or want load­balancing and a single service IP.
In this case, you can create "headless" services by specifying "None" for
the cluster IP (spec.clusterIP).
– Discovery in their (developer) own way
● External Service
– For some parts of your application (e.g. frontends) you may want to
expose a Service onto an external (outside of your cluster, maybe public
internet) IP address.
– Kubernetes supports two ways of doing this: NodePorts and
LoadBalancers.

26. Exposing the Service
<<<<<<<<<<<<<<<<<<<<< Type NodePort >>>>>>>>>>>>>>>>>>>>>>
$ kubeclt get svc tcsvc -o json | grep -i nodeport -C 5
{
"name": "http-alt",
"protocol": "TCP",
"port": 8080,
"targetPort": 8080,
"nodePort": 32188
}
$ kubectl get nodes -o json | grep ExternalIP
{
"type": "ExternalIP",
"address": "104.197.63.17"
}
$ curl http://104.197.63.17:30645
...

27. Exposing the Service
<<<<<<<<<<<<<<<<<<<<< Type LoadBalancer >>>>>>>>>>>>>>>>>>>>>>
$ kubectl delete rc, svc -l app=tomcat
$ kubectl create -f ./tc-app.yaml
$ kubectl get svc -o json | grep -i ingress -A 5
"ingress": [
{
"ip": "104.197.68.43"
}
]
}
$ curl http://104.197.68.43:8080
...

28. Additional Resources to tap in to
(DockYard)
Manage
Images
Dashboard
Manage
Containers
Apache Licensed Open Source
https://github.com/bluemeric/dockyard

29. Additional Resources to tap in to
(#DevOpsFortNight)
● #DevOpsFortnight
from Bluemeric
Video demos / training /
webinars/ industry interviews
on DevOps for free
• Chef
• Puppet
• CI/CD
• Docker
• Kube
• OpenStack
• SDN
• Etc...
https://www.youtube.com/channel/UCPUxGV9QCjJUWgSRH5ei5mQ

30. Additional Resources to tap in to
(#gopaddlemeetup)
Bangalore ­ 1st
week of September
(to be announced).
• Use cases of Docker & Kube
• Industry perspective of DevOps
• goPaddle (demos, hands­on, use cases)

31. Thanks
Bluemeric Technologies Pvt Ltd
#187, Pearl Wood, AECS Layout, A Block,
Bangalore - 560037, India
ne: +91-8
email : info@bluemeric.com
web: http://bluemeric.com
twitter: @bluemeric