버전 1.6. 이 버전은 더 이상 지원되지 않습니다. 자세한 내용은 버전 지원 정책을 참조하세요. 버전 1.7로 업그레이드하는 방법에 대한 자세한 내용은 1.7 문서의 베어메탈용 Anthos 업그레이드를 참조하세요.

사용 가능한 지원되는 버전: 1.14 | 1.13 | 1.12

베어메탈용 Anthos 클러스터 빠른 시작

Anthos clusters on bare metal 소개

Anthos clusters on bare metal 빠른 시작 범위

Anthos clusters on bare metal을 사용하면 다음 네 가지 유형의 클러스터를 정의할 수 있습니다.

관리자 - 사용자 클러스터를 관리하는 데 사용되는 클러스터입니다.
사용자 - 워크로드를 실행하는 데 사용되는 클러스터입니다.
독립형 - 사용자가 직접 관리할 수 있으며 워크로드를 실행할 수 있지만 다른 사용자 클러스터를 만들거나 관리할 수 없는 단일 클러스터입니다.
하이브리드 - 사용자 클러스터도 관리할 수 있는 관리자와 워크로드에 대한 단일 클러스터입니다.

이 빠른 시작에서는 베어메탈용 Anthos 클러스터를 사용하여 2노드 하이브리드 클러스터를 배포합니다. 클러스터를 만드는 방법과 클러스터 생성 프로세스를 모니터링하는 방법을 알아봅니다.

이 빠른 시작에서는 대상 독자가 Kubernetes에 대한 기본적인 지식이 있다고 가정합니다.

Anthos clusters on bare metal 준비

Anthos clusters on bare metal의 설치 명령어인 bmctl은 클러스터 생성을 간소화하도록 설계되었습니다. 이 명령어를 실행하면 Anthos clusters on bare metal에 필요한 Google 서비스 계정과 API가 자동으로 설정되고 이 빠른 시작에서 자동화된 서비스를 사용합니다.

이렇게 하려면 bmctl을 사용하여 클러스터를 만들기 전에 필요한 서비스와 API를 수동으로 설정할 수도 있습니다. 이 문서 후반부에서 사용해야 하는 명령어 변경 내용을 확인할 수 있습니다. 하지만 필요한 Google 서비스를 수동으로 설정하려면 Google 서비스 및 서비스 계정 사용 설정을 참조하세요.

Anthos clusters on bare metal에서 클러스터를 만들려면 먼저 다음을 확인합니다.

편집자 또는 소유자 역할이 있는 Google Cloud 프로젝트를 만듭니다.
다음 설명대로 bmctl 명령줄 도구를 다운로드하여 설치합니다.
bmctl을 실행할 수 있도록 Linux 관리 워크스테이션을 구성합니다. 참고: Cloud Shell을 관리 워크스테이션으로 사용하지 마세요.
1. 아래 설명에 따라 gcloud, gsutil, kubectl을 설치합니다.
2. Docker 버전 19.03 이상을 설치합니다. (Docker 구성에 대한 자세한 내용은 Linux OS 구성 페이지인 CentOS 구성, RHEL 구성 또는 Ubuntu 구성을 참조하세요.)
3. root 액세스를 사용하여 관리 워크스테이션과 원격 클러스터 노드 머신 모두에 SSH를 설정합니다. 처음에는 관리 워크스테이션의 키를 공유하려면 원격 클러스터 노드 머신에서 root SSH 비밀번호 인증을 사용 설정해야 합니다. 키가 있으면 SSH 비밀번호 인증을 중지할 수 있습니다.
4. 관리 워크스테이션에서 비공개/공개 키 쌍을 생성합니다(키의 암호를 설정하지 마세요). 관리 워크스테이션과 클러스터 노드 머신 사이의 비밀번호가 없는 안전한 연결에 SSH를 사용하려면 키가 필요합니다.
```
ssh-keygen -t rsa
```
  또한 클러스터 노드 머신에 대한 SUDO 사용자 액세스를 사용하여 SSH를 설정할 수 있습니다. 하지만 패스워드가 없는 비루트 사용자 연결의 경우 적절한 사용자 인증 정보로 cluster config YAML 파일을 업데이트해야 합니다. 자세한 내용은 샘플 클러스터 구성 파일의 #Node access configuration 섹션을 참조하세요.
