ストイックに生きたい

Goodbye 2025

Sun, 11 Jan 2026 13:42:30 GMT

仕事

転職して 4 年 4 ヶ月が経過した。なかなかの長続きだし、ここまで長いともう転職してからみたいな言い方ではない気がする。

今のポジションとしては CSE II だけど、今年の 4 月ぐらいからフルタイムで社内ツールの開発をやっているので、実質 SysDE では?と思う。チームとしてはグローバルなので英語しか使わず、タイムゾーンの関係上変な時間で生活するようになったので、もう普通の日本時間での生活に戻れる気はしない。そして、Kubernetes を全く触らなくなったので若干危機を感じている。

技術

コンテナ関連で唯一やったといえるのは、Multipass で Kubernetes クラスターを作成できる kubernetes-on-multipass のメンテをちょっとやったぐらい。

コミットログを見てたら 2 月に Fix kernel version check condition in nftables proxier #130401 というのもやってた。たしか、nftables 関連のコード読んでたら見つけた。

そして、12 月あたりから Linux Kernel へのコントリビュートを始め、Mac の上で VMware Fusion で VM 立てて作業していたが限界を感じたので、UM790 Pro を買ったら快適になった。駆け込みで買ったので、メモリ高騰の波に襲われずに済んだ。2026 年からは Linux Kernel に全振りする予定である。

快適になった pic.twitter.com/hgXsf8ZFbK
— さかもとりょーた(27) (@let_constant) December 26, 2025

英語

フルタイムで英語で仕事しているおかげか英語での会話に抵抗はなくなった。抵抗がなくなっただけで字幕は使っているし、集中していないと普通に聞き逃す。やはり英語での世界の方が広いので今後も英語を使っていきたい。

筋トレ

家でよりかは週に何回かジムに行きみたいな生活となった。意外とレッグプレスなどの脚のメニューもやるようになり、昔は脚なんてやってられないと思っていたが意識が変わった。

プライベート

大阪万博に行ったり、箱根行ったりと今年も旅行をした。そして家を購入したのでローンに追われている。もっと給料が欲しいと切に願うのであった。

総括

来年も引き続き、プライベートも仕事も頑張りましょう。

Goodbye 2024

Mon, 24 Feb 2025 07:52:30 GMT

仕事

転職して 3 年 4 ヶ月が経過した。去年の時点ですでに過去の在籍期間の中では最長だったが、自分で驚くぐらい長続きしている。プロモーションしてジョブレベルが上がったのでより頑張っていきたいところではある。

2023 年と比べるとコードを書くことも増え、メンテしている dynein では Rust を書いたりした。コードを書いてるとやはり楽しいので、そろそろソフトウェアエンジニアに戻りたい気持ちも出てきた。

技術

主な領域としては、コンテナというのは変わらず。Kubernetes コアの部分というよりかは kube-proxy とか CoreDNS あたりを触れていた時間が長い気がする。一方で、ネットワーク関連に強くなったかといえばそうでもない。2025 年は Kubernetes にコミットするなどもっと OSS に関わる年にしたいところである。

だいぶ前から作って放置してる自作 DNS サーバーを完成させたいと思って RFC 読んだらいつも発見があって面白い、そろそろ完成させてちゃんと公開したい。

Domain Name Compression に RDATA の圧縮についてちゃんと書かれていたhttps://t.co/LoJJeTKnnD
— さかもとりょーた(26) (@let_constant) November 17, 2024

コード書く時は、Sourcegraph の Cody を使うようになった。GitHub Copilot でも良い気がするが正直違いはわからない。そもそも AI の進化が早く Cursor とか Cline とか色々出てきているもののキャッチアップできていない。コードは自分で書くからこそ楽しさがあるという思いはあったが、検索する代わりに ChatGPT とか Perplexity に投げることで便利さを享受しているので、結局はどう活用するかというだけの話であった。

英語

TOEIC を 2024 年の 1 月に受けてまあ妥当という点数を取った。そして、数ヶ月英語のみで仕事する機会があり英語力のなさを実感したので英語の勉強を頑張りたい。最近は The Stack Overflow Podcast を聞くなど意識はしている。

筋トレ

たまにジムに通うようになり、マシン中心にやるようになり、ベンチプレスなどのフリーウェイトもやるようになった。扱える重量が伸びると成長を感じて面白い。

プライベート

箱根に連れて行ってもらったり、熱海とか韓国に行ったりした。やはり旅行は楽しい。
韓国では、現金と Wise を使って過ごしてたが、急に Wise が使えなくなり焦ったものの、普段のクレカも持ってたので助かった。やはり信じられるのはアメックス様。

総括

来年も引き続き、プライベートも仕事も頑張りましょう。

CoreDNS の仕組みとプラグイン

Sun, 29 Dec 2024 09:00:00 GMT

概要

CoreDNS は、Go で実装された DNS サーバーであり、Kubernetes の DNS サーバーとしても利用されている。
特徴的な仕組みとして、プラグインという仕組みがあり、殆どの機能はプラグインで実装されており、プラグインを自分で実装することも可能である。

CoreDNS のローカルでのビルドおよび実行は、簡単に行うことができる。
具体的には、下記のように make コマンドを実行することで、ビルドを行える。

$ git clone https://github.com/coredns/coredns.git
$ cd coredns
$ make

ビルドが完了すると、coredns というバイナリが生成されるので、実行することで CoreDNS が起動する。

$ ./coredns
maxprocs: Leaving GOMAXPROCS=12: CPU quota undefined
.:53
CoreDNS-1.12.0
darwin/amd64, go1.23.3, 177253340

基礎

CoreDNS では、Corefile という設定ファイルを読み込み、その設定に従って DNS サーバーを起動する。

$ cat Corefile
.:10053 {
    forward . 1.1.1.1
    log
    errors
}

$ ./coredns
maxprocs: Leaving GOMAXPROCS=12: CPU quota undefined
.:10053
CoreDNS-1.12.0
darwin/amd64, go1.23.3, 177253340
[INFO] 127.0.0.1:63479 - 32124 "A IN example.com. udp 40 false 4096" NOERROR qr,rd,ra,ad 67 0.005239353s

上記のような Corefile を用意することで、下記のような動作を行うようになる。
errors プラグインが有効でない場合、デフォルトではエラーログは出力されないので、エラーを確認したいなら有効にしましょう。

10053 番ポートで DNS サーバーを起動する
forward プラグインにより 1.1.1.1 に DNS クエリを転送する
log プラグインによりクエリログを出力する
errors プラグインによりエラーログを出力する

もし、Corefile が存在しない場合は、デフォルトの設定で起動するようになっており、whoami と log プラグインが有効になっている。

	caddy.RegisterServerType(serverType, caddy.ServerType{
		Directives: func() []string { return Directives },
		DefaultInput: func() caddy.Input {
			return caddy.CaddyfileInput{
				Filepath:       "Corefile",
				Contents:       []byte(".:" + Port + " {\nwhoami\nlog\n}\n"),
				ServerTypeName: serverType,
			}
		},
		NewContext: newContext,
	})

Corefile

Corefile は、Caddyfile と同じようにパースされるものとなっており、環境変数等を使用することが可能である。
なお、内部的に使用している coredns/caddy は caddyserver/caddy の v1 のフォークであるため、v2 の機能を利用することはできない。

forward . {$FORWARDS}

$ FORWARDS=1.1.1.1 ./coredns

また、複数のゾーンを指定することができ、それぞれのゾーンに対して別の設定を行うこともできる。
たとえば、example.net では hosts プラグインを有効にし、それ以外では forward プラグインを有効にするような設定を行うことができる。

.:10053 {
    forward . 1.1.1.1
    log
    errors
}

example.net:10053 {
    hosts {
        127.0.0.1 example.net
    }
    log
    errors
}

プラグインの仕組み

Corefile でデフォルトで使うことができるプラグインは、Plugins から確認することができる。
これらのプラグインは、plugin に実装があり、plugin.cfg に定義されているプラグインがビルド時に追加されるようになっている。

また、External Plugins に記載されているプラグインは、plugin.cfg に定義されていない外部のプラグインとなるため、自分で追記した上でビルドする必要がある。

では、具体的にどのように plugin.cfg に定義されているプラグインがビルド時に追加されるかというと、go generate コマンドを実行することで、plugin.go で定義されている directives_generate.go が plugin.cfg を読み込んでコードを生成するようになっている。
その結果、 core/dnsserver/zdirectives.go および core/plugin/zplugin.go が生成されて、プラグインを使用することができるようになる。

プラグインの順番

Configuration に記載があるとおり、各プラグインが実行される順番は Corefile の順番ではなく、plugin.cfg に定義されている順番で実行される。
たとえば、cache プラグインが使用している場合、キャッシュが存在すれば、それ以降のプラグインは実行されない。
このため、Corefile に記載するプラグインの順番を気にする必要はない。

プラグインの追加

サンプルプラグインとして、example が提供されているので、これを使ってプラグインの追加を試すことができる。
plugin.cfg に下記のように追加し、make コマンドを実行することで、example プラグインが追加された状態でビルドされる。
また、前述したとおり、plugin.cfg に定義されているプラグインの順番は重要なため、今回の場合、example プラグインは forward プラグインより前に定義する必要がある。

example:github.com/coredns/example
forward:forward

