시스템 기반의 기초지식

시스템 기반이란 애플리케이션을 가동시키기 위해 필요한 하드웨어나 OS/미들웨어 등과 같은 인프라를 말합니다.

클라우드의 등장으로 시스템 개발의 흐름이 크게 바뀌었습니다. 자사에서 데이터 센터나 기계실을 보유하여 온프레미스 환경에서 가동시키던 서버들을 클라우드 상의 가상 인스턴스로 옮기고 데이터베이스나 네트워크와 같은 클라우드 서비스를 이용함으로써 실행 환경의 구축 범위가 극도로 줄어들어 짧은 사이클로 릴리스를 반복하는 스타일로 바뀌었다.

기능 요구상항

시스템의 기능으로서 요구되는 사항을 말한다. 시스템이나 소프트웨어에서 무엇을 할 수 있는지 모아놓은것

비기능 요구사항

시스템의 성능이나 신뢰성, 확장성, 운용성, 보안 등과 같은 요구사항입니다. 기능 요구상항 이외의 모든 요구사항을 가리킵니다.

비기능 요구사항을 충족시키려면 프로그래밍 지식뿐만 아니라 시스템 기반에 관한 지식이 필요합니다.

하드웨어

시스템 기반을 구성하는 물리적인 요소로서 서버 장치 본체나 데이터를 저장하기 위한 스토리지, 전원 장치 등이 들어갑니다. 넓은 의미에서는 이러한 하드웨어들을 설치하는 데 데이터센터의 설비도 포함

네트워크

시스템 이용자가 원격지에서 액세스할 수 있도록 서버들을 연결하기 위한 요구사항입니다. 라우터, 스위치, 방화벽 등과 같은 네트워크 장비나 그것들을 연결하기 위한 케이블 배선 등도 관리합니다. 사용자가 이용하는 클라이언트 단말기에서 무선 LAN으로 연결하는 경우에는 액세스 포인트 등도 필요합니다.

OS(운영체제)

하드웨어나 네트워크 장비를 제어하기 위한 기본 소프트웨어로, 하드웨어의 리소스나 프로세스를 관리합니다. 클라이언트 OS는 Window/macOS 등이 있습니다. 클라이언트 OS는 이용자가 사용하기 쉽도록 GUI 기능이나 멀티미디어 기능이 마련되어 있습니다.

서버 OS로는 Windows Server, Unix, Linux 등이 있습니다. 서버 OS는 시스템 고속 및 안정적으로 가동하기 위해 필요한 기능으로 특화되어 있습니다. 그래서 하드웨어 성능을 최대한 끌어낼 수 있도록 만들어져 있거나 장시간 가동해도 안정적으로 작동할 수 있습니다. 또한 대량의 데이터를 효율적으로 수행하는 장치도 갖고 있습니다.

미들웨어

서버 OS 상에서 서버가 특정 역할을 다하기 위한 기능을 갖고 있는 소프트웨어 입니다. 시스템 기반을 설계할 때는 어떤 미들웨어를 어떻게 사용할지를 선택하는 것이 좋습니다.

---

가상화

가상화는 서버, 스토리지, 네트워크 및 기타 물리적 시스템에 대한 가상 표현을 생성하는데 사용할 수 있는 기술 가상 소프트웨어는 물리적 하드웨어 기능을 모방하여 하나의 물리적 머신에서 여러개의 운영 체제를 동시에 실행한다.

클라우드 컴퓨팅에서의 가상화
운영 체제(OS) 내에 가상 머신을 생성하는 하드웨어 가상화

가상화 장점

• 리소스 효율성
  가상화 전에는 각 애플리케이션 서버에 물리적인 전용 CPU가 필요하다. 서버 가상화를 사용하면 신뢰성은 그대로 유지하면서도 단일한 물리적 컴퓨터상에서 자체 OS가 있는 자체 VM에서 각각 다수의 애플리케이션을 실행할 수 있습니다. 물리적 하드웨어의 컴퓨터 용량을 최대한 활용 가능하다.

• 관리 편의성
  물리적 컴퓨터를 소프트웨어 정의형 VM으로 대체하면, 소프트웨어로 기술된 정책들을 보다 손쉽게 사용 및 관리할 수 있다. 또한 관리자는 가상화 보안 정책을 사용하여 가상 머신의 역할을 기반으로 특정 보안 구성을 지정할 수 있다. 미사용 가상 머신은 폐기하는 정책을 사용하여 공간과 컴퓨팅 파워를 절감함으로써 리소스 효율성을 더욱 높일 수도 있다.

• 가동 중단 시간 최소화
  OS 및 애플리케이션 충돌로 인해 가동 중단 시간이 발생하고 사용자 생산성에 지장을 초래할 수 있다. 관리자는 다수의 중복되는 가상 머신을 서로 간에 함께 실행하고, 문제 발생 시에 이들 간의 장애 복구를 수행할 수 있습니다.

• 더 빠른 프로비저닝
  각 애플리케이션의 하드웨어를 구매, 설치 및 구성하려면 많은 시간이 필요하다. 하드웨어가 이미 배치되어 있다면, 모든 애플리케이션을 실행하기 위한 가상 머신의 프로비저닝이 훨씬 빨라진다.

• 유연성
  동일한 하드웨어에서 여러 운영 체제를 동시에 실행

• 민첩성
  여러 운영체제 간의 파일 이동 가능

• 내결함성
  서버에 장애가 발생할 경우 서비스 및 소프트웨어는 이용 가능한 다른 서버로 이전 가능

• 비용절감
  물리적 서버의 수를 줄이고 서버의 자원을 재분배 및 재사용 가능

---

클라우드 & 온프레미스

온프레미스(On-premises)

기업 시스템에서 지금까지 상당히 많이 채택되어 온 것으로, 자사에서 데이터센터를 보유하고 시스템 구축부터 운영까지를 모두 수행하는 형태를 온프레미스라고 합니다. 온프레미스 환경에서는 시스템 기반의 구성 요소인 서버나 네트워크 장비를 모두 자사에서 직접 조달하여 시스템 요구사항에 맞춰 인프라를 구축하고 자사에서 운용을 합니다. 하드웨어 뿐만 아니라 OS나 미들웨어도 모두 자사에서 구입하며, 라이선스 관리나 버전업도 자사에서 합니다.

퍼블릭 클라우드(public cloud)

