落とし穴に立て札を立てるが如く

ハマりどころの解決が少しでも早くなることを願って書いていきます

コンテナランタイムcontainerdでKubernetesを立ち上げるには

こちらの記事はcloud.config tech blogにもマルチポストします。

はじめに

前回の記事では、kubeadmを用いてKubernetesクラスターを立ち上げる方法を確立できたのでそれを記事にしました。
今回はその中で大の一つであった、コンテナランタイムとしてcontainerdを使用してKubernetesを立ち上げる方法が確立できたので記事として残しておきます。

環境

今回使用している環境はAWSのEC2としています。
主な設定は以下の通りです。
- name: kubernetestest-dev-app-controlplane
image: Canonical, Ubuntu, 24.04 LTS, amd64 noble image build on 2024-04-23
instanceType: t3.small
パブリックIPの自動割り当て: 有効化

手順

  1. containerdをインストール
sudo apt-get update  
sudo apt-get install -y containerd  
sudo mkdir -p /etc/containerd  
containerd config default | sudo tee /etc/containerd/config.toml  
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml  
sudo systemctl restart containerd  
sudo systemctl enable containerd  
  1. IPv4フォワーディングを有効化し、iptablesからブリッジされたトラフィックを見えるようにする
    こちらでかいせつされているとおり、設定の変更を行います。
    この設定を行わないとkubeadmの起動時にpreflightチェックでエラーを起こすので注意です。
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf  
overlay  
br_netfilter  
EOF  
  
sudo modprobe overlay  
sudo modprobe br_netfilter  
  
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf  
net.bridge.bridge-nf-call-iptables  = 1  
net.bridge.bridge-nf-call-ip6tables = 1  
net.ipv4.ip_forward                 = 1  
EOF  
  
sudo sysctl --system  
  1. kubeadmのインストール、軌道
# Kubernetesのインストール  
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg  
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list  
sudo apt-get update  
sudo apt-get install -y kubelet kubeadm kubectl  
sudo apt-mark hold kubelet kubeadm kubectl  
  
# Kubernetesの起動  
sudo kubeadm init --pod-network-cidr=10.0.0.0/16   

動作確認

kubectl get nodes -o wideコマンドを実行すると、以下のようにコンテナランタイムの名前付きでノードの情報が表示されます。
コンテナランタイムがcontainerdになっています、やったね!(この環境ではCNIも仕込んだためNodeの状態がReadyになっています、コンテナランタイムを仕込んでKubernetesを立ち上げただけの状態だとNot Readyとなります)

おわりに

今回の記事では、コンテナランタイムとしてcontainerdを使用してKubernetesを立ち上げる方法を解説しました。
これと前回の記事と合わせて、最新のパッケージを用いてマシンにKubernetesを仕込む方法が確立できたかと思います。
マシンにkubeadmでKubernetesを仕込む方法が確立できていれば、Kubernetesの新しいバージョンが発表されてもEKSやAKSが対応するのを待つことなく新しいバージョンの機能に触れることができるので、個人的にできるようになりたかったことの一つです。
同じようなことがやりたい方がこの記事を読んでいるのかなと思います、そんな方の助けになれば幸いです。

参考

AWS EC2でkubeadmを用いたKubernetesクラスターを作ってみたのでメモ

こちらの記事はcloud.config tech blogにもマルチポストします。

はじめに

Kubernetesって動かすと楽しいじゃないですか。
でも、Kubernetesで遊ぼうと思ったら普段はローカルでRancher Desktopからシングルノードのクラスターをワンボタンで作ったりEKSやAKSでマネージドなクラスターを作ったりするのですが、それではちょっと物足りないこともあります。
例えば最新のバージョンのKubernetesを使ってみようとしたら、前述の方法だとどれもすぐには対応していなくて、最新バージョンに対応するのを待つ必要があります。
そのためいつでも最新のバージョンのKubernetesを試せるように、ついでにマルチノードの構成で立ち上げるようにするためにAWS EC2の中にkubeadmでKubernetesを立ち上げ、クラスターを構成する方法を確立しておこうと試みたので今のところ確立できている方法をメモしておきます。
そのうちもっといい方法が確立できるかもしれないのでその時はその時で別途記事にしようと思います。

