에지에 베어메탈용 Anthos 클러스터 배포

이 튜토리얼에서는 에지에 Kubernetes 클러스터를 대규모로 배포하기 위해 베어메탈용 Anthos 클러스터 및 Anthos Config Management를 사용하는 즉시 사용 가능한 솔루션을 소개합니다. 이 튜토리얼은 플랫폼 운영자 및 개발자를 대상으로 합니다. 다음 기술 및 개념에 대한 자세한 이해가 필요합니다.

Ansible 플레이북
에지 배포 및 해당 도전과제
Google Cloud 프로젝트 작업 방법
컨테이너화된 웹 애플리케이션 배포
gcloud 및 kubectl 명령줄 인터페이스

이 튜토리얼에서는 Compute Engine 가상 머신(VM)을 사용하여 에지에 배포된 노드를 에뮬레이션하고 샘플 판매 시점 애플리케이션을 에지 워크로드로 사용합니다. 베어메탈용 Anthos 클러스터 및 Anthos Config Management는 에지 클러스터에 대해 중앙화된 관리 및 제어를 제공합니다. Anthos Config Management는 GitHub에서 새 구성을 동적으로 가져와서 이러한 정책 및 구성을 클러스터에 적용합니다.

에지 배포 아키텍처

리테일 에지 배포는 일반적인 베어메탈용 Anthos 클러스터 배포에 사용되는 아키텍처를 보여주는 좋은 방법입니다.

실제 리테일 매장은 기업 사업부와 소비자 사이의 가장 가까운 상호작용 지점입니다. 매장 내부의 소프트웨어 시스템은 기업 중앙 관리 시스템에서 격리된 상태로 워크로드를 실행하고, 적시에 업데이트를 수신하고, 핵심 측정항목을 보고해야 합니다. 또한 향후 더 많은 저장 위치로 확장할 수 있도록 이러한 소프트웨어 시스템을 설계해야 합니다. 베어메탈용 Anthos 클러스터는 매장 소프트웨어 시스템에 대해 이러한 모든 요구사항을 충족시켜 주지만, 에지 프로필은 리테일 매장 프런트와 같이 하드웨어 리소스가 제한된 환경에서의 배포라는 중요한 사용 사례를 지원합니다.

다음 다이어그램은 리테일 매장에서 에지 프로필을 사용하는 베어메탈용 Anthos 클러스터 배포를 보여줍니다.

위 다이어그램은 일반적인 실제 리테일 매장을 보여줍니다. 이 매장에는 카드 리더기, 판매 시점 머신, 카메라 및 프린터와 같은 스마트 장치가 포함되어 있습니다. 또한 저장소에 3개의 물리적 컴퓨팅 하드웨어 장치(Node 1, Node 2, Node 3 라벨로 지정됨)가 포함되어 있습니다. 이 모든 장치는 중앙 네트워크 스위치에 연결되어 있습니다. 따라서 3개의 컴퓨팅 장치가 레이어 2 네트워크를 통해 서로 연결됩니다. 네트워크로 연결된 컴퓨팅 장치가 베어 메탈 인프라를 구성합니다. 베어메탈용 Anthos 클러스터는 3개의 각 컴퓨팅 장치 내에서 실행됩니다. 이러한 기기는 또한 고유 디스크 스토리지가 있고 고가용성을 위해 장치 간 데이터 복제가 구성되어 있습니다.

이 다이어그램은 베어메탈용 Anthos 클러스터 배포에 포함된 다음 주요 구성요소를 보여줍니다.

MetalLB로 표시된 구성요소는 베어메탈용 Anthos 클러스터에 배포된 번들 부하 분산기입니다.
Anthos Config Management 구성요소는 소스 저장소에 대해 클러스터 상태를 동기화할 수 있게 해줍니다. 개별 설치 및 구성이 필요한 선택적인 부가기능이 권장됩니다. Anthos Config Management 및 다른 명명법을 설정하는 방법은 Anthos Config Management 문서를 참조하세요.
매장 위치 외부의 다이어그램 위에 표시된 루트 저장소 및 네임스페이스 저장소는 2개의 소스 저장소를 나타냅니다.