인터넷을 경유하여 불특정 다수에게 제공되는 클라우드 서비스입니다. 자사에서 데이터 센터를 보유하지 않으므로 서버나 네트워크 등 인프라와 관련된 초기 투자가 필요 없습니다. 제공할 서비스에 따라 IaaS/PaaS/SaaS 등이 있습니다. 시스템 기반 부분을 이용하는 서비스는 IaaS라고 합니다. IaaS에서는 이용하고 싶은 사양으로 된 가상 머신이나 스토리지를 선택하고 이용한 시간이나 데이터 양에 따라 요금을 지불하는 형태를 취합니다.

프라이빗 클라우드(private cloud)

특정 기업 그룹에게만 제공되는 클라우드 서비스입니다.

클라우드가 적합한 케이스

트래픽 변동이 많은 시스템

시스템에는 직원용 시스템과 고객용 시스템이 있습니다. 직원용 시스템은 이용자가 한정되어 있기때문에 트래픽을 예상하기 쉬우며 미리 마련해 둬야 할 시스템 기반의 규모나 구성을 검토하기 쉽지만, 고객용 시스템의 경우는 정확 트래픽을 예측하는 것이 극도로 어렵습니다. 트래픽 양에 따라 시스템 기반의 서버 사양이나 네트워크 대역을 가늠하는 설계를 사이징(sizing)이라고 하는데, 사이징이 어려운 시스템은 트래픽 양에 따라 시스템을 단기간에 쉽게 증설할 수 있는 클라우드 시스템으로 구성하는 것이 좋습니다.

재해 대책으로 해외에 백업을 구축하고 싶은 시스템

대규모 재해로 인해 데이터센터 시스템이 다운되면 기간 업무 관련 시스템의 경우 업무를 계속 할 수 없습니다. 따라서 해외에서 백업 시스템을 가동시켜 업무를 계속시킬 필요가 있는 시스템을 구축하는 경우는 온프레미스 환경보다 클라우드가 적합합니다.

서비스를 빨리 제공하고 싶은 시스템

신규 서비스를 보다 빨리 제공하고 싶다. 시간을 단축하고 싶으면 장비 조달에 시간이 걸리는 온프레미스가 아니라 클라우드로 구축하는 게 좋습니다.

온프레미스가 적합한 케이스

높은 가용성이 요구되는 시스템

클라우드의 경우 시스템 가용성은 클라우드 업체가 보장하고 있습니다. 예를 들어, 네트워크가 잠시라도 끊어져서는 안되는 경우와 같이 클라우드 업체가 보장하는 것 이상의 가용성이 필요한 미션 크리티컬 시스템에서는 실제 환경에 적용할 수 없습니다.

기밀성이 높은 데이터를 다루는 시스템

데이터 저장 장소는 클라우드 서비스 측이 정합니다.

특수한 요구사항이 있는 시스템

범용적이지 않은 디바이스나 특수한 플랫폼에서만 움직이는 시스템을 구축하거나 이전할 필요가 있는 경우, 그러한 환경을 클라우 측이 처리해 주지 못하면 이용할 수 없습니다. 의료 시스템과 같이 전용 장비와의 연결이 필요한 경우가 이에 해당됩니다.

기존의 시스템에서 다른 시스템을 이전을 고려할 때는 어떤 시스템을 온프레미스로 남기고, 어떤 시스템 시스템을 클라우드로 옮길지 또는 새로운 시스템 도입을 생각할 때는 온프레미스와 클라우드 중 어떤 것이 적합한지 구분할 수 있어야 합니다.

---

쿠버네티스와 도커

먼저 용어를 먼저 정리하고자 합니다.

컨테이너란 우리가 구동하려는 애플리케이션을 실행할 수 있는 환경까지 감싸서, 어디서든 쉽게 실행할 수 있도록 해주는 기술입니다. PC에 프로그램을 설치할 때를 떠올려보세요. 특정 경로에 맞춰 설치를 해야 하거나, 내 컴퓨터에 필요한 옵션을 일일이 맞춰주느라 설치 과정에서 힘들었던 경험이 있을 텐데요. 컨테이너는 이러한 환경까지 모두 포함하여 독립적으로 프로그램을 실행할 수 있도록 도와주는 기술입니다. 컨테이너 환경을 묶어서 배포한 컨테이너 이미지라는 프로그램을 내려받아 구동하면 실행되기 때문에, 각종 설정 과정이 줄어 들어서 좀 더 편하게 사용할 수 있어요.

컨테이너를 사용할 때 필요한 도구가 컨테이너 런타임입니다. 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구입니다. 종류도 여러 가지가 있는데 그 중 가장 유명한것이 도커입니다. 물론 도커가 사용하는 컨테이너 규격은 표준화되어 있기 때문에 도커가 아닌 다른 컨테이너 런타임들도 도커로 만든 컨테이너를 사용할 수 있습니다.

쿠버네티스는 컨테이너 런타임을 통해 컨테이너를 다루는 도구를 말합니다. 쿠버네티스가 해주는 일은 여러 서버(노드)에 컨테이너를 분산해서 배치하거나, 문제가 생긴 컨테이너를 교체하거나 컨테이너가 사용할 비밀번호나 환경 설정을 관리하고 주입해주는 일 등입니다. 이것을 컨테이너 오케스트레이션이라고 합니다.

---

Docker

도커는 오프소스 커뮤니티 프로젝트, 오픈소스 프로젝트 툴, 해당 프로젝트를 주로 지원하는 기업인 Docker Inc. 및 해당 기업이 공식 지원하는 툴을 포함해 여러 의미를 뜻합니다. 리눅스 컨테이너에 리눅스 어플링케이션을 프로세스 격리기술을 사용하여 더 쉽게 컨테이너로 실행하고 관리할 수 있게 해주는 오픈소스 프로젝트입니다. 도커는 일반적으로 도커 엔진 혹은 도커에 관련된 모든 프로젝트를 말합니다.

도커 엔진
컨테이너를 생성하고 관리하는 주체로서 이 자체로도 컨테이너를 제어할 수 있고 다양한 기능을 제공하는 도커의 프로젝트입니다. 도커의 생태계에 있는 여러 프로젝트들은 도커 엔진을 더 효율적으로 사용하기 위한 것에 불과하기 때문에 도커의 핵심은 도커 엔진이라고 볼 수 있습니다.

• 도커는 container라고 부르는 loosely isolated environment에서 어플리케이션을 package & run할 수 있는 ability 제공

• isolation & security는 given host에서 많은 컨테이너들을 동시 run할 수 있도록 해줌

• 컨테이너는 가볍고 어플리케이션을 실행하기 위한 모든 것을 갖고 있기 때문에, 현재 host에 설치된 것에 의존 X