今回の構成

今回作成した構成は以下のような形です。
Control Plane Nodeが1台、Worker Nodeの数は2台にしましたが実際はお好みで。
コンテナランタイム: runc
CNI: Cilium

作成したリソース

EC2
- name: kubernetestest-dev-app-controlplane
image: Canonical, Ubuntu, 24.04 LTS, amd64 noble image build on 2024-04-23
instanceType: t3.small
keyPair: 新規作成
VPC: kubernetestest-dev-pvc
サブネット: kubernetes-dev-subnet
NSG: kubernetestest-dev-nsg
パブリックIPの自動割り当て: 有効化
- name: kubernetestest-dev-app-worker
image: Canonical, Ubuntu, 24.04 LTS, amd64 noble image build on 2024-04-23
instanceType: t3.micro
keyPair: 新規作成
VPC: kubernetestest-dev-pvc
サブネット: kubernetes-dev-subnet
NSG: kubernetestest-dev-nsg
パブリックIPの自動割り当て: 有効化

インスタンスサイズは、Control Plane用のインスタンスではメモリとCPUがそれぞれ2GiBと2v必要なためt3.smallとしています。
Worker Node用では最低限で構わないのでt3.microにしています。
また、今回は学習用リソースとして作成しているため、インスタンスにローカルから直接sshするためにパブリックIPの自動割り当てを有効にいています。

VPC
- name: kubernetestest-dev-vpc
IPv4 CIDR: 10.0.0.0/16

Subnet
- name:
VPC: kubernetestest-dev-vpc
IPv4 Subnet CIDR: 10.0.0.0/16

Route Table
- name: kubernetes-dev-rtb
VPC: kubernetestest-dev-vpc
routes:
- to: 10.0.0.0/16
target: local
- to: 0.0.0.0/16
target: kubernetestest-dev-igw

IGW
- name: kubernetestest-dev-igw
VPC: kubernetestest-dev-vpc

NSG
- type: ssh
source: 0.0.0.0/0
- type: customTCP
source: 0.0.0.0/0
port: 6443
- type: customTCP
source: 10.0.0.0/16
port: 10250

NSGではこちらを参考に許可する通信を規定しています。
本当はControl PlaneとWorker Nodeで要件は異なりますが、今回はひとまとめにしています。
ssh用の22番、API Serverへのアクセス用の6443番、Kubernetes Nodeのkubelet間のやりとりのための10250番ポートを開放してあります。
特に10250番はクラスター内部の通信であるため、通信元は同じVPC内部に限定しています。

実行したコマンド

リソースが一通り作成できれば、EC2 Instance Connect等を用いてインスタンスssh接続します。
Control Plane NodeとなるEC2インスタンスでは起動後に以下のコマンドを実行してコンテナランタイム、Kubernetes、CNIをインストールしています。
実行時は先にControl Plane Nodeのコマンドから実行してください。

# Dockerのインストール  
sudo apt-get update  
sudo apt-get install -y apt-transport-https ca-certificates curl  
sudo apt-get update  
sudo apt-get install -y docker.io  
  
# Dockerの開始  
sudo systemctl start docker  
sudo systemctl enable docker  
  
# Kubernetesのインストール  
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg  
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list  
sudo apt-get update  
sudo apt-get install -y kubelet kubeadm kubectl  
sudo apt-mark hold kubelet kubeadm kubectl  
  
# Kubernetesの起動  
sudo kubeadm init --pod-network-cidr=10.0.0.0/16  
  
# kubeconfigのコピー  
mkdir -p $HOME/.kube  
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config  
sudo chown $(id -u):$(id -g) $HOME/.kube/config  
  
# CNIのインストール  
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)  
CLI_ARCH=amd64  
if [ "$(uname -m)" = "aarch64" ]; then CLI_ARCH=arm64; fi  
curl -L --fail --remote-name-all https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}  
sha256sum --check cilium-linux-${CLI_ARCH}.tar.gz.sha256sum  
sudo tar xzvfC cilium-linux-${CLI_ARCH}.tar.gz /usr/local/bin  
rm cilium-linux-${CLI_ARCH}.tar.gz{,.sha256sum}  
cilium install  

