Goland+gotestsでテストのテンプレートを簡単に生成する

Goのテストを書く時、これまで手でテスト用のファイルや関数を作っていたのだけど、cweill/gotests というツールを同僚から教えてもらった。これはソースコードからTableDrivenTests ベースのテストコードを生成してくれる。エディタやIDEにも対応していて、Golandの場合はかなり高レベルのインテグレーションがなされていて便利(link)。

gotestsをREADMEの通りにインストールすれば、あとはGolandのエディタ画面上から ⌘N でコンテキストメニューを呼び出し、関数、ファイル、パッケージなどの単位でテストを生成できる。Golandを使っていなくてもぜひ使うといいツールだと思う。

Change IME mode to EIJI automatically when launch Alfred

I’m Japanese IME user. When I launch Alfred with HIRAGANA mode, I can’t input Alfred command smoothly e.g. following image.

So, I hope to change IME to EIJI mode automatically. Alfred has wonderful feature ‘Force Keyboard’. If this is enabled, IME mode will be changed specified mode when launch Alfred! If you want to use ‘Force Keyboard’, you open Alfred Preference, open ‘Advanced’ menu, and select IME mode in ‘Force Keyboard’ .

This is very happy feature, I recommend to config it. Enjoy Alfred!

vault-agent-injectorに関する調査記録

Kubernetesを使う上でPodに渡す秘匿情報をどう管理するか、という点は課題の一つです。Kubernetesの機能であるSecretを使うこともできますが、Hashicorp Vaultを利用している場合Vaultに秘匿情報を格納し、Pod起動時にVaultから取得できればいいなと思ったりもします。

この課題に対応するため、hashicorp/vault-k8sというツールをHashicorpが公開しています。Vaultに格納された秘匿情報を、サイドカー経由でPodに渡すことができるようです。このvault-k8sについてあれこれ調べたことについて紹介します。

Continue reading →

CAEP: Machine health checking a.k.a node auto repair proposal を読む

ClusterAPI v0.3.0で対応予定のMachine Health CheckingについてのCAEP(ClusterAPI Enhancement Proposal)を読んでみます。

このCAEPは、端的にいうと「異常なノードを検出してそれを復旧する」機能を追加するものです。2019年10月30日にPRが作成され、2019年12月19日にマージされています。

モチベーションとして、以下の2点が挙げられています。

  • クラスターを実行するための管理オーバーヘッドを減らす
  • マシン障害への対応能を高め、クラスターノードを正常に保つ

何らかの要因によってノードが正常に動作しなくなった場合、自動的に正常な状態に戻ってくれると管理コストは下がります。かなり嬉しい機能ですよね。gardener/machine-controller-managerは似たような機能を持っているのだけど、ClusterAPIにはなかったので、追いついた?形になります。

ゴールは以下の3点。

  • マシンやノードのグループの自動化された改善を有効にする
  • ノードグループごとに健全性の基準をユーザが定義できるようにする
  • 同時に複数のノードが異常な状態になった時、自動復旧を無効にする閾値を設定できるようにする

単に異常を検知して作り直す、というだけではなく、健全性の基準をユーザが定義できたり過剰に反応して逆にトラブルにならないよう考えられています。

プロポーザル

このプロポーザルでは、Machine Health Checker(MHC)を提案しています。これは不健全なノードを削除することでクラスタのノードを極力健全に保つためのものとあります。

さて、不健全なマシンを自動復旧するためには不健全とは何かの基準が必要です。プロポーザルは基準として3点挙げています。

  • マシンに関連づけられたノードが定義された異常なノードコンディションとなっている
  • マシンがnodeRefを持っていない
  • マシンがnodeRefを持っているが、そのノードがない

MachineHealthCheck CRD

どういうマシンを監視し、どういう場合に異常とみなすかはカスタムリソースを作ることで定義します。 プロポーザルに記載されているサンプルの場合、ノードが ready=Unknownready=Falseの状態で5分経過したら修復されます。また、マッチするノード群のうち40%が異常状態の場合、自動修復を無効にします。

apiVersion: cluster.x-k8s.io/v1alpha3
kind: MachineHealthCheck
metadata:
  name: example
  namespace: machine-api
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "5m"
  - type:    "Ready"
    status:  "False"
    timeout: "5m"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5

Machine Health Check はコントローラーとして実装されており、machineHealthCheckリソース、Machineリソース、Nodeリソースを監視します。あとはReconcileLoopでMachineやNodeの状態に応じてオペレーションを行うだけ。Machine Health Check コントローラはMachineリソースを削除するまでを行い、残りはMachineControllerやMachineSetControllerに任せています。

代替案

他の方法との比較についてもプロポーザル内で触れられています。MachineSetに組み込んだり、ラベルセレクターを使わずにMachineSetをターゲットにしたり、Pod Distributed Budgetのような物を検討したようですが、それぞれいまいちな点があり今回のプロポーザルの設計になったようです(英語力の問題で、却下した理由を理解できなかった)。

MachineHealthCheckリソースを作らなければ自動修復機能が動くこともないので、ClusterAPIをアップグレードしたら突然動いてびっくりする、ということもなく安心。やることがシンプルで、うまい設計だなあと思いました。