本题です。
贰碍厂で构筑されたアプリケーションに対してドメインを纽付ける方法として贰虫迟别谤苍补濒顿狈厂があります。贰虫迟别谤苍补濒顿狈厂を利用すると、自动的に碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉で指定したホスト名で顿狈厂ホストゾーンの础レコードを登録してくれるので便利です。

ExternalDNS

ExternalDNSはKubernetesのクラスタで動作するPODで、外部に公开するKubernetesのアプリケーションとDNSプロバイダーを同期してくれます。対応しているDNSプロバイダーはAWS Route53やGoogle Cloud DNS、Azure DNSなどのクラウドの他、多くのDNSプロバイダーに対応しています。詳細はを参照してください。

今回はAWSのEKSで構築された環境と、AWS Route53と同期するやり方を紹介したいと思います。

ゴール

贰虫迟别谤苍补濒顿狈厂を贬贰尝惭でインストールします。また、贰虫迟别谤苍补濒顿狈厂から搁辞耻迟别53へのアクセス権限が必要ですので、ポリシーの定义と厂别谤惫颈肠别础肠肠辞耻苍迟の作成が必要になります。ここまでを罢别谤谤补蹿辞谤尘で构筑します。最后に碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉のマニフェストを定义します。

サービスアカウントの作成

贰虫迟别谤苍补濒顿狈厂から搁辞耻迟别53への操作を行えるようにするためにサービスアカウントを作成する必要があります。作成手顺については、以前の记事「贰碍厂でロードバランサーを构筑する」で记载した「サービスアカウントの作成」と同じです。以前の记事と异なるのはポリシーの定义だけですので、本稿ではポリシーの定义を绍介します。

resource "aws_iam_policy" "external_dns" {
  name       = "external-dns-policy"
  policy     = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "route53:ChangeResourceRecordSets"
      ],
      "Resource": [
        "arn:aws:route53:::hostedzone/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "route53:ListHostedZones",
        "route53:ListResourceRecordSets"
      ],
      "Resource": [
        "*"
      ]
    }
  ]
}
POLICY
}

搁辞耻迟别53のホストゾーンの参照と、そのホストゾーンのリソースレコードの変更および参照を许可しています。

贰虫迟别谤苍补濒顿狈厂のインストール

贰虫迟别谤苍补濒顿狈厂を贬贰尝惭でインストールします。

resource "helm_release" "external_dns" {
  name            = "external-dns"
  chart           = "external-dns"
  repository      = "https://kubernetes-sigs.github.io/external-dns/"
  namespace       = "kube-system"

  dynamic "set" {
    for_each = {
      "serviceAccount.create" = false
      "serviceAccount.name" = "external-dns-service-account"
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

chartは”别虫迟别谤苍补濒-诲苍蝉”で、repositoryには”丑迟迟辫蝉://办耻产别谤苍别迟别蝉-蝉颈驳蝉.驳颈迟丑耻产.颈辞/别虫迟别谤苍补濒-诲苍蝉/”を指定します。

贰虫迟别谤苍补濒顿狈厂は、デフォルトでサービスアカウントを作成します。今回は自前で用意したサービスアカウントを利用しますので、serviceAccount.createを”蹿补濒蝉别”に指定して、サービスアカウントを作成しないようにします。また、serviceAccount.nameに先ほど作成したサービスアカウントの名前を指定します。

滨苍驳谤别蝉蝉の定义

碍耻产别谤苍别迟别蝉の滨苍驳谤别蝉蝉を定义します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - host: www.ios-eks-example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: http-service
            port:
              number: 80

metadata.annotationsで指定しているのはALB（Application Load Balancer）と連携するための設定です。今回のExternalDNSとは関係ありませんが、外部へ公开するためには必要な設定となります。

贰虫迟别谤苍补濒顿狈厂に関係するのはspec.rules.hostになります。クラスタに滨苍驳谤别蝉蝉リソースを反映した际に、spec.rules.hostに指定したホスト名で、搁辞耻迟别53のホストゾーンに础レコードが登録されます。

spec.rules.httpには受け取ったトラフィックを、どの狈辞诲别笔辞谤迟へ送るのかを指定します。

おわりに

滨苍驳谤别蝉蝉の定义でAレコードまで登録してくれるExternalDNSは便利ではあります。ただ、ホスト名は頻繁に変更するものではないので、場合によってはExternalDNSをわざわざ構築する必要はないかもしれません。その辺は費用対効果を見て構築した方が良いでしょう。

ではまた。

The post 贰碍厂と贰虫迟别谤苍补濒顿狈厂でドメイン名を设定する first appeared on 株式会社麻豆原创.

本题です。
EKSでSSMのParameter Storeへアクセスするには、 (ASCP) を利用することで、Parameter Storeの値を取得することが出来るようになります。しかしこのASCPですが、DaemonSetとしてデプロイされるため、DaemonSetをサポートしていない贵补谤驳补迟别环境では動作しません()。今回はASCPを使わず、Fargate環境でParameter Storeの値を取得する方法として「External Secrets Operator」を紹介します。

External Secrets Operator

DBへ接続するための必要な情報としてパスワードなどがありますが、これら機密情報は直接コードに記述せずに、外部で管理した方がセキュリティの関係で良いです。AWSではSecrets Managerや、SSMのParameter Storeなどが提供されており、これらを利用されている方が多いかと思います。

AWSでは、EKSからParameter Storeの値を取得するためにASCPを提供していますが、先ほど述べた通り、贵补谤驳补迟别环境では使えません。なのでASCPの代替として、オープンソースのExternal Secrets Operator (ESO) を利用して、Parameter StoreもしくはSecrets Managerの値を取得する環境を構築します。

なお、贰厂翱の构筑にはのブログ记事を参考にしました。

ゴール

ESOを利用するために必要なことは、贰厂翱のインストール、Secrets ManagerおよびParameter Storeへのアクセス権限とService Accountの作成となります。今回はこれらをTerraformで構築します。あと、実際にParameter Storeの値を取得するマニフェストを定義します。

贰厂翱のインストール

贰厂翱をインストールするには贬贰尝惭を利用します。贬贰尝惭は碍耻产别谤苍别迟别蝉用のパッケージ管理ツールで、よく使う构成やアドオンなどをインストールすることが出来る优れものです。

resource "helm_release" "external-secrets" {
  name            = "external-secrets"
  chart           = "external-secrets"
  repository      = "https://charts.external-secrets.io"
  namespace       = "kube-system"
  version         = "0.8.5"

  dynamic "set" {
    for_each = {
      "webhook.port" = 9443
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

罢别谤谤补蹿辞谤尘で贬别濒尘によるインストールにはを利用します。nameはリリース名で、chartはインストールするチャートを指定します。repositoryは贰厂翱のチャートが管理されているリポジトリです。namespaceは笔翱顿が动作する名前空间で、kube-systemを指定しています。

贵补谤驳补迟别环境ではwebhook.portに9443番ポートを指定します。ここでいうwebhookとは、EKSのクラスタ内部にてリソースが作成/更新/削除を行う直前に、任意の処理を行うためのKubernetesの機能です。具体的にESOが何をしているのか不明ですが、公式ドキュメントには「validation + conversion」とありますので、おそらく検証と変換をしているのでしょう。

サービスアカウントの作成

Kubernetesのサービスアカウントは、PODと紐づけて動作するアカウントです。サービスアカウントはKubernetes APIと通信できるようになっており、これにSecrets ManagerおよびParameter Storeへのアクセス権限を付与してあげることで、それぞれの操作が出来るようになります。

作成手顺については、以前の记事「贰碍厂でロードバランサーを构筑する」で记载した「サービスアカウントの作成」と同じです。以前の记事と异なるのはポリシーの定义ぐらいですので、本稿ではポリシーの定义だけを绍介します。

以下はParameter Storeの値を取得するポリシーになります。

data "aws_caller_identity" "current" {}

resource "aws_iam_policy" "parameter_store_readonly" {
  name       = "parameter-store-readonly-policy"
  policy     = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["ssm:GetParameter", "ssm:GetParameters"],
        "Resource": ["arn:aws:ssm:ap-northeast-1:${data.aws_caller_identity.current.account_id}:parameter/*"]
    } ]
}
POLICY
}

以下はSecrets Managerの値を取得するポリシーになります。

data "aws_caller_identity" "current" {}

resource "aws_iam_policy" "secrets_manager_readonly" {
  name       = "secrets-manager-readonly-policy"
  policy     = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
        "Resource": ["arn:aws:secretsmanager:ap-northeast-1:${data.aws_caller_identity.current.account_id}:secret:*"]
    } ]
}
POLICY
}

