Tag: Amazon EKS

この記事は、How to build container images with Amazon EKS on Fargate を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar により寄稿されました。 コンテナは、開発者がアプリケーションをパッケージ化、配布、そしてデプロイする方法を簡素化するのに役立ちます。開発者は、アプリケーションコード、ライブラリ、およびその他の依存関係を含むコンテナイメージにコードをパッケージ化します。このイメージを使用して、コンテナ化されたアプリケーションを互換性のある任意のオペレーティングシステムにデプロイすることができます。2013 年の Docker のリリース以来、コンテナの実行、イメージのビルドおよびリポジトリへのプッシュが容易に行えるようになりました。 ただし、Amazon ECS や Amazon EKS のような環境で Docker を使用してコンテナをビルドするには、Docker で Docker を実行する必要がありますが、これには重大な影響があります。おそらく、Docker を使用してコンテナ化された環境でコンテナイメージをビルドするための最も魅力的ではない前提条件は、特権モードでコンテナを実行する、という要件です。これは、セキュリティ意識の高い殆どの開発者が避けたい慣行です。Docker を使用してラップトップ上でイメージをビルドしても、セキュリティに深刻な影響はない場合があります。それでも、Kubernetes クラスターでコンテナに昇格された特権を与えることは避けるのが最善です。この厳しい要件により Fargate では特権コンテナが許可されていないため、Fargate で Docker と EKS を使用してコンテナイメージをビルドすることもできなくなります。 kaniko 特権モードを必要とせずにコンテナイメージをビルドする問題に対処するために、ここ数年で新しいツールが登場しました。kaniko は、Docker と同じように、Dockerfile からコンテナイメージをビルドするツールの 1 つです。ただし Docker とは異なり、Docker デーモンに依存せずに Dockerfile […]

この記事は、Running stateful workloads with Amazon EKS on AWS Fargate using Amazon EFS を翻訳したものです。 本投稿は、Container Specialist Solutions Architect の Re Alvarez-Parmar と Sr Technical Account Manager の Vikram Venkataraman により寄稿されました。 Amazon Elastic Kubernetes Service (EKS) では、EC2インスタンスまたは AWS Fargate で Kubernetes ポッドを実行することができます。コンテナ用のサーバーレスコンピューティングエンジンである AWS Fargate を使用すると、サーバーの作成と管理、データプレーンのスケーリング、EC2 インスタンスの適切なサイズ設定、ワーカーノードのアップグレードの処理を行うことなく、Kubernetes ワークロードを実行できます。今のところ Fargate は、ステートレスなコンテナ化されたワークロードを安全で費用対効果の高い方法で実行するのに理想的です。Fargate は VM で分離された環境で各ポッドを実行し、ノードに自動的にパッチを適用するため安全です。Fargate では、ポッド用に構成したコンピューティングリソースに対してのみ課金されるため、費用対効果が高まります。最近リリースされた Amazon Elastic File System […]

本投稿は Nathan Arnold による記事 Authenticating with Docker Hub for AWS Container Services を翻訳したものです。 Docker Hub は最近利用規約を更新し、コンテナイメージ Pull の rate limits を導入しました。これらの制限は Pro や Team プランのアカウントには適用されませんが、匿名ユーザーは IP アドレスごとに6時間あたり 100 Pull まで、認証済みの無料アカウントは6時間あたり200 Pull までと制限されています。この記事では、新たに設けられた制限による運用の混乱を回避し、プライベートコンテナイメージへのアクセスを制御するために、Amazon ECS と Amazon EKS の両方を使用してプライベートリポジトリからイメージを Pull するために Docker Hub で認証する方法を学びます。まだ Docker Hub を使用していない場合は、AWSクラウド環境とネイティブに統合されたフルマネージドの代替手段としてAmazon Elastic Container Registry (Amazon ECR) を検討してみてはいかがでしょうか。 Amazon ECS による Docker […]

