簡単構築！NUC でおうち Anthos を動かしてみよう

Kazuki Uchima

Published in

google-cloud-jp

27 min readMay 13, 2021

（2021.07.03 追記: Anhtos 料金情報をアップデートしました）

皆さんこんにちは。Google Cloud の内間です。Stay Home が叫ばれるなか、Home Lab 欲が高まってきていませんか？

今回は Intel NUC を使った Anthos clusters on Bare Metal の構築手順を記事としてまとめてみました。意外と簡単に構築できるので良ければみなさんも試してみてください。

Anthos clusters on Bare Metal とは

まずはじめに簡単に Anthos clusters on Bare Metal の紹介をします。

Anthos clusters on Bare Metal とは、ベアメタルや OpenStack といった環境上で動作する Anthos clusters のことです。元々あった Anthos clusters on VMware (旧 GKE on-prem) は VMware vSphere 上でしか動かなかったのですが、Anthos clusters on Bare Metal はより柔軟に構成することができるようになっています。

また、Anthos clusters on VMware と比べて少ないリソースで構成が可能なのも特徴の 1 つです。

Anthos clusters on Bare Metal は以下コンポーネントで構成されています。

Admin Cluster: 各 User Cluster のライフサイクルを管理するクラスタ
User Cluster: ワークロードが稼働するクラスタ
Workstation: Anthos clusters on Bare Metal の管理端末
Bundled LB: 組み込みの L4 ロードバランサ (L7 ロードバランシングはクラスタ内にデプロイされた Ingress Gateway (Envoy) で行う)

デプロイメントオプション

Anthos clusters on Bare Metal のデプロイメントモデルは以下の 2 通りあります。今回は簡単な検証用途なので Standalone Cluster Model を採用し、シングルクラスタを構成していきます。

Standalone Cluster Model

Admin Cluster と User Cluster が同居しているモデルです。後述のMulti Cluster Model と比べて必要となる HW リソースが少なく、複数クラスタの運用が必要ないような小規模環境やエッジでのユースケースなどで利用します。

Multi Cluster Model

Admin Cluster と User Cluster が分かれているモデルです。管理クラスタが存在するため Standalone Cluster に比べて必要な HW リソースは多くなりますが、複数クラスタを集中管理することが可能となります。複数クラスタの運用が必要となる中〜大規模環境などで利用します。

また、今回は Workstation と呼ばれる bmctl* / kubectl が導入されたマシンと、Control Plane Node を同居させる形で構築を進めていきます。

※bmctl … Anthos clusters on Bare Metal 用の管理ツール

前提条件

ここから構築手順の説明に入っていきます。

まず、前提条件です。ここでは各種要件のサマリを記載します（詳細は以下の公式ドキュメントをご確認ください）。

Installation prerequisites overview | Anthos on bare metal | Google Cloud

Anthos clusters on bare metal has the following sets of installation prerequisites: If you use the workstation machine…

cloud.google.com

Google Cloud

Anthos クラスタを登録するための Google Cloud プロジェクトが作成されていること

クラスタノード

Anthos clusters on Bare Metal では 2021.12 現在 Linux ノードマシンのみサポートしています。サポートしているディストリビューションは以下の通りです：

Ubuntu: 18.04/20.04 LTS
CentOS: 8.1/8.2/8.3/8.4
RHEL: 8.1/8.2/8.3/8.4

本記事では Ubuntu 20.04 LTS を利用します。

また、Anthos clusters on Bare Metal のノード 1 台あたりのハードウェアリソースの要件は以下の通りです。クラスタの最低台数は 2 台なので、比較的少ないリソースで構成可能ですね。

今回の検証環境では以下のハードウェアリソース上に Anthos クラスタをデプロイします：

CPU: 4 core (8 thread) × 2 台 = 8 core (16 thread)
RAM: 32 GB × 2 台 = 64 GB
Storage: 500 GB × 2 台 = 1000 GB

ネットワーク

各ノードから Google Container Registry へ到達可能であること
ノード間で L3 接続性があること
ロードバランサノード間で L2 接続性があること
Workstation からインターネットアクセスが可能であること(環境構築時の Cloud Storage バケットへのアクセス / パッケージインストール用途)

利用料金

