Kubernetes - 클라우드 길들이기

Linux를 사용하여 비즈니스에 서비스를 제공하려는 경우 해당 서비스는 안전하고 탄력적이며 확장 가능해야 합니다. 좋은 말이지만 그게 무슨 뜻입니까?

'보안'은 읽기 전용 액세스 또는 쓰기 액세스와 같이 사용자가 필요한 데이터에 액세스할 수 있음을 의미합니다. 동시에 데이터를 볼 수 있는 권한이 없는 당사자에게 데이터가 노출되지 않습니다. 보안은 기만적입니다. 모든 것을 보호했다고 생각할 수 있지만 나중에 구멍이 있음을 알게 됩니다. 프로젝트 시작부터 보안을 설계하는 것이 나중에 개조하는 것보다 훨씬 쉽습니다.

'복원력'은 서비스가 인프라 내에서 장애를 허용함을 의미합니다. 장애는 더 이상 디스크에 액세스할 수 없는 서버 디스크 컨트롤러로 인해 데이터에 도달할 수 없게 될 수 있습니다. 또는 두 개 이상의 시스템이 더 이상 통신할 수 없게 만드는 네트워크 스위치에 장애가 있을 수 있습니다. 이러한 맥락에서 "단일 장애 지점" 또는 SPOF는 서비스 가용성에 부정적인 영향을 미치는 장애입니다. 탄력적인 인프라는 SPOF가 없는 인프라입니다.

'확장 가능'은 수요 급증을 적절하게 처리하는 시스템의 능력을 설명합니다. 또한 시스템을 얼마나 쉽게 변경할 수 있는지도 나타냅니다. 예를 들어 새 사용자를 추가하거나 스토리지 용량을 늘리거나 Amazon Web Services에서 Google Cloud로 인프라를 이전하거나 사내로 이전할 수도 있습니다.

인프라가 하나의 서버 이상으로 확장되는 즉시 보안, 탄력성 및 확장성을 높일 수 있는 많은 옵션이 있습니다. 이러한 문제가 전통적으로 어떻게 해결되었는지, 대규모 애플리케이션 컴퓨팅의 양상을 바꾸는 새로운 기술은 무엇인지 살펴보겠습니다.

오늘날 무엇이 가능한지 이해하려면 기술 프로젝트가 전통적으로 구현된 방식을 살펴보는 것이 좋습니다. 옛날, 즉 10년 전만 해도 기업은 애플리케이션의 모든 구성 요소를 실행하기 위해 하드웨어를 구입하거나 임대했습니다. WordPress 웹사이트와 같이 상대적으로 단순한 애플리케이션도 여러 구성 요소를 가지고 있습니다. WordPress의 경우 Apache와 같은 웹 서버 및 PHP 코드 처리 방법과 함께 MySQL 데이터베이스가 필요합니다. 그래서 그들은 서버를 구축하고, Apache, PHP 및 MySQL을 설정하고, WordPress를 설치하고 떠났습니다.

대체로 그것은 효과가 있었습니다. 오늘날에도 정확히 그런 방식으로 구성된 수많은 서버가 있을 정도로 충분히 잘 작동했습니다. 하지만 완벽하지는 않았고 더 큰 두 가지 문제는 복원력과 확장성이었습니다.

복원력이 부족하다는 것은 서버에 심각한 문제가 있으면 서비스 손실로 이어질 수 있음을 의미했습니다. 분명히 치명적인 오류는 웹사이트가 없다는 것을 의미하지만 웹사이트에 영향을 미치지 않고 예정된 유지 관리를 수행할 여지도 없었습니다. Apache용 일상적인 보안 업데이트를 설치하고 활성화하는 경우에도 웹 사이트가 몇 초간 중단되어야 합니다.

복원력 문제는 '고가용성 클러스터'를 구축하여 대부분 해결되었습니다. 원칙은 웹 사이트를 실행하는 두 대의 서버를 두는 것이었고, 둘 중 하나의 오류로 인해 웹 사이트가 다운되지 않도록 구성되었습니다. 제공되는 서비스는 개별 서버가 아니더라도 탄력적이었습니다.

슬래시닷 효과

확장성 문제는 조금 까다롭습니다. 귀하의 WordPress 사이트에 한 달에 1,000명의 방문자가 방문한다고 가정해 보겠습니다. 어느 날 라디오 4나 아침 식사 TV에서 귀하의 비즈니스가 언급됩니다. 갑자기 20분 만에 한 달치 이상의 방문자를 얻게 됩니다. 우리는 모두 웹 사이트가 '충돌'한다는 이야기를 들었고, 일반적으로 그 이유는 확장성 부족 때문입니다.