• 사용자는 컨테이너를 쉽게 공유 가능
  ➡ 같은 컨테이너면 같은 방식으로 동작

• 도커는 사용자가 컨테이너의 lifecycle을 관리할 수 있도록 tooling과 platform 제공

  • 컨테이너를 사용해 app + its supporting components를 develop
  • 컨테이너는 app을 배포하고 테스트하기 위한 unit이 됨
  • 준비되면 app을 컨테이너 혹은 orchestrated service 형태로 production 환경에 배포
    ➡ 이는 production 환경이 local data center든, cloud provider든, 둘의 hybrid든 상관없이 동일하게 작동

Docker 어디에 사용?

1. 빠르고 일관된 어플리케이션 제공

• 도커는 개발 lifecyle을 간소화(streamline)

  개발자가 어플리케이션과 서비스를 제공하는 local 컨테이너를 사용하여 표준화된 환경에서 작업할 수 있도록 함으로써

• 컨테이너는 CI/CD(지속적통합/지속적전달) workflows에 적합

예제 시나리오

• 개발자는 로컬에서 코드 작성 -> 도커 컨테이너를 이용해 동료와 작업 공유
• 개발자는 도커를 사용해 어플리케이션을 테스트 환경으로 push & 자동화/수동 테스트
• 개발자가 버그를 발견하면 개발 환경에서 수정하고, 테스트 및 검증을 위해 테스트 환경에 재배포
• 테스트가 완료되면 업데이트된 image를 production 환경에 push하는 것만큼 간단하게 고객에게 수정 사항 제공

2. 반응형 배포 & 확장

• 도커의 컨테이너 기반 플랫폼은 이식성이 높은(highly portable) 워크로드 고려

• 컨테이너는 개발자의 로컬 laptop, 데이터 센터의 물리적 or 가상 머신, 클라우드 제공자, 혼합 환경에서 실행 가능

• 도커의 portability & 가벼움 ➡ workload를 쉽게 동적으로 관리할 수 있게 함

  거의 실시간으로 비지니스 요구 사항에 따라 어플리케이션과 서비스를 확장/축소 가능

3. 동일한 하드웨어에 더 많은 workloads 실행

• 도커는 가볍고 빠름

  • hypervisor 기반 가상 머신에 대한 viable & cost-effective한 대안 제공
  • 비지니스 목표 달성을 위해 더 많은 컴퓨팅 용량을 사용 가능

• 도커는 고밀도 환경 + 적은 리소스로 많은 일을 해야 하는 small/medium 배포에 적합

도커 아키텍쳐(Docker Architecture)

client-server 구조

• 도커 client는 도커 daemon과 통신

  도커 daemon은 도커 컨테이너를 빌드, 실행, 배포하는 무거운 작업을 수행

• 도커 client와 daemon은 동일한 시스템에서 실행될 수 있음 or 도커 client를 원격 daemon에 연결 가능

• 도커 client와 daemon은 UNIX 소켓 or 네트워크 인터페이스를 통해 REST API를 사용해 통신

• 다른 도커 client는 컨테이너 세트로 구성된 어플리케이션으로 작업할 수 있는 Docker Compose

The Docker daemon

Docker daemon(dockerd)

• Docker API 요청 수신
• image, container, network, volume 같은 도커 object 관리
• 도커 서비스들을 관리하기 위해 다른 daemons와 소통 가능

The Docker client

Docker client(docker)

• 많은 도커 사용자들이 도커와 상호 작용하는 기본적인 방법
• docker run 같은 명령어를 사용했을 때, client는 이 명령어를 carry out하는 dockerd으로 send
• docker 명령어는 Docker API를 사용
• 둘 이상의 daemon과 소통 가능

Docker Desktop

• 컨테이너화된 어플리케이션 및 microservices를 build하고 공유할 수 있는 Mac, Windows, Linux 환경에서 쉽게 설치할 수 있는 어플리케이션
• Docker daemon(dockerd), Docker client(docker), Docker Compose, Docker Content Trust, Kubernetes, Credential Helper가 포함

Docker regitries

• Docker images 저장

• Docker Hub는 누구나 사용 가능한 public registry

  도커는 default로 Docker Hub에서 image 찾도록 구성됨

• 개인 registry를 실행할 수도 있음

• docker pull or docker run 명령어를 사용하면 구성된 registry에서 요구된 image들을 pull

• docker push 명령어를 사용하면 구성된 registry로 image를 push

Docker objects

도커를 사용하면 image, container, network, volume, plugin, 기타 객체를 생성 & 사용

1. Images

• 도커 컨테이너를 생성하기 위한 지침이 담긴 read-only template

• 종종 추가적인 customization과 함께 다른 이미지를 기반

  예) ubuntu 이미지를 기반으로 하는 이미지를 build할 수 있지만, Apache 웹 서버와 본인의 어플리케이션을 설치 가능 (본인의 앱을 실행시키기 위해 필요한 configuration details 설치 뿐만 아니라)

• own image를 생성 or 다른 사람들이 만들고 registry에 published된 image를 사용

• own image를 빌드하려면 Dockerfile 생성하기

  • Dockerfile에는 image를 생성하고 실행시키기 위해 필요한 단계들을 정의한 simple syntax

    • Dockerfile에 있는 각각의 지시는 image에서 layer 생성
    • Dockerfile 수정하고 image를 재빌드하면, 수정된 layer들만 재빌드되는 것!
      ➡ 이런 부분 때문에 image가 가볍고, 작고, 빨라질 수 있는 것! (다른 virtualization 기술들에 비해)

2. Containers

• image의 실행 가능한 instance
• Docker API 혹은 CLI를 사용해서 컨테이너
• create/start/stop/move/delete
• 컨테이너를 하나 이상의 네트워크와 연결 가능

docker run 예시

장점

Docker을 사용했을 때 장점은 다음과 같다.

모듈성

컨테이너화에 대한 Docker 접근 방식은 전체 애플리케이션을 분해하지 않고도 업데이트 또는 복구를 위해 애플리케이션의 일부를 분해하는 기능에 중점을 둡니다. 이러한 마이크로서비스 기반 접근 방식 외에도 서비스 지향 아키텍처(SOA)와 거의 같은 방식으로 멀티플 애플리케이션 간에 프로세스를 공유할 수 있습니다.

계층 및 이미지 버전 제어

각 Docker 이미지 파일은 일련의 계층으로 구성되며 이러한 계층들은 단일 이미지로 결합됩니다. 계층은 이미지가 변경될 때 생성되고, 사용자가 실행 또는 복사와 같은 명령을 지정할 때마다 새 계층이 생성됩니다.