実機で試す前に確認しておきたいのが料金体系ですね。Anthos では従量課金 (Pay-as-you-go) とサブスクリプションの 2 種類の料金モデルが存在します。

従量課金 (Pay-as-you-go) は利用した分のみの課金となるため、一時的な検証などで利用する場合はこちらの方が適していると思います。ただし時間単位の料金で比較するとサブスクリプションの方がお安くご利用可能ですので、長期的にご利用される場合はサブスクリプションもご検討ください。詳しくは以下公式ドキュメントをご参照ください：

公式ドキュメント：料金

Anthos はクラスタ内 Worker Node の vCPU/Core 数に対して課金されます(Control Plane Node の vCPU/Core 数に対しては課金されません)。今回はベアメタル環境なので、従量課金だと 1 時間あたり $0.03288/vCPU が課金されます。

今回だと Worker Node 1 台 (物理 4 core) で HT を有効化しているので計 8 vCPU 分の課金が発生しますので、丸 1 日 (24 時間) 動かし続けると日本円で約 700 円ほどの費用となります (2021.07 現在)。ちなみに HT を無効化するとこれの半分程度の費用になります。

従量課金 (Pay-as-you-go) では、Anthos クラスタとして登録された Worker Node の vCPU 分の課金が発生しますので、検証が終わった後は必要に応じてノード数を削減したり、 Anthos クラスタのリセットを行い Anthos コンポーネントを削除するなどして不要な課金が発生しないようお気をつけください。(なんらかの理由でクラスタのリセットができない場合は、クラスタを手動で Unregister したり、Anthos API を無効化するという手もあります）

クラスタノードの準備

NUC のセットアップ

ノードとして Intel NUC を利用します。参考までに、今回の環境用に購入した機器は以下の通りです。

今回はノード 2 台 (Control Plane 兼 Workstation × 1, Worker Node × 1) の構成とするので、以下の機器を 2 セット分購入しました。

また、下記機器もセットアップ時に必要になったので、お持ちでない方は購入しておいた方が良いです。

有線接続のキーボード
ディスプレイ
ディスプレイ接続用 HDMI ケーブル
USB メモリ (OS インストール用途)

NUC のセットアップはかなり簡単で、基本的には説明書通りにメモリと SSD を入れるだけです。まず、NUC の裏蓋を開けます。

画像左側に M.2 SSD を取り付けます。

画像右側にある 2 つのスロットにメモリを入れます。

SSD とメモリが入ったら裏蓋を閉めて完成です。

OS のインストール

Ubuntu 20.04 LTS の USB インストールメディアを作っておきます。NUC に電源コード、キーボード、ディスプレイ、上記 USB メモリを接続し、電源 ON します。

OS のインストール手順の詳細は割愛します (下記 Ubuntu Server Install 手順等をご参照ください)。今回の環境では、Static な IP アドレスを設定し OpenSSH server をインストールする以外は全てデフォルト設定を利用しました。

Install Ubuntu Server

また、各 Node のホスト名は任意のものを設定してもらって問題ありません。本記事では以下の 2 つ Node を使ってクラスタを構築していきます。各 Node の名前と役割は以下の通りです：

node01 … Workstation 兼 Control Plane Node
node02 … Worker Node

OS セキュリティ設定

公式ドキュメントを参照し、Anthos clusters on Bare Metal の要件に合うように各種セキュリティ機能を設定します。各 Node 上で以下コマンドを実行し AppArmor と ufw を無効化します。

(2021.12.18 更新: 最新バージョンでは AppArmor の無効化は不要です)

# パッケージの状態確認
sudo apt-get check
 
# 想定される出力結果
# Reading package lists... Done
# Building dependency tree       
# Reading state information... Done
 
# AppArmor の無効化
sudo systemctl stop apparmor
sudo systemctl disable apparmor
 
# AppArmor ステータス確認
sudo systemctl status apparmor | grep "Active"
 
# 想定される出力結果
# Active: inactive (dead) since Sat 2021-01-16 19:04:18 UTC; 15s ago
 
# ufw の無効化 
sudo ufw disable
 
# ufw ステータス確認 
sudo ufw status
 
# 想定される出力結果
# Status: inactive

SSH 設定

各 Node 上で以下コマンドを実行し、Node に root で SSH できるよう構成します。

# root に対するパスワードを設定
sudo passwd root
 
# root ログインの許可
sudo sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config
sudo systemctl status sshd

node01 にログインし、キーペアの生成＆公開鍵の配布をします。

# キーペアの生成
ssh-keygen -t rsa
 
# 生成した公開鍵を各 Node に配布
ssh-copy-id -i ~/.ssh/id_rsa_nuc.pub root@<node01 IP Address>
ssh-copy-id -i ~/.ssh/id_rsa_nuc.pub root@<node02 IP Address>

Workstation の構成

各種ツールのインストール

node01 に gcloud, kubectl, bmctl, Docker をインストールします

gcloud でログインするアカウントには、対象プロジェクトに対する Owner or Editor 権限が付与されていることを事前に確認してください。

Google Cloud SDK のインストール:

# パッケージソースとして Cloud SDK distribution URI を追加
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
 
# Google Cloud public key のインポート
curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key --keyring /usr/share/keyrings/cloud.google.gpg add -
 
# gcloud のインストール
sudo apt-get update && sudo apt-get install google-cloud-sdk
 
# gcloud の初期化設定
gcloud init

kubectl, bmctl, Docker のインストール：

# gcloud ログイン / Token 生成
gcloud auth application-default login
 
# 作業用ディレクトリの作成 & 移動
mkdir anthos-lab && cd anthos-lab
 
# kubectl のインストール (kubectl がインストールされていない場合)
curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
 
chmod +x kubectl
sudo mv kubectl /usr/local/sbin/
 
# Docker のインストール (Docker がインストールされていない場合)
sudo apt-get update
 
sudo apt-get install \
  apt-transport-https \
  ca-certificates \
  curl \
  gnupg-agent \
  software-properties-common \
  docker.io
 
# non-root で Docker を実行できるよう docker グループへ所属させる
sudo usermod -aG docker $USER
 
# 設定を反映させるため再ログイン
exit
ssh xxx@<node01 IP Address>
cd anthos-lab
 
# sudo なしで Docker のバージョンが表示できることを確認
docker version
 
# 想定される出力結果 (19.03 以降のバージョンであることを確認）
# Client: Docker Engine - Community
# Version:           19.03.13
# ...
# Server: Docker Engine - Community
#  Engine:
#  Version:          19.03.13
 
# bmctl のインストール
gsutil cp gs://anthos-baremetal-release/bmctl/1.7.1/linux-amd64/bmctl . && chmod a+x bmctl
sudo mv bmctl /usr/local/sbin/
 
# bmctl が動くことを確認
bmctl -h
 
# 想定される出力結果
# Anthos Bare Metal cluster management command line interface
#  
# Usage:
#  bmctl [flags]
#  bmctl [command]
# 
# ~省略~

Standalone Cluster の作成

詳細は公式ドキュメントをご確認ください。ここでは Standalone Cluster 構築手順のサマリと構成サンプルを記載します

Standalone Cluster 用構成ファイルの作成

node01 上で以下コマンドを実行し Standalone Cluster の構成ファイルを作成します

# クラスタ名の設定
export PROJECT_ID=<PROJECT ID>
export CLUSTER=<クラスタ名>
 
# Anthos Bare Metal 構成ファイル雛形の作成
bmctl create config -c $CLUSTER --enable-apis \
    --create-service-accounts --project-id=$PROJECT_ID
 
# Anthos Bare Metal 構成ファイルの編集
vi bmctl-workspace/$CLUSTER/$CLUSTER.yaml

以下、構成ファイルのサンプルです。太字括弧の部分は環境に応じて適宜修正してください。以下、構成ファイル記載時のポイントです：

sshPrivateKeyPath … 「SSH 設定」手順で作成した Private Key のパスを入力します。

[kind: Cluster]

spec.controlPlane.nodePoolSpec.nodes[].address … node01 の IP アドレスを入力。HA 構成にする場合は 3 Node 分入力します。
spec.clusterNetwork.pods.cidrBlocks … 私の環境では Node 用サブネットと重複していたので 10.10.0.0/16 に変更しました (元々は 192.168.0.0/16)。必要に応じて変更してください。
spec.loadBalancer.vips.controlPlaneVIP … Control Plane アクセス用の VIP。 Node 用サブネットから払い出します。
spec.loadBalancer.vips.ingressVIP … Ingress アクセス用の VIP。 Node 用サブネットから払い出します。
spec.LoadBalancer.addressPools[].addresses … type: LoadBalancer で作成するサービスで利用する IP アドレスレンジ。CIDR の形式(1.2.3.0/24) もしくはレンジ (1.2.3.1–1.2.3.5) で指定可能です。Node 用サブネットから払い出します。spec.loadBalancer.vips.ingressVIP がこの IP アドレスレンジに含まれている必要があるので気をつけてください（例: Ingress VIP が 192.168.10.201 の場合、アドレスプールレンジは 192.168.10.201–192.168.10.220 のように記載する）。

[kind: NodePool]

spec.nodes.address … node02 の IP アドレスを入力。複数 Node 構成にする場合は必要 Node 数分入力します。

gcrKeyPath: <自動入力>
sshPrivateKeyPath: <Workstation 上の Private Key パス> 
gkeConnectAgentServiceAccountKeyPath: <自動入力>
gkeConnectRegisterServiceAccountKeyPath: <自動入力>
cloudOperationsServiceAccountKeyPath: <自動入力> 
---
apiVersion: v1
kind: Namespace
metadata:
  name: cluster-<自動入力>
---
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: <自動入力>
  namespace: cluster-<自動入力>
spec:
  type: standalone
  anthosBareMetalVersion: 1.7.1
  gkeConnect:
    projectID: <自動入力>
  controlPlane:
    nodePoolSpec:
      nodes:
      - address: <node01 の IP Address>
  clusterNetwork:
    pods:
      cidrBlocks:
      - 10.10.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  loadBalancer:
    mode: bundled
    ports:
      controlPlaneLBPort: 443
    vips:
      controlPlaneVIP: <Control Plane 用 VIP>
      ingressVIP: <Ingress 用 VIP>
    addressPools:
    - name: pool1
      addresses:
      - <LB Service VIP 用ネットワークレンジ>
  clusterOperations:
    projectID: <自動入力>
    location: us-central1
  storage:
    lvpNodeMounts:
      path: /mnt/localpv-disk
      storageClassName: local-disks
    lvpShare:
      path: /mnt/localpv-share
      numPVUnderSharedPath: 5
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250
    containerRuntime: docker
---
apiVersion: baremetal.cluster.gke.io/v1
kind: NodePool
metadata:
  name: node-pool-1
  namespace: cluster-<自動入力>
spec:
  clusterName: <自動入力>
  nodes:
  - address: <node02 の IP Address>

以下コマンドを実行し、無事デプロイが成功することを祈ります（私の環境だと大体デプロイ完了まで 20 分程かかりました）。

# クラスタ作成
bmctl create cluster -c $CLUSTER# 想定される出力結果
Please check the logs at bmctl-workspace/kuchima-abm/log/create-cluster-20210502-150056/create-cluster.log
[2021-05-02 15:01:03+0000] Creating bootstrap cluster... OK
[2021-05-02 15:05:18+0000] Installing dependency components... OK
[2021-05-02 15:07:45+0000] Waiting for preflight check job to finish... OK
[2021-05-02 15:10:05+0000] - Validation Category: machines and network
[2021-05-02 15:10:05+0000]  - [PASSED] node-network
[2021-05-02 15:10:05+0000]  - [PASSED] 192.168.50.101
[2021-05-02 15:10:05+0000]  - [PASSED] 192.168.50.101-gcp
[2021-05-02 15:10:05+0000]  - [PASSED] 192.168.50.102
[2021-05-02 15:10:05+0000]  - [PASSED] 192.168.50.102-gcp
[2021-05-02 15:10:05+0000]  - [PASSED] gcp
[2021-05-02 15:10:05+0000] Flushing logs... OK
[2021-05-02 15:10:06+0000] Applying resources for new cluster
[2021-05-02 15:10:06+0000] Waiting for cluster to become ready OK
[2021-05-02 15:17:06+0000] Writing kubeconfig file
[2021-05-02 15:17:06+0000] kubeconfig of created cluster is at bmctl-workspace/kuchima-abm/kuchima-abm-kubeconfig, please run
[2021-05-02 15:17:06+0000] kubectl --kubeconfig bmctl-workspace/kuchima-abm/kuchima-abm-kubeconfig get nodes
[2021-05-02 15:17:06+0000] to get cluster node status.
[2021-05-02 15:17:06+0000] Please restrict access to this file as it contains authentication credentials of your cluster.
[2021-05-02 15:17:06+0000] Waiting for node pools to become ready OK
[2021-05-02 15:17:26+0000] Moving admin cluster resources to the created admin cluster
[2021-05-02 15:19:06+0000] Waiting for node update jobs to finish OK
[2021-05-02 15:20:46+0000] Flushing logs... OK
[2021-05-02 15:20:46+0000] Deleting bootstrap cluster... OK

Standalone Cluster 作成後、生成された kubeconfig を利用してクラスタ内のノード情報が取得できることを確認します。

export KUBECONFIG=<生成された kubeconfig>kubectl get nodes# 想定される出力結果
NAME    STATUS   ROLES    AGE   VERSION
node01   Ready    master  4m51s  v1.19.7-gke.1200
node02   Ready    <none>  3m19s  v1.19.7-gke.1200

最後に簡単なアプリケーションをデプロイしてみて、アクセスできるか試してみます。

# テストアプリケーションのデプロイ
kubectl create deployment httpbin --image=kennethreitz/httpbin:latestkubectl expose deployment httpbin --name httpbin-svc --type LoadBalancer --port 80
 
# 外部アクセス用 IP アドレスの確認
kubectl get svc
NAME          TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
httpbin-svc   LoadBalancer   10.106.57.42   192.168.50.152   80:30821/TCP   5s
kubernetes    ClusterIP      10.96.0.1      <none>           443/TCP        11m
 
# 外部アクセス用 IP アドレスに到達可能な端末からアクセスしレスポンスが返ってくることを確認
curl 192.168.50.152/headers -s -o /dev/null -w "%{http_code}\n"
200

上手くいきました！これで Anthos clusters on Bare Metal のデプロイ完了です。

最後に運用周りの話です。

Anthos clusters on Bare Metal では、デフォルトでは Cloud Monitoring / Cloud Logging にシステムコンポーネントに関するメトリクス / ログが自動的に連携されるようになっています（システムコンポーネント分は Cloud Monitoring / Cloud Logging に関するお金はかかりません）。

もちろんアプリケーションの Pod のメトリクス / ログも Cloud Monitoring / Cloud Logging に連携することが可能です。これはデフォルトだと連携が無効となっているので必要に応じて有効化が必要となっています（システムコンポーネントと違ってこちらは正規の Cloud Monitoring / Cloud Logging 料金が発生します）。

Cloud Monitoring では Anthos clusters on Bare Metal のデプロイが完了したタイミングで Anthos clusters 用に事前定義されたダッシュボードがインポートされるので、すぐに運用を開始することができます。

ちなみにモニタリング / ロギングツールは、 Cloud Monitoring / Logging 以外の 3rd Party 製品をお使いいただくことも可能ですので、使い慣れた製品を利用されたい場合や、オンプレミス上のプラットフォームで監視したい場合などはそちらを利用することができます。

また、監視の話とは変わりますが、Anthos clusters を Google Cloud 側に登録することにより、 Google Cloud Console からオンプレミスのクラスタの情報を確認したり、オンプレミスクラスタ上にアプリケーションをデプロイすることもできるようになります。（この辺りの設定も簡単にできるのですが、本記事が結構長くなってしまったので別記事としてまとめます）

Interl NUC 上での Anthos clusters on Bare Metal の基本的な構築はこれで以上となります。応用編的な記事も後々上げようと思いますので、もしご興味があればぜひそちらもご覧ください。

ちなみに、Anthos 試したいけど空いている物理マシンがないよ〜という場合は ESXi のような仮想環境上に仮想マシンとしてクラスタノードをデプロイすることも可能ですし、GCE 上で Anthos clusters on Bare Metal をデプロイしてお試しいただくことも可能です。もし気になりましたらぜひお試しください！

参考：Compute Engine VM でベアメタル版 Anthos クラスタを試す

それでは皆さん、楽しいおうち Anthos Life をお過ごしください〜