8.3 컨테이너, 오케스트레이션, 클라우드 네이티브

개요와 동기

컨테이너는 애플리케이션을 그 의존성과 함께 하나의 이식 가능하고 격리된 단위로 포장합니다. 노트북에서도, 테스트 환경에서도, 프로덕션에서도 같은 방식으로 실행됩니다. 오케스트레이션 플랫폼, 가장 두드러지게는 쿠버네티스는 기계 군단에 걸쳐 많은 수의 컨테이너를 스케줄하고 관리합니다. 배치, 확장, 상태, 네트워킹, 복구를 처리합니다. 클라우드 네이티브는 이 기초 위에 세워진 더 넓은 아키텍처 스타일로, 느슨하게 결합되고, 독립적으로 배포 가능하며, 수평으로 확장 가능한 서비스로 설계되어 동적이고 자가 복구하는 인프라를 가정하는 애플리케이션입니다.

큰 팀에게 컨테이너와 오케스트레이션은 하나의 어려운 문제를 해결합니다. 여러 팀이 만든 많은 서비스를 공유 인프라에서 믿을 만하고 효율적으로 운영해야 합니다. 컨테이너는 모든 팀에 일관된 패키징과 런타임 계약을 주어 “내 기계에서는 되는데” 부류의 실패를 퇴역시킵니다. 오케스트레이션은 개별 기계를 공통 기반 뒤에 숨겨, 팀이 서버가 아니라 플랫폼에 배포하게 합니다. 이 표준화가 모든 팀이 배포, 확장, 복원력을 다시 발명하지 않고도 수백, 수천 개의 서비스를 운영하게 해 줍니다.

기업과 정부 도입자는 이식성, 복원력, 종속에서 벗어나는 길을 얻습니다. 그 대가로 실제 복잡성과 새로운 보안 책임을 물려받습니다. 컨테이너 플랫폼은 프로그래밍 가능하고 동적이기 때문에 강력하며, 이는 신중하게 다스려야 한다는 뜻입니다. 이미지 출처, 멀티테넌시 격리, 네트워크 정책, 비용이 모두 플랫폼 수준의 관심사가 됩니다. 공공 부문 도입자는 점점 주권 요건을 더합니다. 데이터가 어디에 있고 누가 접근할 수 있는지에 대한 통제입니다. 그래서 선택한 환경 전반에서 일관된 워크로드를 운영하는 능력은 기술적 세부 사항이 아니라 전략적 역량입니다.

핵심 원칙

애플리케이션을 작고, 단일 목적이며, 불변인 컨테이너 이미지로 포장하십시오.
이미지 위생을 실천하십시오. 최소한의 기본 이미지, 고정된 버전, 취약점 스캔, 서명입니다.
가능한 곳에서는 애플리케이션을 무상태이고 수평 확장 가능하게 설계하고 상태를 외부화하십시오.
오케스트레이션 플랫폼의 원하는 상태 모델을 진실의 원천으로 다루고 자가 복구하게 하십시오.
테넌트, 워크로드, 네임스페이스 사이에 격리와 최소 권한을 시행하십시오.
폐기 가능하고, 구성이 외부화되고, 수평 확장 가능한 앱을 만드는 방법론인 12팩터 원칙을 따르고, 분산 시스템의 현실에 맞게 확장하십시오.
비용을 사후 고려가 아니라 눈에 보이는 일급 엔지니어링 관심사로 만드십시오.
전략적 유연성을 지키도록 이식 가능하고 표준 기반인 추상화를 선호하십시오.

권장 사항

엄격한 이미지 위생을 실천한다

컨테이너 이미지는 신뢰와 배포의 기본 단위이므로 그렇게 다루십시오. 공격 표면을 줄이도록 최소한의 신뢰할 수 있는 기본 이미지에서 시작하십시오. 재현성을 위해 의존성과 기본 이미지 버전을 고정하십시오. 빌드 파이프라인에서 모든 이미지의 알려진 취약점을 스캔하고, 치명적 발견이 있는 것은 막으십시오. 승인되고 수정되지 않은 이미지만 돌도록 이미지를 서명하고 배포 시점에 서명을 검증하십시오. 팀이 거기서 빌드하는 강화된 기본 이미지의 선별된 내부 레지스트리를 유지하십시오. 이는 좋은 보안 기본값을 자동으로 퍼뜨립니다.