本記事は、Easy as one-two-three policy management with Kyverno on Amazon EKS を翻訳したものです。 この投稿は、Raj Seshadri と Jimmy Ray によって寄稿されました。 クラウドネイティブな本番環境でコンテナが使用されるようになると、DevOps やセキュリティチームは、コンテナのアクティビティをリアルタイムで可視化し、ホストやネットワークリソースへのコンテナアクセスを制限し、実行中のコンテナに対する脆弱性の悪用に代表されるような攻撃を検出して防止する必要があります。 Kyverno は、ユーザーがプログラミング言語を習得する必要のない Kubernetes 用のポリシーエンジンです。Kyverno は、Kubernetes クラスターにポリシー対応のガバナンスとコンプライアンスを適用するための、直感的で Kubernetes ネイティブな手段を提供します。 ユースケース 今日まで、リアルタイムのコンテナランタイムセキュリティは、そのベストプラクティスを実装するオープンソースツールが限られているために、敷居が高いものでした。Kyverno は、API オブジェクトが変更されたときに Webhook イベントを受信するアドミッションコントローラーとしてインストールされます。この記事では、Kubernetes クラスターの管理者が構成を検証および変更する方法を紹介します。これらはすべて、Rego や他の言語を知らなくても可能です。Kyverno は、EKS クラスター上でポリシー管理をシンプルかつ簡単にしてくれます。 前提条件 すでに EKS または類似の Kubernetes クラスターが稼働していることを前提とします。例えば、このリンクをたどって Amazon EKS の使用を開始することができます。注意: k8s クラスターのバージョンは v1.14 以上である必要があります。このバージョンには Webhook のタイムアウトが追加されています。kubectl version を実行して確認してください。 ステップ […]

元の記事：https://aws.amazon.com/blogs/containers/introducing-aws-step-functions-integration-with-amazon-eks/ 本投稿は Romain Jourdanによる記事を翻訳したものです。 私がAWSに入社してからこれが初めてのAWS Container Blogへの投稿となりますが、サーバーレスとKubernetesという2つのテクノロジの融合、具体的にはAWS Step FunctionsとAmazon Elastic Kubernetes Serviceの統合についてお話しできることにこの上なく興奮しています。

この記事は、Introducing the new Amazon EKS console を翻訳したものです。 Amazon Elastic Kubernetes Service (EKS) は re:Invent 2017 にて提供を開始して以来、 Kubernetes を本番環境で利用するユーザーのニーズを満たすように急速に進化してきました。Intel、Snap、Intuit、GoDaddy、Autodesk などのお客様は、セキュリティ、信頼性、およびスケーラビリティの高さを理由に、最も機密性の高いミッションクリティカルなアプリケーションをAmazon EKS 上で実行しています。 Amazon EKS には、Kubernetes のアプリケーションや API リソースの設定を簡単に可視化できるシンプルな方法がありませんでした。問題を特定して調査するには、Kubernetes と AWS 全体を手動で追跡する必要がありました。これらの作業はすべて、特に新しいユーザーにとって、Amazon EKS を始めて、実行するのに多くの時間が必要なものでした。 2020年12月1日、我々は新しい Amazon EKS コンソールを発表できることを嬉しく思います。Amazon EKS では、Kubernetes クラスター、アプリケーション、および関連するクラウドリソースのステータスを単一の場所で確認できます。新しいコンソールを使うことで、お客様は Kubernetes 環境にまつわる情報をすぐに手に入れられるようになり、アプリケーションのさまざまなコンポーネントの依存関係をすべて理解し、適切にデプロイされていることを確認することが容易になります。 Kubernetes クラスターを詳しく見る EKS コンソールは AWS でホストされるため、追加のセットアップや設定は不要です。コンソールを開き、クラスターを選択するだけです。 Overview タブで、クラスターのワーカーノード一覧が表示されていることにまず気づくでしょう。Kubernetes コントロールプレーンから見て、これらのノードは Kubernetes アプリケーションが実行されるコンピューティングリソースです。ノードをクリックすると、Kubernetes API サーバーがこのノードについて知っているすべての情報が、もう少し詳しく表示されます。さまざまなノードをすばやく探索し、関連するEKS のマネージド型ノードグループと、そのノードが表す […]

