DevOps/Kubernetes
Kubernetes::네트워킹 (Networking)
yscho03
2023. 12. 19. 23:11
728x90
반응형
스위칭 (Switching)
host system 의 interface 확인
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback ...
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether ...
...
interface 의 IP Address 확인
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback ...
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether ...
inet 10.100.0.104/24 brd 10.100.0.255 scope global noprefixroute enp0s3
valid_lft forever preferred_lft forever
inet6 fe80::7e07:17a3:ac9c:8770/64 scope link noprefixroute
valid_lft forever preferred_lft forever
...
라우팅 (Routing)
route 목록 조회
$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default _gateway 0.0.0.0 UG 100 0 0 enp0s3
10.32.0.0 0.0.0.0 255.240.0.0 U 0 0 0 weave
10.100.0.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s3
link-local 0.0.0.0 255.255.0.0 U 1000 0 0 enp0s3
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
route 디테일 조회
$ ip route list
or
$ ip route show
default via 10.100.0.1 dev enp0s3 proto static metric 100
10.32.0.0/12 dev weave proto kernel scope link src 10.46.0.0
10.100.0.0/24 dev enp0s3 proto kernel scope link src 10.100.0.104 metric 100
169.254.0.0/16 dev enp0s3 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
CNI (Container Network Interface)
CNI는 무엇인가?
CNI (Container Network Interface)는 컨테이너 간의 네트워킹을 제어할 수 있는 플러그인을 만들기 위한 표준
CNI 서드파티
- CNI 서드파티를 사용하는 이유는 기본 제공되는 kubenet의 기능이 너무 부족하기 때문이다.
- Calico, Weave, Cilium 등과 같은 다양한 서드파티 CNI 플러그인들이 존재한다.
CNI Weave 설치방법
$ kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
serviceaccount/weave-net created
clusterrole.rbac.authorization.k8s.io/weave-net created
clusterrolebinding.rbac.authorization.k8s.io/weave-net created
role.rbac.authorization.k8s.io/weave-net created
rolebinding.rbac.authorization.k8s.io/weave-net created
daemonset.apps/weave-net created
쿠버네티스 DNS 동작 방식
POD 도메인 형식
다음과 같은 포멧 형식으로 되어 있다.
<POD-IP-ADDRESS>.<NAMESPACE-NAME>.pod.cluster.local
$ kubectl create ns apps
namespace/apps created
$ kubectl run nginx --image=nginx -n apps
pod/nginx created
$ kubectl get pods -n apps -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 11s 10.40.0.4 node1.example.com <none> <none>
$ kubectl run busybox -n apps --image=busybox --rm --restart=Never -it -- nslookup 10-40-0-4.apps.pod.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10:53
Name: 10-40-0-4.apps.pod.cluster.local
Address: 10.40.0.4
pod "busybox" deleted
Service 도메인 형식
다음과 같은 포멧 형식으로 되어 있다.
<SERVICE-NAME>.<NAMESPACE-NAME>.svc.cluster.local
$ kubectl expose pod nginx --name=nginx-service --port 80 --namespace apps
service/nginx-service exposed
$ kubectl get svc -n apps
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP 10.96.216.150 <none> 80/TCP 11s
$ kubectl run -it test --image=busybox --rm --restart=Never -- nslookup nginx-service.apps.svc.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10:53
Name: nginx-service.apps.svc.cluster.local
Address: 10.96.216.150
pod "test" deleted
CoreDNS
CoreDNS란?
- 쿠버네티스의 클러스터 내 POD에서 어떤 도메인을 검색하고자 할 때 kube-system 네임스페이스에 실행되고 있는 CoreDNS가 네임서버로 사용된다.
CoreDNS 보기
- POD 보기
$ kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-78fcd69978-g9sl5 1/1 Running 6 (51m ago) 319d
coredns-78fcd69978-w8c9g 1/1 Running 6 (49m ago) 319d
- Deployment 보기
$ kubectl get deploy -n kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
coredns 2/2 2 2 319d
- ConfigMap 보기
$ kubectl get configmaps -n kube-system
NAME DATA AGE
coredns 1 319d
$ kubectl describe cm coredns -n kube-system
Name: coredns
Namespace: kube-system
Labels: <none>
Annotations: <none>
Data
====
Corefile:
----
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
BinaryData
====
Events: <none>
- Service 보기
$ kubectl get service -n kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 319d
- kubelet 보기
$ cat /var/lib/kubelet/config.yaml | grep -A2 clusterDNS
clusterDNS:
- 10.96.0.10
clusterDomain: cluster.local
- /etc/resolv.conf 파일 보기
$ kubectl run -it --rm --restart=Never test-pod --image=busybox -- cat /etc/resolv.conf
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
pod "test-pod" deleted
CoreDNS 확인
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 1 (64m ago) 4d2h 10.32.0.3 node2.example.com <none> <none>
$ kubectl run -it --rm --restart=Never test-pod --image=busybox -- nslookup 10-32-0-3.default.pod.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10:53
Name: 10-32-0-3.default.pod.cluster.local
Address: 10.32.0.3
pod "test-pod" deleted
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 320d
nginx-service ClusterIP 10.107.213.177 <none> 80/TCP 3s
$ kubectl run -it --rm --restart=Never test-pod --image=busybox -- nslookup nginx-service.default.svc.cluster.local
Server: 10.96.0.10
Address: 10.96.0.10:53
Name: nginx-service.default.svc.cluster.local
Address: 10.107.213.177
pod "test-pod" deleted
Ingress
Ingress란?
- 인그레스는 클러스터 외부에서 클러스터 내부 서비스로 HTTP와 HTTPS 경로를 노출한다.
트래픽 라우팅은 인그레스 리소스에 정의된 규칙에 의해 컨트롤된다.
Ingress 특징
- 인그레스는 외부에서 서비스로 접속이 가능한 URL, 로드 밸런스 트래픽, SSL / TLS 종료 그리고 이름-기반의 가상 호스팅을 제공하도록 구성할 수 있다.
- 인그레스 컨트롤러는 일반적으로 로드 밸런서를 사용해서 인그레스를 수행할 책임이 있으며, 트래픽을 처리하는데 도움이 되도록 에지 라우터 또는 추가 프런트 엔드를 구성할 수도 있다.
- 인그레스는 임의의 포트 또는 프로토콜을 노출시키지 않는다.
- HTTP와 HTTPS 이외의 서비스를 인터넷에 노출하려면 보통 Service.Type=NodePort 또는 Service.Type=LoadBalancer 유형의 서비스를 사용한다.
전제 조건들
- 인그레스 컨트롤러가 있어야 인그레스를 충족할 수 있다. 인그레스 리소스만 생성한다면 효과가 없다.
- ingress-nginx와 같은 인그레스 컨트롤러를 배포해야 할 수도 있다. 여러 인그레스 컨트롤러 중에서 선택할 수도 있다.
이상적으로, 모든 인그레스 컨트롤러는 참조 사양이 맞아야 한다. 실제로, 다양한 인그레스 컨트롤러는 조금 다르게 작동한다.
시나리오
- Ingress Controller 설치
$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.5.1/deploy/static/provider/cloud/deploy.yaml
- Ingress Resource 생성
- 이미 존재하는 Service를 활용하였다.
$ cat > ingress-resource.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: minimal-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
ingressClassName: nginx-ingress
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
$ kubectl create -f ingress-resource.yaml
- Ingress 확인
$ kubectl get svc -n ingress-nginx
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
ingress-nginx-controller LoadBalancer 10.104.133.78 <pending> 80:32446/TCP,443:30391/TCP 29m
ingress-nginx-controller-admission ClusterIP 10.100.35.33 <none> 443/TCP 29m
$ curl http://localhost:32446
728x90
반응형