5. 생성된 공개 키를 클러스터 노드 머신에 추가합니다. 기본적으로 공개 키는 id_rsa.pub ID 파일에 저장됩니다.
```
ssh-copy-id -i ~/.ssh/identity_file root@cluster_node_ip
```
6. 클러스터 노드 머신에서 SSH 비밀번호 인증을 사용 중지하고 관리 워크스테이션에서 다음 명령어를 사용하여 공개 키 인증이 관리 워크스테이션과 클러스터 노드 머신 간에 작동하는지 확인합니다.
```
ssh -o IdentitiesOnly=yes -i identity_file root@cluster_node_ip
```

gcloud 유틸리티 설치

gcloud, gsutil, kubectl 도구는 gcloud CLI에 포함되어 있습니다.

관리 머신에서 여기의 안내에 따라 gcloud CLI를 설치하고 초기화합니다. 이 프로세스는 gcloud 및 gsutil을 설치합니다.
gcloud CLI 업데이트
```
gcloud components update
```
Google 계정으로 로그인하면 서비스 및 서비스 계정을 관리할 수 있습니다.
```
gcloud auth login --update-adc
```
새 브라우저 탭이 열리고 계정을 선택하라는 메시지가 나타납니다.

이 시점에서 Google Cloud 기본 프로젝트를 설정하고 Anthos clusters on bare metal 클러스터를 만들기 전에 다른 서비스 및 Google API를 사용 설정할 수 있습니다. 기본 프로젝트를 설정하면 서비스를 수동으로 사용 설정할 때 시간을 절약할 수 있습니다.

그러나 이 빠른 시작에 설명한 대로 클러스터를 만들 때 bmctl 명령어를 사용하여 직접 프로젝트를 지정하고 Google 서비스를 설정할 수 있습니다. 이렇게 하면 bmctl은 항상 명령어를 실행할 때 지정한 프로젝트 ID를 사용합니다.
gcloud을 사용하여 kubectl을 설치합니다.
```
gcloud components install kubectl
```

bmctl 설치

Anthos clusters on bare metal에서 클러스터를 만들기 위한 명령줄 도구는 bmctl입니다. Cloud Storage 버킷에서 bmctl을 다운로드합니다.

bmctl을 다운로드하려면 다음을 실행하세요.

bmctl에 대한 새 디렉터리를 만듭니다.
```
cd ~
mkdir baremetal
cd baremetal
```

Cloud Storage 버킷에서 bmctl을 다운로드합니다.

gsutil cp gs://anthos-baremetal-release/bmctl/1.6.2/linux-amd64/bmctl bmctl
chmod a+x bmctl

도움말 정보를 확인하여 bmctl가 올바르게 설치되었는지 확인합니다.
```
./bmctl -h
```

클러스터 노드 만들기

클러스터의 노드로 사용될 두 머신을 만듭니다.

머신 한 개는 제어 영역 노드로 작동합니다.
머신 한 개는 작업자 노드로 작동합니다.

관리 워크스테이션이 이러한 노드에 ssh할 수 있어야 하고 제어 영역 VIP에 액세스할 수 있어야 합니다.

클러스터 노드에 필요한 사항에 대한 자세한 내용은 하드웨어 및 운영체제 요구사항(Centos, RHEL, Ubuntu)을 참조하세요.

클러스터 만들기

클러스터를 만들려면 다음 안내를 따르세요.

bmctl를 사용하여 구성 파일을 만듭니다.
구성 파일을 수정하여 클러스터 및 네트워크에 맞게 사용자 설정 하세요.
bmctl을 사용하여 구성 파일에서 클러스터를 만듭니다.

구성 파일 만들기

구성 파일을 만들고 서비스 계정과 API를 자동으로 사용 설정하려면 baremetal 디렉터리에 있는지 확인하고 다음 플래그를 사용하여 bmctl 명령어를 실행합니다.

./bmctl create config -c CLUSTER_NAME \
  --enable-apis --create-service-accounts --project-id=PROJECT_ID

CLUSTER_NAME은 클러스터 이름이고 PROJECT_ID는 소유자 또는 편집자 역할이 있는 Google 프로젝트입니다.