쿠버네티스 패턴을 다시 발명하지 않고 쓴다

쿠버네티스는 확립된 패턴을 채택하는 팀에 보상하고 그 모델과 싸우는 팀을 벌합니다. 원하는 상태에 선언형 매니페스트를 쓰십시오. 플랫폼이 건강하지 않은 인스턴스를 탐지하고 교체할 수 있도록 상태 프로브를 더하십시오. 스케줄러가 워크로드를 안전하게 채워 넣을 수 있도록 자원 요청과 한도를 설정하십시오. 탄력적 수요에는 수평 자동 확장을 쓰십시오. 데이터베이스 관리, 인증서 교체, 사용자 정의 자원 조정처럼 지속적으로 돌아야 하는 운영 로직에는, 사람의 운영 지식을 상태를 지켜보고 행동하는 소프트웨어로 코드화하는 오퍼레이터 패턴을 쓰십시오. 플랫폼 위에 맞춤 오케스트레이션을 만들고 싶은 충동에 저항하십시오. 네이티브 구성 요소를 선호하십시오.

멀티테넌시를 의도적으로 설계한다

많은 팀이 클러스터를 공유할 때 격리는 호의가 아니라 보안과 신뢰성의 요건입니다. 네임스페이스를 테넌시 경계로 쓰십시오. 어떤 테넌트도 다른 테넌트를 굶기지 못하도록 자원 쿼터를 시행하십시오. 트래픽을 명시적으로 허용된 것으로 제한하는 네트워크 정책을 적용하십시오. 역할 기반 접근 통제(RBAC)로 각 팀이 할 수 있는 일을 제한하십시오. 더 강한 격리가 필요한 워크로드에는 별도 클러스터나 더 강한 샌드박싱을 고려하십시오. 모델이 소프트 멀티테넌시(신뢰하는 내부 팀)인지 하드 멀티테넌시(서로 불신하는 워크로드)인지 일찍 정하십시오. 둘은 매우 다른 통제를 요구하기 때문입니다.

클라우드 네이티브로, 12팩터와 그 너머를 구축한다

명시적 의존성, 환경 속 구성, 무상태 프로세스, 폐기 가능성 등을 갖춘 12팩터 방법론은 동적 플랫폼에서 번성하는 서비스에 여전히 훌륭한 기준선입니다. 분산 시스템의 추가된 현실에 맞게 확장하십시오. 부분 실패를 위해 설계하십시오. 작업을 멱등하고 재시도 가능하게 만드십시오. 상태와 텔레메트리를 노출하십시오. 관측 가능성을 애드온이 아니라 내장된 기능으로 다루십시오. 애플리케이션 인스턴스가 폐기 가능하고 수평 확장 가능하게 남도록 모든 상태를 관리형 데이터 서비스로 외부화하십시오.

멀티 클라우드, 하이브리드, 주권 전략을 실용적으로 계획한다

이식성은 가치 있지만 분명한 눈으로 추구하십시오. 필요하면 워크로드를 옮길 수 있도록 컨테이너, 쿠버네티스, 개방형 API 같은 이식 가능한 추상화로 표준화하십시오. 그러나 모든 관리형 서비스를 거부하는 덫은 피하십시오. 이는 실제 생산성을 가설적 이식성과 맞바꿉니다. 하이브리드와 주권 요건에는 같은 워크로드와 파이프라인이 선택한 리전, 사설 데이터 센터, 관할권과 데이터 거주 규칙을 충족하는 주권 클라우드에서 돌 수 있도록 설계하십시오. 주권과 거주의 경계를 아키텍처와 정책에서 명시적으로 만드십시오.

FinOps로 비용을 보이게 한다

탄력적 클라우드 환경에서 비용은 엔지니어링 결정의 직접적 결과이므로 엔지니어에게 가시성과 책임을 주십시오. 비용 배분을 위해 자원에 태그를 달고, 지출을 팀과 서비스에 귀속시키고, 성능 지표 옆에 비용 데이터를 보이십시오. 워크로드의 크기를 조정하고, 수요에 맞게 자동 확장을 쓰고, 놀고 있는 자원을 회수하십시오. 엔지니어링, 재무, 제품을 한데 모으는 FinOps 실천을 확립해, 클라우드 지출이 분기마다의 놀람이 아니라 공유되고 지속적인 책임이 되게 하십시오.

