Kubernetes Networking Genel Bakis-1

KUBEPROXY, CNI:

Her node uzerinde network otomasyonunu saglamak adina tum gereken islemleri control-plane’den gelen olaylara bakarak ilgili iptables ve routing ile ilgili kurallarini olusturmaktadir.

  • Podun (container) ayaga kalktiginda sanal interfacelere baglanmasi
  • Akabinde ic networkte node uzerine tanimlanmis olan CIDR blogundan sanal bir IP almasini saglamaktir.
ADD
DEL
GET
VERSION

Podlar arasi Iletisim

Kubernetes uzerinde en unutulmamasi gereken konularin basinda podlarin uzerinde bulundugu node configurasyonun podlarin yasamini direkt olarak etkiledigidir.

Konteynir ve Interface

Ayaga kaldirilan her pod aslinda birer container ya da (podlar icerisinde birden fazla containter olabilir.) oldugundan her biri kendi icerisinde bir sanal interface’e sahip olmalidir.

$ ip a4: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
link/ether b6:81:2b:21:f8:f8 brd ff:ff:ff:ff:ff:ff
inet 100.127.249.201/32 scope global eth0
ip route ls |grep 100.101.135.85100.101.135.85 dev cali6e9890dac79 scope link

IPTABLES :

Yukarida bahsetmis oldugumuz butun islemler podun hayatina basladigi ilk andan itibaren CNI tarafindan tamamlandi ancak burada K8S ic networkunde bir POD’a herhangi bir trafik nasil gelir bu tarz yonlendirmeleri yapacagimiz husus onemli.

KUBERNETES SERVICE

Podlar kapanabilir, arti veya eksi yonde olceklenebilir buradaki her bir islem her bir poda rastgele bir IP atanacak sekilde davranmaktadir.

kubectl get svcNAME      TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
web-svc ClusterIP 100.68.152.235 <none> 80/TCP 41d
apiVersion: v1
kind: Service
metadata:
name: web-svc
spec:
selector:
app: web-service
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80
iptables -t nat -nL
iptables -t nat -nL |grep -A 3 -B 3 100.101.135.81 => KUBE-SEP-QQFKKCBX2PLEDZRJ
iptables -t nat -nL |grep -A 3 -B 3 100.101.135.80 => KUBE-SEP-MOC4GDVGPEPVJSDN
iptables -t nat -nL |grep -A 3 -B 3 100.101.135.76 => KUBE-SEP-CYRXLGKEYPPWA5W5
Chain KUBE-SEP-QQFKKCBX2PLEDZRJ (1 references)
target prot opt source destination
KUBE-MARK-MASQ all -- 100.101.135.81 0.0.0.0/0 /* web-svc/web-svc: */
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 /* kuard/kuard: */ tcp to:100.101.135.81:80
-A KUBE-SVC-TBXKZ2STP32JFDA3-m comment --comment "robot-shop/mysql:mysql" -j KUBE-SEP-QQFKKCBX2PLEDZRJ

Pod to Service Iletisim (DNS)

Kubernetes uzerinde service ismi uzerinden bir iletisim saglamaktadir, servis isimleri dns kaydi olarak cluster icerisinde konumlanan bir dns podunda konumlanir burada su sekilde bir durum var :

kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
authentication:
anonymous:
enabled: false
.... ...... ...
clusterDomain: "cluster.local"
clusterDNS:
- "10.32.0.237"

Pod to Node to Pod Iletisim

Podlar bir node uzerinde degilde birden fazla node uzerinde schedule edilebilir burada her bir Node kendi icerisiden ana PODCIDR bloguna sadik kalarak kendileri icin bir IP blogu allocate ederler.

100.102.245.192/26 via   NODE1   dev tunl0 proto bird onlink
100.109.199.0/26 via NODE2 dev tunl0 proto bird onlink
100.120.175.0/26 via NODE3 dev tunl0 proto bird onlink

Sonuc

Kubernetes uzerinde ilk baslarda gercek ciddi sekilde nasil yuruyor diye sorguladigimiz DNS basta olmak uzere bircok komponent aslinda bugune kadar yazilmis olarak netfilter, iptables gibi ve butun bunlarin uzerine kurulu onlarca kernel modul uzerine kurulu bir calismanin sonucunda karsimiza cikan otomasyon ve soyutlama katmani olarak karsimiza cikmaktadir.

Kaynakca

--

--

PythonRubyLinux(❤)

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store