이 명령어는 bmctl-workspace/cluster1/cluster1.yaml에 있는 baremetal 디렉터리에 구성 파일을 만듭니다.

구성 파일 수정

구성 파일을 수정하려면 다음 안내를 따르세요.

편집기에서 bmctl-workspace/cluster1/cluster1.yaml 구성 파일을 엽니다.
특정 노드 및 네트워크 요구사항을 위한 파일을 수정합니다. 아래의 샘플 구성 파일을 참조하세요. 이 빠른 시작에서는 OpenID Connect(OIDC)를 생략했습니다.

# gcrKeyPath:  < to GCR service account key>
gcrKeyPath: baremetal/gcr.json
# sshPrivateKeyPath:  < to SSH private key, used for node access>
sshPrivateKeyPath: .ssh/id_rsa
# gkeConnectAgentServiceAccountKeyPath:  < to Connect agent service account key>
gkeConnectAgentServiceAccountKeyPath: baremetal/connect-agent.json
# gkeConnectRegisterServiceAccountKeyPath:  < to Hub registration service account key>
gkeConnectRegisterServiceAccountKeyPath: baremetal/connect-register.json
# cloudOperationsServiceAccountKeyPath:  < to Cloud Operations service account key>
cloudOperationsServiceAccountKeyPath: baremetal/cloud-ops.json
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-cluster1
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
  namespace: cluster-cluster1
spec:
  # Cluster type. This can be:
  #   1) admin:  to create an admin cluster. This can later be used to create user clusters.
  #   2) user:   to create a user cluster. Requires an existing admin cluster.
  #   3) hybrid: to create a hybrid cluster that runs admin cluster components and user workloads.
  #   4) standalone: to create a cluster that manages itself, runs user workloads, but does not manage other clusters.
  type: hybrid
  # Anthos cluster version.
  anthosBareMetalVersion: 1.6.2
  # GKE connect configuration
  gkeConnect:
    projectID: PROJECT_ID
  # Control plane configuration
  controlPlane:
    nodePoolSpec:
      nodes:
      # Control plane node pools. Typically, this is either a single machine
      # or 3 machines if using a high availability deployment.
      - address:  CONTROL_PLANE_NODE_IP
  # Cluster networking configuration
  clusterNetwork:
    # Pods specify the IP ranges from which Pod networks are allocated.
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    # Services specify the network ranges from which service VIPs are allocated.
    # This can be any RFC 1918 range that does not conflict with any other IP range
    # in the cluster and node pool resources.
    services:
      cidrBlocks:
      - 172.26.232.0/24
  # Load balancer configuration
  loadBalancer:
    # Load balancer mode can be either 'bundled' or 'manual'.
    # In 'bundled' mode a load balancer will be installed on load balancer nodes during cluster creation.
    # In 'manual' mode the cluster relies on a manually-configured external load balancer.
    mode: bundled
    # Load balancer port configuration
    ports:
      # Specifies the port the LB serves the kubernetes control plane on.
      # In 'manual' mode the external load balancer must be listening on this port.
      controlPlaneLBPort: 443
    # There are two load balancer VIPs: one for the control plane and one for the L7 Ingress
    # service. The VIPs must be in the same subnet as the load balancer nodes.
    vips:
      # ControlPlaneVIP specifies the VIP to connect to the Kubernetes API server.
      # This address must not be in the address pools below.
      controlPlaneVIP: CONTROL_PLANE_VIP
      # IngressVIP specifies the VIP shared by all services for ingress traffic.
      # Allowed only in non-admin clusters.
      # This address must be in the address pools below.
      ingressVIP: INGRESS_VIP
    # AddressPools is a list of non-overlapping IP ranges for the data plane load balancer.
    # All addresses must be in the same subnet as the load balancer nodes.
    # Address pool configuration is only valid for 'bundled' LB mode in non-admin clusters.
    # addressPools:
    # - name: pool1
    #   addresses:
    #   # Each address must be either in the CIDR form (1.2.3.0/24)
    #   # or range form (1.2.3.1-1.2.3.5).
    #   - LOAD_BALANCER_ADDRESS_POOL-
    # A load balancer nodepool can be configured to specify nodes used for load balancing.
    # These nodes are part of the kubernetes cluster and run regular workloads as well as load balancers.
    # If the node pool config is absent then the control plane nodes are used.
    # Node pool configuration is only valid for 'bundled' LB mode.
    # nodePoolSpec:
    #   nodes:
    #   - address: LOAD_BALANCER_NODE_IP;
  # Proxy configuration
  # proxy:
  #   url: http://[username:password@]domain
  #   # A list of IPs, hostnames or domains that should not be proxied.
  #   noProxy:
  #   - 127.0.0.1
  #   - localhost
  # Logging and Monitoring
  clusterOperations:
    # Cloud project for logs and metrics.
    projectID: PROJECT_ID
    # Cloud location for logs and metrics.
    location: us-central1
    # Whether collection of application logs/metrics should be enabled (in addition to
    # collection of system logs/metrics which correspond to system components such as
    # Kubernetes control plane or cluster management agents).
    # enableApplication: false
  # Storage configuration
  storage:
    # lvpNodeMounts specifies the config for local PersistentVolumes backed by mounted disks.
    # These disks need to be formatted and mounted by the user, which can be done before or after
    # cluster creation.
    lvpNodeMounts:
      # path specifies the host machine path where mounted disks will be discovered and a local PV
      # will be created for each mount.
      path: /mnt/localpv-disk
      # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
      # is created during cluster creation.
      storageClassName: local-disks
    # lvpShare specifies the config for local PersistentVolumes backed by subdirectories in a shared filesystem.
    # These subdirectories are automatically created during cluster creation.
    lvpShare:
      # path specifies the host machine path where subdirectories will be created on each host. A local PV
      # will be created for each subdirectory.
      path: /mnt/localpv-share
      # storageClassName specifies the StorageClass that PVs will be created with. The StorageClass
      # is created during cluster creation.
      storageClassName: local-shared
      # numPVUnderSharedPath specifies the number of subdirectories to create under path.
      numPVUnderSharedPath: 5