AWS ソリューションアーキテクトの落水です。Amazon ECS や Amazon EKS をご利用中のお客様同士で情報交換をしていただくイベント「コンテナラウンドテーブル」の第二回が、2020 年 11 月 10 日にオンラインで開催されました。第一回の様子は、こちらの開催報告のブログをご確認ください。第二回では 5 社の企業様にご参加いただき、CI/CD パイプラインやコストの最適化など、いくつかのトピックを設定して情報交換およびディスカッションが行われました。 当日のタイムテーブル 14:00 – 14:35: 情報交換 AWS のコンテナサービスをどのように活用しているのか、各企業様からユースケースをご紹介いただきました。参加者の方からは『他社様の運用実績や課題を知ることができ、とても参考になった』などの声もいただいており、有意義な情報交換が行われました。 14:35 – 15:25: ラウンドテーブル 参加された各企業様には事前にアンケートを回答していただき、ご要望の多かったトピックについてラウンドテーブルを実施しました。ラウンドテーブルには、AWS からソリューションアーキテクトの加治・濱、プロダクトデベロッパーアドボケイトの Tori Hara も加わりディスカッションが行われました。ラウンドテーブルで行われたディスカッションについて、いくつかの内容をピックアップしてご紹介します。  デプロイにおいて課題に感じている点は？ CI/CD パイプラインを構築しているが、ロールバックなど一部のオペレーションが手動になっているため、できれば自動化したい ロールバックについて、アプリケーションの状態が追いやすかったり、管理がしやすい方法があれば知りたい 例えば Amazon ECS では、デプロイに AWS CodeDeploy を利用することで Canary デプロイなどのトラフィックコントロールが可能となるので、トラフィックの切り戻しを含めてパイプラインに組み込むとロールバックの制御がやりやすくなる アプリケーションの状態は、ビジネスに近いメトリクスで健全かどうかを判断するのが望ましい CI/CD パイプラインはどのように構築している？ Amazon ECS は CI/CD が同一パイプラインだが、Amazon EKS は CI […]

AWS ソリューションアーキテクトの落水です。先日、Amazon ECS や Amazon EKS をご利用中のお客様同士で情報交換をしていただくイベント「コンテナラウンドテーブル」が開催されました。「コンテナラウンドテーブル」とは、Amazon ECS 及び Amazon EKS の情報共有を目的として、参加されたお客様における具体的な課題とその解決方法の情報交流を行っていただくイベントです。当日は、8 社の企業様にご参加いただき、コンテナのユースケースや運用上の課題について情報交換やディスカッションが行われました。

