원글 의 내용에서 정말 간결하고 좋은 내용으로 application 배포의 역사에 관해 설명해주고 있다. 이 내용을 요약하고 번역한 내용을 글로 적겠다.

Traditional deployment era

일찍이 기업들은 application을 physical server에서 실행하였다. Physical server에서는 application의 resource boundary를 정의하는 방법이 없었다. 따라서 이것은 resource allocation issue를 유발하였다. 이를테면 다수의 application이 physical server에서 실행되면, 어떤 한 application이 대다수의 resource를 점유하고 그 결과 다른 application들이 underperform 하는 것이다. 이러한 문제에 대한 해결책은 각 application을 다른 physical server에서 실행시키는 것이었다. 하지만 이것은 활용율이 낮아 scale에 좋지 못하고, 값이 많이 나간다는 점이 두드러졌다.

Virtualized deployment era

앞선 문제에 대한 해답으로 가상화(virtualization)이 소개되었다. 이것은 다수의 VM을 하나의 physical server의 CPU로 실행 할 수 있게 해준다. Virtualization은 VM들 간에 application이 isolated 되는 것을 허용해주고 하나의 application이 다른 application으로 자유롭게 접근하지 못하게 하는 level의 security를 지원해준다.

Virtualization은 physical server에서 리소스 utilization을 더 잘하게 해주며 application을 더 쉽게 추가 및 업데이트 할 수 있기 때문에 더 나은 scalability를 허용해준다. 이로인해 hardware cost도 절감할 수 있다.

각각의 VM은 가상화된 hardware 위에서 OS를 포함한 모든 component들을 실행하는 full machine이다.

Container deployment era

Container는 VM과 비슷하지만, 그들은 application들 간에 OS를 공유하기 위해서 조금 완화된 isolation property를 가지고 있다. 따라서 container는 lightweight로 간주된다. VM과 유사하게 container는 자신만의 file system, CPU 공유, memory, process space 등을 가진다.

Container는 추가적인 이득이 있어서 더 유명해졌다:

• Agile application creation and deployment: VM image를 사용하는 것 보다 container image를 만드는 것이 더 쉽고 효율적임
• Continuous development, integration, and deployment: 안정적이고 더 빈번한 개발이 가능함
• Dev and Ops separation of concerns: application container를 deployment time이 아닌 build/release time에 하기 때문에 application을 infrastructure에서 부터 decoupling한다.
• Observability: OS-level information and metrics 뿐만 아니라 application health나 다른 signal들도 볼 수 있다.
• Environmental consistency across development, testing and production: cloud나 laptop이나 동일한 환경에서 실행한다.
• Cloud and OS distribution portability: Ubuntu, RHEL, CoreOS 등등 어디에서든 실행이 가능하다.
• Application-centric management: 추상화의 정도(level of abstraction)를 virtual hardware 위의 OS에서 OS위의 application으로 끌어올렸다.
• Loosely coupled, distributed, elastic, liberated micro-services: application들이 더 작고 독립적인 조각으로 분할된다. 그리고 이들은 동적으로 배포 및 관리가 된다.
• Resource isolation: 예측이 가능한 aplication performance
• Resource utilization: 고효율

Why you need Kubernetes and what it can do

Container는 application을 bundle 하고 실행하는 좋은 방법이다. Production 환경에서, application을 실행하는 container를 downtime 없이 관리하는 방법이 필요하다. 예를들어 한 container가 죽으면, 다른 container가 시작될 필요가 있는 것이다. 이러한 것이 system에 의해서 관리되면 정말 편리하지 않을까?

이러한 것에 대한 구원으로 Kubernetes가 등장했다. Kubernetes는 분산 시스템을 탄력적으로 운영하게 해주는 framework이다. Application의 scaling과 failover를 관리해주고, deployment pattern 등을 제공해준다. 예를들어 Kubernetes는 canary deployment를 손쉽게 관리할 수 있게 해준다.

Kubernetes는 다음의 것들을 제공해준다:

• Service discovery and load balancing
  • 자신의 IP address나 DNS name 을 사용하여 container를 expose 할 수 있다. Container로의 traffic이 높으면, Kubernetes는 load balance를 하고 network traffic을 distribute 하게 하여 deployment를 안정적으로 할 수 있게 해준다.
• Storage orchestration
  • 자동으로 선택한 storage system을 mount 할 수 있게 해준다.
• Automated rollouts and rollbacks
  • Kubernetes를 사용하여 deployed container들의 desired state를 서술할 수 있고, actual state에서 desired state로 controlled rate에 의해 여기로의 전환을 한다.
• Automatic bin packing
  • Kubernetes에 containerized task를 실행하는데 사용할 수 있는 node의 cluster를 제공한다. Kubernetes에게 container가 얼마만큼의 CPU와 memory를 필요로 하는지 말할 수 있다.
• Self-healing
  • fail한 container를 재시작하고, container를 교체하고, user-defined health check에 응답하지 않는 container를 죽이는 등의 일을 수행한다.
• Secret and configuration management
  • 민감한 정보를 저장하고 관리할 수 있게 해준다. password, OAuth token, SSH key 등. Container image를 다시 build 할 필요 없이 secret이나 application configuration을 deploy하고 update 할 수 있게 해준다.