장단점

선택	장점	단점	가장 적합한 곳
쿠버네티스	강력하고 이식 가능하며 거대한 생태계	가파른 복잡성. 운영 부담	규모에서 많은 서비스
관리형 컨테이너 서비스	더 적은 운영 부담. 더 빠른 시작	일부 종속. 더 적은 통제	단순함을 원하는 팀
단일 공유 클러스터	효율적인 자원 사용	격리가 더 어려움. 피해 범위	신뢰하는 내부 테넌트
테넌트별 클러스터	강한 격리	더 높은 비용과 오버헤드	불신하거나 규제된 워크로드
멀티 클라우드 이식성	유연성. 종속 회피	최소 공통분모 서비스	전략적 위험 완화
깊은 단일 클라우드 관리형 서비스	최대 생산성	벤더 의존	속도 중심 팀

포괄적 트레이드오프는 역량 대 복잡성입니다. 쿠버네티스와 클라우드 네이티브 아키텍처는 탄력성, 복원력, 속도를 전달합니다. 그러나 작은 팀이 으레 과소평가하는 상당한 운영적, 인지적 부담을 부과합니다. 마찬가지로 완전한 멀티 클라우드 이식성을 쫓는 것은 생산성을 선택권과 맞바꿉니다. 올바른 답은 규모와 위험에 달려 있습니다. 많은 팀과 강한 거버넌스 필요가 있는 대규모 조직은 보통 투자를 정당화합니다. 더 작은 노력은 복잡성을 숨기는 관리형 서비스가 더 잘 맞는 경우가 많습니다.

팀과 논의할 질문