복원력을 지원하는 두 대의 서버는 한 대의 서버만 관리할 수 있는 것보다 더 높은 워크로드를 관리할 수 있지만 여전히 제한적입니다. 두 대의 서버에 대해 100% 비용을 지불하게 되고 대부분의 경우 둘 다 완벽하게 작동합니다. 혼자서 사이트를 운영할 수 있습니다. 그런 다음 John Humphrys가 Today에서 귀하의 비즈니스를 언급하고 로드를 처리하기 위해 10대의 서버가 필요하지만 단 몇 시간 동안만 필요합니다.

탄력성과 확장성 문제에 대한 더 나은 솔루션은 클라우드 컴퓨팅이었습니다. 애플리케이션을 실행하는 작은 서버인 서버 인스턴스를 Amazon Web Services(AWS) 또는 Google Cloud에 설정하고 인스턴스 중 하나가 어떤 이유로 실패하면 자동으로 다시 시작됩니다. Auto-Scaling을 올바르게 설정하고 Mr Humphrys로 인해 웹 서버 인스턴스의 작업 부하가 급격히 증가하면 추가 서버 인스턴스가 자동으로 시작되어 작업 부하를 공유합니다. 나중에 이자가 줄어들면 추가 인스턴스가 중지되고 사용한 만큼만 비용을 지불하면 됩니다. 완벽합니다… 아니면 그렇습니까?

클라우드 솔루션은 기존의 독립형 서버보다 훨씬 유연하지만 여전히 문제가 있습니다. 실행 중인 모든 클라우드 인스턴스를 업데이트하는 것은 간단하지 않습니다. 클라우드용 개발에도 어려움이 있습니다. 개발자가 사용하는 노트북이 클라우드 인스턴스와 유사할 수 있지만 동일하지는 않습니다. AWS에 전념하는 경우 Google Cloud로 마이그레이션하는 것은 복잡한 작업입니다. 어떤 이유로든 컴퓨터를 Amazon, Google 또는 Microsoft에 넘기고 싶지 않다고 가정해 보십시오.

컨테이너는 모든 종속성이 있는 애플리케이션을 어디에서나 실행할 수 있는 단일 패키지로 래핑하는 수단으로 등장했습니다. Docker와 같은 컨테이너는 클라우드 인스턴스에서 실행되는 것과 동일한 방식으로 개발자의 랩톱에서 실행될 수 있지만 컨테이너 수가 증가함에 따라 컨테이너 플릿을 관리하는 것이 점점 더 어려워집니다.

답은 컨테이너 오케스트레이션입니다. 이것은 초점의 중요한 변화입니다. 이전에는 워크로드를 서비스할 수 있도록 물리적이든 가상이든 충분한 서버가 있는지 확인했습니다. 클라우드 공급자의 자동 크기 조정을 사용하는 것이 도움이 되었지만 여전히 인스턴스를 처리하고 있었습니다. 로드 밸런서, 방화벽, 데이터 스토리지 등을 수동으로 구성해야 했습니다. 컨테이너 오케스트레이션을 사용하면 이 모든 것(그리고 훨씬 더 많은 것)이 처리됩니다. 필요한 결과를 지정하고 컨테이너 오케스트레이션 도구가 요구 사항을 충족합니다. 우리는 원하는 방식보다는 원하는 것을 지정합니다.

쿠버네티스 되기

Kubernetes(ku-ber-net-eez)는 오늘날 최고의 컨테이너 오케스트레이션 도구이며 Google에서 제공합니다. 대규모 IT 인프라를 운영하는 방법을 아는 사람이 있다면 Google은 알고 있습니다. Kubernetes의 기원은 검색 엔진, Gmail, Google 지도 등을 비롯한 대부분의 Google 애플리케이션을 실행하는 데 여전히 사용되는 내부 Google 프로젝트인 Borg입니다. Borg는 Google이 2015년에 이에 대한 논문을 발표하기 전까지는 비밀이었지만, 이 논문은 Borg가 Kubernetes의 주요 영감이었음을 매우 분명하게 보여주었습니다. 

Borg는 Google 데이터 센터의 계산 리소스를 관리하고 하드웨어 오류, 리소스 고갈 또는 정전을 야기할 수 있는 기타 문제 발생에도 불구하고 Google의 애플리케이션(프로덕션 및 기타)을 계속 실행하는 시스템입니다. Borg "셀"을 구성하는 수천 개의 노드와 여기에서 실행되는 컨테이너를 주의 깊게 모니터링하고 문제 또는 부하 변동에 대응하여 필요에 따라 컨테이너를 시작하거나 중지함으로써 이를 수행합니다.

