쿠버네티스란? 컨테이너화 및 배포 가이드

얼마 전 우리는 모놀리식 웹 애플리케이션을 사용했습니다. 새로운 기능과 기능에서 성장한 거대한 코드베이스는 거대하고 느리게 움직이며 관리하기 힘든 거대 기업으로 변모했습니다. 이제 점점 더 많은 개발자, 아키텍트, DevOps 전문가가 거대한 단일체보다 마이크로서비스를 사용하는 것이 더 낫다는 의견을 제시하고 있습니다. 일반적으로 마이크로서비스 기반 아키텍처를 사용한다는 것은 모놀리스를 프론트엔드 앱과 백엔드 앱(API)의 두 가지 이상의 애플리케이션으로 나누는 것을 의미합니다. 마이크로 서비스를 사용하기로 결정한 후 질문이 발생합니다. 어떤 환경에서 마이크로 서비스를 실행하는 것이 더 낫습니까? 내 서비스를 안정적으로 관리하고 배포하기 쉽게 하려면 무엇을 선택해야 합니까? 짧은 대답은 다음과 같습니다. Docker를 사용하십시오!

이 기사에서는 컨테이너를 소개하고 Kubernetes를 설명하며 CircleCI를 사용하여 앱을 컨테이너화하고 Kubernetes 클러스터에 배포하는 방법을 알려 드리겠습니다.

도커? 도커란?

Docker는 DevOps(및 귀하의 삶)를 더 쉽게 만들기 위해 설계된 도구입니다. Docker를 사용하여 개발자는 컨테이너 에서 애플리케이션을 생성, 배포 및 실행할 수 있습니다. 개발자는 컨테이너를 사용하여 라이브러리 및 기타 종속성과 같이 필요한 모든 부분으로 애플리케이션을 패키징하고 모두 하나의 패키지로 제공할 수 있습니다.

컨테이너를 사용하여 개발자는 이미지를 모든 OS에 쉽게 (재)배포할 수 있습니다. Docker를 설치하고 명령을 실행하기만 하면 애플리케이션이 실행됩니다. 아, 그리고 호스트 OS에서 라이브러리의 새 버전과의 불일치에 대해 걱정하지 마십시오. 또한 동일한 호스트에서 더 많은 컨테이너를 실행할 수 있습니다. 동일한 앱이 될 것입니까 아니면 다른 것이 될 것입니까? 그것은 중요하지 않습니다.

Docker는 멋진 도구인 것 같습니다. 그러나 컨테이너를 어떻게 어디서 시작해야 합니까?

컨테이너를 실행하는 방법과 위치에 대한 많은 옵션이 있습니다. AWS Elastic Container Service(AWS Fargate 또는 수평 및 수직 Auto Scaling이 있는 예약 인스턴스); Azure 또는 Google Cloud에서 사전 정의된 Docker 이미지가 있는 클라우드 인스턴스(템플릿, 인스턴스 그룹 및 자동 크기 조정 포함) Docker가 있는 자체 서버에서 또는 물론 Kubernetes! Kubernetes는 2014년 Google 엔지니어가 가상화 및 컨테이너용으로 특별히 만들었습니다.

쿠버네티스? 저게 뭐에요?

Kubernetes는 컨테이너 실행, 컨테이너 관리, 배포 자동화, 배포 확장, 수신 생성 및 구성, 상태 비저장 또는 상태 저장 애플리케이션 배포 및 기타 여러 작업을 수행할 수 있는 오픈 소스 시스템입니다. 기본적으로 하나 이상의 인스턴스를 시작하고 Kubernetes를 설치하여 Kubernetes 클러스터로 운영할 수 있습니다. 그런 다음 Kubernetes 클러스터의 API 엔드포인트를 가져 kubectl (Kubernetes 클러스터 관리 도구)을 구성하면 Kubernetes가 제공될 준비가 됩니다.

왜 사용해야합니까?