Worker NodeとなるEC2インスタンスでは以下のコマンドを実行しています。KubernetesのインストールコマンドまではControl Plane Nodeと同様です。
クラスターに加入するコマンドは、Control Plane Nodeの立ち上げ時に最後のほうでkubeadm join ~~~といった形で表示されるのでそれをそのままWorker Nodeで打ち込んでください。

# Dockerのインストール  
sudo apt-get update  
sudo apt-get install -y apt-transport-https ca-certificates curl  
sudo apt-get update  
sudo apt-get install -y docker.io  
  
# Dockerの開始  
sudo systemctl start docker  
sudo systemctl enable docker  
  
# Kubernetesのインストール  
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg  
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list  
sudo apt-get update  
sudo apt-get install -y kubelet kubeadm kubectl  
sudo apt-mark hold kubelet kubeadm kubectl  
  
# Kubernetesクラスターに加入  
sudo kubeadm join <Control PlaneノードのプライベートIP>:6443 --token <トークン> --discovery-token-ca-cert-hash sha256:<hash値>  

動作確認

各ノードでコマンドを実行し、成功していれば以下のような出力が得られるかと思います。
Control Plane Nodeでkubectl get nodeを実行

どこのノードでもsudo docker infoコマンドを実行すると現在使用しているDockerのバージョンやコンテナランタイムが表示されるかと思います。

Todo

このクラスターではまだメトリクスサーバーがインストールされていません。
そのためkubectl topコマンドやHPAが使えません。
スケーリングの動きを確かめようと思ったらこのあたりの機能が使える必要があるので、また今度インストールも試してみます。

今回動作確認が取れたコンテナランタイムはruncで、しかもそのためにインストールしたパッケージは少し古めのdocker.ioでした。
推奨されるコンテナランタイムはcotainerdかcri-oなのですが、今回は動作確認が取れなかったので今度動作することを確認したいと思います。

また、今回はEC2やネットワーク系のリソース、Kubernetesのインストール等を手動で行っていますが、1コマンドでできたほうが楽なので今度Terraform化を試してみます。

おわりに

今回は勉強がてらEC2でKubernetesクラスターをkubeadmベースで作成してみました。
この方法が確立できていれば後でいろいろ検証するのに役立ちそうに思います。
ただ、今回はそれなりに苦労した割に妥協した点も多くあるので、これからもっと構成を洗練させていければと考えています。
自分と同様にKubernetesクラスターをkubeadmベースで作ってみたいという方の助けになれば幸いです。

Ambassador で Mapping の apply 時にエラーが起きる時は

こちらの記事はcloud.config tech blogにもマルチポストします。

シンプルな答え

apply 時に出力されるエラーが以下のようなパターンであれば内部の証明書の期限が切れているので、いくつかコマンドを実行して証明書を更新してください。

Error from server: error when creating "<リソース名orマニフェスト名>": conversion webhook for getambassador.io/v3alpha1, Kind=Mapping failed: Post "https://emissary-apiext.emissary-system.svc:443/webhooks/crd-convert?timeout=30s": tls: failed to verify certificate: x509: certificate has expired or is not yet valid: current time yyyy-mm-ddThh:mm:ssZ is after yyyy-mm-ddThh:mm:ssZ  

証明書更新には以下のコマンドを順に実行します。
大抵の場合コマンドは決め打ちで大丈夫ですが、環境に応じて namespace 等変更してください。

# 既存の有効期限が切れた証明書を削除します  
kubectl delete secret emissary-ingress-webhook-ca -n emissary-system  
  
# emissary-apiextを再起動します。再起動のタイミングで証明書が自動生成されます。  
kubectl rollout restart deploy/emissary-apiext -n emissary-system  

原因

Ambassador(現Emissary)のCRDのリクエストを処理するWebhook APIKubernetes内に作られるのですが、このエンドポイントはサーバー証明書を自動的に作成して使用します。
ただ、Ambassadorの古いバージョンでは証明書の更新を自動で更新を行わないた、め起動して1年が経つと証明書の有効期限が切れてしまい、上記のエラーが発生します。
この問題は過去全てのバージョンで発生しますが、現在修正PRがマージされているのでおそらく次のバージョン辺りで修正されるかと思われます。
https://github.com/emissary-ingress/emissary/pull/5494