클러스터 변경사항은 이러한 중앙 소스 저장소로 푸시됩니다. 여러 에지 위치의 베어메탈용 Anthos 클러스터 배포는 소스 저장소에서 업데이트를 가져옵니다. 이 동작은 다이어그램의 두 저장소를 장치에서 실행되는 베어메탈용 Anthos 클러스터 내에 있는 Anthos Config Management 구성요소에 연결하는 화살표로 표시됩니다.
클러스터 일부로 표시된 또 다른 주요 구성요소는 Anthos VM 런타임입니다. Anthos VM 런타임을 사용하면 컨테이너화 없이 클러스터 내에서 기존 VM 기반 워크로드를 실행할 수 있습니다. Anthos VM 런타임 문서에서는 이를 사용 설정하고 VM 워크로드를 클러스터에 배포하는 방법을 보여줍니다.
애플리케이션으로 표시된 구성요소는 리테일 매장에서 클러스터에 배포된 소프트웨어를 나타냅니다. 리테일 매장의 키오스크에 표시된 판매 시점 애플리케이션은 이러한 애플리케이션의 한 가지 예시일 수 있습니다.

다이어그램 아래의 상자는 모두 중앙 네트워크 스위치에 연결되어 있는 리테일 매장 내에 있는 키오스크, 태블릿, 카메라와 같은 많은 장치를 나타냅니다. 매장 내부의 로컬 네트워크 연결은 베어메탈용 Anthos 클러스터 배포 내에서 실행되는 애플리케이션이 이러한 장치에 연결할 수 있게 해줍니다.

다음 섹션에서는 Compute Engine VM을 사용하여 Google Cloud에서 이러한 리테일 매장 배포를 에뮬레이션합니다. 이 에뮬레이션은 튜토리얼에서 이후 베어메탈용 Anthos 클러스터 실험을 계속하기 위해 사용됩니다.

Google Cloud의 에뮬레이션된 에지 배포

다음 다이어그램은 이 튜토리얼에서 Google Cloud에 설정하는 모든 것을 보여줍니다. 이 다이어그램은 이전 섹션의 리테일 매장 다이어그램과 관련이 있습니다. 이 배포는 판매 시점 애플리케이션이 배포되는 에뮬레이션된 에지 위치를 나타냅니다. 이 아키텍처는 이 튜토리얼에서 사용하는 간단한 판매 시점 샘플 애플리케이션을 보여줍니다. 웹 브라우저를 키오스크로 사용하여 클러스터 내의 판매시점 애플리케이션에 액세스합니다.

이 이미지는 판매 시점 애플리케이션의 아키텍처와 Compute Engine VM에서 실행되는 베어메탈용 Anthos 클러스터 내부에 배포되는 방법을 보여줍니다. — 베어메탈용 Anthos 클러스터 내부에 배포된 샘플 애플리케이션

앞의 다이어그램에서 3개의 Compute Engine 가상 머신(VM)은 일반적인 에지 위치의 물리적 하드웨어(또는 노드)를 나타냅니다. 이 하드웨어는 네트워크 스위치와 함께 연결되어 베어메탈 인프라를 구성합니다. Google Cloud의 에뮬레이션된 환경에서 이러한 VM은 Google Cloud 프로젝트의 기본 Virtual Private Cloud(VPC) 네트워크를 통해 서로 연결됩니다.

일반적인 베어메탈용 Anthos 클러스터 설치에서는 자체 부하 분산기를 구성할 수 있습니다. 하지만 이 튜토리얼에서는 외부 부하 분산기를 설정하지 않습니다. 대신 베어메탈용 Anthos 클러스터로 설치된 번들 MetalLB 부하 분산기를 사용합니다. 번들 MetalLB 부하 분산기는 노드 간에 레이어 2 네트워크 연결이 필요합니다. 따라서 Compute Engine VM 사이의 레이어 2 연결은 기본 Virtual Private Cloud(VPC) 네트워크 위에서 VxLAN 오버레이 네트워크를 생성하여 사용 설정됩니다.

