Bottlerocketとは何ですか、EKSでどのように使用しますか？

コンプライアンス対応の最中であったり、その困難な道のりを始めようとしている場合、起動しているEC2インスタンスに対して多くの警告（レッドアラート）に遭遇するかもしれません。さらに、デフォルトのAmazon Linuxイメージの利用が、ご自身のユースケースに適しているのか疑問に感じ始めるでしょう。コンテナ化されたワークロードをサポートし、パッチ適用にかかるオーバーヘッドが少なく、より優れたセキュリティを提供するカスタムAMIがあるのではないかと考えているかもしれません。

Bottlerocketは、最適なコンテナホストとして機能するように細心の注意を払って作られた、専用のLinuxベースのオペレーティングシステムです。不要なオーバーヘッドを削減するように設計されており、コンテナ化されたアプリケーションの現代的な要求に合わせて調整された、軽量で効率的なソリューションとして登場しました。

💡

この特殊なLinuxイメージは、コンテナオーケストレーションの合理化に特化して設計されており、セキュリティ、コンプライアンス、運用効率を優先しています。

Bottlerocketのコアバリュー

Bottlerocketは、以下に詳述する3つの主要なコアバリューに基づいています。

最小限であること

Dockerイメージを実行したいだけなのに、なぜ何百もの不要なアプリケーションが必要なのでしょうか。Bottlerocketは、必要最小限のパッケージのみをベアイメージに含めるミニマリストなアプローチを採用しており、これにより軽量で管理しやすくなっています。

必要なすべてのパッケージは単一のLinuxイメージにインストールされており、これは、サポートするさまざまなプラットフォーム/アーキテクチャと異なるAWSサービスの組み合わせです。各組み合わせは「 バリアント」と呼ばれます。

例えば、 bottlerocket-aws-k8s-1.28-x86_64-1.16 は バリアント であり、EKSバージョン1.28のBottlerocketイメージの x86_64 アーキテクチャ用です。ECSの別のバリアントは、例えば bottlerocket-aws-ecs-2-x86_64-1.16

安全なアップデート

Bottlerocketは、すべてのものを単一のAMIイメージにビンパッキングするという概念に根本的に依存しているため、 パッケージマネージャーはありません。

すべてがイメージにバインドされるため、何かを更新するには、イメージのバージョンを更新するだけで済みます。これにより、テスト済みのすべてのコンポーネントの最新（安定かつ安全な）バージョンが提供され、パッケージを個別に管理する必要がなくなります。

左側には、実行中のバージョンが新しいバージョンに更新されている実行中のインスタンスが表示されています。これは同じインスタンスにダウンロードされますが、別の場所に保存されます。ダウンロードが完了すると再起動が行われ、新しいバージョンがカーネルの主要なソースとして切り替わります。

セキュリティ

セキュリティはBottlerocketインスタンスの最優先事項であり、それを確実にするためにいくつかの対策を講じています。

1. ルートファイルシステムは不変です — ルートファイルシステムが不変であるため、インスタンスイメージには安定したテスト済みのバージョンのみが含まれます。 dm-verity は、ルートハッシュとMerkle treeを使用してファイルシステムの透過的な整合性をチェックするために使用されます。
2. SeLinuxはデフォルトで強制されます
3. シェルなし — そのため、リモート攻撃のリスクが低減されます。

概念

Bottlerocketインスタンスについてさらに理解を深めるための高レベルな概念をいくつかご紹介します。

API駆動型

Bottlerocketインスタンスにはシェルがないため、イメージバージョンとその更新、基本的な操作、管理者レベルのタスクなどをどのように照会するのでしょうか。これらのタスクを解決するために、Bottlerocketは明確に定義されたHTTP APIを提供しており、これによりこれらの問題をすべて解決できます。同時に、各操作に対して正確な手順で、正当な操作のみがインスタンス上で実行されることを保証します。

ブートストラップコンテナ

既に説明したように、ルートファイルシステムは不変であり、 dm-verity によって検証されるため、 /etc は tmpfsを使用して可変ファイルシステムの一部となります。

ブートストラップコンテナを使用すると、インスタンスの起動中にルートファイルシステム上にインストールしたい特定のプログラムや機能を有効にできます。これらは、コンテナランタイム containerd 上で動作するコンテナのセットです。このようなブートストラップコンテナを複数実行でき、すべてのコンテナが正常に終了するとインスタンスの起動が完了します。これらのブートストラップコンテナには特定の終了条件を適用できます。詳細については、 こちらをご覧ください。

デフォルトではセキュアブートも有効になっており、マシンの起動時にUEFIファームウェアによって適切なソフトウェアがオフロードされることを保証します。

コンポーネント

Bottlerocketインスタンスはコンテナ化されたワークロードに特化しており、そのため2つのセットの containerd インスタンスが実行されます。そのうちの1つは、 kubelet のようなオーケストレーターエンジン上で通常のコンテナを実行するために使用され、もう1つは、API駆動のHTTPコールを実行するための擬似シェルとして機能する管理者コンテナを実行するために使用されます。 apiclient 、APIリクエストを実行し、インスタンスをデバッグするためにBottlerocketが提供するツールです。この管理コンテナは、ルートファイルシステムの変更可能性を保証しません。

