Kubernetes 모범 사례. 작은 컨테이너 만들기

Kubernetes에 배포하는 첫 번째 단계는 애플리케이션을 컨테이너에 배치하는 것입니다. 이 시리즈에서는 작고 안전한 컨테이너 이미지를 만드는 방법을 살펴보겠습니다.
Docker 덕분에 컨테이너 이미지 생성이 그 어느 때보다 쉬워졌습니다. 기본 이미지를 지정하고, 변경 사항을 추가하고, 컨테이너를 만듭니다.

이 기술은 시작하기에 적합하지만, 기본 기본 이미지를 사용하면 취약점으로 가득 찬 대형 이미지 작업이 안전하지 않을 수 있습니다.

또한 Docker의 대부분 이미지는 기본 이미지로 Debian 또는 Ubuntu를 사용합니다. 이는 뛰어난 호환성과 손쉬운 사용자 지정을 제공하지만(Docker 파일은 단 두 줄의 코드만 사용) 기본 이미지는 컨테이너에 수백 메가바이트의 추가 로드를 추가할 수 있습니다. 예를 들어, Go "hello-world" 애플리케이션을 위한 간단한 node.js 파일은 약 700MB인 반면, 실제 애플리케이션 크기는 몇 메가바이트에 불과합니다.

따라서 이 모든 추가 작업량은 디지털 공간의 낭비이며 보안 취약점과 버그가 숨어 있는 훌륭한 은신처입니다. 그럼 컨테이너 이미지의 크기를 줄이는 두 가지 방법을 살펴보겠습니다.

첫 번째는 작은 기본 이미지를 사용하는 것이고, 두 번째는 빌더 패턴을 사용하는 것입니다. 더 작은 기본 이미지를 사용하는 것이 컨테이너 크기를 줄이는 가장 쉬운 방법일 것입니다. 아마도 사용 중인 언어나 스택은 기본 이미지보다 훨씬 작은 원본 애플리케이션 이미지를 제공할 것입니다. node.js 컨테이너를 살펴보겠습니다.

Docker에서 기본적으로 node:8 기본 이미지 크기는 670MB이고 node:8-alpine 이미지 크기는 65MB, 즉 10배 더 작습니다. 더 작은 Alpine 기본 이미지를 사용하면 컨테이너 크기가 크게 줄어듭니다. Alpine은 컨테이너를 작게 유지하면서 많은 애플리케이션과 호환되기 때문에 Docker 사용자들 사이에서 매우 인기가 있는 작고 가벼운 Linux 배포판입니다. 표준 Docker "노드" 이미지와 달리 "node:alpine"은 많은 서비스 파일과 프로그램을 제거하고 애플리케이션을 실행하는 데 충분한 파일과 프로그램만 남깁니다.

더 작은 기본 이미지로 이동하려면 Dockerfile을 업데이트하여 새 기본 이미지 작업을 시작하세요.

이제 이전 onbuild 이미지와 달리 코드를 컨테이너에 복사하고 종속성을 설치해야 합니다. 새 Dockerfile에서 컨테이너는 node:alpine 이미지로 시작한 다음 코드에 대한 디렉터리를 만들고 NPM 패키지 관리자를 사용하여 종속성을 설치하고 마지막으로 server.js를 실행합니다.

이 업그레이드로 인해 컨테이너 크기가 10배 더 작아졌습니다. 프로그래밍 언어 또는 스택에 기본 이미지 축소 기능이 없으면 Alpine Linux를 사용하십시오. 또한 컨테이너의 콘텐츠를 완벽하게 관리하는 기능도 제공합니다. 작은 기본 이미지를 사용하는 것은 작은 컨테이너를 빠르게 만드는 좋은 방법입니다. 그러나 빌더 패턴을 사용하면 훨씬 더 큰 감소를 달성할 수 있습니다.

해석된 언어에서는 소스 코드가 먼저 해석기에 전달된 다음 직접 실행됩니다. 컴파일된 언어에서는 소스 코드가 먼저 컴파일된 코드로 변환됩니다. 그러나 컴파일에서는 코드를 실행하는 데 실제로 필요하지 않은 도구를 사용하는 경우가 많습니다. 이는 최종 컨테이너에서 이러한 도구를 완전히 제거할 수 있음을 의미합니다. 이를 위해 빌더 패턴을 사용할 수 있습니다.

코드는 첫 번째 컨테이너에서 생성되고 컴파일됩니다. 그런 다음 컴파일된 코드는 해당 코드를 컴파일하는 데 필요한 컴파일러와 도구 없이 최종 컨테이너로 패키징됩니다. 이 과정을 통해 Go 애플리케이션을 실행해 보겠습니다. 먼저 onbuild 이미지에서 Alpine Linux로 이동하겠습니다.

