EKS Workshop で EKS と k8s を学ぶ

WorkshopのGitHubリポジトリはこちら

https://github.com/aws-samples/eks-workshop-v2

勉強用環境は us-west-2 リージョンを使う。 ap-northeast-1 では動作確認が取れていないらしいので。

cloudshellを使って cloudformationのマニフェストファイルをダウンロードし、AWS の Web IDE C
loud9 を起動する。
このCloud9には workshopで起動する サンプルアプリケーションのマニフェストファイルが含まれている

以降は このCloud9を使って作業を行う。Cloud9のTerminalからも必要なコマンド実行が行える

ちなみにこのCloud9のIDEを起動するための EC2インスタンスが作成されているので、CloudFormationのStackから最後に削除を行うのを忘れないこと

aws cloudformation delete-stack --stack-name eks-workshop-ide

これは cloudshell から行ったほうが良さそう

マニフェストを見ていると Node の インスタンスタイプは EC2になりそう？ manageNodeGroup を指定した場合はそうなりそう。
また設定内容を見ると、ノードインスタンスは３つ作られて最大で６つなる模様。 クラスタが作られたら確認する

30分以上かかったせいか、タイムアウトエラーが発生した。

ただ クラスターは作られていてドキュメントに書かれている以下は作成・設定されていた

• Create a VPC across three availability zones
• Create an EKS cluster
• Create an IAM OIDC provider
• Add a managed node group named default
• Configure the VPC CNI to use prefix delegation

気になるのはNodeGroup と Nodeが一つも作られていない点。一旦削除してもう一度作成してみる

https://www.eksworkshop.com/docs/introduction/setup/your-account/using-eksctl#cleaning-up-steps-once-you-are-done-with-the-workshop

再度実行したけどエラーになった。 CloudFormationを見ると ManagedNodeGroupの作成時にこんなエラーが出ている

Resource handler returned message: "[Issue(Code=NodeCreationFailure, Message=Instances failed to join the kubernetes cluster, ResourceIds=[i-0485edbb6659be70d, i-064255470e0c74cdb, i-0f1c9a7b0e7fbe49b])] (Service: null, Status Code: 0, Request ID: null)" (RequestToken: fee2af60-033b-58e4-04ac-547ec84e63f3, HandlerErrorCode: GeneralServiceException)

途中の経過などを見ているとNode用の EC2インスタンスなども３台起動していたりしているんだけど、NodeGroupからEC2インスタンスへのアクセスができなかった？？

AssumeRole 関連でこんなイベントログが頻発していた。確かに us-west-2 なんて普段使わないから STSのactivateはしていない

STS is not activated in this region for account:************. Your account administrator can activate STS in this region using the IAM Console.

というわけで、 IAM -> Account settings で、 US West(Oregon) の STS status を Active にして再チャレンジ

お、正常にクラスタ作成が終わった

NodeGroup はできているけど、Nodeは設定されていない。
けど Node用と思われる EC2インスタンスは３台起動している

NodeやResourceがAWS コンソールから見られないのは AWS の権限設定が不足しているからな模様

下記に従って実施すればよさそうだが、3-b の my-console-viewer-role と eks-console-dashboard-full-access-group に何を指定するべきかすぐに見つからなかったので保留

https://docs.aws.amazon.com/eks/latest/userguide/view-kubernetes-resources.html#view-kubernetes-resources-permissions

見れた。

roleを作っていなかったので自分のIAMユーザーに対して権限を付与した。

