기본적으로 HAProxy 기반 라우터를 포함하는 OpenShift Platform 버전 4.8
NGINX Ingress 컨트롤러 버전 1.11.0 (NGINX Plus R22)
백엔드 배포
다음 스크립트를 사용하여 백엔드 복제본의 수를 주기적으로 늘리거나 줄이는 백엔드 애플리케이션의 동적 배포로 테스트 실행을 수행했습니다. 이는 동적 OpenShift 환경을 에뮬레이트하고 NGINX Ingress Controller 또는 OCP 라우터가 엔드포인트 변경에 얼마나 효과적으로 적응하는지 측정합니다.
K8s라고도 불리는 Kubernetes는 컨테이너화된 애플리케이션과 워크로드의 배포, 확장, 관리를 자동화하고 조정하기 위한 오픈 소스 플랫폼입니다. 온프레미스, 클라우드, 엣지 등 모든 환경에서 컨테이너로 실행되는 앱을 위한 내장된 유연성, 확장성, 안정성, 고가용성 및 이식성을 갖춘 컴퓨팅 인프라를 제공합니다.
Kubernetes는 가장 일반적인 작업을 자동화합니다. 배포, 로드 밸런싱, 수평적 확장, 롤아웃 및 롤백, 자가 복구 등 컨테이너화된 워크로드를 대규모로 관리하는 것과 관련된
많은 조직이 이미 앱의 일부 또는 대부분에 대해 프로덕션에서 Kubernetes를 사용하고 있으며 다른 조직에서는 이를 평가하고 있습니다. Kubernetes의 인기로 인해 Kubernetes는 컨테이너 오케스트레이션 및 관리를 위한 사실상의 표준이 되었습니다.
쿠버네티스의 이점
Kubernetes 채택은 다음과 같은 도움이 될 수 있기 때문에 빠르게 증가하고 있습니다.
애플리케이션 릴리스 수명 주기를 가속화하고 단순화합니다.
퍼블릭, 프라이빗, 하이브리드 클라우드와 멀티 클라우드 환경 전반에서 워크로드 이동성을 지원합니다.
자원 활용 효율성 향상
확장성과 생산 준비성을 더욱 쉽게 달성할 수 있습니다.
비즈니스 SLA를 충족하도록 환경 최적화
Kubernetes 및 마이크로서비스
마이크로서비스라고 하는 더 작고 느슨하게 결합된 부분으로 리팩터링하면 기존의 모놀리식 애플리케이션을 새로운 앱 기능과 업데이트를 더 빠르게 출시하고 더 쉽게 확장할 수 있으므로 비즈니스 민첩성을 향상하는 데 도움이 됩니다. 클라우드 네이티브 마이크로서비스 아키텍처를 채택하면 기본 컴퓨팅 인프라를 발전시켜야 할 필요성이 높아지므로 마이크로서비스를 실행하는 가장 효율적인 방법 중 하나로 물리적 시스템과 가상 머신에서 컨테이너로의 전환이 관찰됩니다.
마이크로서비스와 컨테이너의 수가 증가함에 따라 컨테이너 관리를 자동화해야 할 필요성도 커지고 있습니다. 이것이 Kubernetes가 작동하는 이유 입니다.
쿠버네티스 대 도커
Kubernetes는 컨테이너화된 앱을 규모에 맞게 조정하고 실행합니다. 그러나 배포 및 실행을 위해 애플리케이션 코드를 컨테이너화된 형식으로 패키징하는 수단을 제공하지 않습니다(컨테이너 이미지에는 앱 코드와 필요한 런타임, 라이브러리 및 기타 소프트웨어 종속성이 포함됨). Pod를 실행하려면 Kubernetes에서도 모든 노드에 컨테이너 런타임을 설치해야 합니다. Kubernetes는 원래 Docker Engine을 컨테이너 런타임으로 사용했습니다. 그러나 Kubernetes 1.24부터 컨테이너 런타임은 컨테이너 런타임 인터페이스 Docker 엔진이 준수하지 않는 CRI( )를 준수해야 합니다. 널리 사용되는 두 가지 CRI 호환 컨테이너 런타임은 CRI-O 와 Containerd (원래 Docker 프로젝트)입니다.
도커와 같은 도구가 필요합니다. 앱을 컨테이너에 패키징하려면 컨테이너화된 앱을 빌드, 공유, 실행하는 데 가장 널리 사용되는 도구 중 하나인 Kubernetes 환경을 포함하여 클라우드에서 온프레미스로 실행하고 배포할 준비가 된 휴대용 컨테이너 이미지로 앱 패키징을 간소화하고 자동화합니다. Docker로 패키징된 컨테이너는 Containerd 및 CRI-O 런타임에서 기본적으로 실행될 수 있습니다.
쿠버네티스 아키텍처
Kubernetes 플랫폼은 풀링된 컴퓨팅 리소스를 공유하는 클러스터로 결합된 노드로 구성됩니다.각 클러스터는 Kubernetes 아키텍처에서 배포 가능한 가장 작은 단위인 Pod를 관리합니다. Pod에는 하나 이상의 앱 컨테이너가 포함되어 있습니다. 포드는 함께 그룹화되어 서비스를 구성합니다.Kubernetes 클러스터 내부의 앱은 여러 가지 방법을 사용하여 외부에서 액세스할 수 있으며, Ingress 컨트롤러는 가장 인기 있고 효율적인 방법 중 하나입니다.
Kubernetes 환경의 구성요소를 자세히 살펴보겠습니다.
Kubernetes 포드
Kubernetes 포드는 Kubernetes에 배포할 수 있는 가장 작은 실행 가능 단위입니다. 포드는 앱 컨테이너 이미지(예: 기존 앱의 물리적 서버 또는 가상 머신)에 대한 "가상 호스트"이며 동일한 컴퓨팅, 스토리지 및 네트워킹 리소스를 공유하는 하나 이상의 컨테이너를 캡슐화합니다. 비교적 단단하게 결합된 것으로 간주됩니다.) 포드는 Kubernetes 노드에 배포되고 실행됩니다.
Kubernetes 노드
Kubernetes 노드는 컴퓨팅 인프라의 가장 작은 단위입니다. 노드는 포드를 배포, 실행, 확장 및 관리하기 위해 프로세서, 메모리, 스토리지 및 네트워킹 리소스를 할당하는 가상 머신 또는 물리적 서버일 수 있습니다. 노드는 서로 결합되어 클러스터를 형성합니다.
Kubernetes 클러스터
Kubernetes 클러스터는 풀링된 컴퓨팅 리소스가 여러 포드에서 공유되는 노드 그룹입니다. 클러스터에는 두 가지 유형의 노드가 있습니다.
작업자 노드 – 포드에서 컨테이너화된 앱을 실행합니다.
마스터 노드 – 작업자 노드와 포드를 오케스트레이션하고 관리하는 Kubernetes 제어 플레인을 실행합니다.
일반적으로 고가용성과 내결함성을 위해 Kubernetes 클러스터에는 각 유형의 노드가 두 개 이상 있습니다.
Kubernetes 배포
Kubernetes 배포는 클러스터에서 Pod의 복제본(또는 인스턴스) 집합으로 앱을 실행하는 방법을 설명합니다. 배포는 다음을 정의합니다.
실행할 포드 복제본 수
Pod 업데이트를 점진적으로 출시하는 방법
포드 복제본을 이전 상태로 롤백하는 방법
포드 복제본을 수평으로 확장하는 방법
Kubernetes의 앱 연결
Kubernetes는 클러스터에서 실행되는 컨테이너화된 앱에 네트워크 연결을 제공하기 위해 듀얼 IPv4/IPv6 스택을 지원합니다. Kubernetes 클러스터의 앱과의 통신과 클러스터 내 서비스 간 통신은 모두 L4 층(IP 주소, 포트) 및 L7 계층 (호스트 이름, 범용 리소스 식별자(URI))에서 관리되며 라우팅, 로드 밸런싱, 보안, 모니터링 및 가시성 기능.을 제공합니다.
쿠버네티스 네트워킹
Kubernetes 네트워킹 모델 각 포드에는 클러스터의 개인 주소 풀에서 동적으로 할당되는 고유한 IP 주소가 있습니다. 동일한 클러스터의 모든 노드에서 실행되는 모든 포드는 동일한 IP 네트워크에 속하며 해당 네트워크를 통해 서로 통신할 수 있습니다. Pod 내의 여러 컨테이너는 루프백 인터페이스를 통해 서로 통신합니다.
쿠버네티스 서비스
Kubernetes 서비스는 클러스터에서 하나 이상의 Pod로 실행되는 앱 또는 마이크로서비스를 네트워크에서 액세스할 수 있도록("노출") 만듭니다. Kubernetes 서비스는 웹 서비스와 같은 동일한 기능을 수행하는 지정된 Pod의 논리적 그룹으로 앱을 나타냅니다. 서비스의 멤버십을 표시하기 위해 서비스의 모든 Pod에 동일한 선택기(또는 레이블)가 적용됩니다. Kubernetes는 새 Pod가 배포되거나 실행 중인 Pod가 종료될 때 레이블을 사용하여 서비스에 대한 Pod 집합을 추적합니다.
Kubernetes 서비스는 정의된 연결 정책에 따라 클러스터 내에서 서로 통신할 수 있으며, Ingress 컨트롤러 등을 사용하여 클러스터 외부에서 액세스할 수 있습니다.
쿠버네티스 인그레스
의 일부인 Ingress 객체는 Kubernetes Ingress API HTTP와 같은 레이어 7(애플리케이션 레이어) 프로토콜을 통해 Kubernetes에서 실행되는 애플리케이션을 외부에 노출하는 데 사용할 수 있습니다. Ingress 게이트웨이 및 Ingress 컨트롤러는 Ingress 객체를 제어하고 사용자와 애플리케이션 간의 통신(사용자-서비스 또는 North-South 연결)을 관리하도록 설계된 도구입니다.
불행하게도 Ingress 객체는 사용자 정의된 요청 처리 정책을 제한적으로 지원합니다. 예를 들어 보안 정책을 정의하고 연결할 수 없습니다. 결과적으로 많은 공급업체에서는 진화하는 고객 요구 사항을 충족하기 위한 방법으로 CRD(사용자 정의 리소스 정의)를 사용하여 Ingress 컨트롤러의 기능을 확장합니다.
예를 들어, NGINX 수신 컨트롤러는 Kubernetes 클러스터 에지에서 API 게이트웨이, 로드 밸런서 및 수신 기능에 대한 성능, 탄력성, 가동 시간, 보안 및 관측 가능성을 향상하기 위해 사용자 지정 리소스(VirtualServer, VirtualServerRoute, TransportServer 및 정책)를 정의합니다. 빈번한 앱 릴리스를 지원하기 위해 NGINX 사용자 정의 리소스는 다중 테넌트 개발 및 DevOps 팀 전체에서 셀프 서비스 거버넌스를 활성화합니다.
쿠버네티스 게이트웨이 API
Gateway API 는 Kubernetes의 서비스 네트워킹을 개선하고 표준화하기 위한 오픈 소스 프로젝트입니다. Kubernetes 커뮤니티에서 관리하는 Gateway API 사양은 Kubernetes Ingress API에서 발전하여 요청 처리를 위한 세분화된 정책을 정의하고 여러 팀과 역할에 걸쳐 구성에 대한 제어를 위임하는 기능을 포함하여 프로덕션 환경에서 Ingress 리소스의 제한 사항을 해결합니다.
서비스 메시
서비스 메시는 Kubernetes 클러스터의 서비스 간 통신(서비스 간 또는 동서 연결)을 제어하는 인프라 계층입니다. 서비스 메시는 로드 밸런싱, 인증, 권한 부여, 액세스 제어, 암호화, 관찰 가능성, 트래픽 분할(Circuit Breaker, A/B 테스트, 블루-그린 및 카나리아 배포)을 포함하여 Kubernetes에서 실행되는 서비스에 대한 핵심 기능을 제공합니다. 그 통신은 빠르고 안정적이며 안전합니다.
쿠버네티스 보안
Kubernetes 보안은 인프라(온프레미스 및 클라우드 컴퓨팅 리소스, 네트워킹 통신, 관리 플레인)와 Kubernetes 클러스터 내에서 실행되는 애플리케이션을 보호하기 위한 계층형 접근 방식입니다.
인프라를 보호하려면 클라우드 및 온프레미스 구현을 보호하기 위한 일반 보안 권장 사항, 자습서 및 모범 사례를 따르십시오.
클러스터로부터 그리고 클러스터 내에서 보안 애플리케이션의 경우 엣지와 Kubernetes 클러스터 내에서 강력한 보안 제어를 구현하여 인증, 권한 부여, 액세스 제어, 암호화, 모니터링 및 가시성을 제공합니다. 옵션으로 제공되는 웹 애플리케이션 방화벽 및 서비스 거부 보호 기능도 포함됩니다.
프로덕션 중인 Kubernetes
Kubernetes 도입 초기에는 DIY(Do-It-Yourself) 접근 방식이 지배적이었지만 많은 조직에서 구축 및 운영이 복잡하고 어렵습니다. 이로 인해 프로덕션 배포를 위해 조직에서는 다양한 기술 구성 요소를 통합하고 유지 관리 수명 주기를 단순화하며 하이브리드 및 멀티 클라우드 환경에 배포할 수 있는 클라우드 관리형 Kubernetes 플랫폼과 사전 패키지된 Kubernetes 배포판을 채택하고 있습니다.
마이크로서비스 아키텍처라고도 알려진 마이크로서비스는 애플리케이션을 설계하고 구축하는 방법입니다. 이는 애플리케이션을 각각 하나의 기능을 수행하지만 함께 작동하여 애플리케이션의 전체 기능을 제공하는 독립적인 서비스로 구성됩니다. 이렇게 하면 한 팀의 변경으로 인해 전체 애플리케이션이 중단될 수 없습니다. 마이크로서비스를 통해 개발 팀은 새로운 앱 구성 요소를 신속하게 구축하고 변화하는 비즈니스 요구 사항을 충족할 수 있습니다.
마이크로서비스와 모놀리식 아키텍처
마이크로서비스 아키텍처는 앱을 핵심 기능으로 세분화하는 방식으로 앱 구축에 대한 기존의 모놀리식 접근 방식과 차별화됩니다.
각 기능을 서비스라고 하며, 각 서비스를 독립적으로 배포하고 구축할 수 있습니다 이는 개별 서비스가 서로 부정적인 영향을 주지 않고 독립적으로 작동하거나 실패할 수 있음을 의미합니다.
시스템을 분할하는 각각의 소규모 개별 서비스는 강력하고 유연하며 완벽합니다. 서비스는 자율 프로세스로 실행되며 API를 통해 다른 서비스와 통신할 수 있습니다.
또한 서로 다른 플랫폼에서 서로 다른 언어로 각 마이크로서비스를 구현할 수도 있습니다. 각 인프라는 컨테이너에서 실행될 수 있으며 이러한 컨테이너는 병렬로 작동할 수 있습니다. 이를 통해 기존 인프라를 더 쉽게 유지 관리할 수 있습니다.
이와 대조적으로 모놀리식 아키텍처는 코드의 다양한 구성 요소가 공유 메모리 공간을 갖춘 하나의 응집력 있는 단위로 함께 작동하도록 설계되었음을 의미합니다. 이러한 유형의 소프트웨어는 독립형입니다. 즉, 장치가 상호 의존적이고 상호 연결되어 있습니다.
개발자가 모놀리식 시스템을 변경하려면 전체 스택을 한 번에 구축하고 배포해야 합니다. 확장성 역시 마찬가지입니다. 개별 모듈뿐만 아니라 전체 시스템을 함께 확장해야 합니다.
모놀리식 아키텍처로 인해 새로운 기술 스택을 채택하기가 어렵습니다. 그리고 새로운 프레임워크나 플랫폼을 사용하려면 전체 솔루션을 다시 작성해야 하는데 이는 번거롭고 시간이 많이 걸릴 수 있습니다.
마이크로서비스 아키텍처의 5가지 이점
그렇다면 마이크로서비스의 주요 이점은 무엇입니까? 비즈니스에 마이크로서비스 아키텍처를 고려해야 하는 이유는 다음과 같습니다.
속도 및 생산성 향상
마이크로서비스 아키텍처의 가장 큰 이점 중 하나는 앱을 관리 가능한 서비스로 분해하여 속도와 생산성 문제를 해결한다는 것입니다.
여러 팀이 동시에 앱의 다양한 구성 요소를 작업할 수 있습니다. 마이크로서비스 간에 구조적 종속성이 없기 때문에 팀은 다른 팀이 작업을 완료할 때까지 마이크로서비스를 만들거나 변경하기 위해 기다릴 필요가 없습니다. 또한 별도의 마이크로서비스를 찾으면 수정하기가 더 쉽다는 점을 명심하세요.
각 마이크로서비스를 개별적으로 테스트할 수 있으므로 품질 보증 프로세스의 속도를 높일 수 있습니다. 또한 다른 구성 요소를 계속 작업하면서 이미 개발된 구성 요소를 테스트할 수도 있습니다.
비즈니스 역량을 중심으로 구성
마이크로서비스 아키텍처의 또 다른 주요 이점은 비즈니스 우선순위에 따라 팀과 프로세스를 구성할 수 있다는 것입니다. 즉, 마이크로서비스를 사용하면 프로젝트 대신 제품을 구축할 수 있습니다.
팀은 글루 코드를 작성하는 대신 비즈니스 기능을 구축하는 데 집중합니다. 따라서 귀하가 생성하는 서비스는 여러 상황에 맞게 조정 가능합니다. 둘 이상의 비즈니스 프로세스에서 동일한 서비스를 재사용할 수 있으며 필요에 따라 다양한 비즈니스 채널을 통해 사용할 수도 있습니다.
각 팀 구성원은 특정 서비스를 담당하며 이는 스마트하고 다기능적인 팀을 구성합니다.
간편한 앱 구축 및 유지 관리
아마도 마이크로서비스 아키텍처의 가장 큰 이점은 앱을 쉽게 구축하고 유지 관리할 수 있다는 점일 것입니다. 마이크로서비스의 핵심은 단순성입니다.
애플리케이션을 더 작은 조각으로 분할하면 구축 및 유지 관리가 더 쉬워집니다. 또한 각 마이크로서비스가 별도의 코드 조각이기 때문에 코드 관리가 훨씬 쉬워집니다. 다양한 데이터베이스, 프로그래밍 언어 및 소프트웨어 환경을 사용하여 서비스를 구현할 수도 있습니다. 이러한 방식으로 각 서비스를 독립적으로 배포, 구축, 재배포하고 관리할 수 있습니다.
예를 들어 마이크로서비스가 너무 많은 메모리를 할당하거나 프로세서에 과도한 부하를 준다고 가정해 보겠습니다. 마이크로서비스 아키텍처를 사용하면 이는 해당 특정 서비스에만 영향을 미칩니다. 즉, 하나의 마이크로서비스의 문제가 전체 시스템에 영향을 미치지 않습니다.
향상된 확장성
마이크로서비스의 또 다른 주요 이점은 향상된 확장성입니다.
각 마이크로서비스는 자율적으로 실행될 수 있으므로 개별 마이크로서비스를 더 쉽게 추가, 업데이트, 제거 및 확장할 수 있습니다. 앞서 언급했듯이 애플리케이션의 다른 마이크로서비스를 중단하지 않고 이 작업을 수행할 수 있습니다.
애플리케이션에 대한 수요가 증가하면 수요 증가의 영향을 받는 마이크로서비스로 더 많은 리소스를 전환하거나 업그레이드하기만 하면 됩니다.
적절하게 조정되면 컨테이너 오케스트레이션 도구를 사용하여 개별 마이크로서비스를 자동으로 확장할 수도 있습니다. 필요한 서비스만 확장하면 회사의 클라우드 서버 리소스 비용을 크게 절약할 수 있습니다.
더 나은 데이터 보안
마이크로서비스 아키텍처는 또한 더 나은 데이터 보안을제공합니다
마이크로서비스 간에 연결이 설정되면 정보 보안이 문제가 됩니다. 그러나 보안 API를 사용하면 인증된 사용자, 애플리케이션 및 서버만 정보에 액세스할 수 있도록 하여 데이터 전송 프로세스를 보호할 수 있습니다.
마이크로서비스가 민감한 금융, 건강 또는 기타 유형의 기밀 정보를 관리하는 경우 보안 API를 사용하면 더 큰 애플리케이션에서 액세스할 수 있는 데이터를 완벽하게 제어할 수 있습니다.
컨테이너는 애플리케이션과 마이크로서비스를 대규모로 실행하는 효율성으로 인해 계속해서 인기를 얻고 있으며 Kubernetes는 컨테이너 관리 및 오케스트레이션 플랫폼의 사실상 표준입니다. Kubernetes용 NGINX 연결 스택은 컨테이너화된 워크로드에 대해 더 나은 가동 시간, 보안, 확장성 및 관찰 가능성을 제공하여 모든 Kubernetes 환경을 개선하는 데 도움이 됩니다.
동시에 온프레미스 및 퍼블릭 클라우드에 애플리케이션을 배포한 조직에서는 예산 및 인프라와 관련된 과제가 대두되고 있습니다.
복잡성 , 도구, 공급업체의 확장이 증가하면 조직이 하이브리드, 멀티 클라우드 Kubernetes 환경을 구성, 운영, 보호, 관리, 자동화하고 문제를 해결하는 것이 어렵고 비용이 많이 듭니다.
복잡한 라이선스 모델은 아키텍처 결정을 약화시켜 잠재적으로 선택한 도구의 가치에 영향을 미칠 수 있습니다.
조직은 원하는 애플리케이션 제공 목표를 달성하기 위해 도구를 사용자 정의하는 데 과도한 시간과 비용을 소비하여 초점을 다른 쪽으로 돌리게 하여 출시 시간을 지연시킬 수 있습니다 .
Kubernetes용 NGINX Connectivity Stack을 통해 조직은 안전하고 빠르며 안정적인 NGINX 데이터 플레인 기능을 위한 번들 도구 세트를 얻을 수 있습니다. 배포된 Kubernetes 노드를 기반으로 하는 간소화된 라이선스는 다양한 사용 사례 및 시나리오를 서비스하는 데 필요한 NGINX 인스턴스 수를 제한하지 않습니다.
Kubernetes 번들의 연결 스택 이점
Kubernetes 번들용 NGINX 연결 스택은 다음과 같은 이점을 제공합니다.
무제한 의 NGINX Ingress Controller 및 NGINX App Protect 포드와 단순화된 패키징은 조직이 최적이 아닌 아키텍처 및 비즈니스 결정을 강요하지 않고도 작업을 수행하는 데 필요한 유연성을 제공합니다.
단일 패키지를 사용하여 Kubernetes 플랫폼의 확장성, 관찰 가능성, 거버넌스 및 보안과 관련된 다양한 사용 사례 세트를 쉽게 구성합니다 .
노드당 라이선스를 통해 앱과 워크로드를 확장하는 예측 가능하고 저렴한 비용으로 제공됩니다.
Kubernetes 번들 구성요소에 대한 연결 스택
Kubernetes용 NGINX 연결 스택에는 다음 구성 요소가 포함되어 있습니다.
NGINX Ingress Controller – API 게이트웨이, 로드 밸런서, 보안 및 관찰 기능을 사용하여 Kubernetes 클러스터 엣지에서 앱 연결을 관리합니다.
NGINX Gateway Fabric – 안전하고 빠르며 안정적인 NGINX 데이터 플레인을 사용하여 하이브리드 및 멀티 클라우드 Kubernetes 환경 전반에 걸쳐 Kubernetes Gateway API를 구현합니다.
NGINX App Protect – Kubernetes 앱 및 API를 위한 F5의 업계 최고의 WAF 및 서비스 거부(DoS) 보호 기능입니다.
NGINX Management Suite 인스턴스 관리자 – 조직의 모든 NGINX 인스턴스를 검색하고 모니터링합니다.
NodePort, LoadBalancer, Ingress 컨트롤러...
고객&커뮤니티와 Kubernetes를 프로덕션 수준으로 만드는 것에 대해 이야기할 때 가장 흔한 질문 중 하나는 Ingress 컨트롤러가 필요한가입니다.
이 질문에 대한 답은 간단한 예 또는 아니요가 아닌 경우가 많지만, 대신 파드로 트래픽을 유도하는 다양한 방법에 대한 교육이 포함됩니다.
이 블로그에서는 Kubernetes 네트워킹의 기본 사항을 다루므로 Ingress 컨트롤러가 필요한지 여부와 언제 필요한지에 대한 정보에 입각한 결정을 내릴 수 있습니다.
쿠버네티스는 외부 트래픽을 파드로 라우팅하는 데 여러 가지 가능한 접근 방식과 계층을 지원하지만, 모두 동등하게 만들어진 것은 아닙니다.
기본 모델은 kube-proxy인데, 이는 실제로 프록시가 아니며 트래픽 부하 분산, API 제어 또는 서비스 동작 모니터링을 위해 설계되지 않았습니다.
(*참고 : 파드 - 파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.)
다행히도 외부 트래픽을 관리하는 다른 방법이 있지만 계속하기 전에 Kubernetes 구성 요소를 간단히 살펴보겠습니다.
쿠버네티스는 서비스를 구성하는 파드를 감시하고 앱 요구 사항에 맞게 필요에 따라 확장합니다.
하지만 파드로 트래픽을 가져오는 방법은 무엇일까요?
여기서 두 가지 유형의 쿠버네티스 객체가 등장합니다.
서비스와 Ingress 컨트롤러입니다.
쿠버네티스 서비스란?
Kubernetes 문서에 따르면 서비스는 "Pod 세트에서 실행되는 앱을 노출하는 추상적인 방법"입니다.
서비스는 특정 노드에서의 위치가 중요하지 않도록 클러스터 또는 컨테이너 네트워크의 Pod를 연결합니다.
즉, 위치가 변경되거나 파괴되고 다시 시작될 때에도 외부 트래픽을 특정 Pod로 라우팅할 수 있습니다.
이런 방식으로 서비스는 매우 기본적인 역방향 프록시와 매우 유사하게 작동합니다.
Kubernetes로 외부 트래픽을 라우팅하는 데 관련된 여러 유형의 서비스와 서비스 객체 유형이 있습니다.
이들은 종종 서로 혼동되지만 사실 각각은 매우 다른 일을 하므로 기능, 용도 및 단점을 살펴볼 가치가 있습니다.
클러스터IP
ClusterIP는 클러스터 내의 다른 서비스가 액세스할 수 있는 Kubernetes 내의 서비스를 제공하는 기본 서비스입니다.
클러스터 외부에서는 액세스할 수 없습니다.
ClusterIP 서비스를 노출하는 유일한 방법은 kube-proxy와 같은 것을 사용하는 것이지만 이것이 의미가 있는 시나리오는 거의 없습니다.
제한된 예로는 노트북에서 서비스에 액세스하거나, 서비스를 디버깅하거나, 모니터링 및 메트릭을 살펴보는 것이 있습니다.
노드포트
NodePort 서비스는 클러스터의 모든 노드에서 특정 포트를 열고 해당 포트의 노드로 전송된 모든 트래픽을 해당 앱으로 전달합니다.
이는 앱으로 트래픽을 가져오는 매우 기본적인 방법이며 실제 트래픽 관리 사용 사례에는 많은 제한이 있습니다.
NodePort당 하나의 서비스만 가질 수 있으며 30000~32767 범위의 포트만 사용할 수 있습니다.
2768개의 포트가 많은 것처럼 들릴 수 있지만 대규모로 Kubernetes를 실행하는 조직은 빠르게 고갈될 것입니다.
또한 NodePort는 레이어 4 라우팅 규칙과 Linux iptables 유틸리티를 사용하여 레이어 7 라우팅을 제한합니다.
라우팅 제한 외에도 NodePort를 사용하는 데에는 세 가지 큰 단점이 있습니다.
다운스트림 클라이언트는 연결하기 위해 각 노드의 IP 주소를 알아야 합니다.
노드의 IP 주소나 가상 머신 호스트가 변경되면 문제가 됩니다.
NodePort는 트래픽을 여러 IP 주소로 프록시할 수 없습니다.
다이어그램에서 보듯이 NodePort는 Kubernetes 클러스터 내에서 로드 밸런싱을 제공하지 않으므로 트래픽은 서비스 전체에 무작위로 분산됩니다.
이는 서비스 과부하 및 포트 고갈로 이어질 수 있습니다.
로드 밸런서
LoadBalancer 서비스는 외부 트래픽을 허용하지만 해당 트래픽의 인터페이스로 외부 로드 밸런서를 필요로 합니다.
이는 외부 로드 밸런서가 실행 중인 파드에 매핑되도록 적절히 조정되고 재구성된 경우 레이어 7 라우팅(파드 IP 주소로)을 지원합니다.
LoadBalancer는 서비스를 외부에 노출하는 가장 인기 있는 방법 중 하나입니다.
클라우드 플랫폼에서 가장 자주 사용되며 소규모 정적 배포에 적합한 선택입니다.
관리형 Kubernetes 서비스를 사용하는 경우 클라우드 공급자가 선택한 로드 밸런서를 자동으로 받게 됩니다.
예를 들어 Google Cloud Platform에서 LoadBalancer 서비스 유형을 사용하여 네트워크 로드 밸런서를 시작할 수 있는
반면, AWS에서는 Application Load Balancer(ALB)가 기본값입니다.
노출하는 각 서비스는 모든 트래픽을 전달하는 자체 공용 IP 주소를 받지만 필터링이나 라우팅은 없으므로
거의 모든 유형의 트래픽(HTTP, TCP/UDP, WebSocket 등)을 보낼 수 있습니다.
또는 클라우드 공급자의 툴링을 사용하지 않으려는 경우(예: 더 큰 기능이나 플랫폼에 독립적인 툴이 필요한 경우)
F5 BIG-IP(외부 로드 밸런서) 및 F5 Container Ingress Services(LoadBalancer 용량으로 작동하는 운영자)와 같은 것으로 대체할 수 있습니다.
이 패턴에 대한 자세한 내용은 블로그의 동일한 아키텍처에서 BIG-IP 및 NGINX Ingress Controller 배포를 참조하세요.
LoadBalancer를 사용하여 앱을 노출하는 것은 앱 파드가 변화하는 수요 수준에 맞춰 확장해야 하는 동적 환경에서는 어렵습니다.
각 서비스가 자체 IP 주소를 받기 때문에 인기 있는 앱은 수백 개 또는 수천 개의 IP 주소를 관리해야 할 수 있습니다.
대부분의 경우 외부 로드 밸런서는 다음 다이어그램에 표시된 대로 NodePort를 통해 서비스에 연결합니다.
이렇게 하면 트래픽이 노드 전체에 고르게 분산되지만
서비스에 대한 로드 밸런싱은 여전히 불가능하므로 여전히 서비스 과부하와 포트 고갈이 발생합니다.
Kubernetes Ingress 컨트롤러란 무엇인가요?
Kubernetes 문서에 따르면 "컨트롤러는 클러스터 상태를 감시한 다음 필요한 경우 변경을 하거나 요청하는 제어 루프입니다.
각 컨트롤러는 현재 클러스터 상태를 원하는 상태에 더 가깝게 옮기려고 시도합니다."
컨트롤러는 Kubernetes에서 여러 작업의 상태를 관리하는 데 사용됩니다. 리소스를 적절히 할당하고,
영구 저장소를 지정하고, cron 작업을 관리합니다.
라우팅 컨텍스트에서 Ingress 컨트롤러는 NodePort와 LoadBalancer의 한계를 극복하는 방법입니다.
Ingress 컨트롤러는 특정 서비스에 레이블이 지정된 파드와의 외부 상호 작용을 구성하고 관리하는 데 사용됩니다.
Ingress 컨트롤러는 동적 레이어 7 라우팅을 일류 시민으로 처리하도록 설계되었습니다.
즉, Ingress 컨트롤러는 훨씬 더 세부적인 제어 및 관리의 수고로움이 덜 합니다.
Ingress 컨트롤러를 사용하면 Ingress 트래픽을 제어할 뿐만 아니라
서비스 수준 성능 메트릭을 제공하고 보안 정책의 일부로 사용할 수도 있습니다.
Ingress 컨트롤러는 TLS 종료, 여러 도메인 및 네임스페이스 처리는 물론
트래픽 로드 밸런싱과 같은 기존 외부 로드 밸런서의 많은 기능을 제공합니다.
Ingress 컨트롤러는 서비스 수준이 아닌 요청별로 트래픽을 로드 밸런싱할 수 있으며,
레이어 7 트래픽을 보다 유용하게 볼 수 있고 SLA를 시행하는 훨씬 더 나은 방법입니다.
그리고 또 다른 보너스가 있습니다.
Ingress 컨트롤러는 특정 파드에서 특정 외부 서비스로만 나가는 트래픽을 허용하는 egress 규칙을 시행하거나,
트래픽이 mTLS를 사용하여 상호 암호화되도록 할 수도 있습니다.
mTLS를 요구하는 것은 의료, 금융, 통신, 정부와 같은 산업에서 규제된 서비스를 제공하는 데 필수적이며,
종단 간 암호화(E2EE) 전략의 핵심 구성 요소입니다.
동일한 도구에서 나가는 트래픽을 제어하면 서비스에 대한 비즈니스 로직의 적용도 간소화됩니다.
Ingress와 Egress가 모두 동일한 제어 평면에 연결되어 있으면 적절한 리소스 규칙을 설정하는 것이 훨씬 쉽습니다.
다음 다이어그램은 Ingress 컨트롤러가 클라이언트의 복잡성을 줄이는 방법을 보여줍니다.
클라이언트는 더 이상 서비스의 IP 주소나 포트를 알 필요가 없습니다.
서비스 전체에 걸친 트래픽 분산이 보장됩니다.
일부 Ingress 컨트롤러는 더 많은 유연성과 제어를 위해 여러 로드 밸런싱 알고리즘을 지원합니다.
Ingress 컨트롤러를 사용하여 로드 밸런서 배포
동일한 아키텍처에서 BIG-IP 및 NGINX Ingress 컨트롤러 배포에서 논의했듯이
많은 조직에서 Ingress 컨트롤러(또는 대부분의 경우 여러 Ingress 컨트롤러 인스턴스)와
함께 외부 로드 밸런서를 배포하는 데 이점이 있는 사용 사례가 있습니다.
이는 조직에서 Kubernetes를 확장하거나 고도로 규정을 준수하는 환경에서 운영해야 할 때 특히 일반적입니다.
이러한 도구는 일반적으로 여러 팀에서 관리하고 다양한 목적으로 사용됩니다.
1. 로드 밸런서(또는 ADC)
소유자: NetOps(또는 SecOps) 팀
사용 사례: 클러스터 외부의 사용자에게 제공되는 서비스와 앱에 대한 유일한 공개 엔드포인트로서 Kubernetes 외부 보안을 용이하게 하고
상위 수준의 네트워크 관리를 제공하도록 설계된 보다 일반적인 어플라이언스로 사용됨.
2. 인그레스 컨트롤러
소유자: 플랫폼 운영 또는 DevOps 팀
사례: 북쪽에서 남쪽으로의 트래픽(HTTP2, HTTP/HTTPS, SSL/TLS 종료,
TCP/UDP, WebSocket, gRPC)의 세분화된 부하 분산, API 게이트웨이 기능, 중앙 집중식 보안 및 ID를 위한 Kubernetes 내부.
이 다이어그램은 여러 클러스터에 걸쳐 트래픽을 분산하는 로드 밸런서를 보여 주며,
클러스터에는 서비스에 균등하게 분산되도록 Ingress 컨트롤러가 있습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가와 상담하기
Red Hat OpenShift Container Platform(OCP)은 가장 인기 있는 관리형 Kubernetes 플랫폼 중 하나이며,
경쟁사와 마찬가지로 OCP에는 사용자가 빠르게 시작할 수 있도록 돕는 기본 트래픽 관리 툴링이 포함되어 있습니다.
HAProxy를 기반으로 하는 OCP 라우터는 OCP 클러스터의 기본 진입점입니다.
HTTP 및 WebSocket 트래픽을 로드 밸런싱하고, 라우터와 애플리케이션 인스턴스 간의 TLS 종료 및 TLS를 지원하며,
Pass-Through Mode에서 TLS 연결을 로드 밸런싱할 수 있습니다.
고객들은 종종 "라우터를 무료로 사용할 수 있는데
OpenShift에서 NGINX Ingress Controller를 왜 사용해야 합니까?" 라고 묻습니다.
게스트 블로거인 GigaOm의 Max Mortillaro 는 OpenShift에서 Enterprise‑Grade Ingress Controller가 필요한 이유로
NGINX Ingress Controller를 사용하려는 몇 가지 정성적 이유를 공유합니다.
> 고급 트래픽 관리 / 사용 편의성 / JWT 검증 및 WAF 통합
하지만 이 질문에 정량적 관점에서 답하는 것도 중요합니다.
이것이 우리가 OCP 환경에서 라우터와 NGINX Plus 기반 NGINX Ingress Controller (nginxINC/Kubernetes-Ingress) 의
성능 테스트를 실시한 이유이며, 테스트 중에 업스트림(백엔드) 서버의 수를 늘리거나 줄이는
동적 배포 또한 실시한 이유입니다.
성능 테스트를 수행할 때 우리는 도구의 성능을 평가하기 위해 두 가지 요소를 살펴봅니다.
동적 배포에서 최종 사용자 경험을 측정하는 데 가장 효과적인 지표는 대기 시간 백분위수 분포라는 것을 알게 되었습니다.
시스템에서 대기 시간을 더 많이 추가할수록 사용자 경험에 미치는 영향이 커집니다.
또한 사용자 경험에 대한 진정한 그림을 얻으려면 분포에서 상위 백분위수의
대기 시간을 포함해야 한다는 것을 알게 되었습니다.
자세한 설명은 블로그의 NGINX 및 HAProxy 의 클라우드에서 사용자 경험 테스트의 성능 결과 섹션을 참조하세요.
성능 테스트 결과
흥미로운 부분으로 바로 들어가서 결과를 검토해 보겠습니다.
테스트 토폴로지와 방법 에 대한 세부 사항은 다음과 같습니다.
위에서 설명한 대로 성능을 평가할 때는 지연 시간과 시간 초과/오류라는 두 가지 요소를 고려합니다.
요인 1: 지연 백분위수 분포
다음 차트에서 알 수 있듯이 NGINX Ingress Controller는 테스트 내내
무시할 수 있는 지연 시간을 추가했으며, 99.999번째 백분위수에서 최대 700ms 미만에 도달했습니다.
반면, OCP 라우터는 상당히 낮은 백분위수에서 지연 시간을 추가했으며,
지연 시간은 기하급수적으로 증가하여 99.99번째 백분위수에서 25,000ms(25초)가 조금 넘는 지점에서 정점에 도달했습니다.
이는 클러스터 환경의 변경 사항이 자주 적용되는 동안 부하가 걸리면
라우터가 사용자 경험을 저하시킬 수 있음을 보여줍니다.
요인 2: 타임아웃 및 오류
위에서 관찰된 지연은 시간 초과 및 오류에 기인할 수 있습니다.
OCP 라우터는 260개의 연결 시간 초과와 85개의 읽기 소켓 오류를 생성한
반면 NGINX Ingress 컨트롤러는 아무것도 생성하지 않았습니다.
다른 성능 테스트에서 보았듯이(동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트 참조),
라우터의 시간 초과 및 오류는 HAproxy가 동적 다시 로드를 처리하는 방식으로 인해 발생합니다.
NGINX Plus 기반 NGINX Ingress 컨트롤러는 엔드포인트가 변경될 때
NGINX Plus API를 사용하여 NGINX 구성을 동적으로 업데이트하기 때문에
시간 초과나 오류를 발생시키지 않습니다 .
테스트 설정 및 방법론
토폴로지 테스트
우리는 테스트 대상 시스템(SUT)으로서 NGINX Ingress Controller와 OpenShift Router에서 동일한 테스트를 실행했습니다.
SUT는 클라이언트에서 TLS 1.3 연결을 종료하고 클라이언트 요청을 별도의 연결을 통해 백엔드 배포로 전달했습니다.
클라이언트는 OpenShift 클러스터와 동일한 LAN에 위치한, CentOS 7을 실행하는 별도의 머신에 호스팅되었습니다.
SUT와 백엔드 배포는 VMware vSphere 6.7.0.45100에 호스팅된 OCP 클러스터에서 실행되었습니다.
TLS 암호화의 경우, 2048비트 키 크기와 완벽한 순방향 비밀성을 갖춘 RSA를 사용했습니다 .
백엔드 애플리케이션의 각 응답은 HTTP 상태 코드 와 함께 약 1KB 의 기본 서버 메타데이터로 구성되었습니다. 200 OK
테스트 방법론
클라이언트 배포
wrk2 (버전 4.0.0)를 사용하여 클라이언트 머신에서 다음 스크립트를 실행하고, 초당 1000개 요청(RPS, 옵션으로 설정)의 일정한 처리량으로 60초 동안(옵션으로 설정) 테스트 -d를-R 실행했습니다 .
./wrk -t 2 -c 50 -d 60s -R 1000 -L https://ingress-url:443/사용된 SUT 소프트웨어
백엔드 배포
다음 스크립트를 사용하여 백엔드 복제본의 수를 주기적으로 늘리거나 줄이는 백엔드 애플리케이션의 동적 배포로 테스트 실행을 수행했습니다. 이는 동적 OpenShift 환경을 에뮬레이트하고 NGINX Ingress Controller 또는 OCP 라우터가 엔드포인트 변경에 얼마나 효과적으로 적응하는지 측정합니다.
while [ 1 -eq 1 ] do oc scale deployment nginx-backend --replicas=4 sleep 10 oc scale deployment nginx-backend --replicas=2 sleep 10 done결론
마이크로서비스 방법론을 채택하는 대부분의 회사는 그 어느 때보다 더 높은 빈도로 CI/CD 파이프라인을 통해 새로운 개발을 추진하고 있습니다.
이러한 이유로 최종 사용자 경험을 방해하지 않으면서
이러한 새로운 방법론의 역량과 성능에 따라 성장하는 데이터 플레인을 활용하는 것이 중요합니다.
최적의 최종 사용자 경험을 제공하려면 모든 상황에서 모든 클라이언트 연결에 대해 지속적으로 낮은 지연 시간을 제공해야 합니다.
성능 결과에 따르면, NGINX Ingress Controller는 개발을 반복하고 개선해야 할 필요성이 높은 컨테이너화된 환경에서
최적의 최종 사용자 경험을 제공합니다.
시작하려면 NGINX Ingress Controller의 무료 평가판을 다운로드하고 NGINX Ingress Operator를 사용하여 배포하는 방법을 알아보세요 .
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
쿠버네티스란 무엇인가?
K8s라고도 불리는 Kubernetes는 컨테이너화된 애플리케이션과 워크로드의 배포, 확장, 관리를 자동화하고 조정하기 위한 오픈 소스 플랫폼입니다. 온프레미스, 클라우드, 엣지 등 모든 환경에서 컨테이너로 실행되는 앱을 위한 내장된 유연성, 확장성, 안정성, 고가용성 및 이식성을 갖춘 컴퓨팅 인프라를 제공합니다.
Kubernetes는 가장 일반적인 작업을 자동화합니다.
배포, 로드 밸런싱, 수평적 확장, 롤아웃 및 롤백, 자가 복구 등 컨테이너화된 워크로드를 대규모로 관리하는 것과 관련된
많은 조직이 이미 앱의 일부 또는 대부분에 대해 프로덕션에서 Kubernetes를 사용하고 있으며 다른 조직에서는 이를 평가하고 있습니다.
Kubernetes의 인기로 인해 Kubernetes는 컨테이너 오케스트레이션 및 관리를 위한 사실상의 표준이 되었습니다.
쿠버네티스의 이점
Kubernetes 채택은 다음과 같은 도움이 될 수 있기 때문에 빠르게 증가하고 있습니다.
Kubernetes 및 마이크로서비스
마이크로서비스라고 하는 더 작고 느슨하게 결합된 부분으로 리팩터링하면 기존의 모놀리식 애플리케이션을 새로운 앱 기능과 업데이트를 더 빠르게 출시하고 더 쉽게 확장할 수 있으므로 비즈니스 민첩성을 향상하는 데 도움이 됩니다.
클라우드 네이티브 마이크로서비스 아키텍처를 채택하면 기본 컴퓨팅 인프라를 발전시켜야 할 필요성이 높아지므로 마이크로서비스를 실행하는 가장 효율적인 방법 중 하나로 물리적 시스템과 가상 머신에서 컨테이너로의 전환이 관찰됩니다.
마이크로서비스와 컨테이너의 수가 증가함에 따라 컨테이너 관리를 자동화해야 할 필요성도 커지고 있습니다. 이것이 Kubernetes가 작동하는 이유 입니다.
쿠버네티스 대 도커
Kubernetes는 컨테이너화된 앱을 규모에 맞게 조정하고 실행합니다. 그러나 배포 및 실행을 위해 애플리케이션 코드를 컨테이너화된 형식으로 패키징하는 수단을 제공하지 않습니다(컨테이너 이미지에는 앱 코드와 필요한 런타임, 라이브러리 및 기타 소프트웨어 종속성이 포함됨).
Pod를 실행하려면 Kubernetes에서도 모든 노드에 컨테이너 런타임을 설치해야 합니다.
Kubernetes는 원래 Docker Engine을 컨테이너 런타임으로 사용했습니다. 그러나 Kubernetes 1.24부터 컨테이너 런타임은 컨테이너 런타임 인터페이스 Docker 엔진이 준수하지 않는 CRI( )를 준수해야 합니다. 널리 사용되는 두 가지 CRI 호환 컨테이너 런타임은 CRI-O 와 Containerd (원래 Docker 프로젝트)입니다.
도커와 같은 도구가 필요합니다. 앱을 컨테이너에 패키징하려면 컨테이너화된 앱을 빌드, 공유, 실행하는 데 가장 널리 사용되는 도구 중 하나인 Kubernetes 환경을 포함하여 클라우드에서 온프레미스로 실행하고 배포할 준비가 된 휴대용 컨테이너 이미지로 앱 패키징을 간소화하고 자동화합니다.
Docker로 패키징된 컨테이너는 Containerd 및 CRI-O 런타임에서 기본적으로 실행될 수 있습니다.
쿠버네티스 아키텍처
Kubernetes 플랫폼은 풀링된 컴퓨팅 리소스를 공유하는 클러스터로 결합된 노드로 구성됩니다.각 클러스터는 Kubernetes 아키텍처에서 배포 가능한 가장 작은 단위인 Pod를 관리합니다. Pod에는 하나 이상의 앱 컨테이너가 포함되어 있습니다. 포드는 함께 그룹화되어 서비스를 구성합니다.Kubernetes 클러스터 내부의 앱은 여러 가지 방법을 사용하여 외부에서 액세스할 수 있으며, Ingress 컨트롤러는 가장 인기 있고 효율적인 방법 중 하나입니다.
Kubernetes 환경의 구성요소를 자세히 살펴보겠습니다.
Kubernetes 포드
Kubernetes 포드는 Kubernetes에 배포할 수 있는 가장 작은 실행 가능 단위입니다.
포드는 앱 컨테이너 이미지(예: 기존 앱의 물리적 서버 또는 가상 머신)에 대한 "가상 호스트"이며 동일한 컴퓨팅, 스토리지 및 네트워킹 리소스를 공유하는 하나 이상의 컨테이너를 캡슐화합니다. 비교적 단단하게 결합된 것으로 간주됩니다.) 포드는 Kubernetes 노드에 배포되고 실행됩니다.
Kubernetes 노드
Kubernetes 노드는 컴퓨팅 인프라의 가장 작은 단위입니다.
노드는 포드를 배포, 실행, 확장 및 관리하기 위해 프로세서, 메모리, 스토리지 및 네트워킹 리소스를 할당하는 가상 머신 또는 물리적 서버일 수 있습니다. 노드는 서로 결합되어 클러스터를 형성합니다.
Kubernetes 클러스터
Kubernetes 클러스터는 풀링된 컴퓨팅 리소스가 여러 포드에서 공유되는 노드 그룹입니다. 클러스터에는 두 가지 유형의 노드가 있습니다.
일반적으로 고가용성과 내결함성을 위해 Kubernetes 클러스터에는 각 유형의 노드가 두 개 이상 있습니다.
Kubernetes 배포
Kubernetes 배포는 클러스터에서 Pod의 복제본(또는 인스턴스) 집합으로 앱을 실행하는 방법을 설명합니다. 배포는 다음을 정의합니다.
Kubernetes의 앱 연결
Kubernetes는 클러스터에서 실행되는 컨테이너화된 앱에 네트워크 연결을 제공하기 위해 듀얼 IPv4/IPv6 스택을 지원합니다.
Kubernetes 클러스터의 앱과의 통신과 클러스터 내 서비스 간 통신은 모두 L4 층(IP 주소, 포트) 및 L7 계층 (호스트 이름, 범용 리소스 식별자(URI))에서 관리되며 라우팅, 로드 밸런싱, 보안, 모니터링 및 가시성 기능.을 제공합니다.
쿠버네티스 네트워킹
Kubernetes 네트워킹 모델 각 포드에는 클러스터의 개인 주소 풀에서 동적으로 할당되는 고유한 IP 주소가 있습니다.
동일한 클러스터의 모든 노드에서 실행되는 모든 포드는 동일한 IP 네트워크에 속하며 해당 네트워크를 통해 서로 통신할 수 있습니다.
Pod 내의 여러 컨테이너는 루프백 인터페이스를 통해 서로 통신합니다.
쿠버네티스 서비스
Kubernetes 서비스는 클러스터에서 하나 이상의 Pod로 실행되는 앱 또는 마이크로서비스를 네트워크에서 액세스할 수 있도록("노출") 만듭니다.
Kubernetes 서비스는 웹 서비스와 같은 동일한 기능을 수행하는 지정된 Pod의 논리적 그룹으로 앱을 나타냅니다.
서비스의 멤버십을 표시하기 위해 서비스의 모든 Pod에 동일한 선택기(또는 레이블)가 적용됩니다.
Kubernetes는 새 Pod가 배포되거나 실행 중인 Pod가 종료될 때 레이블을 사용하여 서비스에 대한 Pod 집합을 추적합니다.
Kubernetes 서비스는 정의된 연결 정책에 따라 클러스터 내에서 서로 통신할 수 있으며, Ingress 컨트롤러 등을 사용하여 클러스터 외부에서 액세스할 수 있습니다.
쿠버네티스 인그레스
의 일부인 Ingress 객체는 Kubernetes Ingress API HTTP와 같은 레이어 7(애플리케이션 레이어) 프로토콜을 통해 Kubernetes에서 실행되는 애플리케이션을 외부에 노출하는 데 사용할 수 있습니다. Ingress 게이트웨이 및 Ingress 컨트롤러는 Ingress 객체를 제어하고 사용자와 애플리케이션 간의 통신(사용자-서비스 또는 North-South 연결)을 관리하도록 설계된 도구입니다.
불행하게도 Ingress 객체는 사용자 정의된 요청 처리 정책을 제한적으로 지원합니다. 예를 들어 보안 정책을 정의하고 연결할 수 없습니다. 결과적으로 많은 공급업체에서는 진화하는 고객 요구 사항을 충족하기 위한 방법으로 CRD(사용자 정의 리소스 정의)를 사용하여 Ingress 컨트롤러의 기능을 확장합니다.
예를 들어, NGINX 수신 컨트롤러는 Kubernetes 클러스터 에지에서 API 게이트웨이, 로드 밸런서 및 수신 기능에 대한 성능, 탄력성, 가동 시간, 보안 및 관측 가능성을 향상하기 위해 사용자 지정 리소스(VirtualServer, VirtualServerRoute, TransportServer 및 정책)를 정의합니다. 빈번한 앱 릴리스를 지원하기 위해 NGINX 사용자 정의 리소스는 다중 테넌트 개발 및 DevOps 팀 전체에서 셀프 서비스 거버넌스를 활성화합니다.
쿠버네티스 게이트웨이 API
Gateway API 는 Kubernetes의 서비스 네트워킹을 개선하고 표준화하기 위한 오픈 소스 프로젝트입니다.
Kubernetes 커뮤니티에서 관리하는 Gateway API 사양은 Kubernetes Ingress API에서 발전하여 요청 처리를 위한 세분화된 정책을 정의하고 여러 팀과 역할에 걸쳐 구성에 대한 제어를 위임하는 기능을 포함하여 프로덕션 환경에서 Ingress 리소스의 제한 사항을 해결합니다.
서비스 메시
서비스 메시는 Kubernetes 클러스터의 서비스 간 통신(서비스 간 또는 동서 연결)을 제어하는 인프라 계층입니다. 서비스 메시는 로드 밸런싱, 인증, 권한 부여, 액세스 제어, 암호화, 관찰 가능성, 트래픽 분할(Circuit Breaker, A/B 테스트, 블루-그린 및 카나리아 배포)을 포함하여 Kubernetes에서 실행되는 서비스에 대한 핵심 기능을 제공합니다. 그 통신은 빠르고 안정적이며 안전합니다.
쿠버네티스 보안
Kubernetes 보안은 인프라(온프레미스 및 클라우드 컴퓨팅 리소스, 네트워킹 통신, 관리 플레인)와 Kubernetes 클러스터 내에서 실행되는 애플리케이션을 보호하기 위한 계층형 접근 방식입니다.
인프라를 보호하려면 클라우드 및 온프레미스 구현을 보호하기 위한 일반 보안 권장 사항, 자습서 및 모범 사례를 따르십시오.
클러스터로부터 그리고 클러스터 내에서 보안 애플리케이션의 경우 엣지와 Kubernetes 클러스터 내에서 강력한 보안 제어를 구현하여 인증, 권한 부여, 액세스 제어, 암호화, 모니터링 및 가시성을 제공합니다. 옵션으로 제공되는 웹 애플리케이션 방화벽 및 서비스 거부 보호 기능도 포함됩니다.
프로덕션 중인 Kubernetes
Kubernetes 도입 초기에는 DIY(Do-It-Yourself) 접근 방식이 지배적이었지만 많은 조직에서 구축 및 운영이 복잡하고 어렵습니다.
이로 인해 프로덕션 배포를 위해 조직에서는 다양한 기술 구성 요소를 통합하고 유지 관리 수명 주기를 단순화하며 하이브리드 및 멀티 클라우드 환경에 배포할 수 있는 클라우드 관리형 Kubernetes 플랫폼과 사전 패키지된 Kubernetes 배포판을 채택하고 있습니다.
관리되고 사전 패키징된 Kubernetes 플랫폼의 몇 가지 예는 다음과 같습니다.
클라우드 관리 Kubernetes
사전 패키징된 Kubernetes 배포판:
컨테이너 및 마이크로서비스
컨테이너와 마이크로서비스는 지구상에서 가장 인기 있는 사이트 중 일부를 지원하지만 여전히 많은 사람들에게 미스터리입니다.
이해해야 할 네 가지 주요 기술은 다음과 같습니다.
컨테이너
컨테이너를 사용하면 다양한 플랫폼에 애플리케이션을 쉽게 배포할 수 있습니다.
마이크로서비스
마이크로서비스는 여러 개의 작은 구성 요소로 크고 복잡한 앱을 구축하는 소프트웨어 아키텍처에 대한 접근 방식이자 작은 구성 요소 자체를 가리키는 용어입니다.
Ingress Controller
Ingress 컨트롤러는 Kubernetes 애플리케이션 트래픽 라우팅의 복잡성을 추상화하고 Kubernetes 서비스와 외부 서비스 간의 브리지를 제공합니다.
서비스 매시
서비스 메시는 일반적으로 컨테이너화된 애플리케이션에 투명한 방식으로 트래픽 관리 및 보안을 처리합니다.
마이크로서비스란 무엇입니까?
먼저, 마이크로서비스란 정확히 무엇인가요? ?
마이크로서비스 아키텍처라고도 알려진 마이크로서비스는 애플리케이션을 설계하고 구축하는 방법입니다.
이는 애플리케이션을 각각 하나의 기능을 수행하지만 함께 작동하여 애플리케이션의 전체 기능을 제공하는 독립적인 서비스로 구성됩니다.
이렇게 하면 한 팀의 변경으로 인해 전체 애플리케이션이 중단될 수 없습니다.
마이크로서비스를 통해 개발 팀은 새로운 앱 구성 요소를 신속하게 구축하고 변화하는 비즈니스 요구 사항을 충족할 수 있습니다.
마이크로서비스와 모놀리식 아키텍처
마이크로서비스 아키텍처는 앱을 핵심 기능으로 세분화하는 방식으로 앱 구축에 대한 기존의 모놀리식 접근 방식과 차별화됩니다.
각 기능을 서비스라고 하며, 각 서비스를 독립적으로 배포하고 구축할 수 있습니다
이는 개별 서비스가 서로 부정적인 영향을 주지 않고 독립적으로 작동하거나 실패할 수 있음을 의미합니다.
시스템을 분할하는 각각의 소규모 개별 서비스는 강력하고 유연하며 완벽합니다.
서비스는 자율 프로세스로 실행되며 API를 통해 다른 서비스와 통신할 수 있습니다.
또한 서로 다른 플랫폼에서 서로 다른 언어로 각 마이크로서비스를 구현할 수도 있습니다.
각 인프라는 컨테이너에서 실행될 수 있으며 이러한 컨테이너는 병렬로 작동할 수 있습니다. 이를 통해 기존 인프라를 더 쉽게 유지 관리할 수 있습니다.
이와 대조적으로 모놀리식 아키텍처는 코드의 다양한 구성 요소가 공유 메모리 공간을 갖춘 하나의 응집력 있는 단위로 함께 작동하도록 설계되었음을 의미합니다. 이러한 유형의 소프트웨어는 독립형입니다. 즉, 장치가 상호 의존적이고 상호 연결되어 있습니다.
개발자가 모놀리식 시스템을 변경하려면 전체 스택을 한 번에 구축하고 배포해야 합니다.
확장성 역시 마찬가지입니다. 개별 모듈뿐만 아니라 전체 시스템을 함께 확장해야 합니다.
모놀리식 아키텍처로 인해 새로운 기술 스택을 채택하기가 어렵습니다.
그리고 새로운 프레임워크나 플랫폼을 사용하려면 전체 솔루션을 다시 작성해야 하는데 이는 번거롭고 시간이 많이 걸릴 수 있습니다.
마이크로서비스 아키텍처의 5가지 이점
그렇다면 마이크로서비스의 주요 이점은 무엇입니까? 비즈니스에 마이크로서비스 아키텍처를 고려해야 하는 이유는 다음과 같습니다.
마이크로서비스 아키텍처의 가장 큰 이점 중 하나는 앱을 관리 가능한 서비스로 분해하여 속도와 생산성 문제를 해결한다는 것입니다.
여러 팀이 동시에 앱의 다양한 구성 요소를 작업할 수 있습니다. 마이크로서비스 간에 구조적 종속성이 없기 때문에 팀은 다른 팀이 작업을 완료할 때까지 마이크로서비스를 만들거나 변경하기 위해 기다릴 필요가 없습니다. 또한 별도의 마이크로서비스를 찾으면 수정하기가 더 쉽다는 점을 명심하세요.
각 마이크로서비스를 개별적으로 테스트할 수 있으므로 품질 보증 프로세스의 속도를 높일 수 있습니다. 또한 다른 구성 요소를 계속 작업하면서 이미 개발된 구성 요소를 테스트할 수도 있습니다.
마이크로서비스 아키텍처의 또 다른 주요 이점은 비즈니스 우선순위에 따라 팀과 프로세스를 구성할 수 있다는 것입니다. 즉, 마이크로서비스를 사용하면 프로젝트 대신 제품을 구축할 수 있습니다.
팀은 글루 코드를 작성하는 대신 비즈니스 기능을 구축하는 데 집중합니다. 따라서 귀하가 생성하는 서비스는 여러 상황에 맞게 조정 가능합니다. 둘 이상의 비즈니스 프로세스에서 동일한 서비스를 재사용할 수 있으며 필요에 따라 다양한 비즈니스 채널을 통해 사용할 수도 있습니다.
각 팀 구성원은 특정 서비스를 담당하며 이는 스마트하고 다기능적인 팀을 구성합니다.
아마도 마이크로서비스 아키텍처의 가장 큰 이점은 앱을 쉽게 구축하고 유지 관리할 수 있다는 점일 것입니다. 마이크로서비스의 핵심은 단순성입니다.
애플리케이션을 더 작은 조각으로 분할하면 구축 및 유지 관리가 더 쉬워집니다. 또한 각 마이크로서비스가 별도의 코드 조각이기 때문에 코드 관리가 훨씬 쉬워집니다.
다양한 데이터베이스, 프로그래밍 언어 및 소프트웨어 환경을 사용하여 서비스를 구현할 수도 있습니다. 이러한 방식으로 각 서비스를 독립적으로 배포, 구축, 재배포하고 관리할 수 있습니다.
예를 들어 마이크로서비스가 너무 많은 메모리를 할당하거나 프로세서에 과도한 부하를 준다고 가정해 보겠습니다. 마이크로서비스 아키텍처를 사용하면 이는 해당 특정 서비스에만 영향을 미칩니다. 즉, 하나의 마이크로서비스의 문제가 전체 시스템에 영향을 미치지 않습니다.
마이크로서비스의 또 다른 주요 이점은 향상된 확장성입니다.
각 마이크로서비스는 자율적으로 실행될 수 있으므로 개별 마이크로서비스를 더 쉽게 추가, 업데이트, 제거 및 확장할 수 있습니다. 앞서 언급했듯이 애플리케이션의 다른 마이크로서비스를 중단하지 않고 이 작업을 수행할 수 있습니다.
애플리케이션에 대한 수요가 증가하면 수요 증가의 영향을 받는 마이크로서비스로 더 많은 리소스를 전환하거나 업그레이드하기만 하면 됩니다.
적절하게 조정되면 컨테이너 오케스트레이션 도구를 사용하여 개별 마이크로서비스를 자동으로 확장할 수도 있습니다. 필요한 서비스만 확장하면 회사의 클라우드 서버 리소스 비용을 크게 절약할 수 있습니다.
마이크로서비스 아키텍처는 또한 더 나은 데이터 보안을 제공합니다
마이크로서비스 간에 연결이 설정되면 정보 보안이 문제가 됩니다.
그러나 보안 API를 사용하면 인증된 사용자, 애플리케이션 및 서버만 정보에 액세스할 수 있도록 하여 데이터 전송 프로세스를 보호할 수 있습니다.
마이크로서비스가 민감한 금융, 건강 또는 기타 유형의 기밀 정보를 관리하는 경우 보안 API를 사용하면 더 큰 애플리케이션에서 액세스할 수 있는 데이터를 완벽하게 제어할 수 있습니다.
컨테이너는 애플리케이션과 마이크로서비스를 대규모로 실행하는 효율성으로 인해 계속해서 인기를 얻고 있으며 Kubernetes는 컨테이너 관리 및 오케스트레이션 플랫폼의 사실상 표준입니다. Kubernetes용 NGINX 연결 스택은 컨테이너화된 워크로드에 대해 더 나은 가동 시간, 보안, 확장성 및 관찰 가능성을 제공하여 모든 Kubernetes 환경을 개선하는 데 도움이 됩니다.
동시에 온프레미스 및 퍼블릭 클라우드에 애플리케이션을 배포한 조직에서는 예산 및 인프라와 관련된 과제가 대두되고 있습니다.
Kubernetes용 NGINX Connectivity Stack을 통해 조직은 안전하고 빠르며 안정적인 NGINX 데이터 플레인 기능을 위한 번들 도구 세트를 얻을 수 있습니다. 배포된 Kubernetes 노드를 기반으로 하는 간소화된 라이선스는 다양한 사용 사례 및 시나리오를 서비스하는 데 필요한 NGINX 인스턴스 수를 제한하지 않습니다.
Kubernetes 번들의 연결 스택 이점
Kubernetes 번들용 NGINX 연결 스택은 다음과 같은 이점을 제공합니다.
Kubernetes 번들 구성요소에 대한 연결 스택
Kubernetes용 NGINX 연결 스택에는 다음 구성 요소가 포함되어 있습니다.