라벨이 'L2 오버레이 네트워크(VxLAN)'로 표시된 직사각형 내에는 3개의 Compute Engine VM 내에서 실행되는 소프트웨어 구성요소가 표시되어 있습니다. 이 직사각형은 베어메탈용 Anthos 클러스터 및 역방향 프록시를 포함합니다. 클러스터는 '베어메탈용 Anthos 클러스터' 직사각형으로 표시됩니다. 클러스터를 나타내는 이 직사각형은 'Kubernetes 네임스페이스(pos)'로 표시된 또 다른 직사각형을 포함합니다. 이는 클러스터 내의 Kubernetes 네임스페이스를 나타냅니다. 이 Kubernetes 네임스페이스 내부의 모든 구성요소는 Anthos 클러스터에 배포되는 판매 시점 애플리케이션을 구성합니다. 판매 시점 애플리케이션에는 API 서버, 인벤토리 및 결제의 세 가지 마이크로서비스가 포함됩니다. 이러한 모든 구성요소가 앞의 에지 출시 아키텍처 다이어그램에 표시된 하나의 '애플리케이션'을 나타냅니다.

Anthos 클러스터의 번들 MetalLB 부하 분산기는 VM 외부에서 직접 연결할 수 없습니다. 이 다이어그램은 Compute Engine VM으로 수신되는 트래픽을 부하 분산기로 라우팅하기 위해 VM 내에서 실행되도록 구성된 NGINX 역방향 프록시를 보여줍니다. 이 방법은 에지 노드가 Google Cloud Compute Engine VM을 사용하여 에뮬레이션된 이 튜토리얼에서만 사용되는 해결 방법입니다. 실제 에지 위치에서는 적절한 네트워크 구성을 통해 이를 수행할 수 있습니다.

목표

Compute Engine VM을 사용하여 에지 위치에서 실행되는 베어메탈 인프라를 에뮬레이션합니다.
에뮬레이션된 에지 인프라에서 베어메탈용 Anthos 클러스터를 만듭니다.
Google Cloud에 클러스터를 연결하고 등록합니다.
Anthos 클러스터에 샘플 판매 시점 애플리케이션 워크로드를 배포합니다.
Google Cloud 콘솔을 사용하여 에지 위치에서 작동하는 판매 시점 애플리케이션을 확인하고 모니터링합니다.
Anthos Config Management를 사용하여 Anthos 클러스터에서 실행되는 판매 시점 애플리케이션을 업데이트합니다.

시작하기 전에

Google Cloud 콘솔의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 만들거나 선택합니다.

참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

프로젝트 선택으로 이동
Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.
Google Cloud CLI를 설치하고 초기화합니다.

anthos-samples 저장소 포크 및 클론

이 튜토리얼에 사용된 모든 스크립트는 anthos-samples 저장소에 저장됩니다. /anthos-bm-edge-deployment/acm-config-sink 아래의 폴더 구조는 Anthos Config Management에 필요한 기준에 따라 구성됩니다. 다음 단계를 진행하기 전에 자체 GitHub 계정으로 이 저장소를 클론합니다.

아직 계정이 없다면 GitHub에서 계정을 만듭니다.
Anthos Config Management 구성에 사용할 개인 액세스 토큰을 만듭니다. 이 작업은 새 변경사항을 동기화하려고 시도할 때 클러스터에서 Anthos Config Management 구성요소가 GitHub 계정으로 인증되기 위해 필요합니다.
1. public_repo 범위만 선택합니다.
2. 앞에서 만든 액세스 토큰을 나중에 사용할 수 있도록 안전한 장소에 저장합니다.
anthos-samples 저장소를 고유 GitHub 계정으로 포크합니다.
1. anthos-samples 저장소로 이동합니다.
2. 페이지 오른쪽 상단 모서리에 있는 포크 아이콘을 클릭하세요.
3. 저장소를 포크할 GitHub 사용자 계정을 클릭합니다. anthos-samples 저장소의 포크된 버전이 있는 페이지로 자동으로 리디렉션됩니다.
로컬 환경에서 터미널을 엽니다.
다음 명령어를 실행하여 포크된 저장소를 클론합니다. 여기서 GITHUB_USERNAME은 GitHub 계정의 사용자 이름입니다.
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
참고: 이 솔루션의 소스 저장소와 이 저장소의 포크 모두 공개 저장소입니다. 이 문서에서는 비공개 저장소를 사용하는 실제 사용 사례와 비슷하게 액세스 토큰을 사용하는 방법을 보여줍니다.