이미지를 서명하고 배포 시점에 서명을 검증하며, 치명적 취약점이 실제로 빌드를 막습니까? 이미지는 신뢰의 단위이므로 그 둘레의 공급망에는 경고가 아니라 하드 관문이 어울립니다. 서명되고 검증된 이미지만 돌 수 있는지, 스캔이 치명적 발견을 막는지 그냥 기록하는지, 팀이 거기서 빌드하는 강화된 기본 이미지의 선별된 레지스트리를 누가 유지하는지 정하십시오. 기업과 정부 워크로드에서 이것은 흔히 컴플라이언스 요건이며, 오염된 의존성이 프로덕션에 닿는 것에 대한 최선의 방어이기도 합니다. 현재 상태를 가져오십시오. 실행 중인 이미지의 몇 퍼센트가 강화된 기본에서 왔는지, 몇 개가 패치되지 않은 치명적 CVE를 지녔는지, 서명되지 않은 이미지가 지금 스케줄될 수 있는지입니다. 치명적 발견이 배포를 막지 못한다면, 스캐너는 장식입니다.
값비싼 용량을 놀리지 않으면서, 자원 요청, 한도, 쿼터가 한 워크로드가 이웃을 굶기지 못하게 하는 방식은 무엇입니까? 공유 클러스터에서 한도 없는 워크로드는 주변의 모든 것을 충돌시키거나 억제할 수 있고, 너무 후하게 설정된 쿼터는 플랫폼을 정당화하는 활용률 이득을 낭비합니다. 합리적인 기본값, 누가 튜닝하는지, 요청이 아예 설정되지 않은 워크로드를 어떻게 잡는지 정하십시오. 규모에서 이것은 신뢰성 통제이자 비용 통제입니다. 크기 조정이 FinOps 절감의 상당 부분이 사는 곳이기 때문입니다. 데이터를 가져오십시오. 현재 클러스터 활용률, 워크로드가 축출되거나 억제되는 빈도, 쿼터가 없는 네임스페이스입니다. 목표는 조밀하고 안전한 빈 패킹이므로, 빠진 한도를 플랫폼이 거부하는 결함으로 다루십시오.
컨테이너 안에 어떤 상태가 살 수 있고, 나머지는 모두 어디로 갑니까? 클라우드 네이티브 복원력은 플랫폼이 마음대로 재스케줄할 수 있는 폐기 가능한 인스턴스에 달려 있으며, 이는 중요한 상태가 컨테이너의 로컬 디스크가 아니라 관리형 데이터 서비스에 살 때만 유지됩니다. 규칙을 명시적으로 정하십시오. 우연히 컨테이너에 저장된 상태는 다음 재스케줄 때 데이터 손실이 되기 때문입니다. 오래된 애플리케이션을 이전하는 팀에게 이것은 흔히 가장 어려운 부분입니다. 레거시 서비스는 안정적인 로컬 파일시스템을 가정하기 때문입니다. 목록을 가져오십시오. 어떤 서비스가 로컬 상태를 쓰는지, 어떤 것이 스티키 세션이나 노드 어피니티에 의존하는지, 각각을 외부화하려면 무엇이 필요한지입니다. 상태가 외부에 있기 전까지, 탄력적으로 보이지만 실제로 옮길 수 없는 컨테이너가 있는 것입니다.
많은 팀이 클러스터를 공유할 때, 격리 모델을 소프트나 하드 멀티테넌시로 의도적으로 골랐으며, 통제가 그 선택에 맞습니까? 네임스페이스는 신뢰하는 내부 팀을 분리하지만, 적극적으로 적대적이거나 침해된 워크로드를 가두지는 못하며, 소프트 테넌시를 하드인 것처럼 다루는 것은 기다리는 보안 사고입니다. 워크로드마다 테넌트가 공정한 공유만 필요한지, 서로 불신한다고 가정해야 하는지 정한 뒤 통제를 맞추십시오. 소프트의 경우 네임스페이스, 쿼터, 네트워크 정책, RBAC, 하드의 경우 별도 클러스터나 더 강한 샌드박싱입니다. 큰 조직에서 이 결정은 비용을 직접 좌우합니다. 테넌트별 클러스터는 공유 네임스페이스보다 훨씬 비싸므로, 격리 예산을 위협 모델이 요구하는 곳에만 쓰고 싶습니다. 테넌트 목록을 가져오십시오. 오늘 어떤 워크로드가 클러스터를 공유하는지, 어느 것이 규제되거나 외부 대면 트래픽을 처리하는지, 네트워크 정책이 여전히 기본 허용인 곳이 어디인지입니다. 기업과 정부 환경에서 불신하는 워크로드를 소프트 테넌시 아래 섞는 것은 바로 감사자가 지적할 발견이므로, 그들보다 먼저 경계의 이름을 정하십시오.
멀티 클라우드 이식성에 얼마를 치르고 있으며, 실제로 쓸 날이 있습니까? 컨테이너, 쿠버네티스, 개방형 API로 표준화하면 워크로드를 옮길 수 있게 유지되지만, 그 선택권을 지키려고 모든 관리형 서비스를 거부하는 것은 조직이 결코 행사하지 않을 수 있는 이식성을 위해 실제 일상의 생산성을 맞바꿉니다. 이식성이 진정한 요건인 곳, 예컨대 서명한 주권이나 퇴출 의무와, 모든 팀을 늦추는 위안 담요인 곳을 정하십시오. 경쟁하는 고려는 속도입니다. 깊은 관리형 서비스는 기능을 더 빨리 출하하고, 최소 공통분모 아키텍처는 모든 팀에 대한 상시 세금입니다. 증거를 가져오십시오. 어떤 관리형 서비스를 피했고 그것이 엔지니어링 시간으로 얼마를 치렀는지, 제공자 사이에서 워크로드를 옮긴 적이 있는지, 계약이 실제로 무엇을 의무화하는지입니다. 정부와 규제 도입자에게 데이터 거주와 주권 클라우드 규칙은 이식성을 협상 불가로 만들 수 있으므로, 같은 매니페스트와 파이프라인이 주권 리전과 사설 구역에서 돌도록 설계하되, 이것이 공짜 보험이 아니라 컴플라이언스 비용임을 정직하게 인정하십시오.
각 팀이 자기가 쓰는 것을 볼 수 있으며, 청구서가 놀람이 되기 전에 누군가 소유합니까? 탄력적 플랫폼에서 비용은 엔지니어링 결정의 직접적 산출물이지만, 비용 배분 태그와 보이는 대시보드가 없으면 지출은 재무가 에스컬레이션할 때까지 아무도 책임을 느끼지 않는 공유 풀로 쌓입니다. 비용을 팀과 서비스에 어떻게 귀속시키는지, 누가 리뷰하는지, 엔지니어가 성능 지표 옆에서 비용을 보는지 분기마다 한 번 듣기만 하는지 정하십시오. 긴장은 책무 대 마찰입니다. 비용을 너무 세게 밀면 모든 결정이 예산 협상이 되고, 무시하면 놀고 지나치게 큰 워크로드가 조용히 복리로 쌓입니다. 숫자를 가져오십시오. 팀별 현재 지출, 얼마의 용량이 놀거나 지나치게 큰지, 폭주하는 워크로드가 얼마나 빨리 알려질지입니다. 기업과 정부 예산에서 귀속되지 않은 클라우드 지출은 거버넌스의 실패이자 실제 재무 위험이므로, 사후에 조정하는 대신 엔지니어링, 재무, 제품이 같은 대화에 있도록 FinOps 실천을 세우십시오.