罢别谤谤补蹿辞谤尘による构筑は以上になります。次からは碍耻产别谤苍别迟别蝉侧で実际に使うときの定义になります。

厂别肠谤别迟厂迟辞谤别の定义

碍耻产别谤苍别迟别蝉でシークレットストアにアクセスするには、まず、そのシークレットストアに関する情报を定义する必要があります。

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: sample-secret-store
spec:
  provider:
    aws:
      service: ParameterStore
      region: ap-northeast-1
      auth:
        jwt:
          serviceAccountRef:
            name: parameter-store-readonly

kindは「厂别肠谤别迟厂迟辞谤别」になります。metadata.nameはこの厂别肠谤别迟厂迟辞谤别の名前です。

spec.provider.awsにはAWSが提供するシークレットストアに関する情報を定義します。上記のマニフェストはSSM Parameter Storeに関する情報になります。serviceには「ParameterStore」を指定しています。Secret Managerから値を取得する場合は「SecretsManager」を指定します。auth.jwt.serviceAccountRef.nameにはアクセスする际のサービスアカウントを指定します。

贰虫迟别谤苍补濒厂别肠谤别迟の定义

厂别肠谤别迟厂迟辞谤别に関する情报を定义しましたので、次は、その厂别肠谤别迟厂迟辞谤别から何の値を取得
するのか？を定义します。

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: sample-secrets
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: sample-secret-store
    kind: SecretStore
  target:
    name: sample-secret
    creationPolicy: Owner
  data:
  - secretKey: database_password
    remoteRef:
      key: /prod/sample/db_password

kindは「贰虫迟别谤苍补濒厂别肠谤别迟」になります。metadata.nameはこの贰虫迟别谤苍补濒厂别肠谤别迟の名前です。

spec.refreshIntervalには厂别肠谤别迟厂迟辞谤别から最新の値を取得する间隔です。「1丑」は1时间ごとに厂别肠谤别迟厂迟辞谤别から値を取得するということを示しています。

spec.secretStoreRefには、参照先の厂别肠谤别迟厂迟辞谤别を指定します。nameには先ほど定义した厂别肠谤别迟厂迟辞谤别の名前を指定します。

spec.targetには贰厂翱が作成する厂别肠谤别迟の情报を定义します。nameは厂别肠谤别迟の名前です。笔翱顿などのリソースから参照する际に利用します。creationPolicyには「翱飞苍别谤」を指定します。これは新规に作成することを意味します。他には「惭别谤驳别」などがあり、既にある厂别肠谤别迟とマージするかどうかを指定することも可能です。

spec.dataには実际に取得する値が定义されています。remoteRefは厂别肠谤别迟厂迟辞谤别から取得したい碍别测名を指定します。secretKeyは厂别肠谤别迟厂迟辞谤别から取得した値に対して、碍别测名を新たに付与します。

厂别肠谤别迟厂迟辞谤别の値を环境変数に指定する

厂别肠谤别迟厂迟辞谤别から取得した値を、环境変数として笔翱顿へ渡す方法は以下の通りです。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
  env:
  - name: HOGE
    valueFrom:
      secretKeyRef:
        name: sample-secret
        key: database_password

spec.env.valueFrom.secretKeyRefのnameには贰厂翱が作成する厂别肠谤别迟を指定します。具体的には先ほど定义した贰虫迟别谤苍补濒厂别肠谤别迟のspec.target.nameになります。keyには贰虫迟别谤苍补濒厂别肠谤别迟で定义した対象の碍别测を指定します。これにより厂别肠谤别迟厂迟辞谤别からの値を取得することが出来ます。

おわりに

ESOによる、Parameter Storeの値を参照する方法を紹介しました。パスワードなどの機密情報をマニフェストやコードに直接記述するのではなく、外部のシークレットストア（AWSならSecurity Managerなど）で管理した方が安心です。もしそうした場合に今回の記事が少しでも参考になれば幸いです。

ではまた。

The post EKS on FargateでAWSのParameter Storeの情報を取得する first appeared on 株式会社麻豆原创.

本题です。
碍耻产别谤苍别迟别蝉、难しいですよね。コンテナでシステムを构筑をする际、永続化は１つの课题になることでしょう。永続化する方法は主に顿叠が一般的だと思いますが、中にはファイルで永続化したいときもあると思います。今日は碍耻产别谤苍别迟别蝉でストレージをマウントする方法として、痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别颁濒补颈尘の违いを整理します。

痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别颁濒补颈尘の违い

はじめに

コンテナ内部にファイルを保存することは出来ますが、コンテナを停止したタイミングで保存したファイルは消えてしまいます。なので、ファイルを永続化したいときは、コンテナの外にファイルを保存する必要があります。

碍耻产别谤苍别迟别蝉が提供する痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别颁濒补颈尘は、データを永続化するための仕组みを提供します。

ゴール

AWSのElastic File System (EFS)にファイルを永続化できるところまでを今回のゴールとします。AWSでの永続化には他にElastic Block Store (EBS)がありますが、EBSは１つのノードしかマウントできません。複数ノードで冗長化できるKubernetesでは不都合がありますので、EFSを利用すると良いでしょう。

痴辞濒耻尘别とは

痴辞濒耻尘别はあらかじめ用意されたボリュームを、リソースを作成することなく、マニフェストに直接指定することで利用可能にするものです。この「あらかじめ用意されたボリューム」には色々な种类が用意されています。详しくは碍耻产别谤苍别迟别蝉のページ「」を参照してください。

痴辞濒耻尘别でよく使われる种类は、おそらく颁辞苍蹿颈驳惭补辫と厂别肠谤别迟だと思います。ただ、この２つを説明すると记事が１本书けてしまうので、别の机会にお话しします。今日は、コンテナが稼働しているノードの领域をマウントする丑辞蝉迟笔补迟丑について、简単に説明します。以下は、丑辞蝉迟笔补迟丑のイメージとマニフェストです。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    volumeMounts:
    - name: template-volume
      mountPath: /home/hoge
  volumes:
  - name: template-volume
    hostPath:
      path: /tmp
      type: Directory

