Anthos clusters on bare metal 빠른 시작

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

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

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

이 빠른 시작에서는 사용자가 Kubernetes를 기본적으로 이해하고 있다고 가정합니다.

Anthos clusters on bare metal 준비

베어메탈용 Anthos 클러스터에 클러스터를 만들기 전에 다음을 수행해야 합니다.

  1. Google Cloud 프로젝트를 만듭니다.
  2. Google Cloud CLI를 설치합니다.
  3. Linux 관리자 워크스테이션을 구성합니다.
  4. bmctl 도구를 설치합니다.

Google Cloud 프로젝트 만들기

이 빠른 시작에서는 모든 Google Cloud 리소스를 구성하는 새 Google Cloud 프로젝트를 만듭니다. 베어메탈용 Anthos 클러스터에 클러스터를 만들려면 계정에 다음 역할 중 하나가 있는 Google Cloud 프로젝트가 필요합니다.

  • 편집자
  • 소유자

자세한 내용은 프로젝트 만들기 및 관리를 참조하세요.

Google Cloud CLI 설치

이 빠른 시작에서는 kubectl 및 bmctl 도구를 사용하여 클러스터를 만들고 설정합니다. 이러한 도구를 설치하려면 gcloud 및 gsutil이 필요합니다. Google Cloud CLI에는 gcloud, gsutil, kubectl 명령줄 도구가 포함되어 있습니다.

필수 도구를 설치하려면 다음 단계를 완료합니다.

  1. 관리자 워크스테이션에서 이 안내를 따라 Google Cloud CLI를 설치하고 초기화합니다. 이 프로세스는 gcloud 및 gsutil을 설치합니다.
  2. Google Cloud CLI를 업데이트합니다. 
    gcloud components update

  3. Google 계정으로 로그인하면 서비스 및 서비스 계정을 관리할 수 있습니다. 

    gcloud auth login --update-adc

    새 브라우저 탭이 열리고 계정을 선택하라는 메시지가 나타납니다.

  4. gcloud를 사용하여 kubectl을 설치합니다.

    gcloud components install kubectl

Linux 관리자 워크스테이션 구성

gcloud, gsutil, kubectl을 설치한 후에 Linux 관리자 워크스테이션을 구성합니다. Cloud Shell을 관리자 워크스테이션으로 사용하지 마세요.

  1. Docker 버전 19.03 이상을 설치합니다. Docker를 구성하는 방법을 알아보려면 Linux 배포판에 해당하는 페이지로 이동합니다.
  2. root 액세스를 사용하려면 관리자 워크스테이션과 원격 클러스터 노드 머신 모두에 SSH를 설정합니다. 처음에는 관리 워크스테이션의 키를 공유하려면 원격 클러스터 노드 머신에서 root SSH 비밀번호 인증을 사용 설정해야 합니다. 키가 있으면 SSH 비밀번호 인증을 중지할 수 있습니다.

  3. 관리자 워크스테이션에서 비공개/공개 키 쌍을 생성합니다. 키에 암호를 설정하지 마세요. 관리자 워크스테이션과 클러스터 노드 머신 간에 안전하고 비밀번호 없는 연결을 위해 SSH를 사용하려면 키가 필요합니다. 다음 명령어를 사용하여 키를 생성합니다.

    ssh-keygen -t rsa

    또한 클러스터 노드 머신에 대한 SUDO 사용자 액세스를 사용하여 SSH를 설정할 수 있습니다. 하지만 패스워드가 없는 비루트 사용자 연결의 경우 적절한 사용자 인증 정보로 클러스터 구성 파일을 업데이트해야 합니다. 자세한 내용은 샘플 클러스터 구성 파일의 #Node access configuration 섹션을 참고하세요.

  4. 생성된 공개 키를 클러스터 노드 머신에 추가합니다. 기본적으로 공개 키는 id_rsa.pub ID 파일에 저장됩니다. 
    ssh-copy-id -i ~/.ssh/IDENTITY_FILE root@CLUSTER_NODE_IP
  5. 클러스터 노드 머신에서 SSH 비밀번호 인증을 사용 중지합니다. 관리 워크스테이션에서 다음 명령어를 사용하여 공개 키 인증이 관리 워크스테이션과 클러스터 노드 머신 간에 작동하는지 확인합니다.
    ssh -o IdentitiesOnly=yes -i IDENTITY_FILE root@CLUSTER_NODE_IP