분야별 관점

스타트업. 자체 호스팅 쿠버네티스 클러스터보다 관리형 컨테이너 서비스에 손을 뻗으십시오. 서비스가 몇 개뿐이고 플랫폼 엔지니어가 없다면 컨트롤 플레인은 감당할 수 없는 방해입니다. 최소한의 기본에서 작은 이미지를 포장하고, 버전을 고정하고, 빌드에 취약점 스캔 하나를 더하고, 인스턴스가 폐기 가능하게 유지되도록 모든 상태를 관리형 데이터베이스로 밀어 넣으십시오. 그것을 정당화할 서비스와 사람이 실제로 생기기 전에는 네임스페이스, 오퍼레이터, 멀티 클라우드 이식성은 건너뛰십시오.

소기업. 전담 플랫폼 전문가도 빠듯한 예산도 없으니 관리형 서비스에 크게 기대고, 인력을 두어야 할 오케스트레이션을 제공자가 운영하게 하십시오. 컨테이너 기본을 보안의 바닥으로 다루십시오. 최소한의 이미지, 버전 고정, 파이프라인의 스캔이 적은 노력으로 대부분의 보호를 줍니다. 만드는 것보다 지원되는 플랫폼을 사는 쪽을 선호하고, 가격이나 약관이 바뀌어도 갇히지 않도록 표준 컨테이너와 개방형 API라는 충분한 이식성을 유지하십시오.

대기업. 과업은 많은 팀에 걸친 플랫폼 거버넌스입니다. 강화된 기본 이미지, 서명 및 스캔 관문, 쿼터가 있는 네임스페이스 테넌시, 네트워크 정책, RBAC, 비용 배분 태그와 FinOps 대시보드를 공급하는 중앙 플랫폼 팀입니다. 수백 개 서비스가 같은 방식으로 운영되도록 배포 계약을 표준화하고, 팀이 배포를 셀프서비스하는 동안 보안, 멀티테넌시, 비용을 중앙에서 관리하십시오. 플랫폼 팀에 제대로 자금을 대십시오. 자원이 부족한 플랫폼은 조직 전체가 기다리는 병목이 되기 때문입니다.

정부. 주권, 데이터 거주, 공적 책임이 아키텍처를 형성합니다. 같은 파이프라인이 주권 리전과 인증된 온프레미스 구역에서 돌도록 표준 컨테이너와 쿠버네티스에서 워크로드를 운영하고, 거주와 접근 경계를 관례가 아니라 정책으로 코드화하십시오. 내부 강화 레지스트리에서 이미지를 가져오고, 가장 민감한 데이터에는 하드 멀티테넌시를 적용하고, 조달 규칙이 단일 벤더 종속을 금지하는 경우가 많으므로 복원력과 협상 지렛대를 주는 이식성을 유지하십시오.

사례

스타트업. 여섯 명의 스타트업이 두 서비스를 최소 기본에서 빌드한 작은 컨테이너 이미지로 포장하고, 아무도 컨트롤 플레인을 돌보지 않아도 되도록 자체 호스팅 쿠버네티스 클러스터 대신 관리형 컨테이너 서비스에서 운영합니다. 기본 이미지 버전을 고정하고 빌드에 취약점 스캔을 더하지만, 실제로 서비스가 소수를 넘기 전까지는 더 무거운 오케스트레이션 기능을 의도적으로 건너뜁니다. 상태는 관리형 Postgres 데이터베이스에 살아 컨테이너가 폐기 가능하게 유지되고, 플랫폼이 데이터 손실 없이 재시작하거나 확장할 수 있습니다.