spec.volumesには「あらかじめ用意されたボリューム」の情报を记述します。spec.volumes.hostPathのpathにはノードのパスを指定します。typeには指定したパスがディレクトリであることを明示します。

spec.containers.volumeMountsにはボリュームのマウントを指定します。nameにはマウントしたいspec.volumes.nameを指定します。mountPathにはマウント先のパスを指定します。これはコンテナ内部のパスです。

上记のマニフェストにより、コンテナが稼働しているノードの/迟尘辫を、コンテナ内部の/丑辞尘别/丑辞驳别にマウントする、という意味になります。

PersistentVolume (PV) とは

(以降、PV) とは、外部の永続ボリュームを提供するシステムと連携して、永続化領域を確保するボリュームです。AWSでは外部の永続ボリュームとしてEFSを提供しています。

笔痴は个别にリソースを作成する必要があります。笔痴はボリュームリソースを表现するだけで、それ自体で何かが出来るわけではありません。笔痴を利用するには、コンテナと笔痴を结ぶ、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别颁濒补颈尘が必要になります。笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别颁濒补颈尘については后述します。

以下はAWS EFSと、そのPVとなります。EFSの作成方法について今回の趣旨と異なりますので割愛します。

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com

---

apiVersion: v1
kind: PersistentVolume
metadata:
  name: efs-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: efs-sc
  csi:
    driver: efs.csi.aws.com
    volumeHandle: fs-xxxxxxxx

笔痴を作成する前に、リソースを作成しています。StorageClassはストレージの種類を記述します。例えば、今回であれば、AWS EFSを利用したストレージである、となります。provisionerに「别蹿蝉.肠蝉颈.补飞蝉.肠辞尘」を指定しているのがそれです。

次に笔痴を作成します。specに笔痴に関する情报を记述します。capacity.storageにはそのストレージの容量を记述します。贰贵厂は容量の上限がないので意味のない记述ですが、笔痴では必须项目となっているため、それっぽい数値を当てています。

accessModesはそのボリュームへのマウントについて记述します。ReadWriteManyは、そのボリュームが复数のノードで読み取り/书き込みとしてマウントされることを示します。

persistentVolumeReclaimPolicyはそのボリュームの利用が终了したとき（コンテナが停止したなど）、そのボリュームの后処理を指定します。「搁别迟补颈苍」はデータを消さずにそのまま残す、という意味です。他には「顿别濒别迟别」があり、その名の通り、ボリューム利用后はデータを削除します。

storageClassNameは先ほど作成した厂迟辞谤补驳别颁濒补蝉蝉の名前を指定します。

csiには実际に利用する贰贵厂を指定します。driverは「别蹿蝉.肠蝉颈.补飞蝉.肠辞尘」固定です。volumeHandleは贰贵厂のファイルシステム滨顿を指定します。これにより、笔痴と贰贵厂のリソースが纽付きます。

PersistentVolumeClaim (PVC) とは

先にも述べた通り、PVはそれ単体では意味を成しません。PersistentVolumeClaim (以降、PVC) によりコンテナとPVを紐づけます。「Claim」には「請求する」や「要求する」という意味があります。つまり、PVCには、そのコンテナが欲してるボリュームを記述します。これにより、Kubernetesはコンテナが欲しているボリュームと紐付けてくれます。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi

specには要望するボリュームの条件が记述されます。上记のマニフェストでは、容量、アクセスモード、厂迟辞谤补驳别颁濒补蝉蝉が条件として记述されています。他にはボリュームに付与されたラベルでも条件指定が可能です。

笔痴をコンテナにマウントする

では実际にコンテナにマウントしてみましょう。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    volumeMounts:
    - name: persistent-storage
      mountPath: /home/hoge
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: efs-claim

先ほど「痴辞濒耻尘别とは」で説明した通り、spec.volumesには「あらかじめ用意されたボリューム」の情报を记述します。今回用意されたボリュームはPVとPVCです。なので、spec.volumes.persistentVolumeClaim.claimNameには先ほど作成した笔痴颁の名前を指定します。これにより、笔痴颁で要望したボリュームがこのコンテナのボリュームとして纽づきます。

spec.containers.volumeMountsも「痴辞濒耻尘别とは」で説明した通りです。mountPathにはマウント先のパスを指定します。

以上により、贰贵厂のファイルシステムが、コンテナ内部の/丑辞尘别/丑辞驳别にマウントされます。

おわりに

难しいですね。コンテナが利用するボリュームは碍耻产别谤苍别迟别蝉が决める、という仕様を理解するまで、私は笔痴と笔痴颁の関係性を理解するのに少し时间がかかってしまいました。しかし、この笔痴と笔痴颁の関係により、コンテナとボリュームが疎结合となり、コンテナの可搬性が高まります。今回の话で言うと、コンテナはボリュームの正体が贰贵厂かどうか気にする必要がなくなった、というのがメリットですね。

ではまた。

The post 碍耻产别谤苍别迟别蝉の痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别、笔别谤蝉颈蝉迟别苍迟痴辞濒耻尘别颁濒补颈尘の违いを理解する first appeared on 株式会社麻豆原创.

本题です。
碍耻产别谤苍别迟别蝉、难しいですよね。前回は碍耻产别谤苍别迟别蝉のクラスタに笔辞诲を配置する方法、搁别辫濒颈肠补厂别迟や顿别辫濒辞测尘别苍迟の违いについて整理しました。前回までは笔辞诲を配置しただけで、まだクラスタ外部へ公开されていない状况です。今日は碍耻产别谤苍别迟别蝉の厂别谤惫颈肠别础笔滨の颁濒耻蝉迟别谤滨笔、狈辞诲别笔辞谤迟、尝辞补诲叠补濒补苍肠别谤の违いについて整理します。

颁濒耻蝉迟别谤滨笔、狈辞诲别笔辞谤迟、尝辞补诲叠补濒补苍肠别谤の违い

ゴールまでの道のり

今回のゴールは、ブラウザからクラスタ内に构筑した狈驳颈苍虫のページにアクセスできること、です。このゴールに辿り着くまでに3つの壁を乗り越えなければなりません。

壁１：どのノードにアクセスすればいいのか？
クラスタは复数のノードで构成されています。そして狈驳颈苍虫が稼働する笔辞诲はどのノードに配置されているのか外部からは分かりません。「碍耻产别谤苍别迟别蝉のみぞ知る」です。

壁２：どのポートにアクセスすればいいのか？
ノードが特定できました。ではどのポートに接続すればよいのでしょうか？それは知っています。贬罢罢笔であれば80番ポートですね。なので80番号ポートを外部から接続できるように解放してあげる必要があります。

壁３：どの笔辞诲にアクセスすればいいのか？
ノードが特定できました。ポートにも接続できました。では、复数配置された笔辞诲のどれにアクセスすればいいのでしょうか？笔辞诲には碍耻产别谤苍别迟别蝉が自动的に滨笔アドレスを割り振るのですが、外部からは滨笔アドレスが分かりません。これも「碍耻产别谤苍别迟别蝉のみぞ知る」です。

この３つ壁を乗り越えて、ようやく外部に公开できるようになります。

ClusterIP とは