$ git diff core/dnsserver/zdirectives.go core/plugin/zplugin.go
diff --git a/core/dnsserver/zdirectives.go b/core/dnsserver/zdirectives.go
index 56174955c..91ef82a7d 100644
--- a/core/dnsserver/zdirectives.go
+++ b/core/dnsserver/zdirectives.go
@@ -56,6 +56,7 @@ var Directives = []string{
        "secondary",
        "etcd",
        "loop",
+       "example",
        "forward",
        "grpc",
        "erratic",
diff --git a/core/plugin/zplugin.go b/core/plugin/zplugin.go
index 12bb4ce15..59bb64a51 100644
--- a/core/plugin/zplugin.go
+++ b/core/plugin/zplugin.go
@@ -57,4 +57,5 @@ import (
        _ "github.com/coredns/coredns/plugin/tsig"
        _ "github.com/coredns/coredns/plugin/view"
        _ "github.com/coredns/coredns/plugin/whoami"
+       _ "github.com/coredns/example"
 )

もし、プラグインが追加されていない場合は、CoreDNS の起動時に Corefile のパースに失敗する。

Corefile:6 - Error during parsing: Unknown directive 'example'

サンプルプラグイン

example プラグインでは、log.Info および log.Debug を使用しており、log.Debug の出力を確認するためには debug プラグインも有効にする必要がある。

.:10053 {
    forward . 1.1.1.1
    log
    errors
    debug
    example
}

example プラグインを有効にした状態で、上記の Corefile を使用することで、クエリの実行時に example プラグインが実行されログが出力されるようになる。

[DEBUG] plugin/example: Received response
[INFO] plugin/example: example
[INFO] 127.0.0.1:65349 - 13760 "A IN example.com. udp 40 false 4096" NOERROR qr,rd,ra,ad 67 0.013614538s

もし、debug プラグインが有効でない場合、log.Debug は出力されない。

[INFO] plugin/example: example
[INFO] 127.0.0.1:49451 - 57280 "A IN example.com. udp 40 false 4096" NOERROR qr,rd,ra,ad 67 0.008662355s

プラグインの実装

プラグインを実装する方法については、Writing Plugins および How to Add Plugins to CoreDNS に記載がある。
より具体的には、plugin.Handler interface を実装し、AddPluggin でプラグインを登録することで実装できる。
example プラグインがわかりやすいので参考にすると良い。

はじめに、setup を通して、plugin.Handler interface を実装している Example struct をプラグインとして追加している。

	// Add the Plugin to CoreDNS, so Servers can use it in their plugin chain.
	dnsserver.GetConfig(c).AddPlugin(func(next plugin.Handler) plugin.Handler {
		return Example{Next: next}
	})

ServeDNS では、プラグインが実行された際の処理を実装している。また、plugin.NextOrFailure を使用することで、次のプラグインに処理を委譲することができる。
このため、plugin.NextOrFailure を意図的に呼びださないことで、プラグインチェーンの途中で処理を止めることができる。

func (e Example) ServeDNS(ctx context.Context, w dns.ResponseWriter, r *dns.Msg) (int, error) {

また、各プラグインでは、ログを出力するために、github.com/coredns/coredns/plugin/pkg/log を使用することができる。
このパッケージは、Go の log パッケージをラップしたもので、ログレベルのプレフィックスをつけたり、debug プラグインによって有効化されるデバッグログの管理も行なっている。

各プラグインの仕組み

例として、いくつかのプラグインの実装を見ていく。

cache

cache プラグインは、TTL をもとにクエリの結果をキャッシュすることができる。
どのようにキャッシュを行なっているかというと、plugin/cache/handler.go で dns.ResponseWriter のラッパーを作成し処理を移譲、その後のプラグインで WriteMsg() が呼ばれたらラッパーの WriteMsg() が呼ばれて、キャッシュするという仕組みである。

forward と cache プラグインを有効化した際の具体的な処理の流れとしては、下記のようになっている。

plugin/cache/handler.go:42 - キャッシュが存在するか確認し、存在しなければ dns.ResponseWriter のラッパーを作成する
plugin/cache/handler.go:108 - plugin.NextOrFailure を呼び出し、次のプラグインに処理を委譲する
plugin/forward/forward.go:208 - forward プラグイン内でラッパーの WriteMsg() を呼び出す
plugin/cache/cache.go:184 - ラッパーの WriteMsg() でキャッシュを行い、dns.ResponseWriter の WriteMsg() を呼び出す

ログを確認するとわかるとおり、キャッシュ後はレスポンスが早くなっている。

[INFO] 127.0.0.1:64375 - 49069 "A IN example.com. udp 40 false 4096" NOERROR qr,rd,ra,ad 56 0.019756003s
[INFO] 127.0.0.1:50379 - 49563 "A IN example.com. udp 40 false 4096" NOERROR qr,aa,rd,ra,ad 56 0.000075345s

ready

ready プラグインは、/ready エンドポイントを有効にし、すべてのプラグインが使用可能なら OK、そうでなければ使用可能ではないプラグインを出力する。
どういう時に使うかというと、Kuberentes において CoreDNS がリクエストを受ける準備が完了したか確認するための readinessProbe を設定するために使用する。

$ curl -i localhost:8181/ready
HTTP/1.1 200 OK
Date: Wed, 01 Jan 2025 16:24:44 GMT
Content-Length: 2
Content-Type: text/plain; charset=utf-8

OK

$ curl -i localhost:8181/ready
HTTP/1.1 503 Service Unavailable
Date: Wed, 01 Jan 2025 16:24:16 GMT
Content-Length: 10
Content-Type: text/plain; charset=utf-8

errors,log

より具体的には、各プラグインで Readiness interface を実装することで、ready プラグインはそれを使用して、プラグインが使用可能かどうかを確認する。
なお、errors や log プラグインは、Readiness interface を実装していないので、上記の結果になることはない。

// The Readiness interface needs to be implemented by each plugin willing to provide a readiness check.
type Readiness interface {
	// Ready is called by ready to see whether the plugin is ready.
	Ready() bool
}

prometheus

prometheus プラグインは、prometheus および各プラグインが集計したメトリクスを prometheus 形式で出力するプラグインである。
メトリクスは、localhost:9153/metrics で公開されるようになっている。

$ curl -s localhost:9153/metrics | grep coredns_cache_hits_total
# HELP coredns_cache_hits_total The count of cache hits.
# TYPE coredns_cache_hits_total counter
coredns_cache_hits_total{server="dns://:10053",type="success",view="",zones="."} 9

実装としてはシンプルで、promhttp パッケージを使用して /metrics に対する HTTP ハンドラを登録、coredns_dns_requests_total などのメトリクスを集計している。
また、各プラグインでは、promauto パッケージを使用してメトリクスを定義しているので、このプラグインを有効化するだけでメトリクスを収集することができる。
たとえば、cache プラグインでは、plugin/cache/metrics.go にメトリクスを定義している。

	// cacheHits is counter of cache hits by cache type.
	cacheHits = promauto.NewCounterVec(prometheus.CounterOpts{
		Namespace: plugin.Namespace,
		Subsystem: "cache",
		Name:      "hits_total",
		Help:      "The count of cache hits.",
	}, []string{"server", "type", "zones", "view"})

Goodbye 2023

Sun, 31 Dec 2023 04:07:30 GMT

仕事

転職して 2 年 4 ヶ月が経過した。過去の会社の在籍期間の中で最長となった。

去年はコードを書くことはなかったが、今年は CDK とか React を少しだけ書いたので、全くコードを書かないということはなかった。グローバルでの仕事も行っていたのでたまに英語で会話することもあったが、英語はやはり難しい。
4 月には、EKS に詳しくなって assessment を通過したので、EKS (Container Service for Kubernetes) Subject Matter Expert というのを取得した。

技術

主な領域としては、コンテナというのは変わらず。Kubernetes のソースコードを読む機会は少なくなかったので多少詳しくなったといえる。

Multipass を使った Kubernetes 環境を用意してみたが、思いのほか便利であった。リポジトリは ryota-sakamoto/kubernetes-on-multipass である。クラスターを作ったり壊したりが簡単にできて検証が捗った。

k3s とかの軽量 Kubernetes が使いたいわけではないから cloud-init で kubeadm 使うやつ書いたけど快適だな
— さかもとりょーた(25) (@let_constant) March 26, 2023

eBPF を学ぶため Learning eBPF を読んでいたが完走しなかった。今は日本語訳も出ているのでそちらを読むのがいい気がしている。

これ読み始めたhttps://t.co/bfcfZt5bb4
— さかもとりょーた(25) (@let_constant) May 8, 2023

ISUCON 13 で 3 位を取った。詳細は ISUCON 13 で 3 位でした(ultra_fast_gopher) に書いたが、ISUCON 7 から毎年参加しており 3 位という順位を取れたのは嬉しかった。

3位でした #isucon pic.twitter.com/rHFsUdySzR
— さかもとりょーた(25) (@let_constant) November 25, 2023

資格

2 月あたりに CKA を受けて受かった。CKAD と比べると難易度はそこまで変わらないという印象を受けた。CKS は受けようと思っていたが expire した。
TOEIC を受けようと思っていたが忘れていたので来年受けようと思う。

筋トレ

筋トレは継続しており、懸垂マシンとダンベルをもらった。懸垂マシンは懸垂以外にもディップスができたりするので色々な筋トレができて便利である。ダンベルはベンチが欲しいという気持ちがある。
また、ジムに行くのはやはりめんどくさいので、このまま道具を増やす可能性が高い。

総括

来年も引き続き、プライベートも仕事も頑張りましょう。

ISUCON 13 で 3 位でした(ultra_fast_gopher)

Sat, 30 Dec 2023 08:23:13 GMT

やったこと

リポジトリは ultra-fast-gopher/isucon13 で公開してある、当然ながら言語は Go を選択した。

アプリケーションに対する改善としては下記を行った。DNS の実装や、bcrypt を逃したりがスコアに効いていた記憶がある。キャッシュは最終手段と言われているが、改善できるところがなくなってもキャッシュするとスコアが伸びるので正義であった。

遅いクエリに INDEX を貼る
N+1 を剥がす
DB に icon_hash を持って、条件付き GET リクエストに対応
DNS を実装して水責めに対応
DB から画像を剥がす
色々キャッシュ
JSONSerializer を早くする
bcrypt を余裕のあるサーバーで実行
不要なトランザクションを剥がす

デプロイには GitHub Actions の self-hosted runners を使用して各インスタンスへのデプロイを行い Discord への通知を行った。通知がきたらベンチマークを実行すればいいので便利だった。また、master ブランチおよび PR への push を契機にデプロイを行っていたので、気軽に改善をデプロイすることができ、高速にイテレーションを回すことができた。

インスタンスへの接続には、Tailscale を使用した。セキュリティグループがどうとか気にしなくていいし、GitHub の Organization で tailnet を共有できるのでとても便利だった。

アプリケーションの解析には、pprotein を使用した。pprof やスロークエリを簡単に見ることができるのでとても便利であった。phpMyAdmin もインデックスを簡単に貼れたり便利だった。

やり残した点として、アプリケーションとベンチマーカーへの理解があげられる。アプリケーションの特性を理解し、ベンチマーカーが何をしているのか理解することで、さらに点数は伸ばす余地があったように思う。たとえば、投げ銭やモデレーションといった点に対して対応する時間がなかった。

スクショ

文字だけなのもあれなので、スクショを貼ることにする。

1 位を出した時

最後までベンチマークを回し続けた、危なかった

感想

元々毎年別のチームで参加していたものの、チームメンバーの都合により ultra_fast_gopher へ入れてもらったので足を引っ張らないが不安であったが、このように結果を残すことができて良かった。個人としては、ISUCON 7 から毎年参加しており入賞を目標としていたので、3 位という順位を取れ満足のいく結果ではあった。
一方で、改善できそうでできなかった点や、問題に対する理解を深めることでさらに点を伸ばせる可能性もあったので、来年に向け精進していきたい。

景品

「TOP30チーム」と「はてな賞」をもらった。ありがとうございます。

ありがとうございます #isucon pic.twitter.com/JdCEewz2eh
— さかもとりょーた(25) (@let_constant) December 31, 2023

Nodelocal DNSCache とはなにか

Wed, 19 Apr 2023 14:13:48 GMT

概要

公式ドキュメントで紹介されているとおり、DNS のキャッシュ用エージェント（CoreDNS）を DaemonSet で各 Node に配置することで、DNS のパフォーマンスを改善しようというものである。やってること自体はシンプルで、キャッシュがあればそれを返すし、なければ kube-dns に問い合わせたり、Node 上の /etc/resolv.conf を参照して名前解決をしたりする。
ソースコードは、Kubernetes DNS にある。

仕組み

公式ドキュメントの図がわかりやすいので引用した。

デフォルト（clusterDNS: kube-dns）では、クライアント側の Pod の dnsPolicy が ClusterFirst の場合、kubelet に指定されている clusterDNS で名前解決を行う。
Nodelocal DNSCache では kube-dns と同じ IP アドレスのインターフェースを作成、bind することで、kube-dns ではなく Nodelocal DNSCache へパケットをルーティングされるようにしている。169.254.20.10 は NodeLocal DNSCache の IP アドレスで、172.20.0.10 は kube-dns の IP アドレスである。

17: nodelocaldns: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether c6:df:93:00:8f:3a brd ff:ff:ff:ff:ff:ff
    inet 169.254.20.10/32 scope global nodelocaldns
       valid_lft forever preferred_lft forever
    inet 172.20.0.10/32 scope global nodelocaldns
       valid_lft forever preferred_lft forever

そして、流れてきた DNS クエリは、Corefile をもとに処理されていて、プレースホルダーについては後述する。
この Corefile わかることは、それぞれ cache が設定されていて、__PILLAR__DNS__DOMAIN__:53（in-addr.arpa:53、ip6.arpa:53）は __PILLAR__CLUSTER__DNS__ に forward されること、それ以外の場合は __PILLAR__UPSTREAM__SERVERS__ に forward されることである。

    __PILLAR__DNS__DOMAIN__:53 {
        errors
        cache {
                success 9984 30
                denial 9984 5
        }
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__CLUSTER__DNS__ {
                force_tcp
        }
        prometheus :9253
        health __PILLAR__LOCAL__DNS__:8080
        }

    .:53 {
        errors
        cache 30
        reload
        loop
        bind __PILLAR__LOCAL__DNS__ __PILLAR__DNS__SERVER__
        forward . __PILLAR__UPSTREAM__SERVERS__
        prometheus :9253
        }

このマニフェストでは、使用者側が置換するべきプレースホルダーがいくつか用意されている。

key	example value	description
PILLAR__DNS__DOMAIN	cluster.local	クラスター内で使用されるドメインを指定する。
PILLAR__LOCAL__DNS	169.254.20.10	NodeLocal DNSCache が使用する IP アドレスを使用する、既存の IP アドレスと被ってなければなんでもいい。
PILLAR__DNS__SERVER	172.20.0.10	kube-dns の IP アドレスを指定する。
PILLAR__CLUSTER__DNS	10.108.67.154	`-upstreamsvc` に指定されたサービスの IP アドレス。デフォルトでは `-upstreamsvc` には `kube-dns-upstream` が指定されていて、手動で置換する必要はない。
PILLAR__UPSTREAM__SERVERS	/etc/resolv.conf	デフォルトでは `/etc/resolv.conf` が指定されていて、手動で置換する必要はない。

ここで出てくる kube-dns-upstream とはなにかというと、ここで定義されている Service で、kube-dns の代わりである。NodeLocal DNSCache が動いている Node では、kube-dns の IP アドレスを使っても NodeLocal DNSCache へルーティングされるので、別の Service を用意することで疎通できるようにしている。

apiVersion: v1
kind: Service
metadata:
  name: kube-dns-upstream
  namespace: kube-system
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
    kubernetes.io/name: "KubeDNSUpstream"
spec:
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53
  selector:
    k8s-app: kube-dns

そして Nodelocal DNSCache は、ここで定義されているとおり、dnsPolicy は Default である。このため、kubelet に指定されている resolvConf が Pod の /etc/resolv.conf として使用される。

ここまでまとめると下記のような動作をする。

domain	behavior
内部ドメイン	キャッシュがあればそれを返す、なければ `kube-dns-upstream` へ forward
外部ドメイン	キャッシュがあればそれを返す、なければ Nodelocal DNSCache が `/etc/resolv.conf` をもとに名前解決を行う

インストール方法

通常

公式ドキュメントで紹介されている方法は、kubernetes/kubernetes で提供されているマニフェストを使う方法である。前述した一部のプレースホルダーを置換することで完了する。

$ curl -O https://raw.githubusercontent.com/kubernetes/kubernetes/v1.27.1/cluster/addons/dns/nodelocaldns/nodelocaldns.yaml
$ kubedns=$(kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP})
$ sed -i "s/__PILLAR__LOCAL__DNS__/169.254.20.10/g; s/__PILLAR__DNS__DOMAIN__/cluster.local/g; s/__PILLAR__DNS__SERVER__/$kubedns/g" nodelocaldns.yaml
$ k apply -f nodelocaldns.yaml

cilium

cilium を使っている場合は注意が必要で、Local Redirect Policy を使わないと NodeLocal DNSCache ではなく kube-dns へクエリが飛ぶので動いていない状態となる。これについてはドキュメントに記載されており、下記のように cilium から提供されているマニフェストをそのまま使うのが簡単である。

なお、hostNetwork を使っていなかったり、インターフェースが作成されないようになってるので色々違う。

$ curl -O https://raw.githubusercontent.com/cilium/cilium/v1.13/examples/kubernetes-local-redirect/node-local-dns.yaml
$ kubedns=$(kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP})
$ sed -i "s/__PILLAR__DNS__SERVER__/$kubedns/g;" node-local-dns.yaml
$ kubectl apply -f node-local-dns.yaml
$ kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.13/examples/kubernetes-local-redirect/node-local-dns-lrp.yaml