---
# Node pools for worker nodes
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-cluster1
spec:
  clusterName: cluster1
  nodes:
  - address: WORKER_NODE_IP

실행 전 확인 실행하기 및 클러스터 만들기

bmctl 명령어는 클러스터를 만들기 전에 클러스터 구성 파일에서 실행 전 검사를 실행합니다. 성공하면 클러스터가 생성됩니다.

실행 전 확인을 실행하고 클러스터를 만들려면 다음 안내를 따르세요.

현재 위치가 baremetal 디렉터리인지 확인합니다.
다음 명령어를 사용하여 클러스터를 만듭니다.

./bmctl create cluster -c CLUSTER_NAME

./bmctl create cluster -c cluster1

bmctl 명령어는 실행 전 확인과 클러스터 생성을 모니터링한 후 출력을 화면에 표시하고 자세한 정보를 bmctl 로그에 기록합니다.

실행 전 검사 및 노드 설치 로그뿐 아니라 bmctl 로그도 baremetal/bmctl-workspace/CLUSTER_NAME/log 디렉터리에 있습니다.

bmctl 실행 전 검사는 제안된 클러스터 설치를 다음과 같은 조건으로 확인합니다.

Linux 배포판 및 버전이 지원됩니다.
SELinux는 '시행' 모드가 아닙니다.
Ubuntu의 경우 AppArmor와 UFW는 활성화되지 않습니다.
CentOS/RHEL의 경우 방화벽이 활성화되지 않습니다.
Google Container Registry에 연결할 수 있습니다.
VIP를 사용할 수 있습니다.
클러스터 머신은 서로 연결성을 가지고 있습니다.
부하 분산기 머신이 동일한 L2 서브넷에 있습니다.

클러스터 생성을 완료하는 데 몇 분 정도 걸릴 수 있습니다.

클러스터 정보 가져오기

클러스터가 성공적으로 생성되면 kubectl 명령어는 새 클러스터에 대한 정보를 표시합니다. 클러스터 생성 중에 bmctl 명령어는 kubectl로 쿼리하는 클러스터의 kubeconfig 파일을 작성합니다. kubeconfig 파일은 bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig에 기록됩니다.

예를 들면 다음과 같습니다.

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get nodes

이 명령어는 다음을 반환합니다.