Docker는 이러한 계층을 재사용하여 새 컨테이너를 구축하는데, 이때 구축 프로세스 속도가 빨라집니다. 중간 변경 사항은 이미지 간에 공유되므로 속도와 크기, 효율성이 더욱 향상됩니다. 또한 계층화에는 버전 제어가 내재되어 있습니다. 새로운 변경 사항이 있을 때마다 변경 로그가 기본 제공되므로 컨테이너 이미지를 완벽하게 제어할 수 있습니다.

롤백

계층화의 가장 큰 장점은 아마 롤백 기능일 것입니다. 모든 이미지에는 계층이 있습니다. 현재의 이미지 반복이 적절하지 않은 경우 이전 버전으로 롤백하면 됩니다. 이 기능은 애자일 개발 접근 방식을 지원하며 툴 관점에서 실제로 지속적 통합 및 배포(CI/CD)를 수행하는 데 도움을 줍니다.

신속한 배포

이전에는 새로운 하드웨어를 확보, 실행, 프로비저닝, 제공하는 데 며칠이 걸렸으며, 이를 위한 작업 및 오버헤드 부담도 상당했습니다. Docker 기반 컨테이너는 배포 시간을 몇 초로 줄일 수 있습니다. 각 프로세스에 대한 컨테이너를 생성하면 해당 프로세스를 새 애플리케이션과 빠르게 공유할 수 있습니다. 또한 컨테이너를 추가하거나 이동하기 위해 운영 체제를 부팅할 필요가 없으므로 배포 시간이 상당히 단축됩니다. 배포 시간이 단축되면 컨테이너에서 생성한 데이터를 쉽고 비용 효율적으로 생성하고 제거할 수 있습니다.

따라서 Docker 기술은 효율성을 더욱 중요시하며 더욱 세분화되고 제어 가능한 마이크로서비스 기반 접근 방식입니다.

도커 사용법

Docker는 자체적으로 단일 컨테이너를 관리할 수 있습니다. 수백 개로 세분화된 컨테이너와 컨테이너화된 애플리케이션을 점점 더 많이 사용하게 되면 관리 및 오케스트레이션이 어려워질 수 있습니다. 결국 모든 컨테이너 전반에서 네트워킹, 보안, 텔레메트리 등의 서비스를 제공하려면 한 걸음 물러서서 컨테이너를 그룹화해야 합니다. 바로 여기에 쿠버네티스가 사용됩니다.

Docker를 사용하면 전통적인 Linux 컨테이너에서 제공되는 것과 동일한 UNIX와 같은 기능을 사용할 수 없습니다. 여기에는 컨테이너 내에서 애플리케이션과 함께 cron 또는 syslog와 같은 프로세스 사용 기능이 포함됩니다. 하위 프로세스를 종료한 후 손자 프로세스를 정리하는 작업(기존 Linux 컨테이너에서 기본적으로 처리하는 작업) 등에도 제한이 있습니다. 이러한 문제는 처음부터 바로 드러나지는 않지만 초기에 구성 파일을 수정하고 이러한 기능을 설정하면 완화할 수 있습니다.

이 외에도 네임스페이스가 지정되지 않은 다른 Linux 하위 시스템 및 기기가 있습니다. 여기에는 SELinux, Cgroups, /dev/sd* 기기 등이 있습니다. 그렇기 때문에 공격자가 이러한 하위 시스템에 대한 제어 권한을 얻을 경우 호스트가 손상됩니다. 경량을 유지하기 위해 호스트 커널을 컨테이너와 공유할 경우 이러한 보안 취약점이 발생할 수 있습니다. 호스트 커널은 호스트 시스템에서 훨씬 더 확실히 분리된 가상 머신과 다릅니다.

Docker 데몬에도 보안 우려 사항이 있을 수 있습니다. Docker 컨테이너를 사용하고 실행하기 위해 가장 많이 사용하는 것이 컨테이너의 퍼시스턴트 런타임인 Docker 데몬입니다. Docker 데몬에는 루트 권한이 필요하므로 이 프로세스에 액세스할 수 있는 사람과 프로세스 상주 위치에 각별히 주의를 기울여야 합니다. 예를 들어, 로컬 데몬의 공격 표면은 비교적 더 공개된 위치에 상주하는 데몬(예: 웹 서버)보다 작습니다.

도커의 아키텍처

리눅스 커널이 제공하는 기능을 활용하면 도커가 아니라 자체적으로 컨테이너를 만드는 것도 가능하다. 그러나 그렇게 개발한 컨테이너는 개발한 컨테이너를 재사용하는것이 어렵고 공유하기도 어렵다. 도커는 소프트웨어 개발자가 컨테이너를 이용해 개발 생산성을 높일 수 있도록 컨테이너를Build(작성), Ship(이동), Run(실행)할 수 있는 기능을 지원한다. 이러한 기능을 제공하는 도커는 도커 데몬 서버와 클라이언트인 도커 커맨드, 그리고 이미지의 보관소인 레지스트리로 구성된다.

1. 도커 데몬
   도커 데몬은 클라이언트인 도커 커맨드의 명령을 받아들여서 도커 오브젝트인 이미지, 컨테이너, 볼륨, 네트워크 등을 관리한다. 그리고 도커 데몬은 네트워크 너머에 있는 우너격 클라이언트로부터 요청을 받는 것도 가능하다.

2. 도커 클라이언트
   도커 커맨드는 컨테이너를 조작하는 커맨드 라인 유저 인터페이스는 도커 데몬의 클라이언트다. 도커 커맨드는 도커 API를 사용하여 도커 데몬에 요청을 보낸다. 도커 커맨드를 통해 사용하는 서브 커맨드 세 가지를 소개하면 다음과 같다.

• docker build : 베이스 이미지에 ㄱ기능을 추가하여 새로운 이미지를 만들 때 사용한다.

• docker pull : 레지스트리에서 이미지를 로컬에 다운로드할 때 사용된다.

• docker run : 이미지를 바탕으로 컨테이너를 실행한다.

3. 이미지
   이미지는 읽기 전용인 컨테이너의 탬플릿을 말한다. 컨테이너를 기동하기 위해 실행 파일과 설정 파일의 묶음이라고 볼 수 있다. 컨테이너를 실행하면 이미지에 담긴 미들웨어나 애플리케이션이 설정에 따라 기동한다. 도커 허브에는 데이터베이스, 웹 서버, 애플리케이션 등 다양한 이미지가 등록되어 있다. 예를듫어, CI/CD도구인 젠킨스도 도커 허브에 등록되어 있어 이미지를 다운받으면 특별한 설치없이 젠킨스를 사용할 수 있다.

