この記事は私が過去 3 年ほど Kubernetes に携わる中で学んだ、ちょっと見つけにくい知識をまとめたものです。 特にカスタムコントローラーを開発するような人に必要となる知識群です。
感想とか指摘とかあれば Twitter までお寄せください。
更新履歴
あけましておめでとうございます。年賀状代わりに開発環境の構築記事を差し上げます。
いやわりと真剣に、開発環境にはその開発者の近況が表れていると思うのですよ。
いっちょあなたもどうですか 😀
閑話休題。
以下今日やった Ubuntu 20.04 LTS のインストール作業記録です。語調変わるのはご勘弁。
新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。
日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。
モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。
ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・チームにも適用できない体験というそのこと自体を共有したいと考えて書いています。
続きを読む使おうとするたびに忘れて調べなおすのでメモ。
HTTP のレスポンスコード 100 は、クライアントが大きなデータを送る前に送信ヘッダレベルで リクエストの受付が可能か調べて、処理可能ならいったん返すためにある。
用途例： Authorization ヘッダによる認証, Content-Length によるサイズチェック
Go の http.Client では Transport で ExpectContinueTimeout を
0 以上に設定し、リクエストヘッダに Expect: 100-continue を入れれば、自動で 100 Continue を待機
してからボディを送るようになる。
http.Server は request.Body から読みだすと自動で 100 Continue 応答をクライアントに投げる。 なので 200 以外のエラーは Body から読みだす前にヘッダをチェックして返すようにすれば良い。
さて、テストコードなんて書きたくなかった私ですが、世の流れには逆らえず今はせっせとテストコードを量産しています。 開発完了＝試験完了＝出荷可能が求められる忙しない世の中でありますから。
目下開発しているのは Kubernetes 向けのネットワークソフトウェア Coil のバージョン 2 なんですが、この開発では main 文以外はすべて自動テストする徹底ぶりです。他にも近年様々にテストコードを書いてきた過程で、以下の知見を得るに至りました。
多分この結論に似たことはあちこちで言われている気はするのですが、結論に至った理由が大事と思うため、以下少し書きます。 あ、以下モックと言ってる用語は専門的には stub だったり test double だったりするかもしれませんが、細かいことは気にしないでください。
続きを読む仕事で、データセンターのアーキテクチャを刷新するプロジェクトを進めてます。 Kubernetes を中心としているので、必然的に Kubernetes 上で動作するアプリケーションを開発する機会があります。
Kubernetes は API サーバー (kube-apiserver) にリソースを登録して、他のプログラムは API サーバー上のリソースを監視して動く Hub & Spoke アーキテクチャを特徴としています。
出展：https://kubernetes.io/docs/concepts/architecture/cloud-controller/
Kubernetes の動作をカスタマイズするには、API サーバーの動作に手を入れる必要があります。kube-apiserver はそのための仕組みとして、通常の API に加えて以下を提供しています。
今回のお題はこの中の Webhook 実装についてです。長くて専門的かつ TL;DR もないのでご注意ください。
続きを読む業務で Linux 向けの Go プログラムを多数開発しています。
しかしながら、開発している機材の OS は好きこのんで Windows です。 在宅から勤務するときに、Windows のリモートデスクトップが最強すぎるので手放せないのが大きな理由です。
そんなわけで、Windows の Hyper-V という機能で Ubuntu を仮想マシンとして動作させ、Emacs で長年開発していました。
しかし近年、モニタも 4K 32 インチと大きくなりましたしメモリも 32 GB 搭載されていますし、なにより Visual Studio Code のような高機能 IDE が手軽に利用できる状況でありながら、ろくにカスタマイズをしない Emacs で開発を続けるのも怠慢かなと考え、「WSL で快適な Go 開発環境を作る」という記事に書いたように Windows + WSL + Visual Studio Code という開発環境を整えました。
開発しているコードは Linux 向けですので、いくら Go がクロスコンパイルが得意といっても本当は Ubuntu 上で開発できるのにこしたことはありません。Windows にせざるを得なかったのは、Ubuntu 上で動作させる Visual Studio Code を 4K の解像度で X プロトコルで表示させるとラグが大きすぎて実用に耐えなかったためでした。
しかし先日、Visual Studio Code から Electron を取り除き、WebSocket でブラウザに画面を表示させるようにする code-server が OSS でリリースされたことにより状況は一変しました。X プロトコルよりもずっと効率的に画面操作ができるので、Chrome on Windows + Ubuntu on Hyper-V + code-server を使うことで以下が実現するのです。
環境構築手順を以下にメモしておきます。
続きを読む