解決策

有効期限が切れた証明書を削除してWebhook APIのDeploymentをrestartします。Podの起動時に証明書が自動生成されます。

# 既存の有効期限が切れた証明書を削除します  
kubectl delete secret emissary-ingress-webhook-ca -n emissary-system  
  
# emissary-apiextを再起動します。再起動のタイミングで証明書が自動生成されます。  
kubectl rollout restart deploy/emissary-apiext -n emissary-system  

おわりに

今回は最近遭遇したエラー対応時に得た知見を共有しました。
一致期間ごとにこのコマンドを実行するCronJobを実行する解決する方法もありますが、根本解決には次のバージョンのEmissaryが公開されたタイミングでアップグレードするべきかと考えています。
同様の問題に直面した方の助けになると幸いです。

参考

cert-manager について簡潔にまとめておきますね

この記事は cloud.config tech blog にもマルチポストします

はじめに

最近触った環境で cert-manager というソフトウェアを使用していて、その概要について把握するのにまあまあ時間がかかったため、あとで忘れたときの備忘録として、そして同様にソフトウェアについて把握したい方向けに簡潔にまとめておきます。

cert-manager とは

Kubernetes や OpenShift 上で動作する TLS 証明書の管理ソフトウェアです。
Kubernetes 上で Pod として常駐し、証明書が期限切れになる前に定期的に証明書の更新を自動的に行ってくれます。
作成した証明書は Kubernetes の Secret として自動生成されます。
Helm またはマニフェストで直接インストール可能です。

インストール方法

※前提条件として Helm のインストールが必要ですが未インストールであれば別途インストールしてください

マニフェストでインストールする

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.5/cert-manager.yaml  

これで、cert-manager ネームスペースに cert-manager がインストールされます

Helm でインストールする

helm repo add jetstack https://charts.jetstack.io --force-update  
helm repo update  
  
helm install \  
  cert-manager jetstack/cert-manager \  
  --namespace cert-manager \  
  --create-namespace \  
  --version v1.14.5 \  
  --set installCRDs=true  

インストールされるカスタムリソース例

cert-manager をインストールすると、cert-manager で使用するいくつかのカスタムリソースが Kubernetes 上にインストールされます。
cert-manager を使用しているクラスターには以下のリソースが存在するため、探してみてください。
インストールされるものの中で代表的なものは以下です。

Issuer

証明書を取得する認証局の設定を行います。
取得する元の認証局によって設定値が異なります。
https://cert-manager.io/docs/concepts/issuer/
パターンによる実装例はこちらから
https://cert-manager.io/docs/configuration/issuers/

ClusterIssuer

Issuer を全ての Namespace で使いまわす場合に使用します。
設定値は Issuer とほぼ同じです。Namespace の指定がないのが大きな差異です。

Certificate

作成する証明書の詳細設定を行うリソースです。
証明書の有効期限や期限の何時間前に更新処理を行うか、作成した証明書を保存する Secret リソースの名前、証明書の CommonName 等を設定します。
https://cert-manager.io/docs/usage/certificate/#creating-certificate-resources

何か問題が起きたときは

証明書発行に何か問題が起きた場合は、まず cert-manager の Pod のログを確認することをお勧めします。
デフォルトでは cert-manager ネームスペースに証明書更新を実行する Pod がいるはずなので、 kubectl logsコマンドで Pod のログを確認してください。

また、cert-manager は起動時の設定次第では Prometheus 用フォーマットでメトリクスを出力できるので、そのメトリクスを監視することで証明書の更新失敗を検知できそうです。
具体的にどんな値が取得できるかは未検証&ドキュメントが見つかりません・・・
https://cert-manager.io/docs/devops-tips/prometheus-metrics/

おわりに

以前作業を行った環境で、名前だけは聞いていた cert-manager について実際に操作する段階でいろいろと調べる羽目になったため、同様に調べるときに欲しそうな情報だけまとめておきました。
同様の場面に遭遇した誰かの役に立つと幸いです。

参考

まずは 106 ページまで読んでみよう まだ読んでいる途中だけど SRE 本についてまとめてみる