4. 컨테이너
   컨테이너는 하나의 프로세스라고 볼 수있다. 즉, 리눅스의 네임스ㅔ이스나 컨트롤 그룹을 통해 다른 프로세스들과 완전히 분리되어 실행되는 프로세스인 것이다. 하지만 컨테이너는 정지된 상태로도 관리되기 때문에 보다 명확하게 표현하자면 실행 가능한 이미지의 인스턴스라고 할 수 있다. docker run 명령어를 통해 이미지는 컨테이로 변환되어 하나의 인스턴스가 된다. 실행 상태의 컨테이너는 IP 주소를 가지는 하나의 독립된 서버처럼 동작한다. 컨테이너의 IP 주소와 포트번호로 온 요청은 컨테이너 내의 프로세스로 연결된다.

5. 도커 레지스트리
   도커 레지스트리는 컨테이너의 이미지가 보관되는 것이다. 도커는 기본으로 도커 허브(Docker Hub)에 있는 이미지를 찾도록 설정되어 있다. docker run hello-world를 실행하면 공개 레지스트리인 도커 허브에 등록된 이미지 hello-world를 다운받아서 컨테이너로서 실행한다. 레지스트리는 리포지터리를 여러개 가지는 보관 서비스다. 그리고 리포지터리는 하나의 이미지에 대해 태그를 사용하여 다양한 출시 버전을 함께 보관하는 곳이다.

도커 컨테이너(Docker Container) 실행 방식

Docker 기술은 Linux 커널과 Cgroups 및 네임스페이스 등 커널의 기능을 사용하여 프로세스를 분리함으로써 독립적으로 실행할 수 있도록 합니다. 이러한 독립성은 컨테이너의 본래 목적입니다. 다시 말해서, 여러 프로세스와 애플리케이션을 서로 개별적으로 실행하여 인프라를 더 효과적으로 활용하고 개별 시스템을 사용할 때와 동일한 보안을 유지할 수 있습니다.

Docker를 포함한 컨테이너 툴은 이미지 기반 배포 모델을 제공합니다. 따라서 여러 환경 전반에서 애플리케이션 또는 서비스를 모든 종속 항목과 손쉽게 공유할 수 있습니다. 또한 Docker는 이 컨테이너 환경 내에서 애플리케이션(또는 애플리케이션을 구성하는 결합된 프로세스) 배포를 자동화합니다.

이러한 툴은 Linux 컨테이너를 기반으로 구축되어 Docker를 사용자 친화적이고 고유하게 만들어 주므로 사용자는 그 어느 때보다 쉽게 애플리케이션에 액세스하고, 신속하게 배포하고, 버전 및 버전 배포를 제어할 수 있습니다.

가상머신 vs 도커 컨테이너

기존의 가상화 기술인 가상머신은 하이퍼바이저를 이용해 여러개의 운영체제를 하나의 호스트에서 생성해서 사용하는 방식이었습니다. 이러한 여러 개의 운영체제는 가상 머신이라는 단위로 구별되고 각 가상머신에는 우분투, CentOS 등의 운영 체제가 설치되어 사용합니다. 그래서 하이퍼바이저에 의해 생성되고 관리되는 운영체제는 게스트 운영체제라고 하며, 각 게스트 운영체제는 다른 게스트 운영체제와는 완전히 독립된 공간과 시스템 자원을 할당받아 사용합니다. 그러나 각종 시스템 자원을 가상화하고 독립된 공간을 생성하는 작업은 하이퍼바이저를 반드시 거치기 때문에 일반 호스트에 비해 성능의 손실이 발생합니다. 그리고 가상 머신은 게스트 운영체제를 사용하기 위한 라이브러리, 커널 등을 전부 포함하기 때문에 가상 머신을 배포하기 위한 이미지로 만들었을 때 이미지의 크기 또한 커집니다.

도커 컨테이너는 가상화된 공간을 생성하기 위해 리눅스 자체 기능인 chroot, 네임스페이스, cgroup을 사용함으로써 프로세스 단위의 격리 환경을 만들기 때문에 성능손실이 거의 없습니다. 컨테이너에 필요한 커널을 공유해서 사용하고 컨테이너 안에는 어플리케이션을 구동하는데 필요한 라이브러리 및 실행파일만 존재하기 때문에 컨테이너를 이미지로 만들었을 때 이미지의 용량 또한 가상 머신에 비해 대폭 줄어듭니다. 따라서 컨테이너를 이미지로 만들어 배포하는 시간이 가상 머신에 비해 빠르며 가상화된 공간을 사용할 때의 성능 손실도 거의 없다는 장점이 있습니다.

도커와 리눅스 컨테이너 차이점

헷갈릴 수도 있지만 Docker는 전통적인 Linux 컨테이너와는 다릅니다. Docker 기술은 처음에는 LXC 기술을 기반으로 개발되었지만 이후에는 이러한 종속 관계를 벗어났습니다. 하지만 대부분의 사람들은 "전통적인" Linux 컨테이너와 연결지어 생각합니다. LXC는 경량의 가상화 방법으로 유용했지만, 뛰어난 개발자 또는 사용자 환경을 제공하지는 못했습니다. Docker 기술은 컨테이너를 구동하는 기능 이상의 것을 제공합니다. 컨테이너 생성 및 구축, 이미지 전송, 이미지 버전 관리 등의 프로세스를 용이하게 해줍니다.

전통적인 Linux 컨테이너는 멀티플 프로세스를 관리할 수 있는 init 시스템을 사용합니다. 즉, 전체 애플리케이션을 하나로 실행할 수 있습니다. Docker 기술은 애플리케이션을 개별 프로세스로 세분화하도록 권장하고 이를 위한 툴을 제공합니다. 이러한 세분화된 접근 방식에는 장점이 있습니다.

도커의 구성요소

도커 이미지와 도커 컨테이너

도커 이미지와 컨테이너는 1:N관계입니다.

레지스트리와 쿠버네티스의 관계

쿠버네티스에서도 레지스트리에서 이미지를 다운받아 컨테이너를 실행한다. 쿠버네티스에서 컨테이너가 동작할 때까지의 흐름을 설명하면 다음과 같다.

