Tag: Amazon EKS

2015年に AWS で初めてリリースされて以来、Red Hat OpenShift は似たようなアーキテクチャを持ってきました。OpenShift 3 、 OpenShift 4 、自己管理の OpenShift Container Platform (OCP) か、マネージドサービスの ROSA かを問わず、お客様はこれまで自身の AWS アカウント内に存在するコントロールプレーンについて、関連するコストを相殺して投資対効果 (ROI) を最大化する方法を検討してきました。これに応えるべく Red Hat は OpenShift 向けに Hosted Control Plane (HCP) をリリースしました。

AWS の Amazon Elastic Kubernetes Service (Amazon EKS) を使用してアプリケーションをモダナイズする際、ユーザーはしばしばスケールに伴う IPv4 アドレス空間の枯渇という深刻な問題に直面します。ユーザーは、運用の複雑さを増やすこと無く、EKS 上の Pod に割り当てられた VPC の CIDR とサブネットをできる限り活用したいと考えています。IPv6 アドレス空間の利用が、スケーラブルなネットワークソリューションを構築するための長期的な解決策になると考えられています。しかし、他のネットワークコンポーネントやアプリケーションの IPv6 サポートの制約から、Amazon EKS ユーザーは IPv4 環境を強いられている可能性もあります。そこで、Amazon EKS ではネットワーク設定を合理化し、運用の複雑さを増やすことなく IPv4 ベースのクラスターをスケーリングできるように、拡張サブネットディスカバリーのサポートを導入しました。

この記事では、Amazon EKS Windows クラスターに Container Insights を有効化するプロセスを紹介します。Container Insights を利用することで、数回のクリックで、Amazon EKS Windows クラスターのコントロールプレーンとデータプレーンの両方の詳細なメトリクスを収集できるようになります。Amazon EKS クラスターで高度な CloudWatch Container Insights を有効にし、Amazon EKS クラスター上で実行中の Windows ワークロードの組み込みのダッシュボードを使うことで、パフォーマンス問題の特定と解決にかかる時間を短縮できます。

2024 年 3 月 12 日に「 AWS Compute Performance and Efficiency 」を目黒で開催しました。本セミナーでは、Amazon Elastic Compute Cloud (Amazon EC2) をコスト効率よく活用する方法について、海外のスペシャリストも交えて解説しました。インスタンスの選び方や AWS Graviton の活用、Kubernetes 環境での最適化、そして最新事例もご紹介をしました。本記事では、発表内容の概要と発表資料を掲載しています。

Kubernetes コミュニティは Kubernetes コンポーネントのサービスレベル指標 (SLI) とサービスレベル目標 (SLO) を定義しており、これらをスケーラビリティに関する議論の出発点として使用できます。この投稿では、これらの SLI と SLO について説明し、Amazon EKS チームがどのようにスケーラビリティテストを実施しているのか説明します。

Riot と AWS のコラボレーションの歴史を振り返り、クラウドの導入にあたって Riot が取った段階的なアプローチがいかにして社内で最もクラウドに対して懐疑的な人たちさえも味方につけられたかについて見ていきましょう。

Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Amazon EKS、Amazon EKS Distro および Amazon EKS Anywhere (リリース 0.19.0) における Kubernetes バージョン 1.29 のサポートを発表できることを嬉しく思います。この記事では、Kubernetes バージョン v1.29 の注目すべき変更点を説明し、利用可能となった最もエキサイティングな機能のいくつかを紹介します。

2023 年 10 月 4 日、Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes バージョンに対する延長サポートのパブリックプレビューを発表しました。これは Kubernetes のマイナーバージョンのサポート期間を 12 ヶ月延長します。そして本日、延長サポートの料金設定を発表します。

コンテナは、モダンでスケーラブルなアプリケーションをデプロイするための頼りになるソリューションになっています。これらのコンテナの起動時間は、特に大きなコンテナイメージを必要とするワークロードを処理する場合に大きな課題となる可能性があります。たとえばデータ分析や機械学習のワークロードには、1 GiB を超えるサイズのイメージが含まれることがよくあります。generative AI などのこの種のワークロードを Amazon Elastic Kubernetes (Amazon EKS) で実行する場合、Amazon Elastic Container Registry (Amazon ECR) などのイメージレジストリからこれらの大きなイメージを取り出して抽出するのに数分かかることがあります。これはパフォーマンスに悪影響を及ぼし、ユーザーエクスペリエンスの低下につながります。
イメージをプリフェッチして Pod をより速く起動する方法を紹介した既存の投稿があります。Amazon EventBridge と AWS System Manager を使用してコンテナイメージをノードにキャッシュし、新しいイメージがイメージレジストリにプッシュされたときにキャッシュを更新します。既存のワーカーノードや継続的なイメージキャッシュに適しています。しかし、クラスターがスケールアップするにつれて新しいワーカーノードが追加されると、すべてのイメージを新しいワーカーノードに取り込むのに時間がかかります。
この投稿では、Bottlerocket で実行されるインスタンスを使用して、この課題に取り組むためのソリューションを紹介します。Bottlerocket は、AWS がコンテナの実行専用に設計した、オープンソースの Linux ベースのオペレーティングシステム (OS) であり、大きなイメージのコンテナ起動時間を短縮するのに役立ちます。

Karpenter は AWS によって開発された Kubernetes のノードライフサイクルマネージャーで、クラスターのノードの設定を最小化することを目的として、2021 年にリリースされました。この 1 年で、GitHub の Star 数は 4900 を超え、200 人以上のコントリビューターによるコードがマージされるなど、素晴らしい成長を遂げています。このような成長の一貫として、alpha 版で行われた数々の破壊的な変更に対処したくないというユーザーに対して、より厳格な安定性を保証する Kubernetes API の成熟の需要が高まっています。