こちらの記事は cloud.config tech blog にもマルチポストします。

ハイライト

  • SRE 本は分厚く見えますが「SREとは何か」については 106 ページまでにまとまっているのでまずは 106 ページまで読んでみるといいですよ!

はじめに

SRE サイトリライアビリティエンジニアリング Google の信頼性を支えるエンジニアリングチーム」は、全 550 ページにもわたってサイトリライアビリティエンジニアリング(以下 SRE)というエンジニアリング手法とは何か、どのように行うのかについて書かれた本です。
通称 SRE 本とも呼ばれており、SRE というものについて知るための最初の一冊なのですが、何と言っても分厚いです。
自分でも気になって読み始めて、私物としても買って読み進めているのですが読み切るのにはかなり時間がかかりそうです。
ただ、全体で Ⅴ 部まであるうちの第 Ⅱ 部まで読み終わり、ここがキリがよさそうに見えたので今の段階で一度、この本がどのようなことが書いてあって、どのように読むのがよさそうかについて現状の自分なりにまとめられればと思います。
「なぜ全部読み切る前から書評を書くの?」というのはあるのですが、理由としては二つあります。

  • 職場に最近この本がやってきて、周りのメンバーが興味を持っていそうなので。できれば一度読んでほしいので。鉄は熱いうちに打つ意味で
  • おもに自分のため、現状での自分の認識を整理する意味で。この先読み進めて印象が変わればそれはそれで書籍を読んで成長したということです

ということで、この記事の第一目的は職場の同じ部屋にいる周りのメンバーが SRE 本を手にして読み始め、何かを得るところまで読み進めさせることになります。そうなるといいな。
他にも、これから SRE 本を読もうと考えている人にとって実際に読み始めるきっかけになったり、すでに読んでいる方にとってこの本が読みやすくなったりすると幸いです。

全容

この本は全体で 5 部構成になっています。その中に各章があります。
それぞれの部で書かれていることをざっくり紹介します。

第 Ⅰ 部 イントロダクション(1-24 ページ)

SRE とは何か、どのようなことをするのかについて、それが生まれた当時の Google の背景を交えながら説明しています。
ソフトウェアエンジニアの背景を持ったエンジニアで運用を行うことでソフトウェアエンジニアリングのアプローチで運用を考えること、それを通してサイトの信頼性を上げていくことが SRE であるというのが結論になるかと思います。

第 Ⅱ 部 原則(25-106 ページ)

SRE の仕事の原則について説明しています。
ここで言う原則とは、SRE ではどのような要素に関心を持つか、どのように仕事を進めるかに関する諸々のトピックになります。
そのため、この書籍を「サイトリライアビリティエンジニアがどのような仕事をするのかについて知りたい」というモチベーションで読むなら一番重点的に読むべきかと考えています。
自分が読んでいるのは現状ここまでです。

第 Ⅲ 部 実践(107-408 ページ)

この章は SRE で扱うトピックについて細かく、各論を述べています。
全体で 300 ページもありますが、一つ一つのトピックの粒度が細かいのでここではディテールを詰めていくために読むことになりそうです。

第 Ⅳ 部 管理(409-478 ページ)

この章では、実際に SRE チームを運用していくときの方法論について書かれています。
新人 SRE がやってきたときにどのように学習経験を積ませて一人前の SRE に成長させるかが主なトピックになります。
逆に、自分が新人 SRE であったときにどのように業務を学んでいくべきかについて書かれていると見ることもできます。

第 Ⅴ 部 まとめ(479-496 ページ)

本当にその通りで、まとめの一言(一言ではない)が書かれています。

まずは 106 ページまで読んでみよう