検証

NodeLocal DNSCache と CoreDNS のログを出しつつ、検証用の Pod を立ててコマンドを実行して結果を見ていく。各 Pod と実行するコマンドは下記のとおりである。

Pod	IP	command
CoreDNS	10.244.0.29	k -n kube-system logs -f -l k8s-app=kube-dns
NodeLocal DNSCache	172.23.111.195	k -n kube-system logs -f -l k8s-app=node-local-dns
netshoot	10.244.0.38	k run netshoot —image=nicolaka/netshoot -it — bash

内部ドメイン

netshoot では、デフォルトで存在する kubernetes Service の名前解決を行うことにする。

netshoot:~# dig kubernetes.default.svc.cluster.local.

NodeLocal DNSCache 側のログはこんな感じで、netshoot の IP アドレスが記録されている。

[INFO] 10.244.0.38:51834 - 38845 "A IN kubernetes.default.svc.cluster.local. udp 77 false 1232" NOERROR qr,aa,rd 106 0.001695631s

CoreDNS 側のログはこんな感じで、NodeLocal DNSCache の IP アドレスが記録されている、

[INFO] 172.23.111.195:57492 - 21023 "A IN kubernetes.default.svc.cluster.local. tcp 77 true 65535" NOERROR qr,aa,rd 106 0.00025829s

2 回目は、NodeLocal DNSCache だけでログが出ていて、キャッシュされているので早いことがわかる。

[INFO] 10.244.0.38:37972 - 54802 "A IN kubernetes.default.svc.cluster.local. udp 77 false 1232" NOERROR qr,aa,rd 106 0.000112795s

外部ドメイン

netshoot では、外部ドメインとして example.com. の名前解決を行うことにする。

netshoot:~# dig example.com.

外部ドメインの場合は、NodeLocal DNSCache で名前解決が行われるので、NodeLocal DNSCache だけでログが出ている。

[INFO] 10.244.0.38:56892 - 40871 "A IN example.com. udp 52 false 1232" NOERROR qr,rd,ra,ad 56 0.355279087s

2 回目はキャッシュされているので早いことがわかる。

[INFO] 10.244.0.38:42148 - 17723 "A IN example.com. udp 52 false 1232" NOERROR qr,aa,rd,ra,ad 56 0.000070897s

cilium

さて、cilium を使っている場合は、hubble observe を使うと簡単に経路を確認できる。

k -n kube-system exec -it cilium-p89s9 -c cilium-agent -- hubble observe --since 3m --pod kube-system/node-local-dns-f2mr6 -

内部ドメインの場合は、kube-dns で名前解決が行われていることが確認できる。

Apr 18 15:01:09.059: default/netshoot:47939 (ID:39341) -> kube-system/node-local-dns-f2mr6:53 (ID:49464) to-endpoint FORWARDED (UDP)
Apr 18 15:01:09.060: kube-system/node-local-dns-f2mr6:58070 (ID:49464) -> kube-system/coredns-5d78c9869d-xh4ql:53 (ID:6868) to-endpoint FORWARDED (TCP Flags: SYN)
Apr 18 15:01:09.060: kube-system/node-local-dns-f2mr6:58070 (ID:49464) <- kube-system/coredns-5d78c9869d-xh4ql:53 (ID:6868) to-endpoint FORWARDED (TCP Flags: SYN, ACK)
Apr 18 15:01:09.060: kube-system/node-local-dns-f2mr6:58070 (ID:49464) -> kube-system/coredns-5d78c9869d-xh4ql:53 (ID:6868) to-endpoint FORWARDED (TCP Flags: ACK)
Apr 18 15:01:09.060: kube-system/node-local-dns-f2mr6:58070 (ID:49464) -> kube-system/coredns-5d78c9869d-xh4ql:53 (ID:6868) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Apr 18 15:01:09.062: kube-system/node-local-dns-f2mr6:58070 (ID:49464) <- kube-system/coredns-5d78c9869d-xh4ql:53 (ID:6868) to-endpoint FORWARDED (TCP Flags: ACK, PSH)
Apr 18 15:01:09.063: default/netshoot:47939 (ID:39341) <- kube-system/node-local-dns-f2mr6:53 (ID:49464) to-endpoint FORWARDED (UDP)

外部ドメインの場合は、NodeLocal DNSCache で名前解決が行われていることが確認できる。

Apr 18 15:02:09.529: default/netshoot:37900 (ID:39341) -> kube-system/node-local-dns-f2mr6:53 (ID:49464) to-endpoint FORWARDED (UDP)
Apr 18 15:02:09.530: kube-system/node-local-dns-f2mr6:35227 (ID:49464) -> 10.188.1.1:53 (world) to-stack FORWARDED (UDP)
Apr 18 15:02:09.530: kube-system/node-local-dns-f2mr6:35227 (ID:49464) <- 10.188.1.1:53 (world) to-endpoint FORWARDED (UDP)
Apr 18 15:02:09.531: default/netshoot:37900 (ID:39341) <- kube-system/node-local-dns-f2mr6:53 (ID:49464) to-endpoint FORWARDED (UDP)

kube-proxy は何をしてるのか

Fri, 06 Jan 2023 15:44:05 GMT

前置き

Kubernetes において、kube-proxy がどのような動きをしているのか知ることは非常に重要である。ソースコード自体は読みやすい。

日付	内容
2023-01-07	`v1.26.0` の内容で公開

kube-proxy とは

ドキュメントに書かれているとおり、kube-proxy は DaemonSet でデプロイされており、各 Node のネットワークプロキシとして動作する。Service の一部を実装しており、iptables や ipvs を使用してトラフィックを制御している。userspace も使えたが、v1.26 で削除された。

cmd/kube-proxy/app/server.go

早速ソースコードを読み始めるが、これは kube-proxy の初期化やサーバーの起動を行っている。

ここで重要なのは、NewProxyServer で iptables と ipvs の proxier の初期化を行っている点である。メインの処理としては、proxier で行っているといっても過言ではない。ここでは、iptalbes の実装を見ていくことにする。

func (s *ProxyServer) Run() error

ここで、healthz・メトリクス・proxier の起動、healthz の設定とかをしている。

pkg/proxy/iptables/proxier.go

デュアルスタックに対応しているかどうかで NewProxier と NewDualStackProxier のどちらかが呼ばれる。関数自体は分かれているものの、NewDualStackProxier では ipv4 と ipv6 の分 NewProxier を呼び出しているだけなので、とりあえずは NewProxier の実装を見ていく。

NewProxier

ここでは、NodePort を localhost で通信できるようにするための route_localnet、ブリッジしたパケットをフィルタリングするための bridge-nf-call-iptables が有効化されているかどうか確認している。ちなみに、v1.26 からは --iptables-localhost-nodeports を指定することで localhost への通信を無効化できるようになった。
あとはマスカレード、LoadBalancer のヘルスチェック用のサーバーの設定もしている。

func (proxier *Proxier) SyncLoop()

ここはなんかしている。重要なのは proxier.syncRunner.Loop で、NewProxier で下記のように初期化されている。2 番目の引数に渡されている syncProxyRules が実行される関数で、メインの処理である。

	// We pass syncPeriod to ipt.Monitor, which will call us only if it needs to.
	// We need to pass *some* maxInterval to NewBoundedFrequencyRunner anyway though.
	// time.Hour is arbitrary.
	proxier.syncRunner = async.NewBoundedFrequencyRunner("sync-runner", proxier.syncProxyRules, minSyncPeriod, time.Hour, burstSyncs)

syncProxyRules

ここはメインの処理で iptables のルールを生成している。800 行ぐらいしかないが、行数以上にでかい。

SNAT

ここで MARK がついている場合に SNAT をしている。

