EKSクラスターへのアクセス制御は、設定する場所が複数に分かれているなど、少々分かり辛いところがあるかもしれません。できるだけ分かり易く解説してみます。 みなさん、こんにちは！ AWS事業本部の青柳＠福岡オフィスです。 今回は、Amazon EKS における「クラスターへアクセスする際の認証・認可」について解説したいと思います。 はじめに みなさんは、EKSクラスターを構築して「kubectl」コマンドで最初にアクセスする際に、どのような手順を実施しているでしょうか？ eksctlコマンドを使用してクラスターを構築する場合は、特に何もすることなく、すぐにkubectl get nodes等のコマンドを使ってクラスターへアクセスできると思います。 また、マネジメントコンソールやAWS CLIを使用する場合は、クラスター構築を行ったIAMユーザーでaws eks update-kubeconf
以前の記事でも紹介した通り、一休では、gRPCを使ったサービスを導入し始めています。 user-first.ikyu.co.jp この記事では、このサービスをAmazon EKSで提供するための設計や気をつけたポイントについて紹介します。 背景 一休では、ウェブアプリケーションの実行環境としてAWS Elastic Beanstalkを採用しています。 そして、この4月からElastic BeanstalkをAmazon EKSへ移行するプロジェクトを進めています。 このgRPCサービスもElastic Beanstalkで運用をしていましたが、以下の問題を抱えていました。 適切にロードバランシングできない。 Elastic BeanstalkでgRPCサービスを運用しようとするとNetwork Load Balancer(NLB)を使うことになります。NLBはレイヤ4のロードバランサです
こちらはAmazon EKS #1 Advent Calendar 2019 7日目の記事です。 EKSでIAM RoleをUserAccountに紐付けたり、ServiceAccountをIAM Roleに紐付けたりする際、AWSのドキュメントに従って設定してはいるものの、その設定によって実際にどんな処理が行われているかを具体的に知らない方も多いのではないでしょうか？(私も今回の記事のために調べるまではそうでした。) そこで今回の記事では、Kubernetesの認証認可の仕組みを解説したあと、AWSのIAMの認証情報をKubernetes内のUserAccountに紐付けるaws-iam-authenticatorの動作の仕組みとKubernetesのService AccountにIAM Roleを紐づける仕組みについて設定方法のレベルから一段掘り下げて実際の動作に焦点を当てながら説明
こんにちは、スタディサプリ ENGLISH SRE グループの巻田です。 現在リクルートの夏アルバイトとしてこのチームに所属しています。 この記事では EC2 上に構築された EKS クラスタの CronJob のみを Fargate 上で実行できるようにするための方法を紹介します。 はじめに スタディサプリ ENGLISH ではインフラに EKS を採用しています。Kubernetes には CronJob1)https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/ と呼ばれる機能があり、ジョブを定期的に実行することができます。スタディサプリ ENGLISH ではこの機能を使って様々なバッチ処理を実行しています。 Fargate を導入したい背景 スタディサプリ ENGLISH で使用している EKS は元々
EKS on Fargate こんにちは。 サイバーエージェントの青山（@amsy810）です。 この記事は Kubernetes3 Advent Calendar の 4日目の記事です（EKS #2 にもクロスポストしています）。 re:Invent で EKS 関連の何かしらの発表がされることを見越して Advent Calendar を埋めたので、書くネタが見つかってホッとしています。 KubeCon 会期中に 「Managed Worker Node for EKS」 がリリースされ歓喜の声が上がりましたが、今回は re:Invent で 「EKS on Fargate」 がリリースされ歓喜の声が上がっているようです。 今回は EKS on Fargate のアーキテクチャを見ていきたいと思います。virtual-kubelet と近いと思ってますが果たして。 （EKS on Fa
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? プロダクションで EKS on Fargate を(できるだけ)使うことを目標に EKS on Fargate に入門します。 Managed Node Groupとの使い分けなどについてもまとめます。 ※ 本記事は 2019/12/14 時点の情報に基づいています。 Fargate、EKS on Fargateとは FargateはAWS上で「仮想マシンの管理なしにコンテナをデプロイできるサービス」です。 元々はAWS独自のコンテナオーケストレーションシステムであるECSの一機能と思われていましたが、EKS on Fargateが登場
Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介 | Amazon Web Services
Amazon Web Services ブログ Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介 本投稿は Micah Hausler と Michael Hausenblas による記事を翻訳したものです AWS ではお客様のニーズに最優先にフォーカスしています。Amazon EKS におけるアクセス権制御に関して、みなさまは「パブリックコンテナロードマップ」の Issue #23 にて EKS でのきめ細かい IAM ロールの利用方法 を求められていました。このニーズに応えるため、コミュニティでは kube2iam、kiam や Zalando’s IAM controller といったいくつかのオープンソースソリューションが登場しました。これらのソリューションは素晴らしいプロダクトであるだけでなく、それぞれのアプローチの要件及び制約は何なのか
Istioとは Istioは、サービスメッシュを実現するために用いられるソフトウェアです。各マイクロサービスと一緒にSidecar Proxyと呼ばれるプロキシをデプロイし、Sidecar Proxy経由で他のマイクロサービスとの通信を行います。Istioでは、Sidecar ProxyとしてLyft社が作成したEnvoyを採用しています。 Istioは、アプリケーション側で特に修正を加えることなく使えるという特徴があります。例えばKubernetes環境の場合、サービスをデプロイすると、IstioによってPod内にSidecar Proxyが自動的に配置されます。Init Containersという機能を使い、Sidecar Proxyを経由するようにiptablesのルールが書き換えられます。こうすることで、アプリケーションの変更なしでSidecar Proxy経由でのマイクロサービス
Cloud Providers are a powerful concept in Kubernetes that provide cloud specific extensions. On AWS, Kubernetes Services of type LoadBalancer are a good example of this. We have documentation on LoadBalancer Services for the Giant Swarm platform. These should also work for most vanilla Kubernetes clusters. In this post, we’ll share some use-cases we’ve seen from our customers. This includes some a
Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey. 簡単な説明 Amazon EKS は、次の 2 つのコントローラのうちの 1 つを使用してロードバランサーを管理します。 AWS ロードバランサーコントローラーまたは Kubernetes サービスコントローラー。以下のトラブルシューティング手順は、Kubernetes サービスコントローラーによって管理されるロードバランサーにのみ適用されます。詳細については、Kubenetes AWS クラウドプロバイダーのウェ
Help us improve the AWS re:Post Knowledge Center by sharing your feedback in a brief survey. Your input can influence how we create and update our content to better support your AWS journey. 解決策 ワーカーノードを Amazon EKS クラスターに参加させるには、以下の手順を実行します。 **重要:**以下の手順には、以下の条件が満たされない環境にワーカーノードを登録するために必要な構成は含まれていません。 クラスターの仮想プライベートクラウド (VPC) では、設定パラメータ domain-name-servers が AmazonProvidedDNS に設定されています。詳細については、「Am
Kubernetesの導入を検討するにあたって、エラーの状況確認から解決に至るまでのオペレーションは押さえておくべき事柄だ。まだ導入に至っていない場合はこういう問題が発生するのかと雑に感じてもらい、導入している場合は問題を解決する際の参考にしてもらえればと思う。 当エントリでは、自分が遭遇した失敗のケースについて原因と解決方法を列挙する。尚、経験ベースなので同じエラーがでても場合によっては別の原因や解決方法があるかもしれない。また、記載したログや設定ファイルのリソース名や値などは適当にマスキングしているので適宜読み替えてほしい。 どのようなタイミングでポッドが起動しなくなるか Kubernetesはポッドが落ちた際に自動的にポッドを再起動するなどのマネジメントを行ってくれる。ただし、ポッドを初めて作る際や、構成を変えたポッドやレプリケーションコントローラをローリングアップデートする際に、誤
概要 自分のkubernetesの理解促進のために、kubernetes（とAWS EKS）に関することをざっとまとめています kubernetesとは ものすごく雑にいうと、複数コンテナのオーケストレーションを管理するためのシステムであり、リモート環境上で複数コンテナに対してdocker-composeみたいに管理できる代物 wiki曰く、 コンテナ化したアプリケーションのデプロイ、スケーリング、および管理を行うための、オープンソースのコンテナオーケストレーションシステム Kubernetesの目的は、「ホストのクラスターを横断してアプリケーションコンテナを自動デプロイ、スケーリング、操作するためのプラットフォーム」を提供することとされている Docker単体では、複数のDockerコンテナ群（マイクロサービスの集まり）を管理するのが難しいという欠点があるので、個々のDockerコンテナ
スマートキャンプの入山です。 Kubernetes（k8s）を運用されている方々は、Podに受け渡す機密情報をどうやって管理していますか？ k8sでの機密情報の管理といえばSecretリソースが一般的ですが、Secretリソースを管理する上では以下のような課題に悩む方が多いのではないでしょうか？ SecretはBase64エンコードのみなので、内容が確認できれば簡単にデコードできてしまう SecretリソースのマニフェストにBase64エンコードのみの機密情報を含むため、GitHubなどにそのままコミットするのは危険 これらの対策として、kubesecやSealed Secretsなどを利用して暗号化を行う方法が主流だと思いますが、今回は外部のKMSなどに保存した機密情報をk8sに直接受け渡すことが可能なKubernetes External Secretsについて、EKSとAWS Sec
まとめ 秘密情報をEKS上で楽に管理したい。 これまでは秘密情報を暗号化したファイルを使って注入してた 変数ごとに何が変更されたかを確認するのが面倒 AWS KMSで暗号化してたのでAWS CLIのインストールのためにPythonを入れるのが微妙 KubernetesのSecretをそのまま使うのは避けたい Base64してるだけで暗号化してない k8sの権限の強い人からは見えてしまう 環境変数の値だけを暗号化してPod内で複合 リポジトリに読める形でコミットできる 追加・変更されたか否かのレベルでなら確認できる Pod以外は複合できないためマルチテナントなk8sだと権限管理が楽 shushならバイナリ一個入れるだけですむ GKEに移っても実装できそうな規模なのでなんとかなりそう。 欠点もある バイナリを一個置く必要がある entrypoint/commandの変更が必須 起動時に暗号化し
アソビュー！SREチームの霧生です。 この記事はアソビュー！ Advent Calendar 2019 13日目の記事となります。 アソビューでは最近一部のアプリケーションのインフラにEKSを導入しています。 その運用をしていく中でDBのuser/passやAPIキーといった機密情報を隠蔽したい要件が出てきました。 ECSでは下記のClassmethodさんの記事にある通り、タスク定義とパラメータストアによる隠蔽ができますが、EKSではまだ公式で対応していないためどうしようかと悩んでいたところ、kubernetes-external-secretsを見つけました。 dev.classmethod.jp kubernetes-external-secretsとは kubernetes-external-secretsはドメインレジストラサービスを提供しているGoDaddy社がOSSとして公開
Amazon EKS ワーカーノードの謎を解くクラスターネットワーク | Amazon Web Services
Amazon Web Services ブログ Amazon EKS ワーカーノードの謎を解くクラスターネットワーク AWS で Kubernetes を実行するには、AWS のネットワーク設定と Kubernetes のネットワーク要件の両方を理解する必要があります。デフォルトの Amazon Elastic Kubernetes Service (Amazon EKS) の AWS CloudFormation テンプレートを使用して、Amazon Virtual Private Cloud (Amazon VPC) と Amazon EC2 ワーカーノードをデプロイすると、通常の場合、すべて機能します。しかし、設定に小さな問題があると、エラーが発生してイライラさせられることがあります。 このブログでは、Amazon VPC を設定するさまざまな方法を見ながら、Amazon EKS が
みんなのウェディングのインフラエンジニア横山です。 今回は、既存VPCを流用したEKS環境の構築手法について書きます。 みんなのウェディングのEKS環境について みんなのウェディングでは現在、インフラ基盤のEKS移行を進めています。 EKS環境を作成する場合、通常は以下のようにeksctlやCloudFormationを利用します。 https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/getting-started.html しかしながら、eksctlを使って構築した場合、今後リソースの内容を更新したいときにeksctlを使い続けることになります。 弊社ではインフラ構成管理に既にterraformを使っています。先々の運用を考えると、使うツールは必要最小限にしておきたいところです。 また、CloudFromtaionを使った場合、新
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Accessing Amazon RDS From AWS EKS
