Amazon Web Services ブログ

AWS Admin

Author: AWS Admin

Amazon Web Services

Amazon EKS クラスター向けのマルチテナント設計時の考慮事項

この投稿は、AWS ソリューションアーキテクトの Roberto Migli による寄稿です。 Amazon Elastic Kubernetes Service (Amazon EKS) は、今日、コンテナアプリケーションを大規模に実行するために、数千の顧客が使用しています。よくある質問の中でも、マルチテナントの Amazon EKS クラスターをチームに提供することについてよく耳にします。 1 つまたは多くのクラスターを実行する必要がありますか? チームごと、環境ごと、アカウントごとに 1 つのクラスターを使用する必要がありますか? 正解や不正解はありません。この投稿では、正しい判断を下すためにいくつかの側面を検討していきます。 問題 マルチテナンシーでは、異なるワークロードまたはチームが同じクラスターを共有し、それらをある程度、論理的または物理的に分離する必要があります。さまざまな理由から分離が必要になる場合があります。たとえば、セキュリティは、各チームが意図したワークロードでのみ動作し、他のチームのワークロードでは動作できないようにするか、アプリケーション間でネットワークを分離 (デフォルトでは、すべての名前空間内のすべてのポッドが相互通信できる) します。もう 1 つの理由は、同じインフラストラクチャを共有するさまざまなワークロード全体でリソース (CPU、メモリ、ネットワークなど) を公平に配分するためです。顧客ごとにソリューションをデプロイするサービスのソフトウェア企業は、同じクラスター上で複数のテナントを実行することでインフラストラクチャの利用率を高めることができますが、各テナント間をさらに高度に分離する必要があります。 マルチテナンシーのための Kubernetes ネイティブソリューション Kubernetes は、1 つのクラスター内でマルチテナンシー設計に役立つネイティブの Kubernetes API と構造をいくつか提供します。コンピューティング、ネットワーキング、ストレージの主な構成要素を以下に示します。 分離を計算する Kubernetes のドキュメントは、名前空間を「複数のユーザー間でクラスターリソースを分割する方法」と定義しているため、マルチテナンシーの基礎となります。Kubernetes オブジェクトのほとんどは名前空間に属しています。下の図には 2 つの名前空間があり、それぞれが互いに実質的に分離されたオブジェクトのセットを実行しています。   名前空間はワークロードやユーザーの分離を提供しませんが、次のコンポーネントを理解するための核心です。1 つ目はロールベースのアクセスコントロール (RBAC) です。Kubernetes API で誰が何を実行できるかを定義する方法を提供します。承認は ClusterRole を介してクラスターに適用することも、Role を介して 1 […]

Read More

Amazon EKS クラスターリソースへのクロスアカウントアクセスを有効にする

この記事は、Satya Sai Naga Venkata Kumar Vajrapu と Jason Smith が寄稿しました。 Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes コントロールプレーンを立ち上げたり維持したりすることなく、AWS で Kubernetes を簡単に実行できるマネージドサービスです。管理対象ノードグループと AWS Fargate での Amazon EKS の最近のリリースにより、ポッド向けにインフラストラクチャをプロビジョニングおよび管理する必要がなくなりました。Kubernetes は、コンテナ化されたアプリケーションのデプロイ、スケーリング、および管理を自動化するためのオープンソースシステムです お客様は複数の AWS アカウントを使用して AWS 環境を管理していることがよくあります。そのようなお客様は、実稼働リソースが開発またはステージングリソースと対話したり共存したりすることを望んでいません。これにより、リソースの分離が向上するという利点が得られますが、アクセス管理のオーバーヘッドが増加します。 AWS Security Token Service (STS) および IAM ロールを使用して、一時的な AWS セキュリティ認証情報を活用することにより、複数のアカウントへのユーザーアクセスを管理できます。けれども、あるアカウントでホストされている Amazon EKS クラスター内のコンテナ化されたワークロードやポッドなどのリソースが、別のアカウントでホストされている Amazon EKS クラスターリソースとやり取りしたい場合はどうでしょうか? こちらの以前のブログでは、サービスアカウントの IAM ロール (IRSA) を使用して、ポッドレベルできめ細かいロールを使用する方法について説明しました。このブログでは、このソリューションを拡張し、あるアカウントでホストされている Amazon […]

Read More

re:Invent に出席する 1 人のストレージ愛好家からストレージセッションのご紹介

