GITHUB_TOKENの指定をoptionalに変更
- commitメッセージの取得などに利用していたのですが、要らない人もいるよなーと思ってoptionalに変更
- GITHUB_TOKENが指定されていない場合は取得にトークンが必要なフィールドをカットしてpostします
(v3リリース予定) mention_only_fail を if_mention に変更
- 破壊的変更その1、failしたときだけメンションする機能なのですが、やや汎用性が低かったので if_mention に変更
- mentionしたいステータスを if_mention に記載してもらった上で mention にどのようなmentionをするか指定する方式
(v3リリース予定) payloadフィールドがコンフリクトしているので名前を変更
- 破壊的変更その2、payloadがGitHub Actions自体が使っているフィールドだった…
- ユーザが明示的に指定できるようにしていたのですが、それだと欲しい情報が欠落するケースがあったので custom_payload という名前に変更
- payloadの情報とGITHUB_TOKENを組み合わせるとJobの実行時間が取れる*2
(v3リリース予定) ドキュメント関係をgatsby + netlifyで管理するように変更
- どうしてもREADMEだと細かいこと書きにくいよなーと思っていた
- ドキュメントの細かいissueに対してREADMEに書くのも増えてくるとなぁと思っていた
- 初めてgatsby + netlify構成を試してみたけどpushすると自動でデプロイとかしてくれて凄い

その他Tech

GKEの更新(2回)
- 1月にus-west-1bのリージョンでずっとインスタンス不足で全然更新できなかった
- terraformのコードを書いてコミットもしたけどapplyできていなかったやつがやっとapplyできた
- 1月のコードをapplyしてマージした後にもう一度更新してapplyしたので2回更新
terraform-provider-googleを3系の最新に更新
- VPCネイティブのクラスタの設定の場合、自分でsubnetの設定とかを定義しないといけなくなった
- あんまりインターネットに例がない割にドキュメントも微妙だったので地味にだるかった
sops/goの更新
- 更新するだけだけどバージョンもgit管理なのでコミットが発生する*3
外部ドメインの証明書更新
- cert-managerで管理していない古いDNSがあり、それの証明書を更新
- tkドメインなのだけど、やたらTXTレコードの反映が遅くてlet's encryptのDNS経由の更新が何度か失敗
- 面倒になって今回からclouddnsで管理するように変更した(変更は早くなってない気もする...)
helm3移行
- helm2系だったものを重い腰を上げて3系に移行した*4
- 公式の移行プラグインが優秀で割とさくっと移行できた
- timeoutのフラグ指定フォーマットが変わっていてそこだけちょっとハマった
helm3フォーマットのchartに変更
- 既存chartをhelm3のフォーマットに書き直した*5
- StatefulSetとかで一部消さないといけないフィールドが変わってたりして地味だるだった
- 最初にどうでもいいchartから変更していて一部PVがロストしたりした*6
サービスの証明書が切れている報告問題の調査
- firebaseで構築しているサイトで証明書が切れているという報告があったので調査
- Googleのバグだった => firebase hostingのSSL証明書の更新が遅れていた - 839の日記
kube-state-metrics/ingress-nginxチャートの更新
- helm3更新前に最新にしておいた
cert-managerチャートの更新(v0.8->v0.13)
- 破壊的変更があると書かれていたのでビビって放置していたが意を決して実行
- 結局全部削除して入れ直しだったが、既存証明書は残せた
- let's encryptに対する秘密鍵の指定に破壊的変更があり(?)、ややハマった
deprecatedなサービスの削除対応
- ドメイン変更に伴うもので勧告期間は半年ぐらい設けていた
- 古い方はTypeScriptじゃなかったのだけど、これでそのサイトのある機能がやっとTypeScript一本にできた
prometheusでの保存先PVの節約
- prometheusのデータはデフォルトで一定期間ごとに削除されるのだが割り当てたdiskが余りすぎていた
- 今までのデータ量的に半分程度で十分ということがわかったので半分にした*7
codeclimate-test-reporterの修正
- 今までruby用のreporterを使っていたけどいつの間にかdeprecatedになっていたので変更

今月のGKEクラスタのSLAは98%を割ってしまった。
割と色々クラスタに対する工事をしていたので主な原因はそれ。