기업. 한 통신 회사가 공유 쿠버네티스 클러스터에서 수백 개의 마이크로서비스를 운영합니다. 플랫폼 팀이 강화된 기본 이미지를 제공하고, 이미지 서명과 취약점 관문을 시행하고, 사업 부문을 쿼터, 네트워크 정책, RBAC가 있는 네임스페이스로 격리합니다. 비용 배분 태그와 FinOps 대시보드가 지출을 각 제품 라인에 귀속시키고, 자동 확장이 용량을 수요에 맞춥니다. 제품 팀은 서버를 관리하지 않고 일관된 플랫폼에 하루에 수십 번 배포합니다. 회사는 보안과 비용에 대한 중앙 통제를 유지합니다.

정부. 한 국가 보건 서비스는 시민 데이터를 국경 안에 국가 법적 통제 아래 유지해야 합니다. 표준 컨테이너와 쿠버네티스를 써서 주권 클라우드 리전에서 워크로드를 운영해, 가장 민감한 데이터를 위해 같은 파이프라인과 매니페스트가 온프레미스 인증 환경에서도 돌게 합니다. 데이터 거주와 접근 경계는 정책으로 코드화되고, 이미지는 내부 강화 레지스트리에서 가져오며, 하드 멀티테넌시가 민감한 워크로드를 격리합니다. 주권 리전과 사설 구역에 걸친 이식성은 컴플라이언스를 희생하지 않고 서비스에 복원력과 협상 지렛대를 줍니다.

비즈니스 사례: 동기, ROI, TCO

컨테이너와 오케스트레이션의 ROI는 더 높은 자원 활용률, 더 빠르고 믿을 만한 배포, 지출을 수요에 맞추는 탄력적 확장, 자가 복구를 통한 개선된 복원력에서 나옵니다. 공통 플랫폼으로 표준화하면 모든 서비스가 같은 배포 및 운영 계약을 따르므로 팀 간 중복 노력이 줄고 온보딩이 빨라집니다.

TCO 분석은 운영 부담에 대해 정직해야 합니다. 도입 비용에는 플랫폼 엔지니어링 인력, 교육, 이미지와 클러스터를 위한 보안 도구, 플랫폼 자체를 운영하는 지속적 노력이 포함됩니다. 도입하지 않는 비용에는 팀 간 일관성 없는 맞춤 배포, 값비싼 인프라의 낮은 활용률, 취약한 수동 확장, 복원력과 주권 요건을 충족하기 어려움이 포함됩니다. 리더십에게 논거는 규모에 달려 있습니다. 어느 서비스 수 아래에서는 복잡성이 보답하지 않을 수 있고 관리형 서비스가 더 현명합니다. 그러나 기업과 정부 규모에서는 거버넌스가 적용되는 클라우드 네이티브 플랫폼이 보통 가장 비용 효율적이고 복원력 있는 기초이며, 플랫폼 팀이 제대로 운영하도록 자금을 댄다는 전제가 있습니다.

안티패턴과 함정

뚱뚱하고 스캔되지 않은 이미지. 신뢰할 수 없는 기본에서 만든 비대한 이미지는 불필요한 취약점을 지니고 모든 것을 느리게 합니다.
모든 것에 쿠버네티스. 소수의 단순한 서비스에 복잡한 오케스트레이터를 채택하면 보답 없이 복잡성만 삽니다.
자원 한도 무시. 요청과 한도가 없으면 한 워크로드가 이웃을 굶기거나 충돌시킬 수 있습니다.
적대적 워크로드에 소프트 테넌시. 불신하는 테넌트를 네임스페이스만으로 격리하는 것은 기다리는 보안 사고입니다.
우연히 상태를 지닌 컨테이너. 폐기 가능한 컨테이너에 중요한 상태를 저장하면 재스케줄 때 데이터 손실이 납니다.
비용 맹목. 클라우드 지출을 엔지니어링 산출물이 아니라 고정 간접비로 다루면 폭주하는 청구서로 이어집니다.
이식성 연극. 조직이 결코 쓰지 않을 이식성을 지키려고 모든 관리형 서비스를 거부하는 것.