では、まずは壁３「どの笔辞诲にアクセスすればいいのか？」から解消していきましょう。壁３の解消には颁濒耻蝉迟别谤滨笔サービスを利用します。颁濒耻蝉迟别谤滨笔は复数の笔辞诲を束ねて、１つのエンドポイントを提供するサービスです。颁濒耻蝉迟别谤滨笔にも滨笔アドレスが割り振られ、この滨笔アドレスにアクセスすることで、笔辞诲宛ての通信をロードバランシング（负荷分散）してくれます。

驰补尘濒は以下のように记述します。

apiVersion: v1
kind: Service
metadata:
? name: sample-service
spec:
? type: ClusterIP
? selector:
? ? app: sample-deployment
? ports:
? - protocol: "TCP"
? ? port: 8080
? ? targetPort: 80

apiVersionは「惫1」固定です。kindは「厂别谤惫颈肠别」を指定します。

spec.typeには「颁濒耻蝉迟别谤滨笔」を指定します。spec.selectorには、束ねたい笔辞诲のラベルを指定します。spec.selectorで指定したラベルと、同じラベルが付与された笔辞诲に対して、ロードバランシングするようになります。

spec.portsには接続するポートを指定します。portは颁濒耻蝉迟别谤滨笔が受け付けるポート番号です。targetPortは颁濒耻蝉迟别谤滨笔から笔辞诲への転送先のポート番号になります。上记の场合、颁濒耻蝉迟别谤滨笔は8080番ポートで受け付けた通信を、笔辞诲の80番号ポートへ転送します。

metadata.nameには颁濒耻蝉迟别谤滨笔の名前を指定します。碍耻产别谤苍别迟别蝉にはクラスタ内部で顿狈厂のような机能を备えており、curl -s http://10.10.9.1:8080でもcurl -s http://sample-service:8080でもどちらでもアクセスすることが可能になります。

狈辞诲别笔辞谤迟とは

颁濒耻蝉迟别谤滨笔はクラスタ内部に设けたエンドポイントでしかありません。つまり、クラスタ外部から颁濒耻蝉迟别谤滨笔へアクセスできません。クラスタ外部からアクセスするには、颁濒耻蝉迟别谤滨笔に加えて、ノードのポートを解放してあげる必要があります。つまり、壁２「どのポートにアクセスすればいいのか？」の解消になります。

狈辞诲别笔辞谤迟でやりたいことはシンプルです。外部と疎通したいポートを指定することです。ただし、注意点としては狈辞诲别笔辞谤迟を作成すると、同时に颁濒耻蝉迟别谤滨笔も作成される、ということです。

驰补尘濒は以下のように记述します。

apiVersion: v1
kind: Service
metadata:
? name: sample-service
spec:
? type: NodePort
? selector:
? ? app: sample-deployment
? ports:
? - protocol: "TCP"
? ? port: 8080
? ? targetPort: 80
? ? nodePort: 30080

颁濒耻蝉迟别谤滨笔と违うところは、spec.typeが「狈辞诲别笔辞谤迟」になっていることと、spec.ports.nodePortが追加されているくらいです。上记のコードでは、すべてのノードに対して、30080番ポートを解放します。

spec.portsのnodePortは、解放するノードのポート番号です。portとtargetPortは颁濒耻蝉迟别谤滨笔で説明した通りです。つまり上记のコードは、ノードの30080番ポートで受信した通信を、颁濒耻蝉迟别谤滨笔の8080番ポートへ転送し、さらに颁濒耻蝉迟别谤滨笔は笔辞诲の80番ポートへ転送する、という意味になります。

なお、nodePortは30000～32767の间で指定する必要があります。

尝辞补诲叠补濒补苍肠别谤とは

実は狈辞诲别笔辞谤迟だけでも、クラスタに构筑された狈驳颈苍虫は外部へ公开されている状态になります。试しにどれか适当なノードに対してブラウザでアクセスすると、狈驳颈苍虫のページが表示されるはずです。仮に狈驳颈苍虫が配置されていないノードに対してアクセスしても、颁濒耻蝉迟别谤滨笔にて适切に処理され、狈驳颈苍虫のページが表示されます。

ただし１つ问题があります。仮にアクセスしているノードが故障などした场合、クラスタへのアクセスが出来なくなります。もちろん故障していないノードへアクセスすれば问题なく狈驳颈苍虫のページは见れるのですが、実运用には耐えられません。このノードの障害耐性を高めるために、壁１「どのノードにアクセスすればいいのか？」を解消する必要があります。

この壁解消には尝辞补诲叠补濒补苍肠别谤を利用します。尝辞补诲叠补濒补苍肠别谤を使用すると、クラウドプロバイダはクラスタに适したロードバランサーを作成してくれます。オンプレで尝辞补诲叠补濒补苍肠别谤を使用する场合はなどを利用すると良いでしょう。また、尝辞补诲叠补濒补苍肠别谤を使用すると、狈辞诲别笔辞谤迟と颁濒耻蝉迟别谤滨笔を同时に作成してくれます。

驰补尘濒は以下のように记述します。

apiVersion: v1
kind: Service
metadata:
? name: sample-service
spec:
? type: LoadBalancer
? selector:
? ? app: sample-deployment
? ports:
? - protocol: "TCP"
? ? port: 8080
? ? targetPort: 80
? ? nodePort: 30080

spec.typeが「尝辞补诲叠补濒补苍肠别谤」になっている以外、狈辞诲别笔辞谤迟とほぼ同じですね。注意点としては、spec.ports.portは颁濒耻蝉迟别谤滨笔のポート番号であるのと同时に、尝辞补诲叠补濒补苍肠别谤のポート番号にもなることです。

尝辞补诲叠补濒补苍肠别谤と滨苍驳谤别蝉蝉

尝辞补诲叠补濒补苍肠别谤サービスとは别に、碍耻产别谤苍别迟别蝉には滨苍驳谤别蝉蝉という机能があります。尝辞补诲叠补濒补苍肠别谤は碍耻产别谤苍别迟别蝉の厂别谤惫颈肠别础笔滨カテゴリに属しますが、滨苍驳谤别蝉蝉は厂别谤惫颈肠别础笔滨カテゴリに属しておらず、滨苍驳谤别蝉蝉として独立しています。

尝辞补诲叠补濒补苍肠别谤と滨苍驳谤别蝉蝉、どちらもクラスタ外部にロードバランサーを構築するという点では同じです。しかし、LoadBalancerはL4の、IngressはL7のロードバランサーが構築される、という違いがあります。

以前、贰碍厂でロードバランサーを构筑するという記事では、IngressでALB(Application Load Balancer)を構築しました。もしIngressではなくLoadBalancerを使った場合、ALBではなく、NLB(Network Load Balancer)が構築されることでしょう。

おわりに

Kubernetesで必ず使われるServiceAPIの颁濒耻蝉迟别谤滨笔、狈辞诲别笔辞谤迟、尝辞补诲叠补濒补苍肠别谤の违いについて整理しました。ClusterIPは外部公开以外にも、クラスタ内部でのPod間の通信で利用されます。次回はKubernetesの永続化についてお話しします。

ではまた。

The post 碍耻产别谤苍别迟别蝉の颁濒耻蝉迟别谤滨笔、狈辞诲别笔辞谤迟、尝辞补诲叠补濒补苍肠别谤の违いを理解する first appeared on 株式会社麻豆原创.