この書籍は全体で 550 ページもあります、一息では読み切れないのもごもっともです。
ただ、この書籍を読む最初の一番の目的は「SRE とは何か」であるかと思います。
その場合は、最初の 106 ページまで読むと大体ほしいものが見つかるかと思うので、まずはそこまで読んでみるのがおすすめです。
というのも、全容で書いた通り、第 Ⅱ 部では SRE の仕事の原則について説明しています。
ここを読めば、SRE の基本的な考え方やそのための概念を理解することができます。
SRE の話題でよく言われるトイルとは何か、SLI、SLO、SLA とは何か、エラーバジェットとは何か、エラーバジェットを使ってどのように仕事をするのかがわかります。
そしてそれらのためにどのように監視や自動化を進めていくのか、アプリのリリースはどのように行うかの具体的な方針が書かれています。
その前の第 Ⅰ 部では SRE とは何かの概要がつかめるので、第 Ⅰ 部と第 Ⅱ 部までで SRE についての概要と基本的な考え方が身に付けられてしまいます。
逆に、第 Ⅲ 部は 300 ページもあるものの中身としてはアラートや障害対応、ロードバランシングといった各論に入っていくのであとで時間を作って読むか、最低限気になったトピックだけ拾い読みする読み方でも良さそうです。
ということで、SRE 本を読むならまずは最初の 106 ページまでをそれなりに集中して読んで、それから他の部を読むのが SRE とは何かについて知る上では良さそうです。

次に読むなら?

第 Ⅳ 部が良さそうです。
というのも、第 Ⅳ 部では SRE の主に育成方法が解説されているのですが、逆に見ると自分が SRE らしいスキルを身に付けたいときにどのように動くべきか、学ぶべきかが書かれているともいえるためです。
第 Ⅰ 部、第 Ⅱ 部と読んできて SRE というエンジニアリング手法に興味が出てきたら次はそれを身に着けるための方法が知りたくなるかと思います。

  • プロジェクトの目的を理解しながら作業を行う
  • ポストモーテムを読む/書く
  • 他のメンバーが行っている障害対応を横で見る(シャドウイングする)
    など、目次を見ただけでもやるべきことが見つかりそうです。
    自分も、次に読むならここかなと考えています。

「SRE とは?」今答えるなら

今の理解を試すため、あとでもっと SRE について知ったあとで読み返して恥ずかしくなるために今の SRE についての理解を書いておきます。
サイトリライアビリティエンジニアリングとは、文字通りサイトの信頼性を高めることを目的としたエンジニアリング手法です。
業務としては主にインフラの運用を行うのですが、ここにソフトウェアエンジニアリングのアプローチを組み込むことでより良い運用を目指します。
例えば、サイトの許容できるレベルの信頼性について SLO をプロダクトオーナーと合意し、それを満たすことを目標にインフラの運用を行います。
SRE チーム内では許容できる SLO と現状の余裕分をエラーバジェットとして管理し、SLO を下回らないように(国内では「SLO を割る」という言い方もあるようです)プロダクト開発チームと折り合いをつけながらサイトの信頼性とプロダクト開発のスピードを両立します。
運用における繰り返しの仕事、オーバーヘッドをトイルと呼び、これについてはできる限りうまく自動化したり仕組みを改善(エンジニアリング)することで減らそうとします。

まとめると、特に運用をエンジニアリングで改善するという考え方をすることがソフトウェアエンジニアリングのアプローチをとるということで、サイトリライアビリティエンジニアリングそれがなのかな・・・と今は考えています。
そうするとサイトリライアビリティエンジニアリングという文字通りの意味「サイトの信頼性」からは少し離れている気もするのですが、そこは「はじめに」で著者も認めているとおり、その内容をはっきりと表現出来ていないということなのかなと思います。
最初に名前を付けた時と実際に運用していく中で振る舞いやコアにあるものが変わってくることはよくあることなので、これもそういうものなのかな・・・・・という理解です。

おわりに

今回の記事では「SRE サイトリライアビリティエンジニアリング」という書籍について、途中まで読んだ状態で内容をまとめてどのように読むと読みやすいかを考えて説明してみました。
全体ではかなり分厚い書籍ですが、まずは特に最初の 106 ページを読もうと考えて読むとそれなりにハードルが下がるかと思うのでおすすめです。
周りのメンバーや他の人がこの書籍から何かを得る助けになっていると幸いです。
また、自分でも 3 章から先も引き続き読み進めるつもりです。
全体を読んでから何か考えが変わったりしたらまたブログを書くと思います~

参考

TerraformでつくったAWS LambdaにEventBridgeのトリガーが有効にならない時は

こちらの記事はcloud.config tech blogにもマルチポストします。