성숙도 모델

1단계: 시작. 컨테이너가 있다 해도 즉흥적으로 쓰입니다. 이미지는 손으로 빌드되고 스캔되지 않으며, 배포는 수동적이고 반응적이고, 공유 플랫폼도 비용 가시성도 격리 모델도 없습니다.

2단계: 발전. 팀이 애플리케이션을 컨테이너화하고 오케스트레이터를 채택하지만 실천은 그룹마다 다릅니다. 이미지 스캔, 자원 한도, 서명이 일관되지 않고, 비용과 멀티테넌시는 체계적으로 다스려지지 않습니다.

3단계: 표준화. 표준화된 플랫폼이 조직 전체에 문서화되어 시행됩니다. 강화된 기본 이미지, 서명 및 스캔 관문, 쿼터와 네트워크 정책이 있는 네임스페이스 기반 테넌시, RBAC, 비용 배분입니다. 클라우드 네이티브와 12팩터 패턴은 지역적 선택이 아니라 기대되는 규범입니다.

4단계: 관리. 플랫폼이 기준선에 대해 측정되고 통제됩니다. 클러스터 활용률, 강화된 기본에서 빌드된 실행 중 이미지의 비율, 패치되지 않은 치명적 취약점, 배포 빈도와 변경 실패율, 축출 및 억제율, 예산에 대한 팀별 및 서비스별 비용을 추적합니다. 관문은 이 증거로 시행됩니다. 빠진 자원 한도와 서명되지 않은 이미지는 자동으로 거부되고, 표준에서의 드리프트는 경고가 아니라 행동을 촉발합니다.

5단계: 오케스트레이션. 플랫폼이 셀프서비스이고 자가 복구하며, 조직 전체에 통합되어 적응적입니다. FinOps가 용량을 지속적으로 크기 조정하고 회수하며, 이식 가능한 아키텍처가 하이브리드와 주권 요건을 뒷받침하고, 플랫폼은 워크로드, 비용, 위험 상황이 이동함에 따라 구성 요소를 퇴역시키고 교체하며 측정된 사용으로 지속적으로 개선됩니다.

논의를 위한 아이디어

어느 규모에서 쿠버네티스 도입이 복잡성 그 자체를 멈추고 보답하기 시작합니까?
워크로드에 맞는 소프트와 하드 멀티테넌시 사이의 올바른 경계는 어디입니까?
멀티 클라우드 이식성에 깊은 관리형 서비스의 생산성에 견주어 얼마나 투자해야 합니까?
모든 결정을 예산 협상으로 만들지 않고 엔지니어에게 실제 비용 책무를 주려면 어떻게 합니까?
기본 이미지의 거버넌스 모델은 무엇이며, 강화된 레지스트리는 누가 유지합니까?
주권과 데이터 거주 요건은 플랫폼 아키텍처를 어떻게 형성합니까?

핵심 요점

컨테이너는 패키징과 런타임을 표준화하고, 오케스트레이션은 규모에서의 운영을 표준화합니다.
이미지 위생, 곧 최소한이고, 고정되고, 스캔되고, 서명된 이미지는 기초적인 보안입니다.
맞춤 오케스트레이션을 만드는 대신 네이티브 쿠버네티스 패턴과 오퍼레이터를 쓰십시오.
워크로드가 서로를 얼마나 신뢰하는지에 따라 멀티테넌시 모델을 의도적으로 고르십시오.
12팩터를 따르고 부분 실패와 관측 가능성 같은 분산 시스템의 현실에 맞게 확장하십시오.
비용을 엔지니어링 산출물로 다루고 FinOps로 지속적으로 관리하십시오.

참고 문헌과 더 읽을거리

Adam Wiggins, The Twelve-Factor App (methodology).
Brendan Burns, Joe Beda, and Kelsey Hightower, Kubernetes Up & Running.
Bilgin Ibryam and Roland Huß, Kubernetes Patterns.
Cornelia Davis, Cloud Native Patterns.
J.R. Storment and Mike Fuller, Cloud FinOps.
Liz Rice, Container Security.
Cloud Native Computing Foundation (CNCF), cloud-native definition and landscape.