Work166 [KANS] 8주차 - Cilium CNI eBPF를 왜 사용할까?iptables의 단점을 보완하기 위함같은 NetworkPolicy를 할당받는 Pod가 무수히 많다면 Pod 수 만큼 iptables rule에 해당 NetworkPolicy가 반영되기 때문에 개수가 많아지고, 결과적으로 성능 저하로 이어짐contrack 테이블의 지속적으로 유지 관리해야함iptables의 규칙에 일치할 때까지 모든 규칙을 평가하기 때문에 비효율적임iptables는 iptables는 규칙을 변경할 때 개별 규칙만을 수정하는 것이 아니라, 전체 규칙 세트를 한 번에 교체하기 때문에 incremental update가 불가능함결과적으로 iptables를 사용하면 클러스터 규모가 커지면 커질 수록 성능 저하가 발생함eBPF는 iptables에서 kernel space와 .. 2024. 10. 26. [KANS] 6주차 - Ingress, Gateway API Ingress 개요Ingress를 이해하기 위해서는 Service의 각 유형들에 대한 이해도가 있어야 함Ingress는 클러스터 외부에서 클러스터 내부 서비스로 트래픽을 전달할 수 있도록 제공하고, Service와 달리 HTTP 및 HTTPS를 사용할 수 있도록 하는 Kubernetes의 오브젝트 Ingress는 다양한 환경과 요구사항에 맞춰 구현될 수 있어야 하고, SSL 인증서 관리, 고급 로드 밸런싱 알고리즘, 웹 애플리케이션 방화벽 등의 기능을 제공할 수 있어야 하기 때문에 Service 처럼 Built-in으로 제공되지 않고 별도로 설치해야함Ingress의 실제 동작 구현은 인그레스 컨트롤러가 처리함 (대표적으로 Nginx, Kong, AWS Loadbalancer Controller 등이 있음.. 2024. 10. 13. [KANS] 5주차 - LoadBalancer(MetalLB, IPVS) 로드밸런서 타입 개요쿠버네티스 클러스터 내 Pod로 외부에서 접속하기 위해서는 요청을 수신하기 위한 expose 설정을 해야하는데 방법 중 하나가 LoadBalancer 타입을 지정하는 것기본적으로 쿠버네티스는 로드밸런서 컴포턴트를 직접적으로 제공하지 않음public cloud를 사용하는 경우에는 CSP에서 제공하는 자체 로드밸런서를 사용온프레미스에서는 주로 MetalLB를 사용함 (MetalLB는 소프트웨어로 동작함)일반적으로 다수의 워커 노드로 트래픽을 분산하기 위해서 앞단에 로드밸런서를 두고, 로드밸런서가 수신한 요청을 대상 노드에 전달하면 수신받은 노드는 기존의 ClusterIP 타입의 동작과 동일하게 iptables rule을 통해 대상 Pod로 트래픽을 전달함이 때는 노드의 포트로 수신한 트래.. 2024. 10. 6. [KANS] 4주차 - Service (ClusterIP, NodePort) 개요Service는 쿠버네티스에서 동작하는 애플리케이션을 내/외부에서 유연하게 접속하기 위한 역할을 하며 ClusterIP, NodePort, LoadBalancer Type을 지원Service 동작에 중요한 부분을 차지하는 것이 kube-proxy 인데 kube-proxy의 ConfigMap을 보면 기본으로 iptables를 사용하는 것으로 설정되어 있음참고로 Amazon EKS는 kube-proxy의 ConfigMap이 간소화되어 설정되어 있고, 기본값이 iptables이기 때문에 굳이 명시되어 있지 않음Pod는 재생성 되면 매번 IP가 변경되기 때문에 클라이언트 입장에서는 매번 IP가 바뀌면 문제가 되기 때문에 Service 개념이 필요함고정 Virtual IP를 할당하고 Domain 주소를 생성해.. 2024. 9. 28. 이전 1 2 3 4 ··· 42 다음