워크스테이션 환경 설정

이 문서에 설명된 에지 배포를 완료하려면 인터넷에 액세스할 수 있고 다음 도구가 설치된 워크스테이션이 필요합니다.

Docker
envsubst 명령줄 인터페이스 도구(일반적으로 Linux 및 Unix 유사 운영체제에 사전 설치됨)

이 섹션에서 구성하는 워크스테이션에서 튜토리얼의 모든 명령어를 실행합니다.

워크스테이션의 새 셸 인스턴스에서 환경 변수를 초기화합니다.

export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

다음 값을 바꿉니다.

PROJECT_ID: Google Cloud 프로젝트 ID입니다.
GITHUB_USERNAME: GitHub 사용자 이름입니다.
ACCESS_TOKEN: GitHub 저장소에 대해 만든 개인 액세스 토큰입니다.

다른 환경 변수는 기본값을 유지합니다. 설명은 다음 섹션을 참조하세요.

워크스테이션에서 Google Cloud CLI를 초기화합니다.

gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

워크스테이션에서 Compute Engine 인스턴스에 대해 Google Cloud 서비스 계정을 만듭니다. 이 스크립트는 <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json에서 새 서비스 계정에 대해 JSON 키 파일을 만듭니다. 또한 SSH 비공개 키 암호화를 위해 Cloud Key Management Service 키링 및 키를 설정합니다.

./scripts/create-primary-gsa.sh

스크립트 일부는 다음과 같습니다. 전체 스크립트를 보려면 View on GitHub 링크를 클릭합니다.

anthos-bm-edge-deployment/scripts/create-primary-gsa.sh

GitHub에서 보기

# ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Compute Engine 인스턴스 프로비저닝

이 섹션에서는 베어메탈용 Anthos 클러스터가 설치되는 Compute Engine VM을 만듭니다. 또한 설치 섹션으로 진행하기 전 이러한 VM에 대한 연결을 확인합니다.

워크스테이션에서 Compute Engine 인스턴스 간 통신에 사용되는 SSH 키를 만듭니다.
```
ssh-keygen -f ./build-artifacts/consumer-edge-machine
```

Cloud Key Management Service를 사용하여 SSH 비공개 키를 암호화하세요.

gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

환경 구성 파일 .envrc를 생성하고 이를 소싱합니다. 생성 후 .envrc 파일에서 환경 변수가 올바른 값으로 대체되었는지 확인합니다.

envsubst < templates/envrc-template.sh > .envrc
source .envrc

다음은 templates/envrc-template.sh 파일의 환경 변수를 대체하여 생성된 .envrc 파일의 예시입니다. 업데이트된 줄이 강조 표시됩니다.

anthos-bm-edge-deployment/templates/envrc.example

GitHub에서 보기

# GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

베어메탈용 Anthos 클러스터가 설치된 Compute Engine 인스턴스를 만듭니다.

./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Ansible로 베어메탈용 Anthos 클러스터 설치

이 가이드에 사용되는 스크립트는 3개의 Compute Engine 인스턴스 그룹에 베어메탈용 Anthos 클러스터를 만듭니다. 생성되는 클러스터 수는 GCE_COUNT 환경 변수로 제어됩니다. 예를 들어 환경 변수 GCE_COUNT를 6으로 설정하여 3 VM 인스턴스가 각각 포함된 2개의 베어메탈용 Anthos 클러스터를 만듭니다. 기본적으로 GCE_COUNT 환경 변수는 3으로 설정됩니다. 따라서 이 가이드에서 3 Compute Engine 인스턴스가 있는 하나의 클러스터가 생성됩니다. VM 인스턴스 이름은 cnuc- 프리픽스와 숫자로 지정됩니다. 각 클러스터의 첫 번째 VM 인스턴스는 설치가 트리거되는 관리자 워크스테이션으로 작동합니다. 클러스터에는 또한 관리자 워크스테이션 VM과 동일한 이름이 지정됩니다(예: cnuc-1, cnuc-4, cnuc-7).