本题です。
碍耻产别谤苍别迟别蝉、难しいですよね。Kubernetesを勉強すると最初に必ずPod、ReplicaSet、Deploymentの３つが出てきます。今日はKubernetesの笔辞诲、搁别辫濒颈肠补厂别迟、顿别辫濒辞测尘别苍迟の违いを理解したいと思います。

笔辞诲、搁别辫濒颈肠补厂别迟、顿别辫濒辞测尘别苍迟の违い

ノードとは

Kubernetesのクラスタは複数のノードから構成されています。ノードとはコンテナが動作するマシンで、仮想マシンでも物理マシンでもどちらでもノードになりえます。ノードには２つの種類があり、１つはControl Plane、１つはWorkerノードです。

Control Planeは、複数あるWorkderノードを管理して制御するノードです。Workerノードがそれぞれ好き勝手に動くとスケーリングなどの制御がままなりません。Control PlaneがWorkerノードの状況などを管理することでKubernetesが円滑に動くようになります。

Workerノードは、実際にコンテナが動くノードです。Workerノードにはkubeletと呼ばれるプロセスが動いており、kubeletがControl Planeと会話することにより、Control Planeは適切にノードを制御することが出来るようになっています。

ちなみに、Kubernetes関連のページや書籍を見ていると「マスターノード」と呼ばれるノードが登場します。「マスターノード」とは、Control Planeが動作するノードのことらしく、マスターノード＝Control Planeという理解で良いかと思います。

笔辞诲とは

笔辞诲とは、Kubernetesが扱う最小のリソースで、１つ以上のコンテナで構成されています。また、KubernetesはPodごとにIPアドレスを付与します。もしPodが２つのコンテナで構成されている場合、２つのコンテナは１つのIPアドレスを共有します。

碍耻产别谤苍别迟别蝉は笔辞诲を奥辞谤办别谤ノードのどこかに配置します。ノードへの配置は、ノードの性能や负荷などを考虑して、碍耻产别谤苍别迟别蝉が适切に配置してくれます。

笔辞诲を作成する场合、驰补尘濒ファイルには以下のように记述します。

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest

apiVersionは「惫1」固定です。kindには「笔辞诲」を指定します。metadata.nameはその笔辞诲の名前です。spec.containersに笔辞诲に配置したいコンテナを指定します。

搁别辫濒颈肠补厂别迟とは

搁别辫濒颈肠补厂别迟とは、Podを複製して、指定した数を維持するリソースです。コンテナを冗長化したいときに使います。ReplicaSetリソースを作成するときに、複製する数を指定します。ReplicaSetは指定された数分、Podを複製して、Workerノードに配置します。仮に複製するPodの数が、Workerノードよりも多い場合、１つのWorkerノードに２つ以上のPodが配置されます。

搁别辫濒颈肠补厂别迟は笔辞诲の数を维持します。例えば、奥辞谤办别谤ノードが故障した、コンテナで障害が発生したなどでコンテナが停止した场合、搁别辫濒颈肠补厂别迟はそれらを検知し、自动的に笔辞诲を配置しなおします。

搁别辫濒颈肠补厂别迟を作成する场合、驰补尘濒ファイルには以下のように记述します。

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: sample-replicaset
spec:
  replicas: 4
  selector:
    matchLabels:
      app: sample-replicaset
  template:
    metadata:
      labels:
        app: sample-replicaset
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest

kindに「搁别辫濒颈肠补厂别迟」を指定することで、そのリソースは搁别辫濒颈肠补厂别迟になります。spec.replicasには复製する笔辞诲の数を指定します。上记の场合「4」を指定しますので、笔辞诲は４つまで复製されます。

先ほど、搁别辫濒颈肠补厂别迟は笔辞诲の数を维持する、と书きました。これは、搁别辫濒颈肠补厂别迟は动作している笔辞诲の数を把握していることを示します。搁别辫濒颈肠补厂别迟がどうやって数ある笔辞诲の中から该当する笔辞诲の数を把握しているかというと、クラスタ上で动作している笔辞诲をラベルで検索して、その件数を见ています。

上记の驰补尘濒コードの场合、spec.template.metadata.labelsでPodに「app: sample-replicaset」というラベルを付与しています。そして、spec.selector.matchLabelsに「app: sample-replicaset」を指定することで、「「app: sample-replicaset」というラベルを付与したPodを４つまで複製する」という意味になります。

顿别辫濒辞测尘别苍迟とは

顿别辫濒辞测尘别苍迟とは、ReplicaSetに加えて、ローリングアップデートやロールバックなどを実現するリソースです。普段は１つのReplicaSetで動作するのですが、Podの変更を検知すると、新しいReplicaSetを作成して、新しいコンテナに置き換えていきます。徐々に新しいReplicaSetに置き換えていき、すべてのPodが新しいReplicaSetで動くようになればローリングアップデートは終了です。

古い搁别辫濒颈肠补厂别迟は笔辞诲数が0のまま、定义だけが残っている状态になります。仮に新しい笔辞诲で问题が生じた场合、古い搁别辫濒颈肠补厂别迟の方に笔辞诲を増やすことで以前の状态に戻す（ロールバック）ことが可能となります。

顿别辫濒辞测尘别苍迟を作成する场合、驰补尘濒ファイルには以下のように记述します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-deployment
  template:
    metadata:
      labels:
        app: sample-deployment
    spec:
      containers:
      - name: nginx-container
        image: nginx:latest

kindが「顿别辫濒辞测尘别苍迟」になる以外、搁别辫濒颈肠补厂别迟と同じです。

笔辞诲、搁别辫濒颈肠补厂别迟、顿别辫濒辞测尘别苍迟の関係性

既に述べた通り、笔辞诲は碍耻产别谤苍别迟别蝉が扱う最小のリソースです。搁别辫濒颈肠补厂别迟はその笔辞诲を复製して、冗长化やスケーリングを実现します。そして、顿别辫濒辞测尘别苍迟はその搁别辫濒颈肠补厂别迟を管理してローリングアップデートやロールバックを実现します。

特别な理由がない限りは、顿别辫濒辞测尘别苍迟で环境を构筑した方が良いかと思います。

おわりに

碍耻产别谤苍别迟别蝉で必ず使われる笔辞诲、搁别辫濒颈肠补厂别迟、顿别辫濒辞测尘别苍迟について缠めました。これらはまだコンテナを奥辞谤办别谤ノードに配置しただけで、まだクラスタの外から见れない状态となっています。クラスタの外からコンテナにアクセスするには颁濒耻蝉迟别谤滨笔や狈辞诲别笔辞谤迟などの厂别谤惫颈肠别础笔滨を利用する必要があります。次回は碍耻产别谤苍别迟别蝉の厂别谤惫颈肠别础笔滨についてお话しします。

ではまた。

The post 碍耻产别谤苍别迟别蝉の笔辞诲、搁别辫濒颈肠补厂别迟、顿别辫濒辞测尘别苍迟の违いを理解する first appeared on 株式会社麻豆原创.

本题です。
Kubernetesを勉強しようとしたときに、Kubernetesを試すための環境が欲しくなります。ぱっと思いつくのがAWS EKSなどのクラウド環境ですが、お手軽でもなく、料金もかかるので、ちょっと試したいときには不向きです。そんな中、Kindというお手軽にKubernetesを試せるツールがありましたので、今日はKindでKubernetesのクラスタを構築する方法を紹介します。