1. eks に対するアクセスを許可するpolicy については、今回はフルアクセスを持っていたので省略
2. eks-console-full-access.yaml を apply したので、 eks-console-dashboard-full-access-group が group指定になる
3. マッピングは Userを指定した。 (本来の運用は user指定ではなく roleとするべき）

サンプルアプリケーションは、どうも go, java17, nodejs で提供されているみたいだけど、今回のWorkshopでは deployment.yaml を読む限り java アプリケーションのように見える。
しかも healthcheck を見ていると Spring-bootじゃないかな。actuatorってのも見えた

上書き前提の場合は、公式のように baseディレクトリとoverlaysディレクトリを並べる感じなのね

https://github.com/kubernetes-sigs/kustomize

ところで、resources の listは リソースの依存関係を考慮した順番にするべきなんだろうか？
サンプルアプリの kustomaization.yaml はそんな感じの並びに見えるんだけど、調べても 実行順に関する説明が見当たらない

「ServiceリソースをNLB」として割り当てる

正確には type: loadBalancer の Service を宣言した場合に、AWSのNLBを割り当てる。 type: loadBalancer は クラスタ外からのトラフィックを受ける場合に利用されるリソース。

Introductionで使った、type: ClusterIP は クラスタ内のトラフィックを受ける場合の標準的なリソース

まずは AWS Load Balancer Controller をインストールする。これは Helm chat を利用する

バージョンは現時点での最新 2.8.1 を使う
https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.8/

と思ったんだけど実行すると 2.8.1は存在しない。って出力されるので --version を指定せずにインストールした

devopskokmr:~/environment $ helm upgrade --install aws-load-balancer-controller eks-charts/aws-load-balancer-controller --namespace "kube-system"   --set "clusterName=${EKS_CLUSTER_NAME}"   --set "serviceAccount.name=aws-load-balancer-controller-sa"   --set "serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"="$LBC_ROLE_ARN"   --wait                                                                                  
Release "aws-load-balancer-controller" does not exist. Installing it now.
NAME: aws-load-balancer-controller
LAST DEPLOYED: Sun Jul  7 07:42:14 2024
NAMESPACE: kube-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
AWS Load Balancer controller installed!

でここまでの serviceリソースは ClusterIP を使っていたので、これを Loadbalancer Controller を利用して AWS NLB （type: loadBalancer) に変更する
まず既存のServiceリソースに追加する形で、nlb用のリソースを用意する。（元のServiceのtypeを上がくのではなく新たにリソースを作る）これはkustomizationがすでに用意されているのでこれをapplyする

