3장. 컨테이너 네트워킹 기본 사항
이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: translation-feedback@oreilly.com
이제 네트워킹 기본 사항과 Linux 네트워킹에 대해 설명했으니, 컨테이너에서 네트워킹을 구현하는 방법에 대해 알아보겠습니다. 네트워킹과 마찬가지로 컨테이너도 오랜 역사를 가지고 있습니다. 이 장에서는 그 역사를 살펴보고, 컨테이너를 실행하기 위한 다양한 옵션을 논의하고, 사용 가능한 네트워킹 설정에 대해 살펴봅니다. 현재 업계에서는 컨테이너 런타임 표준으로 Docker를 채택하고 있습니다. 따라서 Docker 네트워킹 모델에 대해 자세히 살펴보고, CNI가 Docker 네트워크 모델과 어떻게 다른지 설명한 다음, Docker 컨테이너를 사용한 네트워킹 모드의 예시로 장을 마무리하겠습니다.
컨테이너 소개
이 섹션에서는 컨테이너로 이어진 애플리케이션 실행의 진화에 대해 설명합니다. 어떤 사람들은 컨테이너에 대해 실체가 없다고 이야기할 것입니다. 컨테이너는 OS 커널의 기반 기술을 추상화한 또 다른 추상화일 뿐입니다. 기술적으로 옳다는 것은 기술의 핵심을 놓치고 애플리케이션 관리 및 배포라는 어려운 문제를 해결하는 길에서 멀어지게 합니다.
애플리케이션
애플리케이션을 실행하는 데는 항상 어려움이 있었습니다. 오늘날 애플리케이션을 서비스하는 방법은 Cloud, 온프레미스, 컨테이너 등 여러 가지가 있습니다. 애플리케이션 개발자와 시스템 관리자는 다양한 버전의 라이브러리를 다루고, 배포를 완료하는 방법을 알고, 애플리케이션 자체의 이전 버전을 보유하는 등 많은 문제에 직면합니다. 오랫동안 애플리케이션 개발자는 이러한 문제를 해결해야 했습니다. bash 스크립트와 배포 도구에는 모두 단점과 문제가 있습니다. 모든 새로운 회사는 애플리케이션을 배포하는 방식이 다르므로 모든 신규 개발자는 이러한 기술을 배워야 합니다. 업무 분리, 권한 제어, 시스템 안정성 유지를 위해 시스템 관리자는 배포를 위해 개발자의 액세스를 제한해야 합니다. 또한 시스템 관리자는 동일한 호스트 컴퓨터에서 여러 애플리케이션을 관리하여 해당 컴퓨터의 효율성을 높이므로 새로운 기능을 배포하려는 개발자와 전체 에코시스템의 안정성을 유지하려는 시스템 관리자 간에 경쟁이 발생하게 됩니다.
범용 OS는 가능한 한 많은 유형의 애플리케이션을 지원하므로 커널에는 모든 종류의 드라이버, 프로토콜 라이브러리 및 스케줄러가 포함되어 있습니다. 그림 3-1은 하나의 운영 체제를 사용하는 하나의 머신을 보여주지만 해당 호스트에 애플리케이션을 배포하는 방법은 여러 가지가 있습니다. 애플리케이션 배포는 모든 조직이 해결해야 하는 문제입니다.
그림 3-1. 애플리케이션 서버
네트워킹( ) 관점에서 보면 하나의 운영 체제에는 하나의 TCP/IP 스택이 있습니다. ...