シンプルな答え

aws_lambda_permission リソースを作成する必要があります。

resource "aws_lambda_permission" "this" {
  action        = "lambda:InvokeFunction"
  function_name = <作成したLambdaのリソース名>
  principal     = "events.amazonaws.com"
  source_arn    = <作成したaws_cloudwatch_event_ruleリソースのARN>
}

原因

TerraformでLambdaにEventBridgeからのトリガーを作成する際には、EventBridgeからLambdaにアクセスさせる権限を別途付与する必要があります。
この権限の付与はAWSコンソール上からトリガーを作成する際には自動で行われるのですが、AWS CLISDK、CloudFormation等の仕組みを使用してトリガーを作成する場合は手動で実行するする必要があるようです。
Terraformでもこれと同様で手動で権限を付与しなければEventBridgeからLambdaにアクセスできなくてトリガーが動作しないということなのですね。
EventBridgeのトリガー作成画面にも以下のような注意書きがあります。

注: EventBridge コンソールを使用する場合、EventBridge は選択したターゲットについて適切な許可を自動的に設定します。AWS CLI、SDK、または CloudFormation を使用している場合は、適切な許可を設定する必要があります。  

TerraformのLambdaのドキュメントにもNoteがあります。

To give an external source (like an EventBridge Rule, SNS, or S3) permission to access the Lambda function, use the aws_lambda_permission resource

症状

aws_lambda_permissionなしでもLambdaとEventBridge、そしてそのトリガー自体はエラーも起こさずに作成できてしまいます。
ただし、この状態ではEventBridgeで設定したトリガーは有効になっていません。
例えばcronを用いた定期実行を設定していても、そのタイミングでLambdaの実行がトリガーされることはありません。

コンソールからLambdaを確認すると、EventBridgeのトリガーが設定されていないことが確認できます。

一方でEventBridgeの方ではトリガーが作成されているのが確認でき、対象としてLambdaが設定されているように見えてしまうのですが、実際にはトリガーが設定されておらず動作もしません。
紛らわしいですよね~

解決策

ということで、TerraformでLambdaにEventBridgeからのトリガーを作成する際には、EventBridgeからLambdaにアクセスさせる権限を別途付与するためにaws_lambda_permissionリソースを作成します。
プレースホルダーのLambdaリソース名とEventBridgeのARNはそれぞれのリソースのものを設定してください。
Terraformの再apply後、コンソールのLambdaの概要画面でトリガーが設定されていれば成功です!

resource "aws_lambda_permission" "this" {
  action        = "lambda:InvokeFunction"
  function_name = <作成したLambdaのリソース名>
  principal     = "events.amazonaws.com"
  source_arn    = <作成したaws_cloudwatch_event_ruleリソースのARN>
}

おわりに

コンソールで行ったことをTerraformに書き落とせばそのまま動くと考えていたら罠がありました。
コンソールの設定画面やTerraformのLambdaのドキュメントには注意書きがありますが、引っかかるまでこの仕様のこととは気づきませんでした。
おそらく同じことをしようとすれば100人のうち120人くらいが引っかかるかと思います、そんな方の助けになれば幸いです~

参考

Kubestronaut の称号を得たのでちょっと自慢させてください

この記事は cloud.config tech blog にもマルチポストしています。

tech-blog.cloud-config.jp

はじめに

この度私ことなむゆこと南條祐輝は Cloud Native Computing Foundation (CNCF) が主催する Kubernetes 関連資格を見事全て取得し、Kubestronaut の称号を授与されましたのでこちらにて自慢させていただきたく存じます。
https://www.credly.com/badges/d7bb7a25-8784-4be3-b43b-fd6c438bfe2c

Kubestronaut とは