Ansible 플레이북은 다음을 수행합니다.

docker, bmctl, gcloud, nomos와 같은 필수 도구를 사용하여 Compute Engine 인스턴스를 구성합니다.
구성된 Compute Engine 인스턴스에 베어메탈용 Anthos 클러스터를 설치합니다.
cnuc-1이라는 베어메탈용 Anthos 독립형 클러스터를 만듭니다.
Google Cloud에 cnuc-1 클러스터를 등록합니다.
cnuc-1 클러스터에 Anthos Config Management를 설치합니다.
포크된 저장소에서 anthos-bm-edge-deployment/acm-config-sink에 있는 클러스터 구성과 동기화되도록 Anthos Config Management를 구성합니다.
클러스터의 Login token을 생성합니다.

다음 단계를 완료하여 설치 프로세스를 설정하고 시작합니다.

워크스테이션에서 설치에 사용되는 Docker 이미지를 만듭니다. 이 이미지는 Ansible, Python, Google Cloud CLI와 같은 설치 프로세스에 필요한 모든 도구를 포함합니다.

gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

빌드가 성공적으로 실행되면 다음과 같은 출력이 생성됩니다.

...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

템플릿에서 Ansible 인벤토리 파일을 생성합니다.

envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

이전에 빌드된 이미지에서 Docker 컨테이너를 시작하는 설치 스크립트를 실행합니다. 이 스크립트는 내부적으로 Docker를 사용하여 볼륨 마운트로 현재 작업 디렉터리에 컨테이너를 생성합니다. 이 스크립트가 성공적으로 완료되면 생성된 Docker 컨테이너 내에 있어야 합니다. 이 컨테이너 내에서 Ansible 설치를 트리거합니다.

./install.sh

스크립트가 성공적으로 실행되면 다음과 같은 출력이 생성됩니다.

...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

Docker 컨테이너 내에서 Compute Engine 인스턴스에 대해 액세스를 확인합니다.

./scripts/health-check.sh

스크립트가 성공적으로 실행되면 다음과 같은 출력이 생성됩니다.

...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

Docker 컨테이너 내에서 Compute Engine 인스턴스에 베어메탈용 Anthos 클러스터를 설치하기 위해 Ansible 플레이북을 실행합니다. 완료되면 화면에 출력된 클러스터의 Login Token이 표시됩니다.

ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

설치가 성공적으로 실행되면 다음과 같은 출력이 생성됩니다.

...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

Google Cloud 콘솔에서 베어메탈용 Anthos 클러스터에 로그인

Ansible 플레이북이 끝까지 실행된 후 Compute Engine VM 내에 독립형 베어메탈용 Anthos 클러스터가 설치됩니다. 이 클러스터는 Connect Agent를 통해 Google Cloud에 등록됩니다. 그러나 이 클러스터에 대한 세부정보를 보려면 Google Cloud 콘솔에서 클러스터에 로그인해야 합니다. Anthos 클러스터에 로그인하려면 다음 단계를 수행합니다.

이전 섹션의 Ansible 플레이북 출력에서 토큰을 복사합니다.

참고: 콘솔 출력에 더 이상 액세스할 수 없으면 ./build-artifacts/ansible-run.log에서 로그 파일을 확인하여 토큰을 가져옵니다. 또한 다음 Ansible 플레이북을 실행하여 토큰을 다시 가져올 수도 있습니다. ansible-playbook all-get-login-tokens.yaml -i inventory
Google Cloud 콘솔에서 Kubernetes 클러스터 페이지로 이동하고 복사된 토큰을 사용하여 cnuc-1 클러스터에 로그인합니다.

Kubernetes 클러스터 페이지로 이동
1. 클러스터 목록에서 cnuc-1 클러스터 옆에 있는 작업을 클릭한 후 로그인을 클릭합니다.
2. 토큰을 선택하고 복사한 토큰을 붙여넣습니다.
3. 로그인을 클릭합니다.