Fortnite: Battle Royale, Warframe, そしてApex Legendsなど成功している多くのビデオゲームでは、プレイヤーがゲームの一部に無料でアクセスできる”Free-to-Play”モデルを採用しています。このようなゲームは、もはや低品質なものではなく、プレミアムな品質を必要とします。ビジネスモデルはコストの制約を受けていますが、そのような状況に対してAmazon EC2 スポットインスタンスは実行可能な低コストのコンピューティングオプションを提供します。カジュアルなマルチプレイヤーゲームはもちろん、マルチプレイヤーゲームサーバのワークロードを実行するAmazon EKSコンテナのオーケストレーションではプレイヤーへの影響を最小限に抑え、コストを最適化するメカニズムが必要となりますが、そのような場合にはスポットインスタンスの利用がフィットします。 スポットインスタンスはAWSクラウドの利用可能な予備のコンピュートキャパシティを提供することで、オンデマンドに比べて大幅な割引価格でご利用が可能です。スポットインスタンスによるコストを最適化によって、これまでと同じ予算でアプリーケーションのスループットを最大10倍にまでスケールできます。スポットインスタンスはフォールトトレラント(障害許容)なワークロードに最適です。マルチプレイヤーゲームサーバも例外ではありません。ゲームサーバの状態は、リアルタイムなプレイヤーの入力によって更新され、サーバは一時的な状態を保持します。ゲームサーバのワークロードは使い捨てになることが多く、スポットインスタンスを利用することでコンピュートにかかるコストを最大90%削減できます。このブログでは、スポットインスタンスを効果的に使用するためのゲームサーバワークロードの設計方法について説明します。 ゲームサーバワークロードの特徴 簡単に言えば、マルチプレイヤーゲームサーバは現在のキャラクターの位置と状態(主にアニメーション)を更新するためにほとんどの時間を費やします。残りの時間は、戦闘に関するアクションや移動、その他ゲームイベントに関連する画像の更新に費やされます。具体的にゲームサーバのCPUは、クライアントの位置情報を受信し、ゲームステートを計算し、その情報を特定の複数のクライアントに送信するという処理のためにネットワークI/Oを利用します。以上のことから、ゲームサーバのワークロードはカジュアルなマルチプレイヤーゲームには汎用インスタンスタイプ、ハードコアなマルチプレイヤーゲームにはコンピューティング最適化インスタンスタイプが適しています。 AWSはコンピューティング最適化(C4およびC5)や汎用(M5)をはじめとした多種多様なインスタンスタイプにおいてスポットインスタンスを提供しています。キャパシティはアベイラビリティゾーン内のインスタンスタイプごとに別々に変動するため、幅広いインスタンスタイプを使用することで同じ価格でより多くのコンピューティング能力を得ることができます。スポットインスタンスのベストプラクティスに関する情報はAmazon EC2 Spot Instancesの開始方法をご覧ください。 専用のゲームサーバを実行するためのソリューションの１つとして、Amazon GameLiftがあります。GameLiftはAWSの各リージョンでAmazon GameLift FleetIQやスポットインスタンスをデプロイします。FleetIQはプレイヤーのレイテンシ、インスタンス料金、そしてスポットインスタンスの中断(※)を気にしなくてもいいように中断レート(Interuption Rate)をベースとして新しいセッションをゲームサーバに振り分けます。より詳細な情報はAWS Game Techブログに掲載されている”Reduce Cost by up to 90% with Amazon GameLift FleetIQ and Spot Instances“をご覧ください。 (※)スポットインスタンスは空きリソースを提供している特性上、インスタンス需要に応じて中断されることがあります。詳しくはスポットインスタンスの中断をご覧ください。 その他のケースとして、マルチプレイヤーゲームサーバの展開にKubernetesやSwarm, Amazon ECSなどのコンテナベースのオーケストレーションによるゲームサーバのデプロイメントパターンを利用することができます。これらのシステムは大量のゲームサーバとしてデプロイされた複数のリージョンにまたがるDockerコンテナを管理します。本ブログの残りのパートではコンテナ化されたゲームサーバソリューションにフォーカスします。コンテナは軽量で、高速に起動し、ベースとなるインスタンスの使用率が向上するという特性があるため、ゲームサーバのワークロードに適しています。 なぜAmazon EC2 スポットインスタンスを利用するのか？ スポットインスタンスは、使い捨てのゲームサーバワークロードを実行するための選択肢のひとつです。中断２分前に通知を受け取ることで、中断に備えることができます。インスタンスメタデータとAmazon CloudWatchによる通知処理の例を２つご紹介します。詳しくはこのブログの後半の「中断のハンドリング」および「ゲームサーバを冗長化するためには？」を参照してください。 スポットインスタンスは汎用およびコンピューティング最適化(C4およびC5)などゲームサーバのワークロードに適合するさまざまなEC2インスタンスタイプを提供します。また、スポットインスタンスは低い中断レートを提供します。スポットインスタンスアドバイザーは過去の履歴に基づいて、中断レートの低いインスタンスタイプを選択するのに役立ちます。 中断のハンドリング スポットインスタンスを使用する場合、中断によるプレイヤーへの影響を回避することが重要です。ここでは、GitHub上の”Spotable Game Server“で公開されているリファレンスアーキテクチャとサンプルコードによって、プレイヤー影響を避けるための戦略についてご紹介します。具体的には、Amazon EKSにおける、”kubectl drain”コマンドによるNode Drainageを例として挙げます。これにより、ノードのアンスケジューリング(解除)が可能となり、プレイヤーエクスペリエンスに影響を及ぼす可能性がある終了期間(terminationGracePeriodSeconds)にあるノード上で実行されているpodを削除します。その結果、podは正常に終了するシグナルがゲーム内に送信されている間も可動を続けます。 Node Drainage(ノードのドレイニング) Node […]

By: Alexandr Moroz, Sr. Product Manager, Amazon Route 53; Madhuri Peri, Sr. IoT Architect, AWS Professional Services; Aaron Molitor, Sr. Infrastructure Architect, AWS Professional Services; and Sarma Palli, Sr. DevOps Architect, AWS Professional Services AWS Cloud Mapを利用するとクラウドをマッピングすることができます。Amazon S3のバケットやAmazon DynamoDBのテーブル、Amazon SQSのキュー Amazon EC2やAmazon ECS、Amazon EKSやAWS Lambda上で構成されたカスタムクラウドサービスの様な任意のリソースに対しても分かりやすい名前を定義できます。AWS SDKと認証されたAPIクエリを使って分かりやすい名前にてリソースの場所やメタデータを検出することができます。 デプロイメントステージやバージョンの様なカスタム属性によって、リソースをさらにフィルターし、検出することができます。