1. docker build로 이미지를 빌드한다.
2. docker push로 이미지를 레지스트리에 등록
3. kubectl 커맨드로 매니페스트에 기재한 오브젝트들의 생성을 요청한다.
4. 매니페스트에 기재된 리포지터리로부터 컨테이너의 이미지를 다운로드한다.
5. 컨테이너를 파드 위에서 기동한다.

도커와 쿠버네티스의 연동

쿠버네티스는 도커를 컨테이너의 런타임 환경으로 사용한다. 쿠버네티스를 설치할 때 제일 먼저 도커를 설치해야하는 것도 이때문이다.

설치

지원 확인 방법은 시스템 > 정보에서 Windows 사양을 확인합니다.
Windows 10 Pro를 사용한다면 도커를 사용할 수 있지만,
Windows 10 Home의 경우 버전이 20H1, 20H2, 21H1 혹은 그보다 높은 버전이어야 합니다.

다운받고 확인할게 있는데 프로그램 제거에서 window 기능 켜기/끄기에서 이게 체크되어 있는지 체크해준다.

명령어

Docker 자바 이미지 다운

docker pull openjdk:11

젠킨스 이미지 다운

docker pull jenkins/jenkins:jdk11

다운된 이미지 조회

docker images

이미지 삭제

docker rmi [이미지 이름]

이미지 전체 삭제
1. 실행중인 프로세스 종료

• docker ps
• docker stop 컨테이너 ID

2. 종료된 컨테이너 삭제

• docker ps -a
• docker rm 컨테이너 ID

3. 이미지 삭제

• docker images
• docker rmi 이미지 이름

여기까지가 하나씩 삭제하는 방법이고 이거를 하나씩 삭제하면 번거로우니 한번에 삭제하는 방법이 있습니다.

젠킨스 이미지를 컨테이너로 실행

docker run -d -p 8080:9090 -p 50000:50000 -v /home/jenkins:/var/jenkins_home -v /usr/bin/docker:/usr/bin/docker -v /var/run/docker.sock:/var/run/docker.sock -u root jenkins/jenkins:jdk11

컨테이너 실행 확인

docker ps

여기서 조회가 안되면

docker ps -a

전체 컨테이너 목록 확인

docker container ls -a

컨테이너 시작/접속/중지/삭제/재시작

docker start 컨테이너ID
docker attach 컨테이너ID
docker stop 컨테이너ID
docker rm 컨테이너ID
docker restart [컨테이너명, ID]

컨테이너 이름 변경

docker rename [현재 컨테이너명] <변경할 컨테이너 이름>

실행중인 모든 것을 종료
docker ps -a -q 모든 실행중인 컨테이너를 보여줍니다.

docker stop $(docker ps -q)
docker rm $(docker ps -a -q)

이렇게 사용하면 모든 컨테이너를 중지시키고 삭제합니다.

docker images -q는 모든 이미지를 보여줍니다.

docker rmi -f $(docker images -q)

모든 이미지를 삭제합니다.

조회

docker logs 컨테이너ID

도커 실행

docker run -d -p 8080:80 nginx

여기서 백그라운드에서 실행하게 하려면 -d를 붙여주고 포트포워딩을 하려고 하면 -p를 해주면 됩니다.

포트포워딩

포트포워딩(port forwarding)은 컴퓨터 네트워크 상에서 패킷이 방화벽이나 라우터 같은 네트워크 게이트를 지날 때 IP 주소와 포트 번호 결합의 통신 요청을 다른 곳으로 넘겨주는 네트워크 주소 변환의 응용이라고 볼 수 있습니다. 간단히 말해서 포트(Port)를 전달(Forwarding)해 주는 거라고 생각하시면 됩니다. 특정한 포트로 들어오는 데이터 패킷을 다른 포트로 바꿔서 다시 전송해주는 작업인 것이죠. 이러한 방식으로 포트포워딩은 수신 데이터가 NAT 방화벽을 우회하도록 하여 인터넷 연결 속도를 개선합니다. 게다가, 포트포워딩은 인터넷 속도를 개선해주고 원격으로 기기에 액세스하도록 도와줄 수 있습니다.

여기서 이미지가 없으면 자동으로 도커에서 받아준다.

이렇게 사용할 경우 장점은 여러개의 컨테이너를 만들 경우 내부 호스트가 80이고 외부 호스트가 A 컨테이너고 8081이 B 컨테이너면 8080:80은 A 컨테이너로 포트포워딩하고 8081:80은 B 컨테이너로 포트포워딩합니다.

-dit 옵션
아파치 같은 환경을 설치하지 않을 때 그냥 설치해서 사용하면 동작 후 바로 죽는 상황에서 -dit옵션을 사용해서 지속적으로 살릴 수 있습니다. 즉, OS같은 우분투는 혼자서 실행이 안되서 -d -p로 하면 바로 꺼지니 -dit로 지속적으로 실행하게 해줍니다.

docker run -dit ubuntu bash

이거로 인해 죽지 않고 살아있는 것입니다.

attach 옵션
도커에서 받은 이미지에 접근할 수 있는 명령어

docker attach [컨테이너 ID]

이거는 도커안에 있는 우분투에 접근한 것입니다.

여기서 나가려면

exit

docker exec
내가 실행중인 컨테이너에 커맨드를 변경해서 접속하려면 exec를 사용

 docker exec -it 컨테이너ID bash

attach와 exec 차이

우분투를 실행할 때 docker run -dit ubuntu bash로 실행하면 attach로 접속할 수 있고 docker run -d -p 8080:80 httpd 같은 경우는 이렇게 접속해도 죽지않고 실행되니 실행중인 것을 접속할 때는 exec로 접속하면 됩니다. 근데 여기서 위에꺼는 -dit고 아래는 -d면 헷갈리니 그냥 일반적으로 -dit로 쓰고 구분만 잘하면 된다.

볼륨옵션
Docker volume(볼륨)은 컨테이너와 호스트 운영체제 간에 데이터를 공유하거나 저장하기 위한 기능으로, 볼륨을 사용하면 데이터의 지속성을 유지하면서 컨테이너를 생성하거나 삭제할 수 있다. Docker 볼륨은 컨테이너의 파일 시스템이나 디렉토리를 호스트 시스템의 특정 경로와 연결하여 데이터를 저장하고 관리할 수 있도록 해준다.

docker run -d -p 8080:80 -v c:/users/user/webapp/usr/local/apache2/htdocs httpd

Docker 볼륨을 사용하는 주요 이점은 다음과 같다.