Kubernetes를 사용하면 컴퓨팅 리소스를 최대한 활용할 수 있습니다. Kubernetes를 사용하면 돛을 채우는 Kubernetes로 선박(인프라)의 선장이 됩니다. Kubernetes를 사용하면 서비스가 HA가 됩니다. 그리고 가장 중요한 것은 Kubernetes를 사용하면 상당한 비용을 절약할 수 있다는 것입니다.

유망해 보인다! 특히 돈을 절약할 수 있다면! 그것에 대해 더 이야기합시다!

Kubernetes는 나날이 인기를 얻고 있습니다. 더 깊이 들어가서 내부에 무엇이 있는지 조사해 보겠습니다.

내부: Kubernetes란 무엇입니까?

Kubernetes는 전체 시스템의 이름이지만 자동차와 마찬가지로 Kubernetes 기능을 만들기 위해 완벽한 조화를 이루는 많은 작은 부품이 있습니다. 그들이 무엇인지 알아보자.

마스터 노드 – 전체 Kubernetes 클러스터에 대한 제어판입니다. 마스터의 구성 요소는 클러스터의 모든 노드에서 실행할 수 있습니다. 주요 구성 요소는 다음과 같습니다.

• API 서버: 모든 REST 명령의 진입점으로, 사용자가 액세스할 수 있는 마스터 노드의 유일한 구성 요소입니다.
• 데이터 저장소: Kubernetes 클러스터에서 사용하는 강력하고 일관성 있는 고가용성 키-값 저장소입니다.
• 스케줄러: 새로 생성된 포드를 감시하고 노드에 할당합니다. 노드에 포드 및 서비스 배포는 스케줄러로 인해 발생합니다.
• 컨트롤러 관리자: 클러스터에서 일상적인 작업을 처리하는 모든 컨트롤러를 실행합니다.
• 작업자 노드: 미니언 노드라고도 하는 기본 노드 에이전트. 포드는 여기에서 실행됩니다. 작업자 노드에는 컨테이너 간의 네트워킹을 관리하고, 마스터 노드와 통신하고, 예약된 컨테이너에 리소스를 할당하는 데 필요한 모든 서비스가 포함되어 있습니다.
• Docker: 각 작업자 노드에서 실행되고 이미지 및 시작 컨테이너를 다운로드합니다.
• Kubelet: 포드의 상태를 모니터링하고 컨테이너가 실행 중인지 확인합니다. 또한 데이터 저장소와 통신하여 서비스에 대한 정보를 얻고 새로 생성된 서비스에 대한 세부 정보를 작성합니다.
• Kube-proxy: 단일 작업자 노드의 서비스에 대한 네트워크 프록시 및 로드 밸런서입니다. 트래픽 라우팅을 담당합니다.
• Kubectl: 사용자가 Kubernetes API 서버와 통신하기 위한 CLI 도구입니다.

포드 및 서비스란 무엇입니까?

Pod 는 Kubernetes 클러스터의 가장 작은 단위이며 거대한 건물 벽에 있는 벽돌과 같습니다. 포드는 함께 실행해야 하고 리소스(Linux 네임스페이스, cgroup, IP 주소)를 공유할 수 있는 컨테이너 집합입니다. 포드는 오래 살기 위한 것이 아닙니다.

서비스 는 여러 포드 위에 있는 추상화로, 일반적으로 다른 서비스가 가상 IP 주소를 통해 통신하려면 맨 위에 프록시가 필요합니다.

간단한 배포 예

Kubernetes를 실행하기 위한 플랫폼으로 간단한 Ruby on Rails 애플리케이션과 GKE를 사용하겠습니다. 실제로 AWS 또는 Azure에서 Kubernetes를 사용하거나 자체 하드웨어에서 클러스터를 생성하거나 minikube 를 사용하여 로컬에서 Kubernetes를 실행할 수도 있습니다. 이 페이지에서 모든 옵션을 찾을 수 있습니다.