一番パンチがあったのはpreemptive VMのterminationで何故か謎ハマりをしてkube-system系の何かのpod(忘れた)が一番重要なノードに複数個作られていてそれがrequestsにしているリソース量が割と多かったせいでサービス継続に絶対必要なpodが立ち上がれていなかったのに半日ぐらい気づけなかったところ。絶対複数個いらないはずなのになぜか複数個できていたのでGKE側のバグだと思う、手動で消しても戻ってこなかったし。

ポケモン剣盾

頑張ってるけど意外と難しい、なかなか1万位を切るところまでいかなかった。。。
10万位は切れているのでとりあえず4桁を目指したい。

f:id:husq:20200301153829j:plain

*1:現在はv2

*2:まだ未実装で取り方だけは調べたが割とややこしい

*3:CDで使っている

*4:そろそろ大丈夫かな、とも思ったし

*5:15個ぐらいchartを作っていたので割と大変だった

*6:そのおかげでユーザが居るサービスは何事もなく移行できた

*7:金額的には微々たる差だが...

2020-02-22

replicas: 1のStatefulSetのPersistent Volumeサイズを変更する

infra

まず前提としてPVはリサイズが可能です。
refs: Resizing Persistent Volumes using Kubernetes - Kubernetes

1.11以降のクラスタで利用可能な機能で、事前にstorageclassの定義で allowVolumeExpansion: true を付ける必要があります。

自分が検証した際はサイズの増加は可能で減少は行なえませんでした。とはいえ運用上最小限の設定にしておいたなら増やすことはあれど減らすケースはほぼないと思われます。よくある例ではMySQLのStatefulSetを定義しサービスイン後にpvcのサイズを増加したいケースでしょうか。

しかしStatefulSet経由のPVCでPVを作成してしまうとディスクサイズの変更ができません。
例えば以下のようなyamlでsts内でpvcを作ったとします。

  volumeClaimTemplates:
    - metadata:
        name: my-pvc
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: my-storageclass
        resources:
          requests:
            storage: 1Gi

ストレージを2GBにしたい場合は以下のように変更します。

         storageClassName: my-storageclass
         resources:
           requests:
-            storage: 1Gi
+            storage: 2Gi

これをapplyしようとすると以下のようなメッセージが出て変更できません。

The StatefulSet "example-sts" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden

StatefulSetに設定したstorageのサイズを変更する例を調べると StatefulSet: support resize pvc storage in K8s v1.11 · Issue #68737 · kubernetes/kubernetes · GitHub が出てきます。

polarn commented on 5 Mar 2019 @alwinmarkcf You can delete the statefulset without the pods being deleted, by using kubectl delete sts --cascade=false - you can then apply a new statefulset and the pods will keep living.

ではstsは削除しつつpodを削除しないようにすることで新しいstsをapplyする際にpvcのサイズを変更する方法が提案されています。
ただこれはhelmなどで管理していた場合に色々と煩雑なのであまり取りたい手段ではありませんでした。

issueのコメントで

mlmhl commented on 18 Sep 2018 Maybe a better way is to directly update the request size of according PVC object.

とコメントされていますがこれを実現する形で試行し、自分のユースケースでは問題がありませんでした。以下のようにstsとpvcでyamlを分けてapplyします。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: pg-sts
spec:
  replicas: 1
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: pg
  serviceName: pg-svc
  template:
    metadata:
      labels:
        app: pg
    spec:
      volumes:
      - name: my-pv
        persistentVolumeClaim:
          claimName: my-pvc
      containers:
      - name: pg
        image: "postgres:11.5-alpine"
        ports:
        - containerPort: 5432
        volumeMounts:
        - name: my-pv
          mountPath: /var/lib/postgresql/data
        resources: {}
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: my-storageclass
  resources:
    requests:
      storage: 1Gi

その場合、変更するのはpvc側だけでsts側は変更せずにstorageのサイズを変更できます。この方式だとStatefulSetを使いつつPVのサイズが変更できます。

以下のURLでissueにコメントしてみたところ、StatefulSetはreplicasのpod数分pvcを作成してくれるようです。自分は費用的にケチってreplicas: 1で運用していたので気づきませんでしたが、replicas: 3で0をmaster、その他をread replicaで使うなどといったより本番的なユースケースでは上記手法は有効ではなさそうです。
refs: https://github.com/kubernetes/kubernetes/issues/68737#issuecomment-589934270