Work179 [Cilium study] 2주차 - Observability 들어가기 전 실습 환경 구성기본 배포 가상 머신 : k8s-ctr, k8s-w1, k8s-w2초기 프로비저닝으로 kubeadm init 과 join 실행됨Cilium CNI 설치 상태로 배포 완료됨Cilium을 설치 할 때 endpointHealthChecking.enabled 옵션을 통해 헬스체크 활성 여부를 선택할 수 있는데, 3~10대의 노드로 유지할 때는 헬스체크를 켜놓는 것이 유리하지만 11대 이상으로 노드 수가 많아질 경우에는 헬스 체크를 비활성화 하는 것을 권장합니다. 이는 아래 Cilium의 Scalability Report 문서에 명시되어 있으며, 노드 수가 10대를 넘어가는 경우 별도의 전문 모니터링 도구를 활용하는 것을 권장합니다. --set endpointHealthChecking... 2025. 7. 26. [Cilium study] 1주차 - Cilium 구축 환경 이해하기 로컬 환경 설정Vagrant와 VirtualBox를 기반으로 실습 환경을 설정합니다. 구성된 쿠버네티스 클러스터는 아래와 같습니다. Vagrantfile을 기반으로 vagrant up 명령을 실행하여 아래와 같이 쿠버네티스 컨트롤 플레인 1대와 워커노드 2대로 구성된 클러스터를 생성합니다. 각 서버들은 독립적으로 실행된 가상머신들이기 때문에 아래와 같이 동일 IP를 가지고 있더라도 문제는 없습니다. 쿠버네티스 클러스터에서 Pod간 통신에 활용되는 IP는 아니고 vagrant ssh와 같이 호스트와 가상 서버간 통신을 위한 IP입니다. 위 네트워크 구성은 아래와 같습니다. 쿠버네티스 네트워킹쿠버네티스의 네트워킹은 CNI를 통해 이루어지며 이 CNI는 아래 4가지 문제를 해결해야 합니다. 1. 파드 내.. 2025. 7. 18. [Istio 스터디] 9주차 - Ambient Mesh Ambient Mesh 개요Istio의 Ambient Mesh는 2022년 알파 버전으로 시작되어 2024년 GA(General Availability) 버전에 도달한 혁신적인 데이터 플레인 아키텍처입니다. Ambient Mesh는 한국어로 '주변 모드'로 번역되며, 기존 사이드카 프록시 없이 동작하는 Istio 데이터 플레인 모드를 의미합니다.사이드카 모드의 한계점:애플리케이션 간섭: 사이드카 설치나 업그레이드 시 애플리케이션 파드 재시작 필요리소스 활용도 저하: 각 파드마다 사이드카 컨테이너의 CPU/메모리 리소스 소비트래픽 차단: HTTP 구현에 맞지 않는 애플리케이션 중단 가능성컴퓨팅 비용 증가: 사이드카당 개별 리소스 할당으로 인한 비효율Ambient Mesh는 기존 사이드카 모델의 한계를 극복.. 2025. 6. 8. [Istio 스터디] 8주차 - VM Support & Istio Traffic Flow 레거시 워크로드의 정의와 통합 필요성레거시 워크로드는 Kubernetes의 파드가 아닌, VM(가상 머신) 또는 베어메탈 서버에 올라가 있는 애플리케이션을 의미레거시 워크로드를 Istio 서비스 메시에 통합 시 이점:트래픽 라우팅 관리인증 관련 기능(mTLS 통신)세밀한 권한 정책(Authorization policies)텔레메트리(Telemetry) 기능많은 기업 환경에서는 모든 워크로드를 Kubernetes로 마이그레이션하기 어려운 상황이 존재함:유지 관리하는 업체가 없어 히스토리가 불분명할 수 있음컨테이너화하려면 새로운 설계가 필요함다양한 추가 고려사항이 필요함Istio VM 지원의 주요 기법Istio의 VM 지원 기능을 통해 Kubernetes Pod와 VM 워크로드를 단일 서비스 메시로 통합할 .. 2025. 5. 31. 이전 1 2 3 4 5 ··· 45 다음