-A KUBE-POSTROUTING -m mark ! --mark 0x00004000/0x00004000 -j RETURN
-A KUBE-POSTROUTING -j MARK --xor-mark 0x00004000
-A KUBE-POSTROUTING -m comment --comment \"kubernetes service traffic requiring SNAT\" -j MASQUERADE --random-fully

MARK のルールはここで生成されている。

-A KUBE-MARK-MASQ -j MARK --or-mark 0x00004000

そして、どういう場合に MARK がつくかというと、外部からのアクセスやクラスタの IP 外からのアクセス、ループバックの時とかにつくルールが生成される。

DNAT

ここで Service から Pod への DNAT を行っている。下記のようなルールが生成されて、各 Pod へリクエストが送られることがわかる。

-A KUBE-SEP-FTG4NWKEUMM5OZ72 -m comment --comment kube-system/kube-dns:dns -s 192.168.0.5 -j KUBE-MARK-MASQ
-A KUBE-SEP-FTG4NWKEUMM5OZ72 -m comment --comment kube-system/kube-dns:dns -m udp -p udp -j DNAT --to-destination 192.168.0.5:53
-A KUBE-SEP-GHNVWKROTCCBFQKZ -m comment --comment kube-system/kube-dns:dns -s 192.168.1.2 -j KUBE-MARK-MASQ
-A KUBE-SEP-GHNVWKROTCCBFQKZ -m comment --comment kube-system/kube-dns:dns -m udp -p udp -j DNAT --to-destination 192.168.1.2:53
-A KUBE-SEP-QTGKLRHEXOFUNUWC -m comment --comment kube-system/kube-dns:dns -s 192.168.1.3 -j KUBE-MARK-MASQ
-A KUBE-SEP-QTGKLRHEXOFUNUWC -m comment --comment kube-system/kube-dns:dns -m udp -p udp -j DNAT --to-destination 192.168.1.3:53

さて、実際に DNAT していることを tcpdump を使って確認していく。

node: pod => clusterIP
17:22:36.615574 IP (tos 0x0, ttl 64, id 51177, offset 0, flags [none], proto UDP (17), length 80)
    192.168.1.3.40884 > 10.96.0.10.domain: [bad udp cksum 0xcc62 -> 0x2bdb!] 51013+ [1au] A? example.com. ar: . OPT UDPsize=1232 (52)

node: pod => coredns pod(DNAT)
17:22:36.615608 IP (tos 0x0, ttl 63, id 51177, offset 0, flags [none], proto UDP (17), length 80)
    192.168.1.3.40884 > 192.168.0.5.domain: [bad udp cksum 0x82a6 -> 0x7597!] 51013+ [1au] A? example.com. ar: . OPT UDPsize=1232 (52)
controlplane:
17:22:36.604418 IP (tos 0x0, ttl 63, id 51177, offset 0, flags [none], proto UDP (17), length 80)
    192.168.1.3.40884 > 192.168.0.5.domain: [udp sum ok] 51013+ [1au] A? example.com. ar: . OPT UDPsize=1232 (52)

controlplane: b
17:22:36.604441 IP (tos 0x0, ttl 62, id 51177, offset 0, flags [none], proto UDP (17), length 80)
    192.168.1.3.40884 > 192.168.0.5.domain: [udp sum ok] 51013+ [1au] A? example.com. ar: . OPT UDPsize=1232 (52)

controlplane: c
17:22:36.604696 IP (tos 0x0, ttl 64, id 65186, offset 0, flags [DF], proto UDP (17), length 107)
    192.168.0.5.domain > 192.168.1.3.40884: [bad udp cksum 0x82c1 -> 0x5737!] 51013* q: A? example.com. 1/0/1 example.com. [18s] A 93.184.216.34 ar: . OPT UDPsize=1232 (79)

controlplane: d
17:22:36.604706 IP (tos 0x0, ttl 63, id 65186, offset 0, flags [DF], proto UDP (17), length 107)
    192.168.0.5.domain > 192.168.1.3.40884: [bad udp cksum 0x82c1 -> 0x5737!] 51013* q: A? example.com. 1/0/1 example.com. [18s] A 93.184.216.34 ar: . OPT UDPsize=1232 (79)

node: 
17:22:36.616404 IP (tos 0x0, ttl 63, id 65186, offset 0, flags [DF], proto UDP (17), length 107)
    192.168.0.5.domain > 192.168.1.3.40884: [udp sum ok] 51013* q: A? example.com. 1/0/1 example.com. [18s] A 93.184.216.34 ar: . OPT UDPsize=1232 (79)
17:22:36.616415 IP (tos 0x0, ttl 62, id 65186, offset 0, flags [DF], proto UDP (17), length 107)
    10.96.0.10.domain > 192.168.1.3.40884: [udp sum ok] 51013* q: A? example.com. 1/0/1 example.com. [18s] A 93.184.216.34 ar: . OPT UDPsize=1232 (79)

writeServiceToEndpointRules

ここでは、Service の ClusterIP へのリクエストがきた際に、Pod へランダムに振り分けるためのルールを生成している。また、Service の sessionAffinity を指定した際のルールもここで生成されている。

CoreDNS の replicas を 3 にした場合、下記のようなルールが生成されるのだが、ここで面白いのは --probability に指定されている数値である。

-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment \"kube-system/kube-dns:dns -> 192.168.0.5:53\" -m statistic --mode random --probability 0.3333333333 -j KUBE-SEP-FTG4NWKEUMM5OZ72
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment \"kube-system/kube-dns:dns -> 192.168.1.2:53\" -m statistic --mode random --probability 0.5000000000 -j KUBE-SEP-GHNVWKROTCCBFQKZ
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment \"kube-system/kube-dns:dns -> 192.168.1.3:53\" -j KUBE-SEP-QTGKLRHEXOFUNUWC

iptables は上から順に評価されるので、下記のように振り分けられることになる。上から順に 1/N で割り振ることで、均等に振り分けることができるのである。

全てのリクエストの 1/3 を KUBE-SEP-FTG4NWKEUMM5OZ72 へ流す
1 の残りのリクエスト（2/3）の 1/2 を KUBE-SEP-GHNVWKROTCCBFQKZ へ流す
2 の残りのリクエスト（1/3）を KUBE-SEP-QTGKLRHEXOFUNUWC へ流す

sessionAffinity に ClientIP を指定した場合は、前述したルールの前に下記のルールが生成される。ここでは、タイムアウトとしてデフォルトの 10,800 秒（3 時間）が設定されており、最後のリクエストからタイムアウトの秒数が経過していなければ、同じ Pod へリクエストが流れることがわかる。

-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment \"kube-system/kube-dns:dns -> 192.168.0.5:53\" -m recent --name KUBE-SEP-FTG4NWKEUMM5OZ72 --rcheck --seconds 10800 --reap -j KUBE-SEP-FTG4NWKEUMM5OZ72
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment \"kube-system/kube-dns:dns -> 192.168.1.2:53\" -m recent --name KUBE-SEP-GHNVWKROTCCBFQKZ --rcheck --seconds 10800 --reap -j KUBE-SEP-GHNVWKROTCCBFQKZ
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment \"kube-system/kube-dns:dns -> 192.168.1.3:53\" -m recent --name KUBE-SEP-QTGKLRHEXOFUNUWC --rcheck --seconds 10800 --reap -j KUBE-SEP-QTGKLRHEXOFUNUWC

pkg/proxy/healthcheck/service_health.go

LoadBalancer のヘルスチェック用のサーバーは、NewServiceHealthServer により作成されている。

そもそも LoadBalancer のヘルスチェック用のサーバーとは何かというと、type が LoadBalancer かつ externalTrafficPolicy が Local の場合に必要なもので、特定の Node に Endpoints が存在しない時にヘルスチェックを失敗させることで、その Node へトラフィックを流さないようにするものである。
healthCheckNodePort を設定することでポートを指定でき、指定しなかった場合は自動で設定される。externalTrafficPolicy が Local ではない時に設定しようとすると、下記のようにエラーになる。

The Service "test-service" is invalid: spec.healthCheckNodePort: Invalid value: 32234: may only be set when `type` is 'LoadBalancer' and `externalTrafficPolicy` is 'Local'

これをどう使うかというと、下記のように Node に対してリクエストを送るとヘルスチェックができる。エンドポイントが存在すれば 200、存在しなければ 503 が返ってくるのでこれでその Node へトラフィックを流してもいいかどうかわかる。

$ k get node node01 -o wide
NAME     STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
node01   Ready    <none>   16d   v1.26.0   172.30.2.2    <none>        Ubuntu 20.04.5 LTS   5.4.0-131-generic   containerd://1.6.12

$ k get service test-service -o json | jq .spec.healthCheckNodePort
32234