bmctl 도구 다운로드 및 설치

bmctl 명령줄 도구를 사용하여 베어메탈용 Anthos 클러스터에서 클러스터를 만듭니다. bmctl 명령어는 자동으로 Google 서비스 계정을 설정하고 지정된 프로젝트에서 베어메탈용 Anthos 클러스터를 사용하는 데 필요한 API를 사용 설정합니다.

대신 자체 서비스 계정을 만들거나 다른 수동 프로젝트 설정을 직접 수행하려면 bmctl로 클러스터를 만들기 전에 Google 서비스 및 서비스 계정 사용 설정을 참조하세요.

bmctl 도구를 다운로드하여 설치하려면 다음 안내를 따르세요.

  1. bmctl에 대한 새 디렉터리를 만듭니다.
    cd ~
mkdir baremetal
cd baremetal
  2. Cloud Storage 버킷에서 bmctl을 다운로드합니다.
    gsutil cp gs://anthos-baremetal-release/bmctl/1.7.1/linux-amd64/bmctl bmctl
chmod a+x bmctl
  3. 도움말 정보를 확인하여 bmctl가 올바르게 설치되었는지 확인합니다.
    ./bmctl -h

클러스터 노드 만들기

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

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

클러스터 노드의 요구 사항에 대해 자세히 알아보려면 하드웨어 및 운영체제 요구 사항(Centos, RHEL 및 Ubuntu)으로 이동합니다.

클러스터 만들기

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

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

구성 파일 만들기

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

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

CLUSTER_NAME은 클러스터 이름입니다. PROJECT_ID은 Google Cloud 프로젝트 만들기에서 만든 프로젝트입니다.

위 명령어는 다음 경로의 baremetal 디렉터리에 구성 파일을 만듭니다.
bmctl-workspace/cluster1/cluster1.yaml

구성 파일 수정

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

  1. 편집기에서 bmctl-workspace/cluster1/cluster1.yaml 구성 파일을 엽니다.
  2. 특정 노드 및 네트워크 요구사항에 따라 파일을 수정합니다. 다음 샘플 구성 파일을 사용합니다. 이 빠른 시작은 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.7.1
  # 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 virtual IPs 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 load balancer 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 virtual IP (VIP) addresses: 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.
    # These IP addresses do not correspond to physical network interfaces.
    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
  # NodeConfig specifies the configuration that applies to all nodes in the cluster.
  nodeConfig:
    # podDensity specifies the pod density configuration.
    podDensity:
      # maxPodsPerNode specifies the maximum number of pods allowed on a single node.
      maxPodsPerNode: 250
    # containerRuntime specifies which container runtime to use for scheduling containers on nodes.
    # containerd and docker are supported.
    containerRuntime: containerd

---
# 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_1_IP
  - address: WORKER_NODE_2_IP

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

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

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

  1. 현재 위치가 baremetal 디렉터리인지 확인합니다.
  2. 다음 명령어를 사용하여 클러스터를 만듭니다.
    3. ./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는 활성화되지 않습니다.
  • Google Container Registry에 연결할 수 있습니다.
  • VIP를 사용할 수 있습니다.
  • 클러스터 머신은 서로 연결성을 가지고 있습니다.
  • 부하 분산기 머신은 동일한 Layer 2 서브넷에 있습니다.

클러스터를 만드는 데 몇 분 정도 걸릴 수 있습니다.

클러스터 정보 가져오기

클러스터가 성공적으로 생성되면 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 플래그는 기존 클러스터를 통해 설치되지만 이미 할당된 서버 포트로 인해 실패한 실행 전 검사의 결과는 무시합니다.

  1. 현재 위치가 baremetal 디렉터리인지 확인합니다.
  2. 다음 명령어를 --force 플래그와 함께 사용하여 클러스터를 다시 만듭니다.
    3. ./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

출력은 배포에 사용 가능하고 준비된 포드가 3개 있음을 보여줍니다. 

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 클러스터 서비스에 외부 IP 주소를 제공합니다. 외부 IP 주소를 사용하여 서비스를 호출합니다. 

curl 172.16.1.21

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

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

고가용성 제어 영역 만들기

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

예를 들어 구성 파일을 수정하여 제어 영역에 2개의 노드를 추가합니다.

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>