Kubernetes 자체는 Google의 GIFEE('Google's Infrastructure For Everyone Else') 이니셔티브에서 탄생했으며 Google 외부에서 유용할 수 있는 친숙한 Borg 버전으로 설계되었습니다. 2015년 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF) 결성을 통해 리눅스 재단에 기부됐다.

Kubernetes는 컨테이너화된 애플리케이션 및 서비스를 "선언"하는 시스템을 제공하며 애플리케이션이 이러한 선언에 따라 실행되도록 합니다. 프로그램에 스토리지 또는 로드 밸런서와 같은 외부 리소스가 필요한 경우 Kubernetes는 이를 자동으로 프로비저닝할 수 있습니다. 애플리케이션을 확장하거나 축소하여 부하 변화에 따라갈 수 있으며 필요할 때 전체 클러스터를 확장할 수도 있습니다. 프로그램의 구성 요소는 실행 중인 위치를 알 필요조차 없습니다. Kubernetes는 "wp_mysql"에 연결하고 올바른 리소스에 자동으로 연결할 수 있도록 애플리케이션에 내부 이름 지정 서비스를 제공합니다.'

최종 결과는 단일 머신에서 온프레미스 시스템 랙을 통해 모든 주요 클라우드 제공업체에서 실행되는 클라우드 기반 가상 머신에 이르기까지 모든 인프라에서 애플리케이션을 실행하는 데 사용할 수 있는 플랫폼이며 모두 동일한 컨테이너를 사용합니다. 및 구성. Kubernetes는 공급자에 구애받지 않습니다. 원하는 곳 어디에서나 실행할 수 있습니다.

Kubernetes는 강력한 도구이며 필연적으로 복잡합니다. 개요를 살펴보기 전에 Kubernetes 내에서 사용되는 몇 가지 용어를 소개해야 합니다. 컨테이너는 위에서 설명한 대로 단일 애플리케이션을 실행하고 포드로 그룹화됩니다. Pod는 동일한 호스트에 함께 배포되고 일부 리소스를 공유하는 밀접하게 연결된 컨테이너 그룹입니다. 포드 내의 컨테이너는 팀으로 작동합니다. 애플리케이션 컨테이너 및 애플리케이션에 대한 특정 설정이 있는 로깅 컨테이너와 같은 관련 기능을 수행합니다.

네 가지 주요 Kubernetes 구성 요소는 API 서버, 스케줄러, 컨트롤러 관리자 및 etcd라는 분산 구성 데이터베이스입니다. API 서버는 Kubernetes의 핵심이며 모든 관리 요청에 대한 기본 엔드포인트 역할을 합니다. 이는 스케줄러, 명령줄 또는 웹 기반 대시보드를 통한 관리자, 컨테이너화된 애플리케이션 자체와 같은 다른 Kubernetes 구성 요소를 비롯한 다양한 소스에서 생성될 수 있습니다. 요청을 검증하고 etcd에 저장된 데이터를 업데이트합니다.

스케줄러는 리소스 요구 사항, 하드웨어 또는 소프트웨어 제약 조건, 워크로드, 기한 등과 같은 제약 조건을 고려하여 다양한 포드가 실행될 노드를 결정합니다.

컨트롤러 관리자는 클러스터의 상태를 모니터링하고 클러스터를 원하는 상태로 가져오기 위해 필요에 따라 API 서버를 통해 포드를 시작하거나 중지하려고 시도합니다. 또한 일부 내부 연결 및 보안 기능을 관리합니다.

각 노드는 API 서버와 통신하고 일반적으로 Docker를 사용하여 컨테이너를 관리하는 Kubelet 프로세스와 클러스터 내에서 네트워크 프록시 및 로드 밸런싱을 처리하는 Kube-Proxy를 실행합니다.

etcd 분산 데이터베이스 시스템은 시스템 구성 정보를 보유하는 데 사용되는 Linux 시스템의 /etc 폴더와 데몬 프로세스를 나타내는 데 자주 사용되는 접미사 'd'에서 이름을 가져옵니다. etcd의 목표는 키-값 데이터를 분산되고 일관되며 내결함성 방식으로 저장하는 것입니다.

API 서버는 모든 상태 데이터를 etcd에 보관하고 많은 인스턴스를 동시에 실행할 수 있습니다. 스케줄러 및 컨트롤러 관리자는 활성 인스턴스를 하나만 가질 수 있지만 임대 시스템을 사용하여 실행 중인 인스턴스가 마스터인지 확인합니다. 이 모든 것은 Kubernetes가 단일 장애 지점 없이 고가용성 시스템으로 실행될 수 있음을 의미합니다.

함께 모아서

그렇다면 이러한 구성 요소를 실제로 어떻게 사용합니까? 다음은 Kubernetes를 사용하여 WordPress 웹 사이트를 설정하는 예입니다. 실제로 이 작업을 수행하려면 투구 차트라고 하는 미리 정의된 레시피를 사용할 것입니다. 여러 일반적인 애플리케이션에 사용할 수 있지만 여기서는 Kubernetes에서 WordPress 사이트를 시작하고 실행하는 데 필요한 몇 가지 단계를 살펴보겠습니다.

첫 번째 작업은 MySQL의 암호를 정의하는 것입니다.

kubectl create secret generic mysql-pass --from-literal=password=YOUR_PASSWORD

kubectl은 API 서버와 통신하여 명령의 유효성을 검사한 다음 암호를 etcd에 저장합니다. 우리 서비스는 YAML 파일에 정의되어 있으며 이제 MySQL 데이터베이스를 위한 영구 스토리지가 필요합니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
  labels:
    app: wordpress
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi

사양은 대부분 자명해야 합니다. name 및 labels 필드는 Kubernetes의 다른 부분(이 경우 WordPress 컨테이너)에서 이 스토리지를 참조하는 데 사용됩니다.

스토리지를 정의하고 나면 미리 정의된 스토리지를 가리키는 MySQL 인스턴스를 정의할 수 있습니다. 그런 다음 데이터베이스 자체를 정의합니다. Kubernetes 내에서 쉽게 참조할 수 있도록 해당 데이터베이스에 이름과 레이블을 지정합니다.

이제 WordPress를 실행하려면 다른 컨테이너가 필요합니다. 컨테이너 배포 사양의 일부는 다음과 같습니다.

kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  strategy:
    type: Recreate

전략 유형 "재생성"은 애플리케이션을 구성하는 코드가 변경되면 실행 중인 인스턴스가 삭제되고 다시 생성됨을 의미합니다. 다른 옵션으로는 새 인스턴스를 순환하고 기존 인스턴스를 하나씩 제거하여 업데이트를 배포하는 동안 서비스를 계속 실행할 수 있습니다. 마지막으로 PHP 코드와 Apache로 구성된 WordPress 자체에 대한 서비스를 선언합니다. 이를 선언하는 YAML 파일의 일부는 다음과 같습니다.

metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  ports:
    - port: 80
  selector:
    app: wordpress
    tier: frontend
  type: LoadBalancer

서비스 유형을 LoadBalancer로 정의하는 마지막 줄에 유의하십시오. 그러면 Kubernetes 외부에서 서비스를 사용할 수 있도록 Kubernetes에 지시합니다. 해당 라인이 없으면 이것은 단지 내부 "Kubernetes 전용" 서비스일 뿐입니다. 그리고 그게 다야. Kubernetes는 이제 이러한 YAML 파일을 필요한 선언으로 사용하고 클러스터를 "원하는" 상태로 만드는 데 필요한 포드, 연결, 스토리지 등을 설정합니다.

이것은 필연적으로 Kubernetes에 대한 상위 수준의 개요일 뿐이며 시스템의 많은 세부 사항과 기능은 생략되었습니다. 우리는 자동 확장(클러스터를 구성하는 포드와 노드 모두), cron 작업(일정에 따라 컨테이너 시작), Ingress(HTTP 로드 밸런싱, 재작성 및 SSL 오프로딩), RBAC(역할 기반 액세스 제어)에 대해 얼버무렸습니다. , 네트워크 정책(방화벽) 등. 쿠버네티스는 매우 유연하고 매우 강력합니다. 새로운 IT 인프라의 경우 강력한 경쟁자가 되어야 합니다.  

자원

Docker에 익숙하지 않은 경우 https://docs.docker.com/get-started (새 탭에서 열림) 에서 시작하세요 .

https://kubernetes.io/docs/tutorials/kubernetes-basics (새 탭에서 열림) 앱 배포 및 확장에 대한 대화형 튜토리얼이 있습니다 .

그리고 클러스터를 구축하는 방법은 https://kubernetes.io/docs/setup/scratch (새 탭에서 열림)를 참조하세요.

https://tryk8s.com (새 탭에서 열림) 에서 무료 Kubernetes 클러스터를 사용해 볼 수 있습니다 .

마지막으로 https://storage.googleapis.com/pub-tools-public-publication-data/ 에서 Google의 Borg 사용에 대한 훌륭한 개요와 그것이 Kubernetes 설계에 어떻게 영향을 미쳤는지에 대한 긴 기술 문서를 자세히 살펴볼 수 있습니다. pdf/43438.pdf (새 탭에서 열림) .

Tiger Computing (새 탭에서 열림) 에 대해 자세히 알아보십시오 .

• 2020년 최고의 온라인 클라우드 스토리지: 무료, 유료 및 비즈니스 옵션