$ curl 172.30.2.2:32234 -v
*   Trying 172.30.2.2:32234...
* TCP_NODELAY set
* Connected to 172.30.2.2 (172.30.2.2) port 32234 (#0)
> GET / HTTP/1.1
> Host: 172.30.2.2:32234
> User-Agent: curl/7.68.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 503 Service Unavailable
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< Date: Sun, 08 Jan 2023 12:11:40 GMT
< Content-Length: 93
< 
{
        "service": {
                "namespace": "default",
                "name": "test-service"
        },
        "localEndpoints": 0
* Connection #0 to host 172.30.2.2 left intact
}

Goodbye 2022

Sat, 31 Dec 2022 13:04:20 GMT

去年はもうちょっと余裕を持って書いていたが、今年はもう年越し直前で蕎麦を食べながら書いている。

仕事

転職して 1 年 4 ヶ月が経過した。ソフトウェアエンジニアではなくなったので、仕事としてコードを書くことはないが、今のところそれ自体が苦しいことはない。仕事内容は良く同僚にも恵まれており日々の学びが多いためとても充実している。
ソフトウェアエンジニアに戻るかどうかについては、今すぐに戻りたいということはなく、まあそのうち戻るだろうという感じではある。興味のあるチーム自体はいろいろあるのでどこかのチームの人と話してみたい。

技術

主な領域としては、コンテナというのは変わらず。あとは IaC だったり、興味のある分野とかやりたい分野は一貫して変わっていない。
まあでも最新トレンドを追うというよりかは、クラウドの技術にシフトした感じがする。

久しぶりに本をちゃんと読んだ。この本は、Kubernetes の基本的なネットワークについて学ぶことができ、netns とか iptables がどう使われているのかわかる。

Networking and Kubernetes 読み始めたhttps://t.co/BzDG3gmyR1
— さかもとりょーた(25) (@let_constant) April 8, 2022

個人的に記憶にあるのが Zig とか Erlang を触ったことである。Zig は手に馴染む感じがせず Rust で良くねと思った。Erlang はパターンマッチが強く、Scala を初めて書いた時と同じような面白さを感じたし、多分 2023 年も触っている気がする。

Zig が流行ってるのでとりあえず触ってみた pic.twitter.com/cHXcTePYAG
— さかもとりょーた(25) (@let_constant) July 17, 2022

Erlang おさわりしてる
— さかもとりょーた(25) (@let_constant) December 17, 2022

あとは、DNS とかいろいろ作りかけのものが今年も完成しなかったので、来年こそは完成させたい。

資格

去年のサイバーマンデーで買っていた CKAD をやっと受けた。2020 年ぐらいから受けようと思っていたのでついにという感じではある。
CKA / CKS をサイバーマンデーで買ったので、ちゃんと勉強する必要があるなと思っている。

受けた pic.twitter.com/6rztMu0fwy
— さかもとりょーた(25) (@let_constant) November 29, 2022

筋トレ

筋トレ 2022 に書いた通り、真面目に続けているので継続したいし、懸垂を頑張りたい。

総括

来年もプライベートも仕事も頑張りましょう。あとは英語を頑張りたい。

筋トレ 2022

Sun, 18 Dec 2022 12:25:23 GMT

してたこと

基本的に自重中心で腕立て伏せとか懸垂とかしていた。
腹筋ローラーで膝コロ・立ちコロしてたが、あまり楽しくないので最近はしていない。
あとは、今年の後半ぐらいからなんとなくではなく、ちゃんとスケジュールを組んで取り組むようにしてから効果が上がった気がする。

懸垂は最近始めた。もともと家の近くに鉄棒は存在しないと思っていて断念していたが、下記のツイートにある「懸垂のできる公園リスト」を見て、家の近くにあるのを知ったので始めた。懸垂を始めるまでは、チューブ使ったりしていたが、使い方があまり上手くなかったのもあって効果はなかったように思う。

懸垂ができる公園リストですhttps://t.co/isawQvvs5J
— Dai Tamesue 爲末大 (@daijapan) November 9, 2022

使ったもの/使ってたもの

アームバー 30kg
プッシュアップバー
チューブ
腹筋ローラー

プロテイン

プロテインはいつになっても何が良いのかよくわからない。
今まではビーレジェンドのホエイプロテインだったが、マイプロテインのウェイトゲイナーに変えた。5 キログラムあるので量が多いのは良いなと思う。

来年

懸垂を頑張っていきたい、あとはアームバーの負荷を上げたい。
効率を考えるとジムに行くのが良いのだろうがめんどくさいので、家にジムを作りたい。

Catch All Custom Domain

Sat, 05 Feb 2022 11:16:12 GMT

モチベーション

ドメインをいくつか持っていて有効活用したくなり、特定のドメインに送信されたメールを Gmail に転送したくなった。
送信はできなくていいし、メールサーバーを立てるなんてことはしたくないし、この目的のためにクラウド上に何かを作るやる気もなかった。

とりあえず実際に動くことを確認したのは Google Domains と Cloudflare Email Routing である。

Google Domains

Google Domains を使っている場合は、メール転送の機能を使うだけでいいので簡単である。
下記のように、*@example.com に対して設定すれば、全てのメールを転送することができる。
Google Domains のネームサーバーを使っていない場合でも、カスタムネームサーバーによるメール転送を設定するに書いてあるとおり、MX レコードを追加すると転送できる。

Cloudflare Email Routing

~~Email Routing は現在ベータ版の機能なので、Waitlist に登録しましょう。~~
Email Routing はオープンベータになったので誰でも使えます。

Catch-all address に書かれているとおり、機能として Catch-all があるので設定するだけで特定のアドレスに転送することができる。
また、受信したものを転送ではなく Drop することもできるので便利である。

また、Email Routing Insights で紹介されているとおり、メトリクスやログを見ることができるので普通に便利である。

おわり

Google Domains のメール転送を使っていたが、DNS は Cloudflare を使っているので Email Routing を使うようにした。

Goodbye 2021

Thu, 30 Dec 2021 14:58:31 GMT

2021年も色々変化があったがここに記すには余白が狭すぎる。
結局また直前に書き始めることになるとは思ってもいなかった。

OSS

今年の3月に Argo CD 等の OSS を開発している argoproj のメンバーになった。

頑張ります pic.twitter.com/hN5DnFmvrZ
— さかもとりょーた(23) (@let_constant) March 11, 2021

主にやっていたのは argocd-notifications と notifications-engine で、ドキュメントを充実させたり PR のレビューしたり Slack で人間を助けたりしていた。
ちなみに、argocd-notifications は argo-cd/pull/7744 で Argo CD 本体にマージされてv2.3でリリースされる。

仕事

8月に転職し、ソフトウェアエンジニアからクラウドサポートエンジニアになった。
ソフトウェアエンジニアから離れたので仕事でコードを書いてはいないが、今のところ毎日技術に触れているので面白いし、これがクラウドかって気持ちになる。
また数年したらソフトウェアエンジニアに戻る気はするが、今のところは今のポジションで頑張る予定である。

転職するまでは結局ずっと Go を書いていたし、多分今後も何か書く際は Go で書いていく気がする。

技術

基本的にコンテナ系を追っていた一年ではあったし、きっと2021年もコンテナ系を追っていくつもりではある。

BMSファイル再生

途中まで作って満足してやめてしまったが、BMS ファイルを読み込んで再生するやつを作っていた。
これは Go で Engo というライブラリを使っていて、リポジトリは ryota-sakamoto/beatgo にある。

任意のBMSファイルを読んで再生するところまで作った pic.twitter.com/LZ3EDYSZU3
— さかもとりょーた(23) (@let_constant) January 3, 2021

「Automating chaos experiments in production」を読んだ

人生で初めてまともに英語の論文を読んだ。内容は多少古いが。

DNSサーバー

DNS がどうやって動くかを理解したかったので、RFC を読みながら DNS サーバーを作っていた。完全に理解した状態になり、これも途中で飽きてやめた。
これは Rust で書いていたが、UDP のパケットをパースする部分は std::io::Cursor を使って丁寧に書いていた。
リポジトリはソースコードの質が低いので private。

フルサービスリゾルバまで実装した pic.twitter.com/SOte47y8BH
— さかもとりょーた(23) (@let_constant) April 29, 2021

ブログの移行

Netlify から Cloudflare Pages に移行した。とにかく簡単だった。
基本的に持っているドメインは全て Cloudflare を通しているのと、なんとなく移行したくなったから移行した。

NetlifyからCloudflare Pagesへ移行
— さかもとりょーた(23) (@let_constant) July 26, 2021

2021年の目標

2021年は下記の目標を一応掲げてはいた。

TOEIC: 800点
資格: AP, CKAD
発狂皆伝
買った本をちゃんと読む
賢くなる

まず TOEIC、これは定期的に受けてはいるし英語の勉強もたまにしていて12月も受けたのでそれの結果次第なところはある。
資格はAPは申し込み忘れ、CKAD は Black Friday で買ったので来年受ける。
発狂皆伝は発狂六段あたりまで地力を戻したが壁が高すぎるので諦めた。
買った本は今年も色々買ったが読まずに本棚に積まれている。
賢くはなれなかった気がする。

こう見ると何も達成してないが忘れていたことはないし、ここに書いてあること以外の進捗が良いのでよしとする。
一応立てておくことで頭の片隅に置いておくことができるので、2022年も何か立てておくことにする。

総括

来年は仕事も技術も頑張りましょう。

ArgoCD with AWS SSO

Thu, 01 Jul 2021 09:05:37 GMT

前提

ArgoCDではdexを使い認証・認可を行っている。そのため、LDAP・OIDC・SAML等を使うことができる。

動作確認したバージョンは v2.0.4

argocd: v2.0.4+0842d44
BuildDate: 2021-06-23T01:27:53Z
GitCommit: 0842d448107eb1397b251e63ec4d4bc1b4efdd6e
GitTreeState: clean
GoVersion: go1.16
Compiler: gc
Platform: linux/amd64

AWS SSOと一緒に使う

argocd.example.com にArgoCDが立っている前提で

まずAWS SSOの設定をする

新規アプリケーションの追加
カスタム SAML 2.0 アプリケーションの追加

表示名や説明は任意のものを設定し、アプリケーションメタデータは下記のように設定する

さっきの情報を元に dex.config を書く

ssoURL は先ほど作成したアプリケーションのAWS SSO サインイン URLをいれる
entityIssuer と redirectURI は同じものをいれる
caData は先ほど作成したアプリケーションのAWS SSO 証明書をダウンロードしbase64したものを入れる
attr に何を入れるかは後述

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-cm
data:
  url: https://argocd.example.com
  dex.config: |
    connectors:
      - type: saml
        id: saml
        name: saml
        config:
          ssoURL: https://portal.sso.us-west-2.amazonaws.com/saml/assertion/~~~
          entityIssuer: https://argocd.example.com/api/dex/callback
          redirectURI: https://argocd.example.com/api/dex/callback
          caData: $dex.saml.caData
          usernameAttr: subject
          emailAttr: email

apiVersion: v1
kind: Secret
metadata:
  name: argocd-secret
  namespace: argocd
stringData:
  dex.saml.caData: ~~~

RBACの設定をする

これの書き方はRBAC Configurationを参考に

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
data:
  policy.default: role:readonly
  policy.csv: |
    g, ryota-sakamoto, role:admin
  scopes: |
    - name

Attribute mappings

先ほど後述すると書いた部分だが管理されているユーザー属性とマッピングをしやりとりをする必要がある。管理画面にはアプリケーションの中に属性マッピングという項目があるのでそこで設定を下記のように行う。

Supported AWS SSO attributesにどういったものが用意されているのか記載されている。

ユーザーを作成し実際にどういった値が返ってくるのか下記に記載した。

attribute	value
${user:AD_GUID}	926771f849-5b9aa823-3145-4b54-b974-7939f62d405b
${user:email}	sakamo.ryota+argocd@gmail.com
${user:familyName}	Sakamoto
${user:givenName}	Ryota
${user:middleName}
${user:name}	Ryota Sakamoto!!!
${user:preferredUsername}	Ryota Sakamoto!!!
${user:subject}	ryota-sakamoto

英語の勉強を始めて半年が経った

Thu, 01 Apr 2021 12:45:14 GMT

現状

前回はYouTubeとか映画とか見ていたが勉強した気になるだけで効果がないのでやめた。
去年9月から12月でTOEIC IPの点数は+85点上がったが3月に受け忘れたので定点観測ができていない。4月にTOEIC LRを受ける。

何をしているか

とりあえず現状持っている本は以下で、1日1時間から2時間程度勉強している。たまに何もしない日もある。

DUO 3.0

1日1周できるようになるまではSECTION5つ分ぐらいを毎日1時間ぐらいかけて進めた。1日1周できるようになって大体3ヶ月ぐらいやってから触っていないが、英語初心者でも気合いで乗り切れば語彙力はつくことがわかった。

音声は復習用CD買ってきてiPhoneに入れて聞いてた、練習用CDは使ってない。

キク英文法

英文法を鍛えようと思って買ったが1ページもやってない、そのうちやる。

Core1900

Part1の1章分を毎日1時間ぐらいかけて進めた。1日1周できるようになると1時間ぐらいでPart1が回せる。
途中で英語完全上達マップの存在を知ってからは1週回すのではなく音読パッケージとしてCore1900をやっている。

音読は下記の順番で回してる。シャドーイングは難しすぎてできないのでやってないのとリスニングはおまけ。大体1ページ1時間で終わる。

オーバーラッピング(5回)
音読(15回)
リピーティング(5回)
オーバーラッピング(5回)
リスニング(3回)

音声はnaturalの方を使っている。

英会話ペラペラビジネス100

最近買った。とりあえず会話ができるようになるための一歩として。書いてある内容は難しいわけではないのでひたすら回して表現を覚えるのが良さそうな印象がある。

「Automating chaos experiments in production」を読んだ

Mon, 08 Mar 2021 15:32:27 GMT

前置き

この論文が出されたのが2019年5月だが紹介されているシステム(例えばVizceral)はもう既にNetflix内部では利用されていなかったりするので注意が必要。
まあAutomating Chaos Experiments in Productionに2017年3月に動画が出ているのでそういうことだと思うが。

要約

ChAP

Netflixでは1,000台以上のサーバーでマイクロサービスが動いていて、あるコンポーネントで障害が発生した際に可用性を維持するためにタイムアウトやリトライといった仕組みをシステムに入れているがそれがシステム全体に対してどう影響を与えるか等をテストするためにChaos Engineeringを行っている。
また、それを行うためにChaos Automation Platform(ChAP)という基盤を開発している。
ChAPではアプリケーションレベルでfault injectionを行い、failure(呼び出しの代わりに例外)とlatency(呼び出しを実行するときに遅延を入れる)をサポートしている。

experiment

実験を行う最初に2つのクラスター(apii-beseline, api-canary)をSpinnaker経由で作成する。
ランダムに選ばれた1%のユーザーが各々のクラスターにリクエストがいくようにEurekaというService Discoveryのためのツール(他のOSSでいうとCoreDNSとか Consulとか色々ある)を使いリクエストを流す。
その2つのクラスターに対してfault injectionを行いKPIやCPU使用率等の結果を比べることで障害が起きた際のシステムに与える影響を確認している。

safety mechanism

fault injectionは障害を引き起こす可能性がある。そのリスクを軽減するためにいくつかの仕組みが導入されている。

働いている時間(9AM-5PM)のみ実行
顧客に多大な影響を与えた場合に自動的に止まる
総トラフィックの5%を超えないように
failover時には実行できない

Monocle

ChAPは元々self-serveモデルを採用しユーザーが設定等を行っていたが、Monocleと呼ばれるシステムを作り設定を自動で行い実験を行うといったmanagedなモデルも採用した。

Monocleでは3つの種類の実験を生成することができる。これらは経験則に基づいて定義されるためよりシステムの脆弱な部分を見つけることができる。

Failure
Latency just below configured timeout (highest timeout - P99 latency over the past 7 days + 5% buffer)
Latency causing failure (highest configured timeout + 5% buffer)

また、Criticality scoreを用いて実験の優先順位を決めている。このscoreは依存関係やリクエスト量等によって計算される。

fault injection

開発言語としてJavaを使っていたためHystrixというライブラリを開発し使っていたが、Node.jsでの開発もしたりで新しいライブラリを作る必要があったので、fault injectionの仕組みを言語ベースではなく別のアプローチとしてService Meshを採用しIstioを開発した。

感想

読みやすかったし面白かった。内容としては若干古いが考え方として参考になる部分も多いと思う。

これを書いてから気付いたけどthe morning paperというブログにまとめられていた。

Chaos Engineeringではないが仕事でバッチを開発した時にどこでエラーが起きてもリトライ可能なように設計をしたのだが、一定の確率でエラーが起きる前提で開発をすると冪等性の担保が簡単にできるようになったのでよかったことを思い出した。

ArgoCD Notifications v1 Slack Config

Tue, 26 Jan 2021 14:52:57 GMT

日付	内容
2020-01-26	`v1.0.1` の内容で公開
2020-03-11	`v1.0.2` の内容で更新

さて

v0.x to v1.0を見るとわかるがそれなりに破壊的変更があった。
ソースコードレベルでは一部しか見ていないので全部の変更についてはここには書かないし、Slackでしか使ってないのでそこだけ書く。

ちなみに v0.x の設定はdeprecatedなだけでまだ使える。

v0.xのSlackの設定

まずは今までどうやって書いていたかを書く。

ConfigMap

ビルトインとしていくつかのトリガーが存在したのでそれを有効にする。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  config.yaml: |
    triggers:
    - name: on-sync-status-unknown
      enabled: true
    - name: on-sync-failed
      enabled: true
    - name: on-sync-running
      enabled: true
    - name: on-sync-succeeded
      enabled: true
    - name: on-health-degraded
      enabled: true

annotations

下記のようなアノテーションをつけると通知された。

metadata:
  annotations:
    recipients.argocd-notifications.argoproj.io: slack:my-channel

v1.0.0のSlackの設定

まずは提供されているマニフェストを適用する。
v1.0.0 からは2種類提供されるようになっていてcontrollerとcatalogである。

controller は controller で、catalog は通知する内容のテンプレート等が書かれている。
これを適用したら ConfigMap と annotations を追加する。

ConfigMap

同様の動作をさせるための ConfigMap の書き方は下記のようになる。
argocd-notifications-cm は既に存在するので defaultTriggers を追加する。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  defaultTriggers: |
    - on-deployed
    - on-health-degraded
    - on-sync-failed
    - on-sync-running
    - on-sync-status-unknown
    - on-sync-succeeded

annotations (v1.0.2)

v1.0.2 以降で同様の動作をさせるための annotations の書き方は下記のようになる。
improve annotation iterate #159がマージされたので下記のような書き方ができる。

metadata:
  annotations:
    notifications.argoproj.io/subscribe.slack: my-channel

annotations (v1.0.1)

これは古い情報だがメモとして残しておく。
. が2つ続いてるのは意味がわからないと思うが、v1.0.1 以前ではこうする必要がある。

metadata:
  annotations:
    notifications.argoproj.io/subscribe..slack: my-channel

なぜこの書き方をするのか

アノテーションを舐める処理はpkg/subscriptions/annotations.go#L32-L55でやっているのだがここには問題がある。

ここでは変数として trigger と service が重要になる。
trigger は何を起因に通知を飛ばすか、serviceは slack 等が入る。

上に書いた例でいうと trigger には空文字、service には slack が入る。
pkg/subscriptions/annotations.go#L112-L115 に書いてあるのだが、trigger に空文字が入ることで引数として渡された defaultTriggers を使うことができる。
この defaultTriggers には先ほど ConfigMap に書いていた値が入ってくる。

さて問題点だがこの if 文は必ず通るので trigger を空文字にするためにはこのような書き方をする必要がある。

parts := strings.Split(k[len(prefix):], ".")
trigger := parts[0]
service := ""
if len(parts) >= 1 {
	service = parts[1]
} else {
	service = parts[0]
	trigger = ""
}

Goodbye 2020

Thu, 31 Dec 2020 14:16:25 GMT

さて色々変化があった2020年だがここに記すには余白が狭すぎる(?)
1週間ぐらい前から書こうと思ってたのに当日に駆け込みで書くことになるとは思っていなかった。

技術

メモとして残してるのはIngress Nginxのソースコードを読んだり、cert-managerでExternal Issuerを実装する方法を調べたぐらい。
他にはTerraformで遊んだり、kubeadm触ったり、Kubernetesで遊んだりまあそれなりに色々してた。たぶん。
Kong触ったり、kubectlのソース読んだりして色々書こうと思ってたけど書いてる途中でやめた。
2021年はちゃんとCKADをとります。ソフトウェアエンジニアとしては機械学習やったりゲーム作ったりで幅を広げていきたい。
あとはCコンパイラを完成させてないのでちゃんとやる。

仕事

まだ転職してないのでLINE Growth Technologyにいる。2019-08-15に入社したので前職より長く在籍している。僕は仕事としてはSREをやりたいのでよろしくお願いします。あと全く出社しなくなって生活週間が崩壊した。

普段はAnsible書いたりCI/CDのやり方考えたりGo書いたり負荷テストしたり色々してる。
社内システムの脆弱性見つけたり、line/line-bot-sdk-rubyのContributorになったりもした。
人前で発表するのは苦手だったが、社内で勉強会があれば発表するようになったので機会があれば自発的にするもんなんだなと思った。
色々社内システム作ったりしていたけど社外に名前が出ていないので色々やってたとだけ。

LINE DEVELOPER DAY 2020のインフラ構築とかAPIの実装とかした。
LINE DEVELOPER DAY 2020 Webサイト開発の裏側をお話しします！でサーバーサイド開発について話したが資料がまだ公開されていないのでそのうち。

Create External Issuer for cert-manager

Sun, 20 Dec 2020 08:31:16 GMT

さて

Implementing External Issuersを見ると証明書を発行するためにACME等を使わずに自分で実装できるらしいが何をすればいいかよくわからなかったので実装して確認した。
cloudflare/origin-ca-issuerを参考にしたのでこっちを読めば基本的には何をすればいいかはわかる。

どういう時にこれを実装するかというと例えば社内に証明書を管理しているAPIサーバーがあったとしてそこから証明書を取得するとか。

実装

一部エスパーしている部分もあるが大まかにはこのような流れで動いている。

参考実装はryota-sakamoto/cert-manager-external-sampleでkubebuilderを使っている

実装するべき点は3つある

1: external issuerのreconcile
3, 5: CertificateRequestのreconcile
4: 証明書の取得、発行等

1: external issuerのreconcile

customissuer_controller.go#L58

yamlではユーザー名とかパスワードを指定してreconcileすればいいと思う。
(Secret を使うとかそこはよしなにやる)

apiVersion: cert-manager.k8s.sakamo.dev/v1
kind: CustomIssuer
metadata:
  name: customissuer-sample
spec:
  user: user
  password: password

3, 5: CertificateRequestのreconcile

CertificateRequest をreconcileし下記の点を実装すると目的が達成できる

issuerRef が一致するかどうか #L53
CertificateRequest の Status の Certificate が空かどうか #L61
issuerRef で指定したIssuerのStatus等の確認 #78
証明書の取得、発行等 #85
CertificateRequest の Status の更新 #91

まず Certificate に issuerRef を指定してapplyする。
そうすると CertificateRequest と Secret が生成される。

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-certificate
spec:
  secretName: example-com-tls
  dnsNames:
  - example.com
  - www.example.com
  duration: 2160h
  renewBefore: 720h
  issuerRef:
    group: cert-manager.k8s.sakamo.dev
    kind: CustomIssuer
    name: customissuer-sample

$ kubectl get certificate
NAME                  READY   SECRET            AGE
example-certificate   False   example-com-tls   9s

$ kubectl get certificaterequest
NAME                        READY   AGE
example-certificate-crbmv           11s

$ kubectl get secret
NAME                        TYPE                                  DATA   AGE
default-token-lhhdl         kubernetes.io/service-account-token   3      14d
example-certificate-g6gn6   Opaque                                1      17s

CertificateRequest には Certificate で指定した値やCSRが含まれる。
また、Secret の名前はannotationsから取得できる。

$ kubectl get certificaterequest/example-certificate-crbmv -o go-template="{{ .spec.request }}" | base64 --decode
-----BEGIN CERTIFICATE REQUEST-----
(snip)
-----END CERTIFICATE REQUEST-----

$ kubectl get certificaterequest/example-certificate-crbmv -o jsonpath="{.metadata.annotations.cert-manager\.io\/private-key-secret-name}"
example-certificate-g6gn6

Secret には秘密鍵の情報が含まれている。

$ kubectl describe secret/example-certificate-g6gn6
Name:         example-certificate-g6gn6
Namespace:    default
Labels:       cert-manager.io/next-private-key=true
Annotations:  <none>

Type:  Opaque

Data
====
tls.key:  1708 bytes

Status の更新は cert-manager にutilがあるのでそれを使うだけでいい。certificate_request_controller.go#L91

import (
    cmutil "github.com/jetstack/cert-manager/pkg/api/util"
)

cmutil.SetCertificateRequestCondition(cr, certmanager.CertificateRequestConditionReady, metav1.ConditionTrue, certmanager.CertificateRequestReasonIssued, "Certificate issued")

4: 証明書の取得、発行等

ここは要件によって実装は変わるが上記で取得できる値を使ってAPIを叩いたりする。
参考実装では tls.key を使ってオレオレ証明書を作成している。certificate_request_controller.go#L117

実装後

ここまで実装して CertificateRequest から証明書を発行したりすると READY は TRUE になり、TLS証明書の Secret が作成される。
これを Ingress 等で指定すると使うことができる。

$ kubectl get certificaterequest
NAME                        READY   AGE
example-certificate-crbmv   True    27m

$ kubectl get certificate
NAME                  READY   SECRET            AGE
example-certificate   True    example-com-tls   27m

$ kubectl get secret/example-com-tls
NAME              TYPE                DATA   AGE
example-com-tls   kubernetes.io/tls   2      46s

下記のようにアクセスすると証明書が発行できていることが確認できる。

英語の勉強を始めた

Mon, 05 Oct 2020 15:22:05 GMT

動機

元々英語を話せるようになりたいとは思っていたが中々手がつかずにいた。
社内でTOEIC IPを受けれる機会があったので受けたところ なるほど となる点数だったので勉強しようと思った。
年始に英検を取るという目標を掲げていた気がするのでやっと動き始めたという感じである。

何をしているか

DUO 3.0

初学者にはおすすめしないと書いてあったりしたが気合いで乗り切るということで買った。
ちなみに知らない単語しか書いてない。

YouTubeで解説を眺める

英語コーチ-イングリッシュおさるの動画をちょくちょく眺めてる。
わかりやすいと思ってる。たぶん。

英語字幕つきの動画を見る

Amazon Primeオリジナルだと一部英語字幕がついているので

日本語字幕
英語字幕

の順でたまに見ている。イギリス英語の作品は早すぎて全く聞き取れないです。ちなみに単語もわからない。
でも内容わかってると言い回しとかで割と面白さはある。

とりあえず

成果が出てきたらまた何か書こうと思う。

転職して1年経った

Sat, 15 Aug 2020 10:39:55 GMT

最近は何をしているのか

社内向けツールの開発・運用したり、CI/CDの仕組みを整備したり、Kubernetesを触ったりしている。

どんな社内向けツールの開発をしてたりするかというとPMクロストークに書いてあるLP作成ツールやマーケティング配信ツールとか他にも色々開発してたりする。(外部に公開してないものをここに書くのは微妙だと思うのでまあ色々という)

LP作成ツールは去年のLINE DEVLOPER DAY 2019で初期の開発したメンバーが話している。

マーケティング配信ツールはGoで書きたかったのでGoで書いた。
自分が関わっていて新規で書くものはGoで書いてるけど、他はJavaとかKotlinで書かれてたりする。

CI/CDは社内には共通基盤としてDroneがあるのでそれを使っていい感じの仕組みを作ったり、KubernetesだとArgoCD使ったGitOpsとか。

前職は

前職はGMOインターネット株式会社でConoHaのサービス設計をしていた。
どんな事をしていたかというとVPSの機能追加を考えて各所と調整したり、イメージ作ったり、オブジェクトストレージのドキュメントを書いてたりしてた。(not ソフトウェアエンジニア)

転職して変わったところ

横断的に色々できるので楽しいし、強いエンジニアが多いので楽しい。
何よりサービスの成長に関わる事ができるのが楽しい。

社内では色々な勉強会が開かれていて、月1ぐらいで何かしら発表するようになった。
人前に出るのが割と苦手だったが自発的に発表する程度には変わった。(強制ではないので単純に機会の問題だと思うが)
最近だと Nginx Ingress Controller のソースコードを読んだのでどんな事をしているかみたいな話をした。(他には Terraform の Custom Provider の作り方とか)

裁量労働になったので生活習慣が崩壊した。
最近は5時とかに寝てる。家で仕事してるので実質影響なしみたいなところはあるけど。

最後に

エンジニアとしてサービスの成長に関わることに興味があればLINE Growth Technology - connpassからカジュアル面談申し込んでもらうと詳しい話を聞けると思います。

人生初ピアスの感想

Sun, 02 Aug 2020 07:18:26 GMT

前置き

2020-08-01(土)、自宅にて知人にピアスを開けてもらった。
開ける事になった経緯は省略するが、前日の22時頃に突然決まったのでこういうのは勢いが大事だと感じた。
ちなみに開けてもらったのは耳たぶである。

当日9時頃に集合しピアッサーを買いに行くのだが、薬局には売っていなかったのでドン・キホーテまで買いに行った。

感想

開ける直前の恐怖は割と強く今までにない恐怖を感じた。
開けた瞬間の痛みとしては激痛というわけではないが声は出た。あっっって感じ。血は全く出ていなかったらしい。
30分ぐらいは痛みを感じていたが、時間が経つに連れて痛みは感じなくなっていく。

開けた後の満足感はすごかった。良かった。

謝辞

開ける位置も大変良く上手に開けてくれた知人には本当に感謝している。
ありがとう。

Ingress Nginxは何をしてるのか

Sun, 19 Jul 2020 07:34:27 GMT

前置き

ここで書いている内容は全ての事は書いてないし気になったところだけを順番に見ている。
公開後は随時追記や修正をしていくつもりである。

間違っている箇所があったりしたらTwitter(@let_constant)へDMとかで教えてください。

日付	内容
2020-07-19	`ingress-nginx-2.7.0` の内容で公開

NGINX Ingress Controllerとは

NginxをベースイメージとしてリバースプロキシやLBとして動作するIngress実装である。
L7で動作するのでホスト名やパスでのルーティング、SSLのオフロード等が実現できる。

他のIngress実装はTraefikやContourがあり、ここにまとめられている。

お気持ち

ServiceはClusterIPで公開する限りServiceにIPが振られるのでIngressはそれを見ていると思っていた。
ではそうなるとSticky Sessionsはどうやって実現しているのか不思議になった。
How it worksを読むと普通に書いてあるが、Endpointsを使用している。

これを知った時感動した。

Nginx IngressがServiceじゃなくてEndpoints見てるって知った時感動したよね
— さかもとりょーた(25) (@let_constant) May 27, 2020

ところで Nginx Ingress Controller のことを nginx-ingress なのか ingress-nginx って言えばいいのかいつもわからなくなる。正解を知りたい。

全体像

まずは大まかな全体像の図を貼る。
NodePort で公開されていたり、Job により Secret が生成されていたりする。

実装の話

バージョンは2020-06-21(日)時点で最新のingress-nginx-2.7.0
マニフェストはbaremetal/deploy.yaml

マニフェストを見るとcontrollerのDeploymentやJobが動いている事がわかる。
Podとして動いているものを順番に見ていく事にする。

ingress-nginx-controller
ingress-nginx-admission-create
ingress-nginx-admission-patch

ingress-nginx-controller {#ingress-nginx-controller}

イメージとしては下記のような順番で生成されている。

ビルド

ビルドは build/build.sh で行なっていて3つのバイナリを作っている。

nginx-ingress-controller はcontroller本体
wait-shutdown は preStop で叩いている
dbg はnginxの状態を検査するデバッグ用のツールである

go build \
  -ldflags "-s -w \
    -X ${PKG}/version.RELEASE=${TAG} \
    -X ${PKG}/version.COMMIT=${GIT_COMMIT} \
    -X ${PKG}/version.REPO=${REPO_INFO}" \
  -o "rootfs/bin/${ARCH}/nginx-ingress-controller" "${PKG}/cmd/nginx"

go build \
  -ldflags "-s -w \
    -X ${PKG}/version.RELEASE=${TAG} \
    -X ${PKG}/version.COMMIT=${GIT_COMMIT} \
    -X ${PKG}/version.REPO=${REPO_INFO}" \
  -o "rootfs/bin/${ARCH}/dbg" "${PKG}/cmd/dbg"

go build \
  -ldflags "-s -w \
    -X ${PKG}/version.RELEASE=${TAG} \
    -X ${PKG}/version.COMMIT=${GIT_COMMIT} \
    -X ${PKG}/version.REPO=${REPO_INFO}" \
  -o "rootfs/bin/${ARCH}/wait-shutdown" "${PKG}/cmd/waitshutdown"

nginxのバイナリは images/nginx/rootfs/build.sh で行なっていて、モジュール等のバージョンが書いてある。

controller本体 {#controller}

マニフェスト

提供されているマニフェストでは下記のような引数で起動している。
全ての引数の詳細はCommand line argumentsに書いてある。

--election-id はHPAやreplica数を増やした場合にリーダー選出するためのidである、リーダー選出する実装についてはここ
--ingress-class はクラスタ内で複数のIngress Controllerを動かしている際に指定が必要になる、GKEを使ってる場合とかはちゃんと指定する必要がある
--validating-webhook はAdmission Controllerを起動してシンタックスエラーがないか等を調べる、指定しない場合は起動されない

args:
  - /nginx-ingress-controller
  - --election-id=ingress-controller-leader
  - --ingress-class=nginx
  - --configmap=ingress-nginx/ingress-nginx-controller
  - --validating-webhook=:8443
  - --validating-webhook-certificate=/usr/local/certificates/cert
  - --validating-webhook-key=/usr/local/certificates/key

main.go

フラグのパースやサーバーの起動を実装している。

Kubernetesのバージョンが v1.14.0 v1.18.0 と比べてログを出したり IngressClass リソースから取得したりする
v1.14.0 未満では k8s.io/api/extensions/v1beta1 を使うようにログに出る
v1.18.0 からは IngressClass リソースが実装されていて、kubernetes.io/ingress.class アノテーションは非推奨になった
ヘルスチェック用のサーバー起動
GoやNginxのメトリクスを収集するためのCollectorの起動

$ kubectl -n ingress-nginx exec -it ingress-nginx-controller-7fd7d8df56-dv7s6 -- bash -c "curl -s localhost:10254/metrics | grep go_gc"
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 3.58e-05
go_gc_duration_seconds{quantile="0.25"} 9.96e-05
go_gc_duration_seconds{quantile="0.5"} 0.0002579
go_gc_duration_seconds{quantile="0.75"} 0.0006037
go_gc_duration_seconds{quantile="1"} 0.009535
go_gc_duration_seconds_sum 0.0567369
go_gc_duration_seconds_count 75

pprof用のエンドポイントを生やす、デフォルトでは 10245 番のポートで開放されていてここで実装されている
controllerの起動

controller.NewNGINXController にはcontrollerの実装が書かれているので次はここの実装を見る。
SIGTERM を投げることで停止されるようになっている。

ngx := controller.NewNGINXController(conf, mc)

mux := http.NewServeMux()
registerHealthz(nginx.HealthPath, ngx, mux)
registerMetrics(reg, mux)

go startHTTPServer(conf.ListenPorts.Health, mux)
go ngx.Start()

handleSigterm(ngx, func(code int) {
	os.Exit(code)
})

internal/ingress/controller/nginx.go

func NewNGINXController(Configuration, metric.Collector) NGINXController {#NewNGINXController}

EventBroadcaster の作成、ここにサンプルがあるがこれを使う事で Events に書き込む事ができる

eventBroadcaster := record.NewBroadcaster()
eventBroadcaster.StartLogging(klog.Infof)
eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{
	Interface: config.Client.CoreV1().Events(config.Namespace),
})

/etc/resolv.conf から nameserver の取得
Admission Controllerの設定
store.New でIngressやSecretといった各リソースのイベントが発火された際の処理を実装している
イベントの発火後は引数の updateCh に送信し、ここで受信する。

n.store = store.New(
	config.Namespace,
	config.ConfigMapName,
	config.TCPConfigMapName,
	config.UDPConfigMapName,
	config.DefaultSSLCertificate,
	config.ResyncPeriod,
	config.Client,
	n.updateCh,
	pod,
	config.DisableCatchAll)

(*NGINXController).syncIngress を syncQueue のcallback関数として指定している
キューにタスクが追加されるたびに syncIngress が実行される
syncIngress では実際にEndpointsを取ったりしている、ここは詳しく見ていく: nginx.go#L139

n.syncQueue = task.NewTaskQueue(n.syncIngress)

nginx.confのテンプレートの初期化
コンテナ内では /etc/nginx/template/nginx.tmpl に配置されるのでConfigMapを使う事で任意のnginx.confで動かす事が可能
GeoIPファイルの監視の設定

func (*NGINXController) Start() {#controller-start}

electionID を使ったリーダー選出し、Ingressリソースのステータスを更新するPodを決める、リーダー選出は client-go で実装されている。
--enable-ssl-passthrough を指定してcontrollerを起動した場合に、 nginx.ingress.kubernetes.io/ssl-passthrough アノテーションのついたリソースでSSLパススルーを行うプロキシサーバーの起動
Admission Controller の起動
Nginx の起動
syncQueue の起動、Exponential Backoff によるリトライの実装
Nginx の起動
updateCh から受信したイベントを syncQueue に流す

func (*NGINXController) Stop() error

Admission Controller の停止
Nginx の停止、Nginx が停止しているかどうかはプロセスの一覧を取ってnginxという名前がないか見ているだけのシンプルな実装である

func (*NGINXController) syncIngress(interface{}) error {#syncIngress}

キューにタスクが追加されるたびにこの関数が実行される。
実行はここでしている。

実際にここの処理で Endpoints を取得していることが確認できる
getConfiguration => getBackendServers => createUpstreams => serviceEndpoints

endp, err := n.serviceEndpoints(svcKey, path.Backend.ServicePort.String())

service-upstream が指定されている場合は Endpoints ではなく Service に振られているIPを使う
テンプレートを評価し、nginx -s reload を実行する

Admission Controller {#admission-controller}

Admission Controller のHadnlerの実装はここでしている。

if n.cfg.ValidationWebhook != "" {
		n.validationWebhookServer = &http.Server{
			Addr:      config.ValidationWebhook,
			Handler:   adm_controler.NewAdmissionControllerServer(&adm_controler.IngressAdmission{Checker: n}),
			TLSConfig: ssl.NewTLSListener(n.cfg.ValidationWebhookCertPath, n.cfg.ValidationWebhookKeyPath).TLSConfig(),
		}
	}

NGINXController は CheckIngress を実装していて、
Admission Controller がリクエストを受け取ると (*IngressAdmission) HandleAdmission(*v1beta1.AdmissionReview) が叩かれてその中で CheckIngress が叩かれる。

(NGINXController) CheckIngress(networking.Ingress) error

下記のような事を行なっている。

kubernetes.io/ingress.class アノテーションが起動時に指定した --ingress-class と一致するかどうか

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: application-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  backend:
    serviceName: application-service
    servicePort: 8080

起動時に --watch-namespace を指定していた場合、指定された Namescape かどうか
nginx -t による生成する予定の nginx.conf のテスト

Leader Election {#leader-election}

Leaderとなった Pod は Ingress のステータスを毎秒同期している。

client-go で実装されていて、 ConfigMap を使いロックをしている。
Leaderが落ちたりして renewTime の更新ができなかった場合は他の Pod が renewTime と holderIdentity を更新しLeaderに昇格する。

$ kubectl -n ingress-nginx get cm/ingress-controller-leader-nginx -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  annotations:
    control-plane.alpha.kubernetes.io/leader: '{"holderIdentity":"ingress-nginx-controller-75f84dfcd7-f22xq","leaseDurationSeconds":30,"acquireTime":"2020-06-22T14:38:14Z","renewTime":"2020-07-15T18:22:19Z","leaderTransitions":0}'
  creationTimestamp: "2020-06-22T14:38:14Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:metadata:
        f:annotations:
          .: {}
          f:control-plane.alpha.kubernetes.io/leader: {}
    manager: nginx-ingress-controller
    operation: Update
    time: "2020-07-15T18:22:19Z"
  name: ingress-controller-leader-nginx
  namespace: ingress-nginx
  resourceVersion: "295822"
  selfLink: /api/v1/namespaces/ingress-nginx/configmaps/ingress-controller-leader-nginx
  uid: 00f21dfe-d5d9-4dc0-becf-e7bbd45be4ff

wait-shutdown {#wait-shutdown}

シンプルな実装だった。

err := exec.Command("bash", "-c", "pkill -SIGTERM -f nginx-ingress-controller").Run()
if err != nil {
	klog.Errorf("unexpected error terminating ingress controller: %v", err)
	os.Exit(1)
}

// wait for the NGINX process to terminate
timer := time.NewTicker(time.Second * 1)
for range timer.C {
	if !nginx.IsRunning() {
		timer.Stop()
		break
    }
}

dbg {#dbg}

デバッグ用のCLIである。

$ /dbg --help
dbg is a tool for quickly inspecting the state of the nginx instance

Usage:
  dbg [command]

Available Commands:
  backends    Inspect the dynamically-loaded backends information
  certs       Inspect dynamic SSL certificates
  conf        Dump the contents of /etc/nginx/nginx.conf
  general     Output the general dynamic lua state
  help        Help about any command

Flags:
  -h, --help   help for dbg

Use "dbg [command] --help" for more information about a command.

ingress-nginx-admission-create {#ingress-nginx-admission-create}

kube-webhook-certgenに実装がある。
これは何をしているかというと期限の長い自己証明書を生成してシークレットに設定してくれるやつだ。

指定されているnamespaceのSecretが存在しなかった場合のみ生成されるようになっている。
ここではAdmission Controllerの証明書を生成しようとしているのがわかる。

- name: create
  image: jettech/kube-webhook-certgen:v1.2.0
  imagePullPolicy: IfNotPresent
  args:
    - create
    - --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.ingress-nginx.svc
    - --namespace=ingress-nginx
    - --secret-name=ingress-nginx-admission

100年後で生成されているのが確認できる。

$ kubectl -n ingress-nginx describe secret/ingress-nginx-admission
Name:         ingress-nginx-admission
Namespace:    ingress-nginx
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
cert:  623 bytes
key:   227 bytes
ca:    485 bytes

$ kubectl -n ingress-nginx get secret/ingress-nginx-admission -o jsonpath="{.data.ca}" | base64 --decode | openssl x509 -noout -dates
notBefore=Jun 22 14:32:42 2020 GMT
notAfter=May 29 14:32:42 2120 GMT

ingress-nginx-admission-patch {#ingress-nginx-admission-patch}

ではpatchは何をしているのか。

webhook-name に指定されている名前の ValidatingWebhookConfiguration を取得し、
実装としては各webhookに対して先程生成した自己証明書と failure-policy を設定している。

- name: create
  image: jettech/kube-webhook-certgen:v1.2.0
  imagePullPolicy: IfNotPresent
  args:
  - create
  - --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.ingress-nginx.svc
  - --namespace=ingress-nginx
  - --secret-name=ingress-nginx-admission

何をしているかはわかったがこれはcreateと一緒に済ませる事ができそうな感じがしてるので
これが導入された経緯も探してみたが特に書いてないので jettech/kube-webhook-certgen についても深追いしてみる。

Add a validating webhook for ingress sanity check #3802
このPRでAdmission Controllerによる検証が導入された。この時点ではJobは導入されていない。
[stable/nginx-ingress] Add Validation webhook for nginx ingress controller #17230
このPRでhelmチャートに追加された。

jettech/kube-webhook-certgen

結論から書くと設計思想のようなものは見つける事ができなかった。

helmチャートのPRを見るとわかるが、 Implementation is inspired by the prometheus operator webhooks と書いていて同じ仕組みで動いている。

[stable/prometheus-operator] PrometheusRule Admission Webhooks #14543
このPRでhelmチャートに追加された。
PrometheusRules Admission Webhooks
ドキュメントには上で書いていたような事がちゃんと書かれていた。

Review 2019

Sun, 29 Dec 2019 14:42:00 GMT

今年一番大きかった出来事は転職だ。

前職のGMOインターネットではサービスデザインチームという部署でConoHaというプロダクトをビジネスサイドから関わっていた。
OS・アプリケーションのイメージを作ったり、オブジェクトストレージのドキュメントを書いたりしてた。

現職のLINE Growth TechnologyではGoを書いたり、Kubernetesの検証とかをしている。

去年の始めにこんなことを言っているが、競プロは少しだけ頑張ってOSSと資格は特に何もやっていない。
来年はOSSにコントリビュートしたいし資格も取りたい。

OSSか競プロか資格を頑張ります
— さかもとりょーた(21) (@let_constant) January 2, 2019

1月

4月にリリースするやつのプロトタイプ的なのを作っていた記憶がある
プライベートではRustを書いていた

2月

蟻本をこの時期に読み始めたらしいが覚えていない

とうとう蟻本を読み始めることに成功した
— さかもとりょーた(21) (@let_constant) February 13, 2019

SRE本を買ったが未だに半分ぐらいしか読んでいない

やっていきがある pic.twitter.com/DB1KPpRSsD
— さかもとりょーた(21) (@let_constant) February 20, 2019

3月

部署移動を切望していた
ちなみに年末年始には伝えていたのに話は全然進んでいなかった

もう3月なんですけど僕はシステムに行けますか？
— さかもとりょーた(21) (@let_constant) March 5, 2019

4月

仕事では一人で開発してたやつでプレスリリースが出せた
サーバーはRust、フロントはNuxtで書いた

【GMOインターネット】気軽に使えるVPS「ConoHa byGMO」日本初、コマンド操作不要で「KUSANAGI」の管理が可能なツール「ConoHa KUSANAGI manager」提供開始 https://prtimes.jp/main/html/rd/p/000002608.000000136.html

令和になった

令和
— さかもとりょーた(21) (@let_constant) April 1, 2019

お名前が繋がりにくくなっているのを見ていた

お名前落ちてるじゃん
— さかもとりょーた(21) (@let_constant) April 1, 2019

ずっとWindowsだったがMacBook Proを買った
整備済み品で買った

MBP買ってしまった
— さかもとりょーた(21) (@let_constant) April 1, 2019

転職を考え始めた

転職先探してるのでよろしくお願いします
— さかもとりょーた(21) (@let_constant) April 19, 2019

5月

まあ評価されない会社にいてもしょうがないでしょ
— さかもとりょーた(21) (@let_constant) May 16, 2019

6月

内定が出た
退職エントリは書いていない

退職エントリ書くつもりなのでよろしくお願いします
— さかもとりょーた(21) (@let_constant) June 11, 2019

7月

k3sに感動していた

DockerからPrivateなDocker Registryを使ったk3sに移したけどとても体験が良い
— さかもとりょーた(21) (@let_constant) July 18, 2019

8月

人生で2回目の転職をした
From: GMOインターネット株式会社
To: LINE Growth Technology株式会社

そういえば転職しました pic.twitter.com/sFLUnwzvT9
— さかもとりょーた(21) (@let_constant) August 19, 2019

この頃は競プロをしていた

簡易タスクランナー作ったら捗るようになった pic.twitter.com/wY4UXQOkaV
— さかもとりょーた(21) (@let_constant) August 20, 2019

9月

チームで使ってるJenkinsfileと戦っていた

秘伝のJenkinsfile感あるな
— さかもとりょーた(21) (@let_constant) September 17, 2019

10月

何もしていない

11月

Rui Ueyama@rui314さんのCコンパイラをGoで書いていた

gccでちゃんと-gつけてから、gdb使ったら普通に便利で・・・
— さかもとりょーた(21) (@let_constant) November 10, 2019

12月

カオスエンジニアリングとかoperator-sdkとか色々見てた

https://t.co/W1EapXzUzS
— さかもとりょーた(21) (@let_constant) December 15, 2019

https://t.co/WaYCdw1hwU
— さかもとりょーた(21) (@let_constant) December 21, 2019

応用の勉強を始めた

そろそろ応用取るか
— さかもとりょーた(21) (@let_constant) December 26, 2019

Profile

Wed, 22 May 2019 15:54:08 GMT

Ryota Sakamoto(27)

I’m a Software Engineer and interested in container technologies(like Kubernetes), automation platform(like CI/CD, testing), SRE, application performance tuning, and so on.

Jobs

2016/03 ~ 2018/03: Software Engineer at Aijus
2018/04 ~ 2019/08: Service Design at GMO internet
2019/08 ~ 2021/07: Software Engineer at LINE Growth Technology
2021/08 ~ Now: Cloud Support Engineer at Amazon Web Services

OSS Maintainer

Other

Twitter / GitHub / LinkedIn