AWS ヒーロー として、また何年も re:Invent を出席し、この会議を最大限に活用するためのヒントをいくつか取り上げました。これが、re:Invent での時間をもっと活用するのに役立つことを願っており、初めての参加者であれ何年も参加している方々であれ、クラウドストレージの知識を増やしていただければ幸いです。私のキャリアはデータストレージ焦点を宛ててきており、re:Invent ではデータ愛好家を常に喜ばせるさまざまなストレージのコンテンツがあります。 ストレージセッションを使ってアジェンダを構築する セッションの登録は 10 月 15 日から開始されるため、セッションが満員になる前に忘れずに登録してください。 今は セッションカタログ を見直し、出席したいセッションやイベントを絞り込むのに良い時期です。AWS はあなたが行うことができることが常にあるように確認しており、スケジュールを埋めていくことは容易です。セッションカタログを参照するときには、「Topics」セクションで「Storage」を選択することにより、ストレージに焦点を充てるセッションをフィルタリングできます。多くのセッションがあり、最も人気のあるものは複数回 (および複数の場所で) 提供されます。1 つのセッションが予定に合わない倍は、繰り返しのセッションが見つかる可能性がよくあります。 re:Invent に初めて出席する場合、セッションカタログには圧倒されてしまう可能性があります。カタログに 150 のストレージプレゼンテーションがあり、カンファレンスのキーノート中に新製品やキーノートが発表になった後ではさらに多くのセッションが追加される場合があります。AWS ストレージサービスについて学びたいだけである場合は、中程度のレベル (レベル 200) セッションから始めてください。私は可能な限りチョークトーク (レベル 300) を探します。それらはサービスの概要と聴衆者のディスカッションの機会と両方を提供してくれるからです。これは、サービスについて学習する一方で、自分の質問について尋ねられ、同じ興味をもつその他の人とのネットワーキングも行うことができます。アドバンストとエクスパートレベル (レベル 400) のセッションは、中程度のセッションよりもサービスに特化したセッションです。アドバンストセッションは、サービスが行うことのベーシックな理解があることを前提にしています。これらは、使用したり、考えたりしている特定のサービスを掘り下げるために役立ちます。ここでもまた、私はネットワーキングと Q&A の機会のために、チョークトークとビルダーセッションを探します。 私が最も楽しみしているセッションは、次の通りです。 STG201-L – リーダーシップセッション: ユニオンのストレージの状態 このセッションでは、新しいサービスと更新プログラムが公開されるため、すべてのストレージ愛好家にとって必須です。このセッションは、すべてのストレージセッションにトーンを設定するものと考えることが多く、1 週間を通じてストレージセッションで期待できるものをよく理解できます。プロのヒント: このセッションはすぐに満員になるため、早めにご登録ください。 STG202 – AWS ファイルストレージの新機能 ファイルストレージスペースで見たい製品の発表がいくつかありますが、このセッションで探しているアップデートを入手できるように祈っていました。 STG205 – データ移行: テクノロジーとオプションを理解する 過去 3 […]

Read More

AWS Step Functions と AWS Systems Manager を使用して、Amazon EBS ボリュームのサイズ変更を自動化する

アクティブなアプリケーションで、Amazon EC2 インスタンスの Amazon EBS ボリューム使用率がプロビジョニング済み容量に達してしまうことがあります。どのアプリケーションを使用しているかによって異なりますが、プロビジョニング済み容量が使い果たされると、アプリケーション停止のリスクが生じ、お客様に影響を与えることがあります。これに対するソリューションの 1 つに、アプリケーションへのフェールオーバーメカニズムの設計がありますが、オーケストレーションの負担になる可能性があります。より簡単なソリューションは、EBS ボリュームのサイズを自動的に変更することです。 Infor では、本番環境での数千に及ぶ EC2 インスタンス (Windows と Linux) を管理しています。当社はこうした停止を防ぐ予防的アプローチが必要であったため、特定のしきい値に達したときボリュームが自動的に増加するように、本投稿で説明するソリューションを開発しました。このアプローチには 2 つの利点があります。 異常が発生し、ボリュームのスペースが非常に少なくなると、プロビジョニング済み容量が枯渇する前に自動的にボリュームを拡張します。このアクションにより、根本原因を調査し解決するまで、問題に対処できます。 そのため、ボリュームを過剰にプロビジョニングする必要がなくなりました。このソリューションは、より多くのスペースが必要になると、徐々に自動的にボリューム容量を増やし、EBS コストを削減します。 この投稿では、Infor で開発した自動 EBS ボリュームサイズ変更プロセスを順を追って説明します。さらに、そのアーキテクチャを確認し、ベストプラクティスをいくつか学びます。 概要 AWS は Amazon EBS Elastic Volumes を 2017 年に発表しました。この機能では、ダウンタイムなしでシンプルな API 呼び出しで、ボリュームのサイズを増やしたり、パフォーマンスを調整したり、ボリュームタイプをその場で変更したりできます。 ボリュームの変更は比較的簡単ですが、ファイルシステムを拡張して、追加のストレージを活用しようとすると一筋縄ではいきません。これは通常、OS 上で手動で行いますが、AWS Systems Manager がインスタンスを管理している場合には、AWS Lambda を使用して OS レベルのスクリプトを実行する Systems Manager コマンドを送信できます。 次のリストは、このワークフローの手順を示しています。 ボリュームが 80% に達することをモニタリングし、自動化をトリガーします。 特定のシステムが除外されたため、続行する前に一連のチェックを実行します。フリートの […]

Read More