diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md index f086ab21f51c9..332af17e9e42b 100644 --- a/content/ko/docs/concepts/overview/what-is-kubernetes.md +++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md @@ -1,207 +1,178 @@ --- -reviewers: -- bgrant0607 -- mikedanese -title: What is Kubernetes? +title: 쿠버네티스란 무엇인가? content_template: templates/concept weight: 10 --- {{% capture overview %}} -This page is an overview of Kubernetes. +이 페이지에서는 쿠버네티스 개요를 설명한다. {{% /capture %}} {{% capture body %}} -Kubernetes is a portable, extensible open-source platform for managing -containerized workloads and services, that facilitates both -declarative configuration and automation. It has a large, rapidly -growing ecosystem. Kubernetes services, support, and tools are widely available. - -Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon -a [decade and a half of experience that Google has with running -production workloads at -scale](https://research.google.com/pubs/pub43438.html), combined with -best-of-breed ideas and practices from the community. - -## Why do I need Kubernetes and what can it do? - -Kubernetes has a number of features. It can be thought of as: - -- a container platform -- a microservices platform -- a portable cloud platform -and a lot more. - -Kubernetes provides a **container-centric** management environment. It -orchestrates computing, networking, and storage infrastructure on -behalf of user workloads. This provides much of the simplicity of -Platform as a Service (PaaS) with the flexibility of Infrastructure as -a Service (IaaS), and enables portability across infrastructure -providers. - -## How is Kubernetes a platform? - -Even though Kubernetes provides a lot of functionality, there are -always new scenarios that would benefit from new -features. Application-specific workflows can be streamlined to -accelerate developer velocity. Ad hoc orchestration that is acceptable -initially often requires robust automation at scale. This is why -Kubernetes was also designed to serve as a platform for building an -ecosystem of components and tools to make it easier to deploy, scale, -and manage applications. - -[Labels](/docs/concepts/overview/working-with-objects/labels/) empower -users to organize their resources however they -please. [Annotations](/docs/concepts/overview/working-with-objects/annotations/) -enable users to decorate resources with custom information to -facilitate their workflows and provide an easy way for management -tools to checkpoint state. - -Additionally, the [Kubernetes control -plane](/docs/concepts/overview/components/) is built upon the same -[APIs](/docs/reference/using-api/api-overview/) that are available to developers -and users. Users can write their own controllers, such as -[schedulers](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), -with [their own -APIs](/docs/concepts/api-extension/custom-resources/) -that can be targeted by a general-purpose [command-line -tool](/docs/user-guide/kubectl-overview/). - -This -[design](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) -has enabled a number of other systems to build atop Kubernetes. - -## What Kubernetes is not - -Kubernetes is not a traditional, all-inclusive PaaS (Platform as a -Service) system. Since Kubernetes operates at the container level -rather than at the hardware level, it provides some generally -applicable features common to PaaS offerings, such as deployment, -scaling, load balancing, logging, and monitoring. However, Kubernetes -is not monolithic, and these default solutions are optional and -pluggable. Kubernetes provides the building blocks for building developer -platforms, but preserves user choice and flexibility where it is -important. - -Kubernetes: - -* Does not limit the types of applications supported. Kubernetes aims - to support an extremely diverse variety of workloads, including - stateless, stateful, and data-processing workloads. If an - application can run in a container, it should run great on - Kubernetes. -* Does not deploy source code and does not build your - application. Continuous Integration, Delivery, and Deployment - (CI/CD) workflows are determined by organization cultures and preferences - as well as technical requirements. -* Does not provide application-level services, such as middleware - (e.g., message buses), data-processing frameworks (for example, - Spark), databases (e.g., mysql), caches, nor cluster storage systems (e.g., - Ceph) as built-in services. Such components can run on Kubernetes, and/or - can be accessed by applications running on Kubernetes through portable - mechanisms, such as the Open Service Broker. -* Does not dictate logging, monitoring, or alerting solutions. It provides - some integrations as proof of concept, and mechanisms to collect and - export metrics. -* Does not provide nor mandate a configuration language/system (e.g., - [jsonnet](https://github.com/google/jsonnet)). It provides a declarative - API that may be targeted by arbitrary forms of declarative specifications. -* Does not provide nor adopt any comprehensive machine configuration, - maintenance, management, or self-healing systems. - -Additionally, Kubernetes is not a mere *orchestration system*. In -fact, it eliminates the need for orchestration. The technical -definition of *orchestration* is execution of a defined workflow: -first do A, then B, then C. In contrast, Kubernetes is comprised of a -set of independent, composable control processes that continuously -drive the current state towards the provided desired state. It -shouldn't matter how you get from A to C. Centralized control is also -not required. This results in a system that is easier to use and more -powerful, robust, resilient, and extensible. - -## Why containers? - -Looking for reasons why you should be using containers? +쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, +확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 +용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. +쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다. + +구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 [구글의 +15여년에 걸친 대규모 운영 워크로드 운영 +경험](https://research.google.com/pubs/pub43438.html)을 기반으로 만들어졌으며 +커뮤니티의 최고의 아이디어와 적용 사례가 결합되었다. + +## 쿠버네티스가 왜 필요하고 무엇을 할 수 있는가? + +쿠버네티스에는 많은 기능이 있다. 다음과 같이 생각해 볼 수 있다. + +- 컨테이너 플랫폼 +- 마이크로서비스 플랫폼 +- 이식성 있는 클라우드 플랫폼 +그리고 더 많은 기능. + +쿠버네티스는 **컨테이너 중심의** 관리 환경을 제공한다. 이 환경은 사용자 +워크로드를 위해서 컴퓨팅, 네트워킹 및 스토리지 인프라스트럭처를 +오케스트레이션한다. 이는 Platform as a Service(PaaS)의 매우 단순명료함에 +Infrastructure as a Service (IaaS)의 유연함을 더해 주며, 인프라스트럭처 +제공자 간 이식이 가능하게 해준다. + +## 어떻게 쿠버네티스가 플랫폼이 될 수 있는가? + +쿠버네티스가 제공하는 많은 기능이 있지만, 신규 기능을 통해 혜택을 얻을 수 있는 +새로운 시나리오는 항상 있게 마련이다. 개발자의 생산성을 극대화할 수 있도록 +애플리케이션에 특화된 워크플로우를 최적화할 수 있다. 초기에 수용 가능한 애드혹 +오케스트레이션은 대규모의 견고한 자동화를 필요로 하곤 한다. 이것이 쿠버네티스가 +애플리케이션을 더 쉽게 배포하고, 스케일링하며, 관리하는 컴포넌트와 툴의 생태계를 +만드는 플랫폼의 기능을 하도록 설계된 이유이다. + +[레이블](/docs/concepts/overview/working-with-objects/labels/)은 사용자가 원하는 +방식대로 자원을 정리할 수 있도록 해준다. +[어노테이션](/docs/concepts/overview/working-with-objects/annotations/)은 +자원에 사용자 정의 정보를 추가해서 사용자의 워크플로우에 활용할 수 있도록 하고 +관리 툴이 상태를 쉽게 체크할 수 있는 방법을 제공해 준다. + +추가로, [쿠버네티스 컨트롤 플레인](/docs/concepts/overview/components/)은 +개발자와 사용자가 공통으로 사용할 수 있는 [API](/docs/reference/using-api/api-overview/)를 +기반으로 하고 있다. 사용자는 범용의 [명령줄 도구]((/docs/user-guide/kubectl-overview/))를 +대상으로 하는 [자체 API](/docs/concepts/api-extension/custom-resources/)를 가진 +[스케줄러](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md)와 +같은 사용자만의 컨트롤러를 작성할 수 있다. + +이 [설계](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)를 통해 +쿠버네티스 위에 많은 다른 시스템을 올릴 수 있게 된다. + +## 쿠버네티스가 아닌 것 + +쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 +아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, +PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱, 로깅 및 모니터링과 +같은 기능에서 공통점이 있기도 하다. 하지만, 쿠버네티스는 모놀리식(monolithic)하지 +않아서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 +개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 +유연성을 지켜준다. + +쿠버네티스는 + +* 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 + 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, + 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 + 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서 + 매우 잘 동작할 것이다. +* 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. + 지속적인 통합, 지속적인 배포(Delivery, Deployment)(CI/CD) 워크플로우는 + 기술적인 요구사항은 물론 조직 문화와 취향에 따라 결정된다. +* 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, mysql), + 캐시 또는 클러스터 스토리지 시스템(예, Ceph)와 같은 애플리케이션 레벨의 서비스를 + 제공하지 않는다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 + 구동 중인 애플리케이션이 Open Service Broker와 같은 이식 가능한 메커니즘을 통해 접근할 + 수도 있다. +* 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, + 메트릭을 수집하고 노출하는 메커니즘을 제공한다. +* 기본 설정 언어/시스템(예, [jsonnet](https://github.com/google/jsonnet))을 제공하거나 + 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다. +* 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다. + +추가로, 쿠버네티스는 단순한 *오케스트레이션 시스템*이 아니다. 사실, +쿠버네티스는 오케스트레이션의 필요성을 없애준다. *오케스트레이션*의 +기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 +수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 +있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도된 상태로 나아가도록 한다. +A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 +보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다. + +## 왜 컨테이너인가? + +왜 컨테이너를 써야하는지 이유를 알고 싶은가? ![Why Containers?](/images/docs/why_containers.svg) -The *Old Way* to deploy applications was to install the applications -on a host using the operating-system package manager. This had the -disadvantage of entangling the applications' executables, -configuration, libraries, and lifecycles with each other and with the -host OS. One could build immutable virtual-machine images in order to -achieve predictable rollouts and rollbacks, but VMs are heavyweight -and non-portable. - -The *New Way* is to deploy containers based on operating-system-level -virtualization rather than hardware virtualization. These containers -are isolated from each other and from the host: they have their own -filesystems, they can't see each others' processes, and their -computational resource usage can be bounded. They are easier to build -than VMs, and because they are decoupled from the underlying -infrastructure and from the host filesystem, they are portable across -clouds and OS distributions. - -Because containers are small and fast, one application can be packed -in each container image. This one-to-one application-to-image -relationship unlocks the full benefits of containers. With containers, -immutable container images can be created at build/release time rather -than deployment time, since each application doesn't need to be -composed with the rest of the application stack, nor married to the -production infrastructure environment. Generating container images at -build/release time enables a consistent environment to be carried from -development into production. Similarly, containers are vastly more -transparent than VMs, which facilitates monitoring and -management. This is especially true when the containers' process -lifecycles are managed by the infrastructure rather than hidden by a -process supervisor inside the container. Finally, with a single -application per container, managing the containers becomes tantamount -to managing deployment of the application. - -Summary of container benefits: - -* **Agile application creation and deployment**: - Increased ease and efficiency of container image creation compared to VM image use. -* **Continuous development, integration, and deployment**: - Provides for reliable and frequent container image build and - deployment with quick and easy rollbacks (due to image - immutability). -* **Dev and Ops separation of concerns**: - Create application container images at build/release time rather - than deployment time, thereby decoupling applications from - infrastructure. -* **Observability** - Not only surfaces OS-level information and metrics, but also application - health and other signals. -* **Environmental consistency across development, testing, and production**: - Runs the same on a laptop as it does in the cloud. -* **Cloud and OS distribution portability**: - Runs on Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine, and anywhere else. -* **Application-centric management**: - Raises the level of abstraction from running an OS on virtual - hardware to running an application on an OS using logical resources. -* **Loosely coupled, distributed, elastic, liberated [micro-services](https://martinfowler.com/articles/microservices.html)**: - Applications are broken into smaller, independent pieces and can - be deployed and managed dynamically -- not a fat monolithic stack - running on one big single-purpose machine. -* **Resource isolation**: - Predictable application performance. -* **Resource utilization**: - High efficiency and density. - -## What does Kubernetes mean? K8s? - -The name **Kubernetes** originates from Greek, meaning *helmsman* or -*pilot*, and is the root of *governor* and -[cybernetic](http://www.etymonline.com/index.php?term=cybernetics). *K8s* -is an abbreviation derived by replacing the 8 letters "ubernete" with -"8". +애플리케이션을 배포하는 *구식의 방법*은 운영 체제의 패키지 관리자를 +사용해서 애플리케이션을 호스트에 설치하는 것이었다. 이 방식은 +애플리케이션의 실행 파일, 설정, 라이브러리 서로 간의 라이프사이클과 +호스트 OS와 얽히게 된다는 단점이 있다. 예측 가능한 롤아웃과 롤백을 +위해서 불변의 가상 머신 이미지를 만들 수도 있지만, VM은 너무 크고 +이식 가능하지 않다. + +*새로운 방법*은 하드웨어 가상화가 아닌 운영 체제 수준의 가상화에 기반한 +컨테이너를 배포하는 것이다. 이 컨테이너는 서로 격리되고 호스트와도 +격리된다. 컨테이너는 컨테이너 자체의 파일시스템을 갖고, 다른 컨테이너의 +프로세스를 알 수 없으며, 연산에 필요한 자원을 제한할 수 있다. VM보다 +빌드하기 쉬우며, 기반이 되는 인프라스트럭처와 호스트 파일시스템에서 +디커플되었기(decoupled) 때문에 클라우드나 OS 배포판 간 이식성이 있다. + +컨테이너는 작고 빠르기 때문에, 애플리케이션 각각을 컨테이너 이미지로 +패키지할 수 있다. 이렇게 애플리케이션과 이미지를 일대일 관계를 갖도록 +하면 컨테이너의 혜택을 만끽할 수 있게 된다. 불변의 컨테이너 이미지는 +배포 시점이 아닌 빌드/릴리스 시점에 만들어질 수 있다. 왜냐하면 각각의 +애플리케이션은 애플리케이션 스택 외의 나머지 요소와 조합될 필요가 없기 +때문이고, 운영 인프라스트럭처 환경에 밀접하게 결합시킬 필요도 없기 +때문이다. 컨테이너 이미지를 빌드/릴리스 시점에 생성하게 되면 개발 +환경부터 운영 환경까지 일관된 환경을 가져갈 수 있게 된다. 마찬가지로, +컨테이너는 VM보다 훨씬 더 투명해서 모니터링과 관리가 용이하다. +컨테이너의 프로세스 라이프사이클이 수퍼바이저 프로세스에 의해 컨테이너 +내에 감추어지지 않고, 인프라스트럭처에 의해 관리될 때 더욱 이는 +용이해진다. 컨테이너마다 단일 애플리케이션을 담게되면, 궁극적으로 +컨테이너를 관리하는 것이 애플리케이션의 배포를 관리하는 것과 같아진다. + +컨테이너의 혜택 요약: + +* **기민한 애플리케이션 생성과 배포**: + VM 이미지 사용 대비 컨테이너 이미지 생성이 보다 쉽고 효율적임. +* **지속적인 개발, 통합 및 배포**: + 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 + (이미지의 불변성 덕에) 빠르고 쉽게 롤백할 수 있다. +* **개발과 운영의 관심사 분리**: + 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 + 만들기 때문에, 애플리케이션이 인프라스트럭처에서 디커플된다. +* **가시성** + OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 + 그 밖의 시그널을 볼 수 있다. +* **개발, 테스팅 및 운영 환경을 걸친 일관성**: + 랩탑에서도 클라우드에서와 동일하게 구동된다. +* **클라우드 및 OS 배포판 간 이식성**: + Ubuntu, RHEL, CoreOS, on-prem, Google Kubernetes Engine 및 다른 어디에서든 구동된다. +* **애플리케이션 중심 관리**: + 가상 하드웨어의 OS에서 애플리케이션을 구동하는 수준에서 OS의 + 논리적인 자원을 사용하여 애플리케이션을 구동하는 수준으로 추상화 + 수준이 높아진다. +* **느슨하게 커플되고, 분산되고, 유연하며, 자유로운 [마이크로서비스](https://martinfowler.com/articles/microservices.html)**: + 애플리케이션은 단일 목적의 머신에서 비대한 모놀리식 스택으로 + 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 + 관리될 수 있다. +* **자원 격리**: + 애플리케이션 성능을 예측할 수 있다. +* **지원 사용량**: + 고효율 고집적. + +## 쿠버네티스(Kubernetes)의 뜻은? K8s? + +**쿠버네티스**는 *키잡이*나 *파일럿*을 뜻하는 그리스어에서 유래했으며, +이는 *governor*(통치자)와 [cybernetic(인공두뇌학)](http://www.etymonline.com/index.php?term=cybernetics)의 +어원이다. *K8s*는 "ubernete" 8 글자를 "8"로 대체한 약어이다. {{% /capture %}} {{% capture whatsnext %}} -* Ready to [Get Started](/docs/setup/)? -* For more details, see the [Kubernetes Documentation](/docs/home/). +* [시작할](/docs/setup/) 준비가 되었는가? +* 보다 자세한 내용은 [쿠버네티스 문서](/ko/docs/home/)를 참조한다. {{% /capture %}}