이 앱의 소스 파일은 이 GitHub 리포지토리에서 찾을 수 있습니다.

새 Rails 앱을 생성하려면 다음을 실행하세요.

 rails new blog

config/database.yml file 에서 프로덕션용 MySQL 연결을 구성하려면 다음을 수행하십시오.

 production: adapter: mysql2 encoding: utf8 pool: 5 port: 3306 database: <%= ENV['DATABASE_NAME'] %> host: 127.0.0.1 username: <%= ENV['DATABASE_USERNAME'] %> password: <%= ENV['DATABASE_PASSWORD'] %>

기사 모델, 컨트롤러, 보기 및 마이그레이션을 생성하려면 다음을 실행하십시오.

 rails g scaffold Article title:string description:text

Gemfile에 보석을 추가하려면:

 gem 'mysql2', '< 0.6.0', '>= 0.4.4' gem 'health_check'

Docker 이미지를 생성하려면 Dockerfile을 잡고 다음을 실행하십시오.

 docker build -t REPO_NAME/IMAGE_NAME:TAG . && docker push REPO_NAME/IMAGE_NAME:TAG

Kubernetes 클러스터를 생성할 시간입니다. GKE 페이지를 열고 Kubernetes 클러스터를 만듭니다. 클러스터가 생성되면 "연결 버튼"을 클릭하고 명령을 복사합니다. gCloud CLI 도구(방법)와 kubectl이 설치 및 구성되어 있는지 확인합니다. 복사한 명령을 PC에서 실행하고 Kubernetes 클러스터에 대한 연결을 확인하십시오. kubectl cluster-info 실행합니다.

앱이 k8s 클러스터에 배포할 준비가 되었습니다. MySQL 데이터베이스를 생성해 봅시다. gCloud 콘솔에서 SQL 페이지를 열고 애플리케이션에 대한 MySQL DB 인스턴스를 만듭니다. 인스턴스가 준비되면 사용자와 DB를 생성하고 인스턴스 연결 이름 을 복사합니다.

또한 사이드카 컨테이너에서 MySQL DB에 액세스하기 위해 API 및 서비스 페이지에서 서비스 계정 키를 생성해야 합니다. 여기에서 해당 프로세스에 대한 자세한 정보를 찾을 수 있습니다. 다운로드한 파일의 이름을 service-account.json 으로 바꿉니다. 나중에 해당 파일로 돌아올 것입니다.

애플리케이션을 Kubernetes에 배포할 준비가 되었지만 먼저 애플리케이션에 대한 비밀, 즉 민감한 데이터를 저장하기 위해 만들어진 Kubernetes의 비밀 개체를 만들어야 합니다. 이전에 다운로드한 service-account.json 파일을 업로드합니다.

 kubectl create secret generic mysql-instance-credentials \ --from-file=credentials.json=service-account.json

애플리케이션에 대한 비밀 생성:

 kubectl create secret generic simple-app-secrets \ --from-literal=username=$MYSQL_PASSWORD \ --from-literal=password=$MYSQL_PASSWORD \ --from-literal=database-name=$MYSQL_DB_NAME \ --from-literal=secretkey=$SECRET_RAILS_KEY

값을 바꾸거나 환경 변수를 값으로 설정하는 것을 잊지 마십시오.

배포를 만들기 전에 배포 파일을 살펴보겠습니다. 3개의 파일을 하나로 연결했습니다. 첫 번째 부분은 포트 80을 노출하고 포트 80에서 3000으로 오는 모든 연결을 포워딩하는 서비스입니다. 서비스에는 연결을 포워딩해야 하는 파드에 서비스가 알고 있는 선택기가 있습니다.

파일의 다음 부분은 배포 전략을 설명하는 배포입니다. 포드 내에서 실행될 컨테이너, 환경 변수, 리소스, 프로브, 각 컨테이너의 마운트 및 기타 정보입니다.