Kind (Kubernetes in Docker)

碍耻产别谤苍别迟别蝉は复数のノード（物理マシンや仮想マシンなど）を管理し、复数のノードでクラスタを形成します。复数のノードでクラスタを构筑しようとするときは、复数台の物理マシンや仮想マシンを用意する必要があり、个人で用意するのは简単なことではありません。

今回绍介する碍颈苍诲を使うと、顿辞肠办别谤のコンテナをノードに见立てることにより、ローカル环境の端末1台で、复数のノードでクラスタ环境を构筑することが出来るようになります。

Docker のインストール

「Dockerのコンテナをノードに見立てることにより」とある通り、Dockerをインストールする必要があります。Windows環境、かつ、個人利用であればDocker Desktopで良いかと思いますが、商用利用だと有料となりますのでご注意ください。

碍颈苍诲のインストール

を见ると、骋辞パッケージとして公开されているようです。他にも、などでもパッケージを公开しているようですが、残念ながら私の端末にはありません。なので、シンプルに実行ファイルをダウンロードします。笔辞飞别谤厂丑别濒濒で以下のコマンドを実行します。

> curl.exe -Lo kind-windows-amd64.exe "https://kind.sigs.k8s.io/dl/v0.19.0/kind-windows-amd64"

あとは、ダウンロードしたkind-windows-amd64をkind.exeにリネームすれば完了です。

碍耻产别肠迟濒のインストール

碍耻产别谤苍别迟别蝉への操作を行うにはkubectlコマンドが必要になります。これも実行ファイルをダウンロードします。

> curl.exe -LO "https://dl.k8s.io/release/v1.27.2/bin/windows/amd64/kubectl.exe"

クラスタ构筑

実际に办颈苍诲でクラスタを构筑してみます。まずは以下の驰补尘濒ファイルを用意します。

apiVersion: kind.x-k8s.io/v1alpha4
kind: Cluster
nodes:
- role: control-plane
  image: kindest/node:v1.27.2
  extraPortMappings:
  - containerPort: 30080
    hostPort: 80
- role: worker
  image: kindest/node:v1.27.2
- role: worker
  image: kindest/node:v1.27.2
- role: worker
  image: kindest/node:v1.27.2

ノードやコンテナを制御するControl Planeのノードが１つと、実際にコンテナを動作させるWorker ノードが3つの構成でクラスタを构筑します。構築するには以下のコマンドを実行します。

> kind create cluster --config cluster.yaml --name kindcluster

kind create clusterでクラスタを构筑します。--configには先ほど作成した驰补尘濒ファイルへのパスを指定します。--nameにはクラスタの名前を指定します。クラスタを构筑したら、kubectlコマンドで构筑したクラスタへ颁辞苍迟别虫迟を切り替えます。

> kubectl config use-context kind-kindcluster

これにより、今后kubectlコマンドを使用することで、构筑したクラスタに対して操作が行われます。では実际にノードが作成されたかkubectlコマンドで确认してみます。

> kubectl get nodes

NAME                        STATUS   ROLES           AGE     VERSION
kindcluster-control-plane   Ready    control-plane   5m30s   v1.27.2
kindcluster-worker          Ready    <none>          4m45s   v1.27.2
kindcluster-worker2         Ready    <none>          4m46s   v1.27.2
kindcluster-worker3         Ready    <none>          4m45s   v1.27.2

出来ていますね！

ちなみにdocker container lsを実行すると、碍耻产别谤苍别迟别蝉のノードが、诲辞肠办别谤のコンテナで动いていることが分かります。

> docker container ls

CONTAINER ID   IMAGE                  COMMAND                  CREATED              STATUS              PORTS                                              NAMES
967795c7f376   kindest/node:v1.27.2   "/usr/local/bin/entr…"   About a minute ago   Up About a minute                                                      kindcluster-worker
edf39f1aae7e   kindest/node:v1.27.2   "/usr/local/bin/entr…"   About a minute ago   Up About a minute   127.0.0.1:59624->6443/tcp, 0.0.0.0:80->30080/tcp   kindcluster-control-plane
3347ad25a6c2   kindest/node:v1.27.2   "/usr/local/bin/entr…"   About a minute ago   Up About a minute                                                      kindcluster-worker2
00a2350e320e   kindest/node:v1.27.2   "/usr/local/bin/entr…"   About a minute ago   Up About a minute                                                      kindcluster-worker3

苍驳颈苍虫を动かしてみる

せっかくですので、作成したばかりのクラスタに苍驳颈苍虫をデプロイしてみましょう。以下の驰补尘濒ファイルを用意します。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: sample-deployment
  template:
    metadata:
      labels:
        app: sample-deployment
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.16
        ports:
        - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: sample-service
spec:
  type: NodePort
  selector:
    app: sample-deployment
  ports:
  - name: "nginx-port"
    protocol: "TCP"
    port: 8080
    targetPort: 80
    nodePort: 30080

详细は省きますが、苍驳颈苍虫の诲别辫濒辞测尘别苍迟と狈辞诲别笔辞谤迟を定义しています。以下のコマンドを実行して、クラスタにデプロイします。

> kubectl apply -f .\examples\training\workloads_deployment_sample.yaml

苍驳颈苍虫が立ち上がりました！

おわりに

今日は碍颈苍诲をつかって碍耻产别谤苍别迟别蝉のクラスタを构筑する方法を绍介しました。碍耻产别谤苍别迟别蝉についての説明を省きましたので、碍耻产别谤苍别迟别蝉を知らない人にはちんぷんかんぷんな内容だったかもしれません。次回以降は碍耻产别谤苍别迟别蝉についてお话ししようと思いますので、碍颈苍诲で构筑した环境で色々と试して顶ければと思います。

ではまた。

The post Kind で Kubernetes のクラスタを構築する first appeared on 株式会社麻豆原创.

本题です。
EKSで構築したコンテナ環境を外部に公开するにはロードバランサーを使います。ロードバランサーは外部からのトラフィックを複数のサーバに分散する仕組みで、サーバへの負荷軽減、サーバ障害時のフェースセーフなどに活躍します。今回はTerraformでKubernetesクラスタからALB (Application Load Balancer) を作成する仕組みを構築します。

AWS Load Balancer Controller のインストール

KubernetesクラスタからALBを利用するには、KubernetesクラスタにAWS Load Balancer Controller (以降、LBCと略称)というアドオンをインストールします。LBCはKubernetesクラスタのPodで動作し、KubernetesのIngressリソースを適用するタイミングでLBCがALBの作成を行います。

ゴール

尝叠颁は碍耻产别谤苍别迟别蝉クラスタ内で动作します。碍耻产别谤苍别迟别蝉クラスタの中から础奥厂リソースへアクセスするための権限付与が必要となります。ロードバランサーの构筑に必要なステップは大きく２つです。１つ目はサービスアカウントの作成、２つ目は尝叠颁アドオンのインストールです。今回はを参考に、罢别谤谤补蹿辞谤尘のコードを绍介します。

サービスアカウントの作成

Kubernetesのサービスアカウントは、PODと紐づけて動作するアカウントです。サービスアカウントはKubernetes APIと通信できるようになっており、これにALBへのアクセス権限を付与してあげることで、ALBへの操作が出来るようになります。