• 데이터 지속성: 컨테이너가 종료되더라도 볼륨에 저장된 데이터는 유지. 이를 통해 컨테이너 재시작, 업데이트, 삭제 등의 작업에서 데이터를 보존할 수 있음.
• 공유 데이터: 여러 컨테이너 간에 데이터를 공유하거나 컨테이너와 호스트 간에 데이터를 주고받을 수 있음.
• 백업 및 복원: 볼륨을 사용하여 중요한 데이터를 백업하고 필요한 경우 복원할 수 있음.

도커에 받은 젠킨스 비번알기

docker exec -it <container_id_or_name> cat /var/jenkins_home/secrets/initialAdminPassword

<container_id_or_name>은 단계 1에서 확인한 Jenkins 컨테이너의 ID나 이름으로 대체되어야 합니다.

MySQL 다운

docker pull mysql:8.0.28

Docker Mysql 컨테이너 생성 및 실행

docker run -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=12345 --name mysql-container -v /home/mysql/:/var/lib/mysql mysql:8.0.28 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --max-allowed-packet=1073741824

• -d : 백그라운드에서 실행

• -p : 3306:3306 한것은 포트 포워딩, 실제 내 서버로 들어온 3306 포트는 도커의 3306 포트로 보내겠다는 의미

• -e : mysql을 도커로 실행할 때 반드시 있어야 하는 옵션 중 하나, root 의 패스워드를 지정

• --name : 컨테이너의 이름을 설정, 이 부분을 설정하지 않는다면 랜덤하게 설정됨

• -v : 내 서버와 mysql 서버의 특정 폴더를 공유하겠다는 의미인데, 이 부분이 필요한 이유는 db 데이터를 컨테이너가 삭제되어도 보존하기 위해서 설정하는 것

• mysql:8.0.28 : docker images 했을 경우 repository와 tag명

• --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci : 한글 출력을 위한 인코딩

컨테이너 생성 및 시작 및 접속

docker run -it 컨테이너ID

Mysql 컨테이너 bash shell 접속(실행되고 있던 컨테이너 접속)

docker exec -it mysql-container bash

컨테이너 나오기

exit

Mysql 서버 접속

 mysql -u root -p

MySQL 시작/중지/재시작

# MySQL Docker 컨테이너 실행
$docker start mysql-container

# MySQL Docker 컨테이너 중지
$docker stop mysql-container 

# MySQL Docker 컨테이너 재시작
$docker restart mysql-container

도커 허브에 로그인

docker login -u [ID]

도커 디스크의 사용량 확인

docker system df

Docker의 시스템 전체 정보 확인.

docker system info

mage 상세 정보 표시

#docker image inspect [이미지명]
$doker image inspect boot:letest

docker hub image 검색

• docker hub에 올라와있는 public 이미지들을 검색할 수 있다.

• Official 컬럼으로 공식 이미지인지 확인 할 수 있다.

# docker search [옵션] <검색어>
$docker search mysql

# 옵션 사용 예제 - 자동빌드 설정, star수 15개 이상인 mysql 이미지
$docker search --filter is-automated=true --filter starts=15 mysql

옵션

Dockerfile 로 image 생성(빌드)

# 기본 커맨드
# docker build -t [dockerHub ID]/[이미지명]:[태그명] [DockerFile위치]

# 태그 지정X 시 :latest 지정됨
$docker build -t [dockerHub ID]/[이미지명] .

이미지 삭제

# 이미지만 삭제
$docker rmi [이미지 ID]

# 컨테이너 + 이미지 강제 삭제
$docker rmi -f [이미지 ID]

컨테이너 삭제

# 컨테이너 단건 삭제
$docker rm [컨테이너 ID]

# 컨테이너 다건 삭제
$docker rm [컨테이너 ID}, [컨테이너 ID]

# 컨테이너 전체 삭제
$docker rm 'docker ps -a -q'

컨테이너 접속

# 실행되고 있는 컨테이너에 접속 - attach
# 컨테이너 run시 /bin/bash 사용하지 않았다면 접속 불가.
$docker attach [컨테이너명, ID]

# 실행중인 컨테이너에 접속, 명령수행가능(일시적) - exec
# exit로 종료
$docker exec -it [컨테이너명, ID] /bin/bash

dockerfile이란?

dockerfile은 docker image를 만들기 위한 설정 파일을 의미한다.

구성요소

• FROM
  빌드할 베이스 이미지를 지정. 이미지가 로컬에 없으면 도커 허브에서 해당 이미지를 검색해 다운. ex) FROM ubuntu:latest

• RUN
  컨테이너에서 실행할 명령어를 지정. 보통 컨테이너에 필요한 라이브러리를 다운받는 명령어나 디렉토리를 만드는 명령어를 지정한다. ex) RUN apt-get update

• ADD
  컨테이너에서 배치할 파일이나 디렉토리를 지정. ex) ADD ./message /message ===> 해당 명령어는 현재 디렉토리에 위치한 message라는 파일을 컨테이너의 루트 디렉토리에 message라는 이름으로 배치하라는 소리다.

• CMD
  컨테이너가 시작할 때 실행할 명령어를 지정. RUN은 이미지를 빌드할 때 실행되고 CMD는 이미 빌드된 이미지(컨테이너)가 시작할 때 실행된다. 여러 CMD는 모두 실행되지 않고 맨 마지막 CMD만 실행된다.

• ENTRYPOINT
  CMD와 동일. 하지만 CMD에서는 param값을 대체할 수 있지만 ENTRYPOINT는 불가능하다. ENTRYPOINT와 CMD는 같이 쓰이면서 CMD는 default값을 가진 param을 갖는 명령어를 지정할 때 쓰이고 ENTRYPOINT는 그렇지 않을 때 쓰인다. 또한 CMD와 마찬가지로 여러 ENTRYPOINT는 모두 실행되지 않고 맨 마지막 ENTRYPOINT만 실행된다.

• LABEL
  key-value 형식의 메타데이터를 이미지에 추가.

• ENV
  LABEL과 동일하지만 메타데이터 대신 환경변수를 설정.

• VOLUME
  컨테이너 내의 특정 디렉토리를 지정. 해당 디렉토리를 외부 경로에 마운트되어 컨테이너가 삭제되어도 해당 디렉토리의 정보는 보존될 수 있게 됨. 외부 경로란 HOST OS의 /var/lib/docker/volumes 경로를 의미한다.

---

쿠버네티스란?

쿠버네티스는 컨테이너화된 애플리케이션을 효율적으로 배포하고 운영하기 위해 설계된 오픈 소스 플랫폼이다. 따라서 쿠버네티스를 이해하기 위해서는 먼저 컨테이너를 사용하는 이유부터 알아야 한다.