마지막 부분은 Horizontal Pod Autoscaler입니다. HPA 는 매우 간단한 구성을 가지고 있습니다. 배포 섹션에서 컨테이너에 대한 리소스를 설정하지 않으면 HPA 가 작동하지 않습니다.

GKE 편집 페이지에서 Kubernetes 클러스터에 대한 수직 자동 확장 처리를 구성할 수 있습니다. 그것은 또한 매우 간단한 구성을 가지고 있습니다.

이제 GKE 클러스터로 배송할 시간입니다! 먼저 작업을 통해 마이그레이션을 실행해야 합니다. 실행하다:

kubectl apply -f rake-tasks-job.yaml – 이 작업은 CI/CD 프로세스에 유용합니다.

kubectl apply -f deployment.yaml – 서비스, 배포 및 HPA를 생성합니다.

그런 다음 kubectl get pods -w 명령을 실행하여 포드를 확인합니다.

 NAME READY STATUS RESTARTS AGE sample-799bf9fd9c-86cqf 2/2 Running 0 1m sample-799bf9fd9c-887vv 2/2 Running 0 1m sample-799bf9fd9c-pkscp 2/2 Running 0 1m

이제 애플리케이션에 대한 인그레스를 생성해 보겠습니다.

1. 고정 IP 만들기: gcloud compute addresses create sample-ip --global
2. 수신(파일) 생성: kubectl apply -f ingress.yaml
3. 수신이 생성되었는지 확인하고 IP를 가져옵니다. kubectl get ingress -w
4. 애플리케이션에 대한 도메인/하위 도메인을 만듭니다.

CI/CD

CircleCI를 사용하여 CI/CD 파이프라인을 생성해 보겠습니다. 실제로 CircleCI를 사용하여 CI/CD 파이프라인을 만드는 것은 쉽지만 이와 같은 테스트 없이 빠르고 더러운 완전 자동화된 배포 프로세스는 소규모 프로젝트에서는 작동하지만 심각한 작업에는 이 작업을 수행하지 마십시오. , 새 코드에 프로덕션에 문제가 있으면 돈을 잃게 됩니다. 그렇기 때문에 강력한 배포 프로세스를 설계하고, 전체 롤아웃 전에 카나리아 작업을 시작하고, 카나리아가 시작된 후 로그에서 오류를 확인하는 등의 작업을 고려해야 합니다.

현재 우리에게는 작고 간단한 프로젝트가 있으므로 테스트가 필요 없는 완전 자동화된 CI/CD 배포 프로세스를 만들어 보겠습니다. 먼저 CircleCI를 저장소와 통합해야 합니다. 여기에서 모든 지침을 찾을 수 있습니다. 그런 다음 CircleCI 시스템에 대한 지침이 포함된 구성 파일을 만들어야 합니다. 구성은 매우 간단해 보입니다. 요점은 GitHub 리포지토리에 master 와 production 이라는 두 가지 분기가 있다는 것입니다.

1. 마스터 브랜치 는 새로운 코드를 위한 개발용입니다. 누군가가 새 코드를 마스터 분기에 푸시하면 CircleCI는 마스터 분기에 대한 워크플로(코드 빌드 및 테스트)를 시작합니다.
2. 프로덕션 분기 는 새 버전을 프로덕션 환경에 배포하기 위한 것입니다. 프로덕션 브랜치의 워크플로는 다음과 같습니다. 새 코드를 푸시(또는 마스터 브랜치에서 프로덕션으로 PR 열기)하여 새 빌드 및 배포 프로세스를 트리거합니다. 빌드하는 동안 CircleCI는 새 Docker 이미지를 만들고 GCR에 푸시하고 배포를 위한 새 롤아웃을 만듭니다. 롤아웃이 실패하면 CircleCI가 롤백 프로세스를 트리거합니다.