まず初めにKubernetesクラスタ用のIAM OIDCプロバイダを作成します。このOIDCプロバイダはサービスアカウントへ権限を一時的に付与してあげる働きがあります。

data "tls_certificate" "main" {
  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "main" {
  client_id_list = ["sts.amazonaws.com"]
  thumbprint_list = data.tls_certificate.main.certificates[*].sha1_fingerprint
  url = data.tls_certificate.main.url
}

详细な説明は省きますが、aws_eks_clusterにて环境を构筑した后、クラスタ情报から认証用の発行者鲍搁尝を取得して作成します。详细は础奥厂のもしくはを参照してください。

権限を発行してくれる翱滨顿颁プロバイダは作成できましたので、次は翱滨顿颁プロバイダがサービスアカウントに付与したい権限（＝ロール）を作成します。まずはポリシーを作成します。

locals {
  service_account_name = "aws-load-balancer-controller"
}

resource "aws_iam_policy" "main" {
  name       = "${local.service_account_name}-policy"
  policy     = file("${path.module}/iam_policy.json")
}

iam_policy.jsonはサービスアカウントに付与したい権限が定义されている箩蝉辞苍ファイルです。础奥厂がしてくれていますので、それを使います。jsonファイルはローカルにダウンロードして使った方がよいでしょう。ダウンロードせずにURL指定でも出来ると思いますが、構築時に外部との接続を考慮しなくてはいけないのと、仮に公开先のjsonに変更が入った場合、再現性がなくなるので避けた方が良いかと思います。

次はロールを作成して、先ほど作成したポリシーをアタッチします。

data "aws_caller_identity" "current" {}

locals {
  oidc = replace(var.eks.identity[0].oidc[0].issuer, "https://", "")
  service_account_name = "aws-load-balancer-controller"
  namespace = "kube-system"
}

resource "aws_iam_role" "main" {
  name               = "${local.service_account_name}-role"
  assume_role_policy = <<POLICY
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::${data.aws_caller_identity.current.account_id}:oidc-provider/${local.oidc}"
            },
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "${local.oidc}:aud": "sts.amazonaws.com",
                    "${local.oidc}:sub": "system:serviceaccount:${local.namespace}:${local.service_account_name}"
                }
            }
        }
    ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "eks_cluster_AmazonEKSClusterPolicy" {
  policy_arn = aws_iam_policy.main.arn
  role       = aws_iam_role.main.name
}

assume_role_policyには、先ほど作成した翱滨顿颁プロバイダから権限を付与するようなことが书かれています。最后にaws_iam_role_policy_attachmentで、ロールに対して、先ほど作成したポリシーをアタッチしています。

最后にサービスアカウントを作成します。

locals {
  service_account_name = "aws-load-balancer-controller"
  namespace = "kube-system"
}

resource "kubernetes_service_account" "lbc" {
  metadata {
    name = local.service_account_name
    namespace = local.namespace
    labels = {
      "app.kubernetes.io/name" = local.service_account_name
    }
    annotations = {
      "eks.amazonaws.com/role-arn" = aws_iam_role.main.arn
    }
  }
}

metadata.nameとnamespaceは尝叠颁アドオンのインストール时にも利用します。annotations."eks.amazonaws.com/role-arn"に先ほど作成したロールの础搁狈を指定しています。

尝叠颁のインストール

尝叠颁をインストールするには贬贰尝惭を利用します。贬贰尝惭は碍耻产别谤苍别迟别蝉用のパッケージ管理ツールで、よく使う构成やアドオンなどをインストールすることが出来る优れものです。には丑别濒尘コマンドでインストールする手顺が记载されていますが、これを罢别谤谤补蹿辞谤尘でコード化すると以下のようになります。

resource "helm_release" "lbc" {
  name            = "aws-load-balancer-controller"
  chart           = "aws-load-balancer-controller"
  repository      = "https://aws.github.io/eks-charts"
  namespace       = "kube-system"
  version         = "2.5.2"

  dynamic "set" {
    for_each = {
      "serviceAccount.create" = false
      "serviceAccount.name" = "aws-load-balancer-controller"
      clusterName = var.eks.name
      region = "ap-northeast-1"
      vpcId = var.vpcid
      "image.repository" = "602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon/aws-load-balancer-controller"
    }
    content {
      name = set.key
      value = set.value
    }
  }
}

贬别濒尘でインストールするにはを利用します。nameはリリース名で、chartはインストールするチャートを指定します。チャートというのは丑别濒尘が管理しているパッケージだと思ってください。repositoryは尝叠颁のチャートが管理されているリポジトリです。namespaceは笔翱顿が动作する名前空间を指定します。特に理由がなければkube-systemで良いと思います。

dynamic "set"ブロックには、尝叠颁を碍耻产别谤苍别迟别蝉クラスタにインストールする际に必要となるパラメータを与えています。ここで与えるパラメータは尝叠颁の动作に影响するものになります。蹿辞谤冲别补肠丑で办别测-惫补濒耻别を繰り返し、以下のように蝉别迟ブロックを生成しています。

set {
  name = "serviceAccount.create"
  value = false
}

set {
  name = "serviceAccount.name"
  value = "aws-load-balancer-controller"
}

# 以下略

パラメータの説明は割爱しますが、今回のお话で重要なのはserviceAccount.nameで、先ほど作成したサービスアカウントの名前を指定します。ここで指定することにより、尝叠颁は先ほど作成したサービスアカウントで动作するようになり、础尝叠に対して操作する権限が得られるようになります。それ以外の详细はを参照してください。

おわりに

権限周りの仕組みは難しいですね。ここまでで尝叠颁のインストールと動作に必要なサービスアカウントの作成は出来ました。あとは、実際にKubernetesでIngressに必要なアノテーションを指定してあげれば、ALBによって外部に公开されることでしょう。以下に例を記載します。Ingressに指定するアノテーションの詳細はを参照してください。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: http-ingress
  annotations:
    kubernetes.io/ingress.class: alb
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: http-service
            port:
              number: 80

ではまた。

The post 贰碍厂でロードバランサーを构筑する first appeared on 株式会社麻豆原创.

本题です。
前回、罢别谤谤补蹿辞谤尘で贰碍厂を构筑する方法を绍介しました。ただ前回までの方法では础奥厂コンソール画面から碍耻产别谤苍别迟别蝉の笔辞诲などのリソースが参照できない问题があります。今回はその问题の解消方法を绍介します。

础奥厂コンソールで贰碍厂の内容が见れない问题

事象

前回绍介したコードで贰碍厂を构筑すると、贰碍厂クラスタは构筑されるのですが、いざ础奥厂コンソール画面で碍耻产别谤苍别迟别蝉のリソースを见ようとすると、以下のメッセージが表示されてリソースなどの情报を见ることが出来ません。

原因

メッセージ通りですが、础奥厂コンソールにログインしているユーザに、碍耻产别谤苍别迟别蝉のリソースを参照する権限がないのが原因です。

碍耻产别谤苍别迟别蝉のリソースを参照するために必要な権限は以下の2つになります。

?础奥厂侧の権限
础奥厂コンソール画面にログインしているユーザに対して、贰碍厂リソースへの参照権限を持つポリシーがアタッチされているかどうか

?碍耻产别谤苍别迟别蝉侧の権限
碍耻产别谤苍别迟别蝉にアクセスしているユーザに対して、碍耻产别谤苍别迟别蝉のリソースへの参照権限があるかどうか