Google Cloud 콘솔에서 Config Management 페이지로 이동하여 구성 사양 상태를 확인합니다. 상태가 동기화됨인지 확인합니다. 동기화됨 상태는 Anthos Config Management에서 GitHub 구성이 배포된 클러스터 cnuc-1과 성공적으로 동기화되었음을 나타냅니다.

구성 관리 페이지로 이동

외부 트래픽의 프록시 구성

이전 단계에서 설치된 베어메탈용 Anthos 클러스터에는 MetalLB라는 번들 부하 분산기가 사용됩니다. 이 부하 분산기 서비스는 Virtual Private Cloud(VPC) IP 주소를 통해서만 액세스됩니다. 외부 IP를 통해 수신되는 트래픽을 번들 부하 분산기로 라우팅하려면 관리자 호스트(cnuc-1)에서 역방향 프록시 서비스를 설정합니다. 이 역방향 프록시 서비스는 관리자 호스트(cnuc-1)의 외부 IP를 통해 판매 시점 애플리케이션의 API 서버에 연결할 수 있게 해줍니다.

이전 단계의 설치 스크립트는 샘플 구성 파일과 함께 관리 호스트에 NGINX를 설치했습니다. 부하 분산기 서비스의 IP 주소를 사용하도록 이 파일을 업데이트하고 NGINX를 다시 시작합니다.

워크스테이션에서 SSH를 사용하여 관리자 워크스테이션에 로그인합니다.
```
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1
```
관리자 워크스테이션 내에서 트래픽을 API 서버 부하 분산기 서비스로 라우팅하도록 NGINX 역방향 프록시를 설정합니다. 부하 분산기 유형 Kubernetes 서비스의 IP 주소를 가져옵니다.
```
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
```

가져온 IP 주소로 템플릿 구성 파일을 업데이트합니다.

sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

NGINX를 다시 시작하여 새 구성이 적용되었는지 확인합니다.
```
sudo systemctl restart nginx
```

NGINX 서버 상태를 보고 '활성(실행 중)'이 보고되는지 확인합니다.

sudo systemctl status nginx

NGINX가 성공적으로 실행되면 다음 예시와 같은 출력이 생성됩니다.

● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

SSH 세션에서 관리자 워크스테이션으로 나갑니다.
```
exit
```
셸 세션에서 Docker 컨테이너로 나갑니다. 관리자 인스턴스를 종료한 후에도 설치에 사용된 Docker 컨테이너 내에 있습니다.
```
exit
```

판매 시점 애플리케이션 액세스

외부 프록시 설정에서는 Anthos 클러스터 내에서 실행되는 애플리케이션에 액세스할 수 있습니다. 샘플 판매 시점 애플리케이션에 액세스하기 위해 다음 단계를 완료합니다.

워크스테이션에서 관리자 Compute Engine 인스턴스의 외부 IP 주소를 가져오고 판매 시점 애플리케이션의 UI에 액세스합니다.

EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

스크립트가 성공적으로 실행되면 다음과 같은 출력이 생성됩니다.

Point the browser to: 34.134.194.84:8082

웹브라우저를 열고 이전 명령어의 출력에 표시된 IP 주소로 이동합니다. 다음 예시 스크린샷에 표시된 대로 샘플 판매 시점 애플리케이션을 액세스하고 테스트할 수 있습니다.

Anthos Config Management를 사용하여 API 서버 업데이트

샘플 애플리케이션은 루트 저장소에서 구성 파일을 업데이트하여 새 버전으로 업그레이드할 수 있습니다. Anthos Config Management가 업데이트를 감지하고 변경사항을 클러스터에 자동으로 적용합니다. 이 예시에서 루트 저장소는 이 가이드의 시작 부분에서 클론한 anthos-samples 저장소입니다. 샘플 판매 시점 애플리케이션이 새 버전으로의 업그레이드 배포를 진행하는 방식을 보기 위해 다음 단계를 수행합니다.