요즘날 각종 애플리케이션을 이용하는데 일상에서 수시로 사용하고 경쟁 애플리케이션이 범람하는 가운데 중요성이 높아지는 것이 지속적 통합(CI)과 지속적 배포(CD)다. 사용자에게 새로운 기능과 서비스를 빠르고 안정적으로 제공해야 하는 것이다. 컨테이너 기술은 이러한 요구 사항에 효과적인 대안을 제시합니다.

개발자들은 일반적으로 오픈소스를 사용해서 개발을 하는데 오픈 소스의 경우 버전이 계속 바뀌기 때문에 같은 팀의 개발자들 간에도 서로 다른 버전을 사용하는 상황이 벌어지기 일쑤다. 즉, 개발자들간에 개발 환경의 차이가 발생하여 개발 생산성과 안정성이 떨어지는 것이다.

이러한 상황에서는 컨테이너 기술이 빛을 발합니다. 컨테이너 기술은 필요한 라이브러리나 운영체제 패키지 등을 모두 담아서 불변의 실행 환경을 만든다. 이렇게 하면 개발자들 간에 그리고 테스트와 운영 환경 간의 차이를 없앨 수 있어 개발 생산성을 높이고, 애플리케이션 정식 서비스를 안정적으로 배포할 수 있게 합니다.

요약

즉, 개발자들이 개발을 할 때 각자 다른 버전을 사용하는 일들이 있는데 그럴 때 컨테이너 기술을 사용해서 불변의 환경을 만들어서 안정적으로 배포할 수 있게 해준다.

쿠버네티스 개요

쿠버네티스는 구글의 사내 운영 시스템인 Brog를 오픈 소스로 만든 것이며, 크게 다음과 같은 기능을 제공한다.

• 배포 계획에 맞춰 애플리케이션을 신속하게 배포

  • 컨테이너 개수, CPU 사용률, 메모리 사용량 설정 가능
  • 저장 공간, 네트워크 접근 제어, 로드밸런싱 기능 설정 가능

• 가동 중인 애플리케이션을 스케일 업/다운할 수 있다.

  • 요청이 많을 때는 컨테이너 수를 늘려서 처리 능력을 높임
  • 요청이 적을 때는 컨테이너 수를 줄여서 자원 점유율이나 요금을 줄임

• 새로운 버전의 애플리케이션을 무정지로 업그레이드

• 하드웨어 가동률을 높여 자원 낭비를 줄인다.

쿠버네티스 목표의 특징

다양한 환경에서 쿠버네티스 사용가능

• 퍼블릭 클라우드

  고객들 간에 공유하는 대신 저렴하고 신속한 운영이 가능한 인프라 환경

• 프라이빗 클라우드

  독점적으로 사용하여 보안을 높일 수 있는 인프라 환경

• 멀티 클라우드

  여러 퍼블릭 클라우드를 함께 사용하는 경우

• 하이브리드 클라우드

  온프레미스와 퍼블릭 클라우드를 함께 사용하는 경우

• 온프레미스

  자사 설비를 이용해 애플리케이션에 특화된 운영을 하는 경우

계속되는 변화를 전제로 설계된 높은 유연성과 확장성

• 마이크로 서비스화된 애플리케이션에 최적화된 실행 환경
• 느슨한 결합에 의한 유연성, 교체 용이성
• 다양한 스펙의 서버가 혼재하는 클라스터 구성에서 사용 가능
• 저장소나 로드밸런서의 동적 프로비저닝
• 퍼블릭 클라우드 API와 연동한 쿠버네티스 조작

고가용성과 성능 관리

• 서버 정지 시 애플리케이션 재배포 자동화
• 애플리케이션의 이상 종료 시 자동 재기동
• 필요한 인스턴스의 개수를 유지
• 높은 부하에서 자동 스케일

쿠버네이티스가 해결하는 과제

1. 애플리케이션의 비번한 출시
   경쟁사보다 뛰어난 애플리케이션을 제공하기 위해서는 많은 아이디어를 시험해봐야 하는데 쿠버네티스는 민감한 작업을 안전하게 자동화해준다. 이것을 사용하면 운영중인 서비스를 무정지로 교체할 수 있다. 그리고 롤아웃을 취소하고 롤백하는 것도 가능하다.

2. 무정지 서비스
   쿠버네티스의 자기 회복 기능은 무정지 서비스 운영을 도와준다. 응답이 없어진 컨테이너를 재기동하며, 쿠버네티스 클러스터 내에 지정한 수만큼 컨테이너가 돌도록 관리해준다.

3. 초기 비용을 낮추고 비즈니스 상황에 맞게 규모를 조정
   컨테이너 기술은 애플리케이션과 실행 환경을 하나로 묶어서 배포할 수 있게 해준다. 그리고 쿠버네티스는 복수의 노드 위에서 컨테이너가 조화롭게 돌아갈 수 있도록 해준다.

4. 쿠버네티스와 외부 서비스와의 연동

5. 개발 환경과 운영 환경의 분리
   컨테이너 개발이 완료되어 테스트까지 끝났다면 정식 서비스 때 배포 까지는 이미지를 다시 빌드하지 않는것이 좋다. 테스트로 검증되지 않은 기능이 포함될 여지가 있기 때문이다. 하지만 운영환경에서 사용하는 엔드포인트나 인증 정보는 테스트 환경과 다르기 마련이다. 쿠버네티스는 클러스터를 여러 개의 가상 환경으로 분할하는 것이 가능하다. 그리고 각각의 가상 환경에 설정 파일, 보안이 필요한 인증서나 비밀번호를 저장할 수 있다. 그리고 컨테이너에서는 이 저장된 정보에 접근할 수 있다. 따라서 이를 활용하면 테스트 환경에서 운영 환경으로 옮길 때, 이미지를 다시 만들 필요가 없다. 즉, 테스트가 완료된 컨테이너의 이미지를 그대로 정식 운영 환경에 배포할 수 있다.

6. 온프레미스와 클라우드 위에 구축

7. 애플리케이션 중심의 오케스트레이션
   퍼블릭 클라우드 덕택에 애플리케이션을 위한 인프라 구축하는 노동과 시간이 상당히 줄었다. 애플리케이션 개발자가 YAML파일을 기술하여 쿠버네티스에 제출하면 로드밸런서, 저장소, 네트워크, 런타임 등의 환경이 구성된다.

8. 특정 기업에 종속되지 않는 표준 기술

9. 서버들의 가동률 높이기