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 인스턴스를 검색하고 모니터링합니다.
쿠버네티스란 무엇인가?
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 연결 스택에는 다음 구성 요소가 포함되어 있습니다.