베어메탈용 GKE 빠른 시작

베어메탈용 GKE 소개

베어메탈용 GKE를 사용하면 다음 네 가지 유형의 클러스터를 정의할 수 있습니다.

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

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

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

베어메탈용 GKE 준비

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

  1. Google Cloud 프로젝트를 만듭니다.
  2. 관리자 워크스테이션을 구성합니다.

Google Cloud 프로젝트 만들기

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

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

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

이 빠른 시작에서는 bmctl 및 kubectl을 사용하여 클러스터를 만들고 사용합니다. 이 명령줄 도구는 Linux 관리자 워크스테이션에서 실행됩니다. 관리자 워크스테이션 설정은 관리자 워크스테이션 기본 요건을 참조하세요.

클러스터 노드 만들기

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

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

클러스터 노드의 요구사항에 대해 자세히 알아보려면 클러스터 노드 머신 기본 요건으로 이동하세요.

클러스터 만들기

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

  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 프로젝트 만들기에서 만든 프로젝트입니다.

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

구성 파일 수정

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

  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
---
# Cluster configuration. Note that some of these fields are immutable once the cluster is created.
# For more info, see https://cloud.google.com/anthos/clusters/docs/bare-metal/1.14/reference/cluster-config-ref#cluster_configuration_fields
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.14.11
  # 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:
      - 10.96.0.0/20
  # 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

---
# 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 로그에 기록합니다.

다음 디렉터리 baremetal/bmctl-workspace/CLUSTER_NAME/log에서 bmctl, 실행 전 검사 및 노드 설치 로그를 찾을 수 있습니다.

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

  • Linux 배포판 및 버전이 지원됩니다.
  • SELinux는 '시행' 모드가 아닙니다.
  • Ubuntu에서 Unflicated Firewall(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

베어메탈용 GKE는 서비스에 외부 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>