EKSでのBottlerocketインスタンスの使用

EKSノードでBottlerocketインスタンスを使用するのは非常に簡単です。適切なAMIと正しいラベルをノードに渡すことで、Bottlerocket Update Operatorがこれらのノードのイメージ更新を実際に確認し、更新が利用可能になったときに再起動できるようにするだけです。Bottlerocket Update Operatorについては後ほど説明します。

現在のEKSデプロイメントでは、ノードを2つの形式でデプロイしています。

1. Terraform — これが初期ノードグループを起動します。この初期ノードグループは、 Karpenter Podを実行するために使用され、必要に応じてさらにノードを起動します。
2. Karpenterノード — これらは、保留中のワークロードがある場合にKarpenterコントローラーによって起動されるノードです。

Terraform EKSの変更点

私たちの EKS用のTerraformコードに変更を加えるには、 eks_managed_node_groups というオプションに、次のような追加のノードプールを追加します。

eks_managed_node_groups = {    
 bottle = {
     enable_bootstrap_user_data = true
     platform = "bottlerocket"
     bootstrap_extra_args = <<-EOT
       [settings]
       "motd" = "TrueFoundry: MLOpsプラットフォーム"
       [settings.kubernetes.node-labels]
       "bottlerocket.aws/updater-interface-version" = "2.0.0"
     EOT

     instance_types = local.env.user_input.tfy_control_plane.enabled == "True" ? ["c6a.xlarge", "m6a.xlarge", "c6i.xlarge", "r6a.xlarge"] : ["c6a.large", "m6a.large", "c6i.large", "r6a.xlarge"]
     capacity_type  = "SPOT"
     ami_type       = "BOTTLEROCKET_x86_64"
     # 不要であり、使用されません。同じタグを2つのセキュリティグループに付けることも避けてください。
     create_security_group = false

     # Karpenterポッドを2つ実行するのに十分な容量を確保してください。
     min_size = 2
     max_size = 2
     desired_size = 2

     labels = {
       "class.truefoundry.io" = "bottle"
     }

     tags = {
       # これは、Karpenterが使用するために作成された起動テンプレートにタグ付けします。
       "karpenter.sh/discovery" = local.env.cluster_name
     }
     block_device_mappings = {
       xvdb = {
         device_name = "/dev/xvdb"
         ebs = {
           volume_size           = 100
           volume_type           = "gp3"
           throughput            = 150
           delete_on_termination = true
         }
       }
     }
   }
 }


In these there are few important things to note in the above spec

1. We need to pass the "bottlerocket.aws/updater-interface-version" = "2.0.0" so that bottlerocket update operator can interface it.
2. ami_type = "BOTTLEROCKET_X86_64" — to pass the bottlerocket AMI
3. block device mapping to /dev/xvdb — bottlerocket can’t use /dev/xvda as custom AMI is using /dev/xvda to store the root image of size 2GB.

Karpenter

Karpenter is relatively newer way of autoscaling your workloads. Based on the compute required it will try to bring the right sized node, simultaneously bin-packing the daemonsets so that all necessary workloads gets executed on the node.

We rely heavily on karpenter to spin Compute and GPU workloads. Karpenter has a concept called Provisioner(which is now deprecated and named as NodePool ) defining the allowed size of nodes with right labels and taints if required. Moreover through AwsNodeTemplates (which is now deprecated and named as NodeClasses ) you can define the template of the node, giving the right security group, AMI family and root volume size.

Now you can understand where we might have to make changes in the Karpenter provisioner and awsnodetemplates to make sure Karpenter spins Bottlerocket instances.

1. We give the label "bottlerocket.aws/updater-interface-version" = "2.0.0" in the provisioner section.
2. We give the root volume to be /dev/xvdb and amiFamily as Bottlerocket in awsnodetemplate

Through this Karpenter is able to support bottlerocket instances as well.

I am trying to avoid mentioning the provisioner and awsnodetemplate spec as they are now deprecated by karpenter in older versions.

Bottlerocket Update operator (brupop)

Bottlerocket update operator or brupop is a controller for keeping your bottlerocket instances in an EKS cluster up-to-date.

Brupop design

It consists of three main components

1. Controller — Controller is the main brain which checks for upstream image updates and orchestrates the entire update process
2. Agent — Agent runs on each node which gets instructions by controller to perform the operation
3. API server — API which authenticates the agent and the API calls its trying to make

Installing brupop

Brupop has two helm charts which we need to install

• bottlerocket-shadow — which consists of bottlerocketshadow CRDs

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: bottlerocket-shadow
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: default
 source:
   chart: bottlerocket-shadow
   repoURL: https://bottlerocket-os.github.io/bottlerocket-update-operator
   targetRevision: 1.0.0
 syncPolicy:
   automated: {}
   syncOptions:
     - CreateNamespace=true