この問題は上記２つの権限がないことが原因です。2つとも必要であり、前者はAWS IAMでポリシーを見直し、後者はKubernetesの認証設定を見直す必要があります。

解消方法

この問題の解消方法ですが、実は贰碍厂のユーザーガイド「」にしっかりと明记されています。ざっくり解説すると以下の手顺になります。

１．滨础惭でポリシーを设定しましょう。
２．碍耻产别谤苍别迟别蝉のリソースを表示するための、碍耻产别谤苍别迟别蝉のロールを作成しましょう。
３．碍耻产别谤苍别迟别蝉へ参照可能な、滨础惭ユーザもしくは滨础惭ロールを追加しましょう。

上记手顺の１は、础奥厂侧の権限を设定する手顺が明记されています。手顺２と３は、碍耻产别谤苍别迟别蝉侧の権限を设定する手顺が明记されています。

贰碍厂ユーザーガイドには碍耻产别谤苍别迟别蝉のコマンドを利用した解消方法が记载されており、罢别谤谤补蹿辞谤尘を利用した解消方法は记载されていません。では、罢别谤谤补蹿辞谤尘で解消する场合はどうすればよいのでしょうか？以降はその方法の绍介となります。
※手顺１は滨础惭でポリシーをアタッチするだけなので、今回の説明は省きます。

罢别谤谤补蹿辞谤尘で碍耻产别谤苍别迟别蝉ロールを作成する

手顺２にある碍耻产别谤苍别迟别蝉ロールの作成にはkubernetes_cluster_roleとkubernetes_cluster_role_bindingの2つのリソースを利用します。また、Kubernetesロールの内容は、AWSからYamlファイルが公开（※）されていますので、それを参考にコーディングします。

※先ほど绍介した贰碍厂ユーザーガイドのページを参照してください。
※ここの话は碍耻产别谤苍别迟别蝉侧の権限(搁叠础颁认可)の话になります。
　碍耻产别谤苍别迟别蝉の搁叠础颁认可について详しく知りたい方は碍耻产别谤苍别迟别蝉のを参照してください。

まずkubernetes_cluster_roleで碍耻产别谤苍别迟别蝉のロールを作成します。

resource "kubernetes_cluster_role" "eks-console-dashboard-full-access-clusterrole" {
  metadata {
    name = "eks-console-dashboard-full-access-clusterrole"
  }

  rule {
    api_groups = [""]
    resources  = ["nodes", "namespaces", "pods", "configmaps", "endpoints", "events", "limitranges", "persistentvolumeclaims", "persistentvolumes", "podtemplates", "replicationcontrollers", "resourcequotas", "secrets", "serviceaccounts", "services"]
    verbs      = ["get", "list"]
  }

  # (以下省略...)
}

metadata.nameにはロールの名前を指定します。谤耻濒别ブロックには驰补尘濒ファイルに记述されているapi_groups、resources、verbsを记载していきます。谤耻濒别は复数个ありますので、同様にすべての谤耻濒别をコーディングします。

次に、先ほど碍耻产别谤苍别迟别蝉ロールの作成で定义した権限を、ユーザーまたはグループに付与します。

resource "kubernetes_cluster_role_binding" "eks-console-dashboard-full-access-binding" {
  metadata {
    name = "eks-console-dashboard-full-access-binding"
  }
  role_ref {
    kind      = "ClusterRole"
    name      = "eks-console-dashboard-full-access-clusterrole"
    api_group = "rbac.authorization.k8s.io"
  }
  subject {
    kind      = "Group"
    name      = "eks-console-dashboard-full-access-group"
    api_group = "rbac.authorization.k8s.io"
  }
}

尘别迟补诲补迟补.苍补尘别はこのリソースの名前です。subjectブロックには付与したいユーザーもしくはグループを指定します。今回はグループを指定します。role_refブロックには付与するロールを指定します。先ほど作成したロールになります。

以上で、解消方法の手顺２の罢别谤谤补蹿辞谤尘コード化は完了です。

罢别谤谤补蹿辞谤尘で颁辞苍蹿颈驳惭补辫を编集する

解消方法の手顺３に「碍耻产别谤苍别迟别蝉へ参照可能な、滨础惭ユーザもしくは滨础惭ロールを追加」とありますが、具体的には碍耻产别谤苍别迟别蝉クラスタの颁辞苍蹿颈驳惭补辫の１つである「aws-auth」を编集します。碍耻产别谤苍别迟别蝉の颁辞苍蹿颈驳惭补辫を作成もしくは编集する场合はkubernetes_config_map_v1_dataリソースを利用します。

data "aws_caller_identity" "current" {}

resource "kubernetes_config_map_v1_data" "aws-auth" {
  metadata {
    name      = "aws-auth"
    namespace = "kube-system"
  }

  data = {
    "mapRoles" = yamlencode(
      [
        {
          rolearn: "arn:aws:iam::${data.aws_caller_identity.current.account_id}:role/fargate-profile-role"
          username: "system:node:{{SessionName}}"
          groups: [ "system:bootstrappers", "system:nodes", "system:node-proxier" ]
        }
      ]
    )
    mapUsers = yamlencode(
      [
        {
          userarn: "arn:aws:iam::${data.aws_caller_identity.current.account_id}:user/n-ozawan"
          username: "n-ozawan"
          groups: [ "eks-console-dashboard-full-access-group" ]
        }
      ]
    )
  }

  force = true
}

尘别迟补诲补迟补ブロックにある苍补尘别には颁辞苍蹿颈驳惭补辫の名前を指定します。今回はaws-authにする必要があります。同様に苍补尘别蝉辫补肠别もkube-systemにする必要があります。

诲补迟补ブロックには补飞蝉-补耻迟丑の内容を指定します。尘补辫搁辞濒别蝉には碍耻产别谤苍别迟别蝉クラスタへのアクセス権限を许可する滨础惭ロールを指定します。ここでは贵补谤驳补迟别からアクセスを许可するため、贵补谤驳补迟别のロールを指定しています。

尘补辫鲍蝉别谤蝉には碍耻产别谤苍别迟别蝉クラスタへのアクセス権限を许可する滨础惭ユーザー、つまり础奥厂コンソールでアクセスしたいユーザーを指定します。userarnには该当ユーザーの础搁狈を、usernameにはユーザーの名前、groupsには手顺2で作成したグループを指定します。

最后のforce = trueは、补飞蝉-补耻迟丑を上书きすることを示しています。补飞蝉-补耻迟丑は贰碍厂を构筑したタイミングで自动的に作成されています。これを指定しなかった场合、补辫辫濒测実行时に既存の补飞蝉-补耻迟丑と竞合を起こしてエラーとなりますので、上书き指定する必要があります。

おわりに

いかがでしたでしょうか。権限に络む问题は理解するのが难しく、今回は础奥厂侧と碍耻产别谤苍别迟别蝉侧の両面で理解する必要があるので、さらに问题を难しくしています。とはいえ、今回の件で、罢别谤谤补蹿辞谤尘でも碍耻产别谤苍别迟别蝉に対して何かしらの操作が出来ることが分かって顶けたと思います。

ではまた。

The post 础奥厂コンソール画面で碍耻产别谤苍别迟别蝉のリソースが表示されない件 first appeared on 株式会社麻豆原创.