워크스테이션에서 image 필드를 업데이트하여 API 서버 버전을 v1에서 v2로 변경합니다. 배포를 위한 YAML 구성은 anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml의 파일에 있습니다.

anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml

GitHub에서 보기
```
containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1
```

포크된 저장소에 변경사항을 추가, 커밋 및 푸시합니다.

git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

Google Cloud 콘솔에서 Config Management 페이지로 이동하여 구성 사양 상태를 확인합니다. 상태가 동기화됨인지 확인합니다.

구성 관리 페이지로 이동

Google Cloud 콘솔에서 Kubernetes Engine 워크로드 페이지로 이동하여 배포가 업데이트되었는지 확인합니다.

Kubernetes Engine 워크로드 페이지로 이동

배포 상태가 확인이면 이전 섹션의 IP 주소로 브라우저를 연결해서 판매 시점 애플리케이션을 확인합니다. 다음 스크린샷 예시에 표시된 것처럼 제목 버전에 애플리케이션 변경사항이 배포되었음을 나타내는 'V2'가 표시됩니다.

변경사항을 확인하려면 브라우저 탭을 새로고침해야 할 수 있습니다.

삭제

불필요한 Google Cloud 요금이 부과되지 않도록 작업이 완료되었으면 이 가이드에 사용된 리소스를 삭제해야 합니다. 이러한 리소스를 수동으로 삭제하거나 Google Cloud 프로젝트를 삭제하여 모든 리소스를 삭제할 수도 있습니다. 또한 로컬 워크스테이션에서 수행한 변경사항도 삭제해야 할 수 있습니다.

로컬 워크스테이션

설치 스크립트로 수행된 변경사항을 삭제하도록 다음 파일을 업데이트해야 합니다.

/etc/hosts 파일에 추가된 Compute Engine VM IP 주소를 삭제합니다.
~/.ssh/config 파일에서 cnuc-*에 대한 SSH 구성을 삭제합니다.
~/.ssh/known_hosts 파일에서 Compute Engine VM 지문을 삭제합니다.

프로젝트 삭제

이 절차에 대해 전용 프로젝트를 만든 경우 Google Cloud 콘솔에서 Google Cloud 프로젝트를 삭제하세요.

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.

프로젝트의 모든 항목이 삭제됩니다. 이 문서의 태스크에 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.

여러 아키텍처, 튜토리얼, 빠른 시작을 살펴보려는 경우 프로젝트를 재사용하면 프로젝트 할당량 한도 초과를 방지할 수 있습니다.

Google Cloud 콘솔에서 리소스 관리 페이지로 이동합니다.

리소스 관리로 이동

프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.

대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

수동

이 절차에 기존 프로젝트를 사용한 경우 다음을 수행합니다.

이름에 cnuc- 프리픽스가 있는 모든 Kubernetes 클러스터를 등록 취소합니다.
이름에 cnuc- 프리픽스가 있는 모든 Compute Engine VM을 삭제합니다.
이름에 abm-edge-boot 프리픽스가 있는 Cloud Storage 버킷을 삭제합니다.
방화벽 규칙 allow-pod-ingress 및 allow-pod-egress를 삭제합니다.
Secret Manager 보안 비밀 install-pub-key를 삭제합니다.

다음 단계

다른 에지 위치를 추가하여 이 가이드를 확장할 수 있습니다. GCE_COUNT 환경 변수를 6으로 설정하고 이전 섹션과 동일한 단계를 다시 실행하면 3개의 새로운 Compute Engine 인스턴스(cnuc-4, cnuc-5, cnuc-6)와 cnuc-4라는 새로운 베어메탈용 Anthos 독립형 클러스터가 생성됩니다.

또한 포크된 저장소에서 클러스터 구성을 업데이트하여 ClusterSelectors를 사용해서 판매 시점 애플리케이션의 서로 다른 버전을 cnuc-1 및 cnuc-4의 두 클러스터에 선택적으로 적용할 수 있습니다.

이 가이드의 개별 단계와 관련된 스크립트에 대한 자세한 내용은 anthos-samples 저장소를 참조하세요.