빌드를 실행하기 전에 CircleCI에서 프로젝트를 구성해야 합니다. API 및 GCloud의 서비스 페이지에서 다음 역할을 사용하여 새 서비스 계정을 만듭니다. GCR 및 GKE에 대한 전체 액세스, 다운로드한 JSON 파일 열기 및 콘텐츠 복사, CircleCI의 프로젝트 설정에서 이름으로 새 환경 변수 생성 GCLOUD_SERVICE_KEY 를 입력하고 서비스 계정 파일의 내용을 값으로 붙여넣습니다. 또한 다음 환경 변수인 GOOGLE_PROJECT_ID (GCloud 콘솔 홈페이지에서 찾을 수 있음), GOOGLE_COMPUTE_ZONE (GKE 클러스터의 영역) 및 GOOGLE_CLUSTER_NAME (GKE 클러스터 이름)을 만들어야 합니다.

CircleCI의 마지막 단계(배포)는 다음과 같습니다.

 kubectl patch deployment sample -p '{"spec":{"template":{"spec":{"containers":[{"name":"sample","image":"gcr.io/test-d6bf8/simple:'"$CIRCLE_SHA1"'"}]}}}}' if ! kubectl rollout status deploy/sample; then echo "DEPLOY FAILED, ROLLING BACK TO PREVIOUS" kubectl rollout undo deploy/sample # Deploy failed -> notify slack else echo "Deploy succeeded, current version: ${CIRCLE_SHA1}" # Deploy succeeded -> notify slack fi deployment.extensions/sample patched Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 2 out of 3 new replicas have been updated... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 1 old replicas are pending termination... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... Waiting for deployment "sample" rollout to finish: 2 of 3 updated replicas are available... deployment "sample" successfully rolled out Deploy succeeded, current version: 512eabb11c463c5431a1af4ed0b9ebd23597edd9

결론

새로운 Kubernetes 클러스터를 만드는 과정이 그렇게 어렵지 않은 것 같습니다! 그리고 CI/CD 프로세스는 정말 굉장합니다!

네! 쿠버네티스는 굉장합니다! Kubernetes를 사용하면 시스템이 더 안정적이고 쉽게 관리할 수 있으며 시스템의 캡틴이 됩니다. 말할 것도 없이 Kubernetes는 시스템을 약간 게임화하고 마케팅에 +100포인트를 제공합니다!

이제 기본 사항을 숙지했으므로 더 나아가 이를 고급 구성으로 전환할 수 있습니다. 향후 기사에서 더 많은 내용을 다룰 계획이지만 그 동안에는 다음과 같은 과제가 있습니다. 클러스터 내부에 있는 상태 저장 DB로 애플리케이션을 위한 강력한 Kubernetes 클러스터 생성(백업을 위한 사이드카 Pod 포함), 내부에 Jenkins 설치 CI/CD 파이프라인에 대해 동일한 Kubernetes 클러스터를 만들고 Jenkins가 포드를 빌드의 슬레이브로 사용하도록 합니다. 인그레스에 대한 SSL 인증서를 추가/획득하려면 certmanager를 사용하세요. Stackdriver를 사용하여 애플리케이션에 대한 모니터링 및 알림 시스템을 만드세요.

Kubernetes는 쉽게 확장할 수 있고 공급업체에 종속되지 않으며 인스턴스 비용을 지불하기 때문에 비용을 절감할 수 있다는 점에서 훌륭합니다. 그러나 모든 사람이 Kubernetes 전문가이거나 새 클러스터를 설정할 시간이 있는 것은 아닙니다. 대안적 관점에서 동료 Toptaler Amin Shah Gilani는 Heroku, GitLab CI 및 이미 파악한 대량의 자동화를 사용하는 사례를 제시합니다. 효과적인 초기 배포 파이프라인을 구축하는 방법 에서 더 많은 코드를 작성하고 더 적은 작업을 수행하기 위해 .