**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# セルフマネージド Bottlerocket ノードの作成
<a name="launch-node-bottlerocket"></a>

**注記**  
マネージド型ノードグループでは、ユースケースにいくつかの利点がある場合があります。詳細については、「[マネージドノードグループを使用してノードライフサイクルを簡素化する](managed-node-groups.md)」を参照してください。

このトピックでは、Amazon EKS クラスターに登録する [Bottlerocket](https://aws.amazon.com/bottlerocket/) ノードの Auto Scaling グループを起動する方法について説明します。Bottlerocket は AWS が提供する Linux ベースのオープンソースのオペレーティングシステムで、仮想マシンやベアメタルホスト上でコンテナを実行するために使用できます。ノードがクラスターに参加したら、それらのノードに Kubernetes アプリケーションをデプロイ可能になります。Botttlerocket の詳細については、GitHub の [Using a Bottlerocket AMI with Amazon EKS](https://github.com/bottlerocket-os/bottlerocket/blob/develop/QUICKSTART-EKS.md) と `eksctl` ドキュメント内の [Custom AMI support](https://eksctl.io/usage/custom-ami-support/) を参照してください。

インプレースアップグレードについて詳しくは、GitHub の [Bottlerocket Update Operator](https://github.com/bottlerocket-os/bottlerocket-update-operator) を参照してください。

**重要**  
Amazon EKS ノードは標準の Amazon EC2 インスタンスであり、通常の Amazon EC2 インスタンス価格に基づいて請求されます。詳細については「[Amazon EC2 料金](https://aws.amazon.com/ec2/pricing/)」を参照してください。
AWS Outposts 上の Amazon EKS 拡張クラスターで Bottlerocket ノードを起動できますが、AWS Outposts 上のローカルクラスターでは起動できません。詳細については、「[AWS Outposts を使用して Amazon EKS をオンプレミスにデプロイする](eks-outposts.md)」を参照してください。
`x86` または Arm プロセッサを使用して Amazon EC2 インスタンスにデプロイできます。ただし、Inferentia チップがあるインスタンスにデプロイすることはできません。
Bottlerocket は、AWS CloudFormation と互換性があります。ただし、Amazon EKS の Bottlerocket ノードをデプロイするためにコピーできる公式の CloudFormation テンプレートはありません。
Bottlerocket のイメージには、SSH サーバーやシェルは付属していません。SSH で管理者コンテナを有効にし、ユーザーデータとともにブートストラップの設定ステップを渡すために、帯域外のアクセス方式を使用できます。詳細については、GitHub の「[bottleRocket readme.md](https://github.com/bottlerocket-os/bottlerocket)」のセクションを参照してください。  
 [探査](https://github.com/bottlerocket-os/bottlerocket#exploration) 
 [管理者コンテナ](https://github.com/bottlerocket-os/bottlerocket#admin-container) 
 [Kubernetes 設定](https://github.com/bottlerocket-os/bottlerocket#kubernetes-settings) 

この手順には、`eksctl` バージョン `0.215.0` 以降が必要です。お使いのバージョンは、以下のコマンドを使用して確認できます。

```
eksctl version
```

`eksctl` のインストールまたはアップグレードの手順については、 `eksctl` ドキュメントの「[インストール](https://eksctl.io/installation)」を参照してください。注意: この手順は、`eksctl` で作成されたクラスターでのみ機能します。

1. 次のコンテンツをデバイスにコピーします。*マイクラスター* の部分は自分のクラスター名に置き換えます。この名前には英数字 (大文字と小文字が区別されます) とハイフンのみを使用できます。先頭の文字は英数字である必要があります。また、100 文字より長くすることはできません。名前は、クラスターを作成する AWS リージョンおよび AWS アカウント内で一意である必要があります。*ng-bottlerocket* をノードグループの名前に置き換えます。ノードグループ名は 63 文字以下である必要があります。先頭は文字または数字でなければなりませんが、残りの文字にはハイフンおよびアンダースコアを含めることもできます。Arm インスタンスにデプロイするには、*m5.large* を Arm インスタンスタイプに置き換えます。*my-ec2-keypair-name* を、起動後に、SSH を使用してノードに接続するときに使用できる Amazon EC2 SSH キーペアの名前に置き換えます。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については*「アマゾン EC2 ユーザーガイド」*の「[アマゾン EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。残りのサンプル値はすべて独自の値に置き換えます。置き換えが完了したら、変更したコマンドを実行して `bottlerocket.yaml` ファイルを作成します。

   Arm Amazon EC2 インスタンスタイプを指定する場合は、デプロイする前に「[Amazon EKS 最適化 Arm Amazon Linux AMI](eks-optimized-ami.md#arm-ami)」の考慮事項を確認してください。カスタム AMI を使用したデプロイの手順については、GitHub の [Building Bottlerocket](https://github.com/bottlerocket-os/bottlerocket/blob/develop/BUILDING.md) と、`eksctl` ドキュメントの [Custom AMI support](https://eksctl.io/usage/custom-ami-support/) を参照してください。マネージド型ノードグループをデプロイするには、起動テンプレートを使用してカスタム AMI をデプロイします。詳細については、「[起動テンプレートを使用してマネージドノードをカスタマイズする](launch-templates.md)」を参照してください。
**重要**  
ノードグループを AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットにデプロイする場合、クラスターの作成時に AWS Outposts、AWS Wavelength、または AWS Local Zone サブネットは渡さないでください。次の例では、サブネットを指定する必要があります。詳細については、`eksctl` ドキュメントの「[設定ファイルからノードグループを作成する](https://eksctl.io/usage/nodegroups/#creating-a-nodegroup-from-a-config-file)」と「[Config ファイルのスキーマ](https://eksctl.io/usage/schema/)」を参照してください。*region-code* を、クラスターのある AWS リージョンに置き換えます。

   ```
   cat >bottlerocket.yaml <<EOF
   ---
   apiVersion: eksctl.io/v1alpha5
   kind: ClusterConfig
   
   metadata:
     name: my-cluster
     region: region-code
     version: '1.35'
   
   iam:
     withOIDC: true
   
   nodeGroups:
     - name: ng-bottlerocket
       instanceType: m5.large
       desiredCapacity: 3
       amiFamily: Bottlerocket
       ami: auto-ssm
       iam:
          attachPolicyARNs:
             - arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy
             - arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly
             - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
             - arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy
       ssh:
           allow: true
           publicKeyName: my-ec2-keypair-name
   EOF
   ```

1. 次のコマンドでノードをデプロイします。

   ```
   eksctl create nodegroup --config-file=bottlerocket.yaml
   ```

   出力例は次のとおりです。

   ノードの作成中に、複数の行が出力されます。出力の最後の行は次のサンプル行が表示されます。

   ```
   [✔]  created 1 nodegroup(s) in cluster "my-cluster"
   ```

1. (オプション) [Amazon EBS CSI プラグイン](https://github.com/kubernetes-sigs/aws-ebs-csi-driver)を使用して、Bottlerocket ノード上に Kubernetes [永続ボリューム](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)を作成します。デフォルトの Amazon EBS ドライバーは、Bottlerocket に含まれていないファイルシステムツールを利用します。ドライバーを使用してストレージクラスを作成する方法の詳細については、「[Amazon EBS で Kubernetes ボリュームストレージを使用する](ebs-csi.md)」を参照してください。

1. (オプション) デフォルトでは、`kube-proxy` は `nf_conntrack_max` カーネルパラメータを、Bottlerocket がブート時に設定するものとは異なるデフォルト値に設定します。Bottlerocket の[デフォルト設定](https://github.com/bottlerocket-os/bottlerocket-core-kit/blob/develop/packages/release/release-sysctl.conf)を保持するには、次のコマンドを使用して `kube-proxy` 設定を編集します。

   ```
   kubectl edit -n kube-system daemonset kube-proxy
   ```

   次の例にある `kube-proxy` 引数に、`--conntrack-max-per-core` と `--conntrack-min` を追加します。`0` の設定は、変更がないことを意味します。

   ```
         containers:
         - command:
           - kube-proxy
           - --v=2
           - --config=/var/lib/kube-proxy-config/config
           - --conntrack-max-per-core=0
           - --conntrack-min=0
   ```

1. (オプション) [サンプルアプリケーション](sample-deployment.md)をデプロイして、Bottlerocket ノードをテストします。

1. 次の条件が true の場合、IMDS への Pod アクセスをブロックすることをお勧めします。
   + IAM ロールをすべての Kubernetes サービスアカウントに割り当てることによって、必要最小限のアクセス許可のみを Pod に付与しようとしている。
   + クラスター内の Pod が、現在の AWS リージョンの取得など、その他の理由で Amazon EC2 インスタンスメタデータサービス (IMDS) へのアクセスを必要としていない。

   詳細については「[ワーカーノードに割り当てられたインスタンスプロファイルへのアクセスを制限する](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node)」を参照してください。