새 Dockerfile에서 컨테이너는 golang:alpine 이미지로 시작됩니다. 그런 다음 코드용 디렉터리를 생성하고 이를 소스 코드에 복사한 다음 해당 소스 코드를 빌드하고 애플리케이션을 실행합니다. 이 컨테이너는 onbuild 컨테이너보다 훨씬 작지만 실제로 필요하지 않은 컴파일러 및 기타 Go 도구를 여전히 포함하고 있습니다. 그럼 컴파일된 프로그램을 추출하여 자체 컨테이너에 넣어 보겠습니다.

이 Docker 파일에서 이상한 점을 발견할 수 있습니다. 두 개의 FROM 행이 포함되어 있습니다. 처음 4줄 섹션은 AS 키워드를 사용하여 이 단계의 이름을 지정한다는 점을 제외하면 이전 Dockerfile과 완전히 동일해 보입니다. 다음 섹션에는 새 이미지를 시작하는 새로운 FROM 행이 있습니다. 여기서 golang:alpine 이미지 대신 Raw alpine을 기본 이미지로 사용합니다.

Raw Alpine Linux에는 SSL 인증서가 설치되어 있지 않으므로 HTTPS를 통한 대부분의 API 호출이 실패하므로 일부 루트 CA 인증서를 설치해 보겠습니다.

이제 재미있는 부분이 나옵니다. 컴파일된 코드를 첫 번째 컨테이너에서 두 번째 컨테이너로 복사하려면 두 번째 섹션의 5행에 있는 COPY 명령을 사용하면 됩니다. 하나의 애플리케이션 파일만 복사하며 Go 유틸리티 도구에는 영향을 미치지 않습니다. 새로운 다단계 Docker 파일에는 크기가 12MB에 불과한 컨테이너 이미지가 포함됩니다. 이는 700MB였던 원래 컨테이너 이미지와 비교하여 큰 차이입니다!
따라서 작은 기본 이미지와 빌더 패턴을 사용하는 것은 많은 작업 없이 훨씬 더 작은 컨테이너를 만드는 좋은 방법입니다.
애플리케이션 스택에 따라 이미지와 컨테이너 크기를 줄이는 추가 방법이 있을 수 있지만 작은 컨테이너가 실제로 측정 가능한 이점을 제공합니까? 작은 컨테이너가 매우 효과적인 두 가지 영역, 즉 성능과 보안을 살펴보겠습니다.

성능 향상을 평가하려면 컨테이너를 생성하고 이를 레지스트리에 삽입(푸시)한 다음 거기에서 검색(풀)하는 프로세스의 기간을 고려하십시오. 더 작은 컨테이너가 더 큰 컨테이너에 비해 뚜렷한 이점이 있다는 것을 알 수 있습니다.

Docker는 레이어를 캐시하므로 후속 빌드가 매우 빨라집니다. 그러나 컨테이너를 구축하고 테스트하는 데 사용되는 많은 CI 시스템은 레이어를 캐시하지 않으므로 상당한 시간이 절약됩니다. 보시다시피 대형 컨테이너를 구축하는 데 걸리는 시간은 머신 성능에 따라 34초에서 54초로, 빌더 패턴을 사용하면 컨테이너를 사용할 때 23초에서 28초로 단축됩니다. 이런 종류의 작업의 경우 생산성은 40~50% 증가합니다. 그러니 코드를 몇 번이나 빌드하고 테스트하는지 생각해 보세요.

컨테이너가 빌드된 후 Kubernetes 클러스터에서 사용할 수 있도록 해당 이미지(푸시 컨테이너 이미지)를 컨테이너 레지스트리에 푸시해야 합니다. Google Container Registry를 사용하는 것이 좋습니다.

Google Container Registry(GCR)를 사용하면 원시 스토리지 및 네트워킹 비용만 지불하고 추가 컨테이너 관리 비용은 없습니다. 비공개적이고 안전하며 매우 빠릅니다. GCR은 풀 작업 속도를 높이기 위해 많은 트릭을 사용합니다. 보시다시피 go:onbuild를 사용하여 Docker 컨테이너 이미지 컨테이너를 삽입하는 데는 컴퓨터 성능에 따라 15~48초가 소요되며, 더 작은 컨테이너를 사용한 동일한 작업은 14~16초가 소요되며, 생산성이 떨어지는 시스템의 경우 작업 속도의 이점이 3배 증가합니다. 더 큰 컴퓨터의 경우 GCR이 이미지 공유 데이터베이스에 전역 캐시를 사용하므로 시간이 거의 동일합니다. 즉, 이미지를 전혀 로드할 필요가 없습니다. 저전력 컴퓨터에서는 CPU가 병목 현상을 일으키기 때문에 작은 컨테이너를 사용하는 이점은 여기서 훨씬 더 큽니다.