ポイントかどうかわからないけど、元の ClusterIP の場合 targetPort(podにアクセスするポート）は、 deployment.yaml で宣言している port ディレクティブで name: http, containerPort: 8080, protocaol: TCP で定義していて、Serviceの方では この http を指定しているが、 変更後は Serviceのマニフェストでも 8080 を直接している。この違いはなんだろう？

とにかくリソースを作り、 kubectl get svc -n ui を実行すると service リソースが２つ作られるが、今作った ui-nlb の方は external-ip としてDNSが用意されている。
つまりこのALBには外部からアクセスするためのpublicIP が提供されていることになる

また AWS コンソールで ALBを見るとNLBが作成されていることと、targetGroupとしてクラスタノードである３つのEC2インスタンスが指定されている

これで今 UI には ClustIP と Loadbalancer の 2つのServiceリソースにつながっており、生成されたIPでブラウザからアプリケーションを表示することができる

現在のNLBは instance mode と呼ばれる ノードインスタンスをターゲットにしたモードになっている。これをインスタンスではなく podの IP を指定する IP mode に変更することができる。
これはノードを Fargateにした時に便利。（EC2インスタンスでも使える）
https://www.eksworkshop.com/docs/fundamentals/exposing/loadbalancer/ip-mode

次に Ingress リソースを作る
これもあらかじめ用意されている kustomizeで新規リソースとして生成する

しばらくすると Loadbalancer と同じく ブラウザからアプリケーションを表示できる様になる。

ちなみに ingressリソースのマニフェストはこんな感じ
healthcheck-path として /actuator/health/liveness が指定されているのでやっぱりSpring Bootアプリかな

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

リクエストパスによって、振り分けルールを複数用意する場合に、ingressリソースのマニフェストをサービスごとに用意して ALBとしては統合することができる。

その場合それぞれの ラベル group.name で同じグループを指定すればよく、workshopだと catalog APIへのアクセス用のリクエストパスも用意している

ちなみに AWS が出力する IP は apply する度に変わるのね

ちなみに AWS が出力する IP は apply する度に変わるのね

実際のアプリケーションなら ドメインを取得して、ALBもしくはCloudFrontにプロビジョニングして使うと思うので、その場合の使い方がわからないな

アノテーションの alb.ingress.kubernetes.io/schema を internet-facing から internal にすると 内部だけに制限されるっぽい。
ただこの後、alb に dns をプロビジョニングしたり、cloudfrontからこのalbに接続させる必要がありそう

targetGroupBinding というリソースを使う方法もある？ この場合は ingressリソースを作ってpodに接続するのではなく、別途ALBを用意してtargetGroup と このリソースを紐づけるのかな？
https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.7/guide/targetgroupbinding/targetgroupbinding/

k8sの外部公開に関しては色々な方法があるんだと理解した。以下自分が認識したServiceとIngress と 各Typeの概念（上手く言語化できていないので間違っているかも

• Service : ReplicaSetで冗長化したPodのIP/Portに対してロードバランシングを行う（L4）
  • ClusterIP: k8sクラスタ内に公開される仮装IP
    • ExternalIP: クラスタ外からアクセスするためにノードに対する外部 IP/Portを公開する
  • NodePort: k8s の 全ノードに対して外部 IP/Portを公開する
  • LoadBalancer: k8sクラスタ外のLoadBalancerを利用してクラスタのPodにアクセスする
    • 今回のworkshopで言うと、AWS の Load Balancer controller を 利用して AWS NLB を作成し、指定したクラスタ内の Service (type: ClusterIP) への ルーティング を行っている
    • インターネットに公開されているのは この AWS NLB の
• Ingress: クライアントからのリクエストホストやパス、クライアントIPを元にロードバランシングを行う（L7
  • AWS や GCP の ALB サービス のような クラスタ外のロードバランサを利用する
    • 今回の workshop だと AWS Load Balancer controller を 利用して AWS ALB を作成する。Ingress Resource (マニフェスト） を元に ALB の ルールとターゲットが生成される。
    • ターゲットには クラスタ内の Service (type: ClusterIP) が指定される
    • インターネットに公開されているのは この AWS ALB の IP だと考えている
  • クラスタ内に ingress を設置することもできる
    • 代表的なのは Nginx-ingress や Traefik (トラフィック) などがある
    • クラスタ内に用意するので、クラスタ外からアクセスするために この ingress に対する Serviceは必要になる
      • 要は Ingressなんだけど クラスタ内に podを Deployment(ReplicaSet)で作成し、このReplicaSetを外部公開するためのServiceも必要になるということ。これに AWS NLB が必要になったりする

上記は、Service(LoadBalancer) と Ingress のどちらにおいても リソース（マニフェスト）で、AWS の ELB (NLB/ALB) を管理することになる。

課題として実際のインフラ設定を考えると、この ELB の IPに対して DNSでドメインを割り当てる。あるいは前段に CloudFrontを用意する場合は Distribution の一つとして ELBリソースを指定するのだが、AWS ではなく k8sリソースで制御すると リソースが変わって更新する度に DNS や CloudFron の Distributionの再設定が必要になる。

このため、AWS ELB は k8s の 管理外にし、ELB の Target Group と に対して k8s リソースを紐づける Target Group Binding というカスタムリースを使うと、k8s側のService リソースが変わっても Target Group と Service を紐づけてくれる模様。

ここの Persistent Volume について勘違いしてて 永続化ボリュームはPod と 1 対 1 に紐づいている模様(永続化はしているのでPodが削除されても残る) また、accessModes が ReadWriteOnce になっているので この Podからしか書き込みも読み込みもできないらしい。
※厳密にもノードに対して 1対1なので 同一ノードにPodが複数あればそれらのPodからはアクセスできる。

となると気になるのは Database のようなStorageとして使う場合に ReplicaSetで複数ノードにPodを配置してしまうとPodごとにデータが変わってしまうのではないだろうか？
accessMode は 他には ReadOnlyMany(複数Pod/nodeからの読み込みは可能） や ReadWriteMany(複数Pod/nodeからの書き込み・読み込みが可能) があるが、ReadWriteMany は EKSではサポートしていないという記述もあり。。。

まぁ実際にはAWSを使っている場合は DatabaseもRDSを使うから別にいいけど、Podに紐づく Persistence Volume であることは意識しておきた

あと、ここではDynamic Provision を用いて 自動的に EBS Volumeを作成しつつ Podに割り当てている。
StatefulSet の場合は Podごとに Volumeを割り当てるので、Dynamic Provision を用いると Podを生成するタイミングで PersistenceVolumeClaimを発行するタイミングで該当するPVを作成してくれるらしい

考え方は同じじゃなかった。 EBS (StatefulSet) の場合は StatefulSet リソースとして Volume を volumeClaimTemplates に置き換えることで、Persistence Volume としてEBS を用意して、PersistenceVolumeClaim によって StatefulSet の VolumeをPVに置き換える形で割り当てていた。
さらにDynamicProvisionによってStatefulSetのPodに対するPVを自動作成する様にしていた

対して EFSを使った場合は、上記と異なる

• PVは全Podで共有のものを使うので DynamicProvisionによってPodごとにPVを自動作成しない様にする
• このため予め StorageClass を 事前に定義し 単一のEFS Volumeを宣言しておく
• PersistenceVolumeClaimリソースも事前に用意し、ここで宣言したStorageClassを紐づけておく
• Deploymentでは PodのVolum Specとして 前述のPersistenceVolumeClaimを指定しておく

こうすることで、DynamicProvisionを使ってPodにPVを割り当ててもマニフェストで指定した共通のPV（EFS)が割り当てられる様になる

ちなみにこれは EBS と EFS の違いというよりは、 StatefulSet と Pod の違いという意味でもある。
StatefulSet は 名前の通り 状態をもつPodのため、元々データの永続化を意識しているので VolumeClaimTemplate というSpec Template項目が用意されている。

対して Podにはデータ永続化に対するSpec項目が無いので、Volume Specとして PersistenceVolumeClaim を定義している

なおAWSにおけるEBSとEFSの使い分けとして、EBSはVolume Blockとして EC2インスタンスにアタッチする形を取るので、StatefulSetの永続化ボリュームとして相性が良い。(だから Fargate では利用できない？)
EFSはサーバーレスのNFSで Node とアタッチするという考え方ではなくネットワークを通してアクセスする共有ストレージとして利用ができる (だからFargateでも利用ができる？）

次の様に アノテーションを検出することで podの リソースが確認できる

kubectl get pod -n checkout -l app.kubernetes.io/component=service -o json | jq -r '.items[0].metadata.annotations'

{
  "CapacityProvisioned": "0.25vCPU 1GB",
  "Logging": "LoggingDisabled: LOGGING_CONFIGMAP_NOT_FOUND",
  "prometheus.io/path": "/metrics",
  "prometheus.io/port": "8080",
  "prometheus.io/scrape": "true"
}

これらのリソースはマニフェストで変更することができる

もちろん Replicaの数も変更できる

次は Podのロギング。
デフォルトでは Nodeの /var/logs にログが出力されるらしい。これをCloudwatchに出力する方法を学ぶ

今回はFluentBitをDaemonsetで使うことで ノードレベルで podのログを収集する
で AWS 向けの FluentBitイメージがありそれを使うのだが、なんかこの章を始めるときに行った設定で事前に Daemonsetが作成されていた。この辺も実際に動かしたかったなぁ

さらに ConfigMapも追加で作成されており、/var/log/containers/*.log に出力されたログが CloudWatch にも出力される様になっていて logGroup /eks-workshop/worker-fluentbit-logs-vLHNPp から確認できる
この時点ではアプリケーションにアクセスしていないのでログは出力されない。

代わりにアプリへのアクセスではなくて、ui podの再作成によってui アプリのフレームワークであるSpring Bootの起動ログをpodのログとしてCloudwatchに出力する

再起動の方法はマニフェストファイルを更新しないので apply は使わずに、pod を deleteした後に deployment を 再度 rolloutする
このあと、kubectl logs -n ui deployment/ui を実行するとコンソールにログが出力される

Cloudwatchでは ロググループ /aws/eks/fluentbit-cloudwatch/workload/ui にこの時の起動ログが出力される

うーんちょっと消化不良だが次に進む

Fargate の場合、FluentBit をベースにしたログルータが利用できるそう
これを有効にするには専用のConfigMapを適用すれば良い。
このConfigMapでは FluentBit の INPUTセクションはデフォルト値が利用され変更不可らしい。つまりFagate内に出力されたログを FILTER と PARSER, OUTPUT を定義するだけで良いみたい

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/fargate-logging.html

今回は Metrics 部分のみの話になっている。
このあとは Logについては収集する模様

ちなみにここでスクレイピングしていたメトリクスは Cluster全体のものになる。次は PodレベルのMetricsも取得する

例えば ReadOnlyなRoleを用意し、access-scope として Cluster全体や 特定のnamespaceだけに絞る。そのRoleを使って delete や 異なるNamespaceのPodを参照しようとするとforbidden とすることができる

また Roleリソースとして定義し bindingすることでも同様の制御ができる

従来だと ConfigMapリソースとして aws-auth を用意することで アクセス制御ができていたがこれは非推奨になっており今後は access-policy を用いて制御すること

Service Accounts と IAM Role

Service Account に IAM Role を割り当てることで、EKSのPodから AWSの 各種サービスへのアクセスを許可させることができる？

サンプルアプリの cartsサービスは AWS DynamoDBにアクセスしてCart情報を保存する。このため PodからDynamoDBへのアクセスが必要。

ワークショップでの実験として初期状態では Carts Namespace の ConfigMap で DynamoDBにアクセスするための AccessKeyやエントリポイントが定義されていてそれを元にCartsPodから接続していたがConfigMapの定義からこれらの接続設定を無くしたことでアクセスできない様にした
エラーログを見ると、これまではDynamoDBにアクセスできるRoleにAssumeしていた様だが、AccessKeyが参照できなくなったことでAssume Role が出来なくなった。DynamoDB側ではアクセスを許可されていないRoleで接続しされたので400エラー(AccessDenied)としている

ここから Service Account に IAM Role を付けていくが、そのためには IAM OIDC Identity Provider を作成して クラスタに割り当てる必要がある。
今回はすでにこのProviderは作成済み。

また DynamoDBにアクセスして読み書きするためのPolicy と IAM Role も用意されている。 このIAM Role には 信頼できる関係として OIDC プロバイダが割り当たっており これにより Assume Role が 可能な状態になっている。
そこで cart に割り当てられている Service Account に この IAM Roleをアサインすることで OIDC プロバイダ経由で DynamoDBにアクセスするためのRoleをAssumeする

Service AccountにIAMロールをアサインしたら deployment を リスタートする

結果として AccessKeyの設定を必要とせずにDynamoDBへのアクセスができる様になった

Amazon EKS Pod Identity

OIDC provider ではなく EKS Pod Identity という機能を使ってアクセス権を付与するのかな？
さっきと同じく Cart サービスと DynamoDB の接続を利用するので まずはAccessKeyをConfigMapから除去しDynamoDBへ接続できない状態にする

今度は eks-pod-identity-agent を アドオンとして EKS クラスタにインストールする。インストールすると kube-system name spaceに eks-pod-identity-agent が daemonSetリソースとして作成される。

あとは DynamoDBにアクセスするPolicy を持つ IAM Role に 信頼する関係として Pod Identity を用いてこのRoleにAssumeする権限をつける
そしてこのRoleを Service Account に付与する。

Service Accout に IAM Roleを付与するのは変わらず、AssumeRole を付与する実行者(Principal)が OIDC Provider か Pod Identity かの違いの様に見えた

Secrets Management

k8s の Secret Resource は センシティブなデータを Key - Value を管理するが 実仕様を考えると以下の様な課題がある

• Manifest には Key - Value な値を定義する必要がある。Gitで管理するとこのような情報が漏れる
• EKS コンソール 上では 値は Base64でエンコードされて表示されるが、容易にDecode出来てしまう

そこで、Secretリソースを用いるのではなく AWS の Secret Manager を使って センシティブ情報を EKS クラスタ外で管理させる試み

外部に格納したSecretにアクセスするための Kubernetes Secrets Store CSI Driver があるが、AWSにはこのための `AWS Secrets and Configuration Provider (ASCP) が提供されている。
これをDaemonSet リソースとして作成することで 各ノードからSecret Managerに接続できる様にする
（Secrets Store CSI Driver は 専用のNamespaceで作成され、ASCPは kube-system namespace に作成される）

CSIドライバーが SecretManagerに アクセスするために 専用の SecretProviderClass リソースを作成し、この中で アクセスするSecretオブジェクトを指定する。SecretのKeyは複数指定することができる。
作成した SecretProviderClass と CSI ドライバー を利用するように Deployementを修正することでSecretManagerから値を参照できる様になる

AWS Secrets and Configuration Provider (ASCP) とは別に External Secrets Operator (ESO) という仕組みがある

これは SecretManagerにアクセスできる Service Account と そのServiceAccountからアクセスできる ClusterSecretStore リソースを用意する。
この ClusterSecretStoreをDeploymentで指定することで、専用のServiceAccountのRoleでSecretを取得できる様になる
大きな違いはわからないけど、こうすることで 複数のPodから同じSecretを参照したいときに指定しやすいのかも

Amazon GuardDuty for EKS

GuardDuty は AWSアカウント、ワークロード、S3内に格納されたデータを保護し、脅威の検出を定期的にモニタリングしてくれる。また、CloudTrail Event, VPC Flow Logs, DNS Logsから ネットワークのアクティビティを分析も行ってくれる

EKSに対してGuardDutyが保護してくれることについて確認をする。
EKSに対しては 監査ログのモニタリングと 実行時のモニタリングすることでEKSクラスタを保護する

GuardDutyはAWS コンソールから有効にする。今回は EKS Protectionを有効にする。30日間はフリートライアルが可能らしい
ワークショップの説明とちょっと変わっていて、EKS Protection では Audit Log のモニタリングのみ有効にでき、Runtimeのモニタリングは Runtime Monitoring から有効にする。ただRuntime MonitoringでEKSを有効にしても CoverageにClusterが出てこないのは謎

k8sクラスタには amazon-guardduty namespace に agent Podが生成されている

この状態で あえて kube-system namespace に生成した Pod でコマンドを実行すると 監査対象のKubeSystemPod内での実行ログが検出されGuardDutyに取り込まれる（反映まで少々時間が掛かる）

他にも DefaultのService Acountへのアクセスや EKS クラスタダッシュボードが公開されていたりするとGuardDutyで検知される

またRuntimeモニタリングだと例えば default Namespaceで crypto コマンドなどを実施すると検知される

細かい設定はできないが セキュリティ強化を考えたときには 設定しておきたいサービスではある

Pod Security Standards

Pod Secruity Standard(PSS) は、セキュリティに関する３つの異なるポリシーを定義することで幅広くカバーすることを目的としている

• Privileged(特権)
• Baseline(基準）
• Restricted(制限)

また Pod Security Admission(PSA) によって ３つのモードで それぞれのPSSポリシーを実装する

• enforce (強制)
• audit (監査)
• warn (警告)

ここからサンプルアプリケーションを使ったNetworkポリシーの設定に入る。
サンプルアプリのデフォルでは 各サービスごとにNamespaceで区切ってはいるものの サービス間の通信は特に制限なく行える。 例えば、catalog サービスから checkout サービスへのアクセスができたり。
ただサンプルアプリのアーキテクチャとしては、ユーザーとの窓口になる UIサービスを介してバックエンドの各サービスと通信をするが、バックエンドサービス間は checkout -> Orders 以外は通信が不要
な構成

Egress 制御

まずは Podから外部への通信を制御する。サンプルアプリの UI サービスからの通信を制御してみる
この マニフェストは、適用するPodを制限していないのでUIを含む全てのPodに対して適用される。また Egress の定義だが 許可するものものない。つまりこのマニフェストを UI Namespace に対して apply すると UI Namespace内の 全ての Podに対して 別のPodへの通信ができなくなる

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels: {}
  policyTypes:
    - Egress

kubectl apply -n ui -f ~/environment/eks-workshop/modules/networking/network-policies/apply-network-policies/default-deny.yaml
これで UI Namespace内の全てのPodからの通信がブロックされた

ここから UI の pod に対して、 ラベルに service を付けた Pod あるいは kube system namespace への通信のみ許可する マニフェストで applyする

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: ui
  name: allow-ui-egress
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: ui
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
          podSelector:
            matchLabels:
              app.kubernetes.io/component: service
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system

なお、このマニフェストでは metadata.namespace で ui を指定しているので、applyで -n ui を指定しなくても UI Namespace以外には適用されない。さっきの denyの方は マニフェストでは Namespaceが指定されていなかったので、 apply 時に指定していた

これにより、service ラベルがついた、 catalogサービスのPodにはアクセスできる様になった。 ただし catalog の 背後にある DB Pod (MySql) には service ラベルが付与されていないので 直接 アクセスはできないまま。 また 外部インターネットのWebページなどにもアクセスではできない

Ingress 制御

次に Ingress の設定を学ぶ
Catalog Namespace において Catalog サービスは UI ネームスペースからの通信のみ許可する。また Catalog データベースは Catalog サービスからの通信しか許可しない

今は、Catalogサービスは UIサービスだけでなく、orders などのui 以外のサービスからの通信も許可された状態

ここで Catalog Namespace に対して、 ui namespace の uiラベルが付与された Podからのアクセスのみを許可する NetworkPolicy をapplyする

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: catalog
  name: allow-catalog-ingress-webservice
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: catalog
      app.kubernetes.io/component: service
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ui
          podSelector:
            matchLabels:
              app.kubernetes.io/name: ui

これで ui 以外の Namespace からの通信が遮断された
ただこれは、ingress(inbound) の対象が catalog service だけであり、 catalog database はまだ他のnamespaceから通信できる状態なので catalog database に対しても ingress を設定し、catalog service からの通信のみ許可する

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: catalog
  name: allow-catalog-ingress-db
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: catalog
      app.kubernetes.io/component: mysql
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app.kubernetes.io/name: catalog
              app.kubernetes.io/component: service

このあと ネットワークのデバッグ方法についてのセクションがあり、Pod内のログを見る方法が説明されているが見られなかったのでスキップ

ただこの実験からわかることとして、許可するサービスを指定する場合は PodだけでなくそのNamespaceも一緒に指定しないとダメな模様

podを再起動（今のPodを削除して rollout を自動実行）する...

Pod を削除すると Rolloutが実行される理由だけど、 Deploymentリソースである deployment/catalog で Replicaに指定したしたPod数を維持しようとするので、Podを削除することで rollout によるPodの再作成が行われると理解している

ただなんで checkout service と checkout redis がそれぞれ 別の private subnet に割り当てられたのかが不明。

今度は buildspec.yml を使って、component の Docker Image を build し ECRにPushさせる。
必要なファイルを更新して 先ほどと同じように CodeCommitへPushすると CodePipeline が実行されてイメージビルドが始まる。 実行開始するまで数分かかる。

で、ECRにイメージができていたので、これを使ってデプロイをしてみる。
ここで deployeするDocker Imageを更新したときに GitOpsが走りpodが更新される様にFluxで 対象のImageReposity, ImagePolicy, ImageUpdateAutomation の各マニフェストを設定しておく

ここでブラウザでサンプルアプリを表示しタイトルを確認する。
このタイトルを変更して再度コミット・Pushを行う

CodePipelineでイメージをビルドしてPushした後、しばらくすると自動的にImageが更新されており、ブラウザをリロードするとタイトルが変わった

FluxCD と Flux って同じものを指しているっぽいな
Fluxについては公式サイトも見たほうがより理解ができそう

https://fluxcd.io/

なんとなく、ArgoCDの方がFluxより簡単そうに見えなくもないが どうなんだろ？？

Argo CD の公式
https://argoproj.github.io/cd/

お仕事では Argo Rollouts を使って Blue-Green Deployment を実施している
https://argoproj.github.io/rollouts/