NAME      STATUS   ROLES    AGE   VERSION
node-01   Ready    master   16h   v1.17.8-gke.16
node-02   Ready    <none>   16h   v1.17.8-gke.16

클러스터 생성이 실행 전 검사에서 실패하면 실행 전 검사 로그에 오류가 있는지 확인하고 클러스터 구성 파일에서 오류를 수정합니다. 실행 전 검사 로그는 /log 디렉터리에 있습니다.

~/baremetal/bmctl-workspace/CLUSTER_NAME/log

클러스터의 각 머신에 대한 실행 전 검사 로그는 CLUSTER_NAME 디렉터리에 있으며 IP 주소로 구성됩니다. 예를 들면 다음과 같습니다.

bmctl-workspace/cluster1/log
└── preflight-20201007-034844
    ├── 172.17.0.3
    ├── 172.17.0.4
    ├── 172.17.0.5
    ├── 172.17.0.6
    ├── 172.17.0.7
    └── node-network

실행 전 검사 오류 무시

실행 전 확인 후 클러스터 생성이 실패하면 bmctl 명령어에서 --force 플래그를 사용하여 클러스터를 다시 설치할 수 있습니다.

--force 플래그는 기존 클러스터을 통해 설치되지만 이미 할당된 서버 포트로 인해 실행 전 검사 실패의 결과는 무시합니다.

현재 위치가 baremetal 디렉터리인지 확인합니다.
다음 명령어를 --force 플래그와 함께 사용하여 클러스터를 다시 만듭니다.

./bmctl create cluster -c CLUSTER_NAME --force

./bmctl create cluster -c cluster1 --force

배포 및 서비스 만들기

배포의 매니페스트는 다음과 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      app: metrics
      department: sales
  replicas: 3
  template:
    metadata:
      labels:
        app: metrics
        department: sales
    spec:
      containers:
      - name: hello
        image: "gcr.io/google-samples/hello-app:2.0"

매니페스트를 my-deployment.yaml로 저장하고 배포를 만듭니다.

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-deployment.yaml

배포를 확인합니다.

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get deployments

출력은 배포에 세 개의 실행 중인 Pod가 있음을 보여줍니다.

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
my-deployment      3/3     3            3           16s

유형 LoadBalancer 서비스의 매니페스트는 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: metrics
    department: sales
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080

매니페스트를 my-service.yaml로 저장하고 서비스를 만듭니다.

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig create -f my-service.yaml

서비스를 확인합니다.

kubectl --kubeconfig bmctl-workspace/cluster1/cluster1-kubeconfig get service my-service

출력:

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S
my-service   LoadBalancer   172.26.232.2   172.16.1.21   80:30060/TCP

Anthos clusters on bare metal이 서비스에 외부 IP 주소를 제공했음을 확인합니다. 외부 IP 주소를 사용하여 서비스를 호출합니다.

curl 172.16.1.21

출력은 다음과 같은 hello world 메시지입니다.

Hello, world!
Version: 2.0.0
Hostname: my-deployment-75d45b64f9-6clxj

고가용성 제어 영역 만들기

이 빠른 시작에서는 단순한 2-노드 하이브리드 클러스터를 만듭니다. 고가용성 제어 영역을 만들려면 제어 영역 노드가 3개인 클러스터를 만듭니다.

예를 들어 위에 표시된 구성 파일을 수정하여 제어 영역에 노드를 추가합니다.

controlPlane:
  nodePoolSpec:
    clusterName: cluster1
    nodes:
    # Control Plane node pools. Typically, this is either a single machine
    # or 3 machines if using a high availability deployment.
    - address: <Machine 1 IP>
    - address: <Machine 2 IP>
    - address: <Machine 3 IP>

자체 노드 풀에서 부하 분산기 실행

이 빠른 시작에서는 단순한 2-노드 하이브리드 클러스터를 만듭니다. 부하 분산기는 제어 영역을 실행하는 동일한 노드에서 실행됩니다.

부하 분산기를 자체 노드 풀에서 실행하려면 구성 파일의 loadBalancer 섹션에 있는 nodePoolSpec 값을 수정합니다.

  loadBalancer:
    nodePoolSpec:
      clusterName: "cluster1"
      nodes:
      - address: <LB Machine 1 IP>
      - address: <LB Machine 2 IP>