• bottlerocket-update-operator — 実際のオペレーターで構成される

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: bottlerocket-update-operator
 namespace: argocd
 finalizers:
 - resources-finalizer.argocd.argoproj.io
spec:
 destination:
   namespace: brupop-bottlerocket-aws
   server: https://kubernetes.default.svc
 project: default
 source:
   chart: bottlerocket-update-operator
   repoURL: https://bottlerocket-os.github.io/bottlerocket-update-operator
   targetRevision: 1.3.0
 syncPolicy:
   automated: {}
   syncOptions:
     - CreateNamespace=true
   

宛先ネームスペースは常に brupop-bottlerocket-aws として彼らのHelmチャートで固定されているためです。

コントローラーは bottlerocketshadow CRDを使用してノードを管理します。このドキュメントの以前の箇所で、ノードにラベル "bottlerocket.aws/updater-interface-version" = "2.0.0" を付けるようお願いしました。これは、コントローラーがbrupopに制御させたいBottlerocketインスタンスを識別できるようにするためです。

以下のコマンドを実行することで、ノードのステータスを簡単に確認できます。

$ kubectl get brs  -n brupop-bottlerocket-aws
NAME                               STATE   VERSION   TARGET STATE   TARGET VERSION   CRASH COUNT
brs-ip-xx-xx-1-243.ec2.internal    Idle    1.17.0    Idle           <no value>       0
brs-ip-xx-xx-14-136.ec2.internal   Idle    1.17.0    Idle           <no value>       0
brs-ip-xx-xx-31-78.ec2.internal    Idle    1.17.0    Idle           <no value>       0


TrueFoundryにおけるBottlerocketのサポート

弊社では TrueFoundry bottlerocketインスタンスはCPUとGPUの両方のワークロードをサポートするため、MLOpsの全工程を、適切な問題を解決するための適切なコード開発に集中できるようになり、メンテナンス可能なパッチやセキュリティ修正の負担を軽減します。

よくある質問

bottlerocketとは何ですか？

Bottlerocketは、最適なコンテナホストとして特別に設計された、専用のLinuxベースのオペレーティングシステムです。軽量かつ効率的であるため、コンテナ化されたアプリケーションのオーバーヘッドを削減します。この特殊なOSは、EKSにおけるコンテナオーケストレーションを効率化し、最新のワークロードに対して、強力なセキュリティ、コンプライアンス、運用効率を優先します。

bottlerocketを使用する理由は何ですか？

**bottlerocket**は、コンテナ化されたワークロード向けに最適化された、最小限で専用設計のOSであるため、利用をお勧めします。不変のルートファイルシステムによりセキュリティを強化し、複雑なパッケージ管理を不要にする、合理化されたイメージベースのアップデートを提供します。この特殊なOSは運用効率とコンプライアンスを向上させ、EKSクラスターに最適です。

EKSのオートモードはbottlerocketを使用しますか？

KarpenterのようなEKSのオートスケーリングツールは、Bottlerocketを活用できます。Karpenterを設定してBottlerocket AMIを使用してノードをプロビジョニングすることで、コンテナ化されたアプリケーション向けに、セキュアで最小限かつ効率的なホストを提供します。この統合により、動的なEKSワークロードの運用が合理化され、セキュリティが強化されます。

bottlerocket AMIとは何ですか？

bottlerocket AMIは、Bottlerocket OSがプリインストールされたAmazon Machine Imageです。この特殊なLinuxイメージは、最新のコンテナ化されたアプリケーション向けに作られた、セキュアで最小限のコンテナホストです。すべてのコンポーネントを1つのイメージにバンドルすることで、管理を簡素化し、安全なアップデートを保証します。米国のEKS環境に最適です。

bottlerocketは不変ですか？

はい、bottlerocketインスタンスのルートファイルシステムは不変です。この重要なセキュリティ機能により、安定したテスト済みのバージョンのみがイメージに含まれることが保証され、整合性が向上します。アップデートはbottlerocketイメージ全体を置き換えることで実行され、EKS環境の管理を簡素化し、セキュリティを強化します。

EKSにおけるbottlerocketとは何ですか？

Bottlerocketは、Amazon EKS上のコンテナ化されたワークロード向けに最適化された、専用のLinuxオペレーティングシステムです。EKSノードに最小限でセキュアかつ効率的な基盤を提供し、運用オーバーヘッドを削減し、セキュリティ体制を強化します。この特殊なOSはコンテナオーケストレーションを効率化し、bottlerocket EKS環境の信頼性を高めます。

bottlerocket OSとは何ですか？

Bottlerocket OSは、最適なコンテナホストとして設計された、専用のLinuxベースのオペレーティングシステムです。最高の効率性、セキュリティ、コンプライアンスを実現するように設計されています。この特殊なOSは、最小限のアプローチを提供し、コンテナオーケストレーションを効率化し、特にEKSのような環境において、不要なオーバーヘッドを削減することで、コンテナ化されたアプリケーションの管理を簡素化します。