Kubestronaut は、CNCF が主催している Kubernetes 関連の資格 5 つ全てを同時に有効にした人に贈られる称号です。
2024 年 3 月に行われたKubeCon Europe の 4 日目の Keynoteにて教育アンバサダープログラム関連の動きの一つとして発表されました。
同時に有効にするというのは説明が必要なのですが・・・
Kubernetes の資格には合格してから 3 年間(2024 年 4 月 1 日以降に取得したものは 2 年間になりました、残念)の有効期限があり、その期限を迎えると資格が失効します。
そのため、同時に有効にするということは 5 つ全ての資格が全てそれぞれ最後に取得してから有効期限を迎えていない状態であるということです。
Kubernetes 関連の技術は日々変化しているため、試験に合格したことがあるというだけでなく、最新の Kubernetes の知識のキャッチアップがちゃんとできているかどうかも問われるようです。
5 つ全ての資格を取得した状態にすると最後の資格を取得してから 1 か月以内に CNCF からメールが届き、上記のように Credly で Kubestronaut の称号を授与されます。

Kubernetes 資格の特徴

CNCF が主催している Kubernetes 資格は 5 つあり、そのうちの 3 つ(CKAD、CKA、CKS)はハンズオン形式の試験になります。
ハンズオン形式なので、試験では実際の Kubernetes 環境に接続し、コマンドラインで操作を行って問題を解きます。
問題では Kubernetes の知識を問われるだけでなく、試験時間に対して問題数が多いため個々の操作を効率的に行うテクニックも要求されます。
詳しくはKubernetes が普段使いの人のための CKAD 対策の話の記事もどうぞ。
残りの二つの試験(KCNA、KCSA)は 4 択問題を解く形式で、こちらは残りの資格の入門レベルの位置づけになります。
Kubernetes 資格の目立つ特徴としては、受験コストがそれなりに高いことが挙げられます。
CKA、CKS、CKAD の試験の価格は 2024 年 4 月現在それぞれ 395$です。
KCNA、KCSAは250$です。
もちろん日本円で支払うと為替レートの影響も受けるため、ざっくり手計算で 60000 円強、37500 円強かかることになります。
試験を管理している Linux Foundation は頻繁に試験のセールを行っているため実際にはこの価格の 7 割~半額で受験していますが、それでもこれらの資格を全て取得しようとすると受験だけでもそれなりのコストがかかります。

特典は?

Kubestronaut になると以下のような特典があるそうです。

  • Kubestronaut ジャケット(こちらに写真があります)
  • CNCF のイベントや資格のディスカウント(資格の維持に助かります・・・が、具体的に何割引きになるかはまだ発表されていません)
  • CNCF の Ambassadorとして登録される(らしい)

なぜこの称号を狙おうと思ったのか

Kubernetes は元々業務で頻繁に使用していて自分にとって強みのある技術であると考えていたので、そのスキルが CNCF に称号として認めてもらえたら嬉しいかな、というのが一番のモチベーションでした。
副次的には具体的に有用な特典(特にディスカウントとか)もあるため、これから先 Kubernetes 資格を維持していくために有用かなと思えたのも理由の一つです。
あとは Kubestronaut Program が発表された段階で CKS、CKAD、CKA の資格を既に保持していたため、残りは入門レベルの資格である KCNA と KCSA の 2 つだけであったことも大きかったかと思います。
もし今 Kubernetes 資格を 1 つも取得していない状態で Kubestronaut Program のことを知ったとして、特典のために 1 つから資格を取得し始めていたかと思うとそうでもない気がします。
あくまでその時の状態で追加で支払うコストが比較的安くなっていたため目指しただけかもしれません。
それでもその時点で残りの 2 つの資格の取得のために 2 週間ほどの猛勉強の時間と 250$x2(セールの 3 割ほどのディスカウントはありました)のコストが必要だったのですが、その時はそれでも十分見合うだろうと考えていました。今もそう考えています。不思議です。

おわりに

今回は CNCF から発表された Kubestronaut という称号について自慢したり紹介したりしてきました。
Kubernetes の知見や取得した資格がまだない状態から狙っていくようなものではないかとは思いますが、それなりに Kubernetes について詳しかったり、すでに Kubernetes 資格を半分近く持っているという人にとってはこれまで積み上げてきたものが一つ公に認められるようなそういう称号であるように感じます。
そういった方は目指してみるべきかと思います。

参考

KubeCon + CloudNativeCon Europe 2024 Day four: Looking to the past and the future of Kubernetes (and more news
Announcing the Kubestronaut program
Kubestronaut program | CNCF
Kubestronaut Program - Linux Foundation
CNCF Ambassadors