GCR을 사용하는 경우 빌드 시스템의 일부로 GCB(Google Container Builder)를 사용하는 것이 좋습니다.

보시다시피 이를 사용하면 생산적인 머신보다 Build+Push 작업 기간을 단축하여 훨씬 더 나은 결과를 얻을 수 있습니다. 이 경우 컨테이너를 빌드하고 호스트로 보내는 프로세스가 거의 2배 가속화됩니다. . 또한 매일 120분의 무료 빌드 시간을 얻을 수 있으며, 이는 대부분의 경우 컨테이너 구축 요구 사항을 충족합니다.

다음으로 가장 중요한 성능 지표인 Pull 컨테이너 검색 또는 다운로드 속도가 나옵니다. 그리고 푸시 작업에 소요되는 시간을 별로 신경 쓰지 않는다면 풀 프로세스의 길이는 전체 시스템 성능에 심각한 영향을 미칩니다. 세 개의 노드로 구성된 클러스터가 있고 그 중 하나가 실패한다고 가정해 보겠습니다. Google Kubernetes Engine과 같은 관리 시스템을 사용하는 경우 데드 노드가 자동으로 새 노드로 교체됩니다. 그러나 이 새 노드는 완전히 비어 있으므로 작업을 시작하려면 모든 컨테이너를 해당 노드로 끌어야 합니다. 가져오기 작업이 충분히 오래 걸리면 클러스터는 전체 시간 동안 더 낮은 성능으로 실행됩니다.

이러한 일이 발생할 수 있는 경우는 많습니다. 클러스터에 새 노드를 추가하거나, 노드를 업그레이드하거나, 배포를 위해 새 컨테이너로 전환하는 경우도 있습니다. 따라서 풀 추출 시간을 최소화하는 것이 핵심 요소가 됩니다. 작은 컨테이너가 큰 컨테이너보다 훨씬 빠르게 다운로드된다는 것은 부인할 수 없는 사실입니다. Kubernetes 클러스터에서 여러 컨테이너를 실행하는 경우 상당한 시간 절약이 가능합니다.

이 비교를 살펴보십시오. 작은 컨테이너에 대한 가져오기 작업은 go:onbuild를 사용한 동일한 작업보다 머신의 전력에 따라 4~9배 더 적은 시간이 소요됩니다. 공유된 소형 컨테이너 기반 이미지를 사용하면 새로운 Kubernetes 노드를 배포하고 온라인 상태로 전환하는 시간과 속도가 크게 향상됩니다.

보안 문제를 살펴보겠습니다. 작은 컨테이너는 공격 표면이 더 작기 때문에 큰 컨테이너보다 훨씬 안전한 것으로 간주됩니다. 진짜야? Google Container Registry의 가장 유용한 기능 중 하나는 컨테이너의 취약점을 자동으로 검사하는 기능입니다. 몇 달 전에 온빌드 컨테이너와 다단계 컨테이너를 모두 만들었으니 거기에 취약점이 있는지 살펴보겠습니다.

그 결과는 놀랍습니다. 소형 컨테이너에서는 중형 취약점 3개만 감지되었고, 대형 컨테이너에서는 치명적 취약점 16개와 기타 취약점 376개가 발견되었습니다. 큰 컨테이너의 내용을 살펴보면 대부분의 보안 문제는 우리가 사용하는 애플리케이션과 관련이 없고 우리가 사용하지도 않는 프로그램과 관련되어 있음을 알 수 있습니다. 그래서 사람들이 공격 표면이 크다고 말할 때 그것이 바로 그런 의미입니다.

요점은 분명합니다. 시스템에 실제 성능과 보안 이점을 제공하는 작은 컨테이너를 구축하세요.

Kubernetes 모범 사례. 네임스페이스가 있는 Kubernetes의 구성

일부 광고 🙂

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. $4.99부터 시작하는 개발자용 클라우드 VPS, 귀하를 위해 우리가 발명한 고유한 보급형 서버 아날로그: VPS(KVM) E5-2697 v3(6코어) 10GB DDR4 480GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

Dell R730xd는 암스테르담의 Equinix Tier IV 데이터 센터에서 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com