nekop's blog

OpenShift / JBoss / WildFly / Infinispanの中の人 http://twitter.com/nekop

Red HatのOpenJDKのサポート

【JDK 11 リリース直前】各ベンダーのJDKリリースモデル特集！というイベントがあってRed Hatさんもどうですか、ってお誘いが来たんですが予定が入っており参加できなかったのでエントリを書いておきます。

Red Hat Enterprise Linux (RHEL)には商用サポートされるOpenJDKパッケージが含まれています。RHELのサブスクリプション費用に含まれており、OpenJDKのサポートには追加の費用はかかりません。yum install java-1.8.0-openjdkのようにパッケージをインストールすれば使えます。

OpenJDKのサポート期間についてはOracle社の影響が大きいという側面があり、RHELのサポート期間とは異なるサポート期間が定められています。

サポート期間についてOpenJDK 6は開始時点が遅かったので短くなっていますが、7も8も実績として8年はサポートしています。6と7についてはOracle社による無償アップデート終了後、UpstreamをRed Hatがリードしています。8もそうなるかな？

新しいOpenJDKリリースモデルで非LTSリリースとなったOpenJDK 9, 10などはRed Hatでは商用サポート予定はありません。LTSリリースのみ商用サポート予定となっていくと思います。

サポート内容はプロダクションサポートと呼ばれるもので、利用中の障害、バグの調査、バグ修正やセキュリティ修正の提供などが含まれます。開発サポートではないので、APIの使い方がわからない、といったような質問はサポート範囲外となります。

RHEL 7.5以降のOpenJDK 8ではウルトラローポーズGCであるShenandoah GCがサポートされています。-XX:+UseShenandoahGCで有効化できます。Shenandoah GCについてはサイボウズさんのざっくりわかった気になるモダンGC入門を見ると良いと思います。OpenJDK 11にExperimentalとして含まれるZGCについても書かれています。

あとはWindowsで開発して本番はRHEL、という一般的なユーザ向けにWindows版開発用OpenJDKというのも配布しています。開発用途専用です。Mac版は現時点で残念ながらありません。

OpenJDKへのコントリビュートはOracle社が圧倒的ですが、Oracle社以外ではRed Hatが一位となっています。

まとめ

  • Red Hat Enterprise Linux (RHEL)には長期商用サポートされるOpenJDKが含まれているよ
  • OpenJDK 11もOpenJDK 7, 8と同様にサポート予定だよ
  • RHEL 7.5以降のOpenJDK 8でウルトラローポーズGCのShenandoah GC使えるよ

Red Hat OpenShift Service Meshをインストールしてみる

Red Hat OpenShift Service Meshがプレビューリリースしたのでインストールしてみます。OpenShift向け製品版のIstioです。

セットアップはこんな感じ。

# Enable admission webhooks in master
MASTER_CONFIG_PATCH="admissionConfig:
  pluginConfig:
    MutatingAdmissionWebhook:
      configuration:
        apiVersion: v1
        disable: false
        kind: DefaultAdmissionConfig
    ValidatingAdmissionWebhook:
      configuration:
        apiVersion: v1
        disable: false
        kind: DefaultAdmissionConfig"
sudo cp -a /etc/origin/master/master-config.yaml{,.prepatch}
sudo oc ex config patch /etc/origin/master/master-config.yaml.prepatch -p "$MASTER_CONFIG_PATCH" | sudo tee /etc/origin/master/master-config.yaml
sudo /usr/local/bin/master-restart api
sudo /usr/local/bin/master-restart controllers

# sysctl vm.max_map_count=262144 on each node
echo "vm.max_map_count = 262144" | sudo tee -a /etc/sysctl.d/99-elasticsearch.conf
sudo sysctl vm.max_map_count=262144

# Install istio
curl -LO https://raw.githubusercontent.com/Maistra/openshift-ansible/maistra-0.1.0-ocp-3.1.0-istio-1.0.0/istio/istio_product_operator_template.yaml
oc new-project istio-operator
oc new-app -f istio_product_operator_template.yaml --param=OPENSHIFT_ISTIO_MASTER_PUBLIC_URL=https://s310.example.com:8443
cat <<EOF | oc create -n istio-operator -f -
apiVersion: "istio.openshift.com/v1alpha1"
kind: "Installation"
metadata:
  name: "istio-installation"
spec:
  jaeger:
    elasticsearch_memory: 1Gi
EOF

セットアップ直後の状態はこうなります。

$ oc get all -n istio-operator
NAME                                  READY     STATUS    RESTARTS   AGE
pod/istio-operator-5df6cbf496-tlrfn   1/1       Running   0          18m

NAME                     TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
service/istio-operator   ClusterIP   172.30.186.9   <none>        60000/TCP   18m

NAME                             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/istio-operator   1         1         1            1           18m

NAME                                        DESIRED   CURRENT   READY     AGE
replicaset.apps/istio-operator-5df6cbf496   1         1         1         18m


$ oc get all -n istio-system
NAME                                              READY     STATUS              RESTARTS   AGE
pod/openshift-ansible-istio-installer-job-j2c6m   0/1       ContainerCreating   0          58s

NAME                                              DESIRED   SUCCESSFUL   AGE
job.batch/openshift-ansible-istio-installer-job   1         0            58s

openshift-ansible-istio-installer-job podはAnsibleを実行しているようです。この実行が終わったらセットアップ完了で以下の状態になります。

$ oc get all -n istio-system
NAME                                              READY     STATUS      RESTARTS   AGE
pod/elasticsearch-0                               1/1       Running     0          8m
pod/grafana-6d5c5477-rbskl                        1/1       Running     0          19m
pod/istio-citadel-6f9c778bb6-trf6k                1/1       Running     0          21m
pod/istio-egressgateway-957857444-dx26j           1/1       Running     0          21m
pod/istio-galley-c47f5dffc-dn25p                  1/1       Running     0          21m
pod/istio-ingressgateway-7db86747b7-l86zp         1/1       Running     0          21m
pod/istio-pilot-5646d7786b-s29kv                  2/2       Running     0          21m
pod/istio-policy-7d694596c6-698v5                 2/2       Running     0          21m
pod/istio-sidecar-injector-57466d9bb-z6vdv        1/1       Running     0          21m
pod/istio-statsd-prom-bridge-7f44bb5ddb-2d75m     1/1       Running     0          21m
pod/istio-telemetry-7cf7b4b77c-6vxn4              2/2       Running     0          21m
pod/jaeger-agent-9f4xz                            1/1       Running     0          18m
pod/jaeger-collector-9c9f8bc66-7278h              1/1       Running     7          18m
pod/jaeger-query-fdc6dcd74-v9t5c                  1/1       Running     7          18m
pod/openshift-ansible-istio-installer-job-j2c6m   0/1       Completed   0          25m
pod/prometheus-84bd4b9796-wwfms                   1/1       Running     0          21m

NAME                               TYPE           CLUSTER-IP       EXTERNAL-IP                   PORT(S)                                                                                                     AGE
service/elasticsearch              ClusterIP      172.30.38.243    <none>                        9200/TCP                                                                                                    19m
service/elasticsearch-cluster      ClusterIP      172.30.117.160   <none>                        9300/TCP                                                                                                    19m
service/grafana                    ClusterIP      172.30.182.60    <none>                        3000/TCP                                                                                                    19m
service/istio-citadel              ClusterIP      172.30.169.27    <none>                        8060/TCP,9093/TCP                                                                                           21m
service/istio-egressgateway        ClusterIP      172.30.177.77    <none>                        80/TCP,443/TCP                                                                                              21m
service/istio-galley               ClusterIP      172.30.22.227    <none>                        443/TCP,9093/TCP                                                                                            21m
service/istio-ingressgateway       LoadBalancer   172.30.253.232   172.29.93.241,172.29.93.241   80:31380/TCP,443:31390/TCP,31400:31400/TCP,15011:32718/TCP,8060:30594/TCP,15030:30606/TCP,15031:32105/TCP   21m
service/istio-pilot                ClusterIP      172.30.111.153   <none>                        15010/TCP,15011/TCP,8080/TCP,9093/TCP                                                                       21m
service/istio-policy               ClusterIP      172.30.49.238    <none>                        9091/TCP,15004/TCP,9093/TCP                                                                                 21m
service/istio-sidecar-injector     ClusterIP      172.30.11.70     <none>                        443/TCP                                                                                                     21m
service/istio-statsd-prom-bridge   ClusterIP      172.30.48.15     <none>                        9102/TCP,9125/UDP                                                                                           21m
service/istio-telemetry            ClusterIP      172.30.72.184    <none>                        9091/TCP,15004/TCP,9093/TCP,42422/TCP                                                                       21m
service/jaeger-collector           ClusterIP      172.30.129.165   <none>                        14267/TCP,14268/TCP,9411/TCP                                                                                18m
service/jaeger-query               LoadBalancer   172.30.244.29    172.29.154.76,172.29.154.76   80:32087/TCP                                                                                                18m
service/prometheus                 ClusterIP      172.30.49.188    <none>                        9090/TCP                                                                                                    21m
service/tracing                    LoadBalancer   172.30.115.191   172.29.75.1,172.29.75.1       80:30290/TCP                                                                                                17m
service/zipkin                     ClusterIP      172.30.202.148   <none>                        9411/TCP                                                                                                    18m

NAME                          DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
daemonset.apps/jaeger-agent   1         1         1         1            1           <none>          18m

NAME                                       DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/grafana                    1         1         1            1           19m
deployment.apps/istio-citadel              1         1         1            1           21m
deployment.apps/istio-egressgateway        1         1         1            1           21m
deployment.apps/istio-galley               1         1         1            1           21m
deployment.apps/istio-ingressgateway       1         1         1            1           21m
deployment.apps/istio-pilot                1         1         1            1           21m
deployment.apps/istio-policy               1         1         1            1           21m
deployment.apps/istio-sidecar-injector     1         1         1            1           21m
deployment.apps/istio-statsd-prom-bridge   1         1         1            1           21m
deployment.apps/istio-telemetry            1         1         1            1           21m
deployment.apps/jaeger-collector           1         1         1            1           18m
deployment.apps/jaeger-query               1         1         1            1           18m
deployment.apps/prometheus                 1         1         1            1           21m

NAME                                                  DESIRED   CURRENT   READY     AGE
replicaset.apps/grafana-6d5c5477                      1         1         1         19m
replicaset.apps/istio-citadel-6f9c778bb6              1         1         1         21m
replicaset.apps/istio-egressgateway-957857444         1         1         1         21m
replicaset.apps/istio-galley-c47f5dffc                1         1         1         21m
replicaset.apps/istio-ingressgateway-7db86747b7       1         1         1         21m
replicaset.apps/istio-pilot-5646d7786b                1         1         1         21m
replicaset.apps/istio-policy-7d694596c6               1         1         1         21m
replicaset.apps/istio-sidecar-injector-57466d9bb      1         1         1         21m
replicaset.apps/istio-statsd-prom-bridge-7f44bb5ddb   1         1         1         21m
replicaset.apps/istio-telemetry-7cf7b4b77c            1         1         1         21m
replicaset.apps/jaeger-collector-9c9f8bc66            1         1         1         18m
replicaset.apps/jaeger-query-fdc6dcd74                1         1         1         18m
replicaset.apps/prometheus-84bd4b9796                 1         1         1         21m

NAME                             DESIRED   CURRENT   AGE
statefulset.apps/elasticsearch   1         1         19m

NAME                                              DESIRED   SUCCESSFUL   AGE
job.batch/openshift-ansible-istio-installer-job   1         1            25m

NAME                                            HOST/PORT                                              PATH      SERVICES               PORT              TERMINATION   WILDCARD
route.route.openshift.io/grafana                grafana-istio-system.apps.s310.example.com                       grafana                http                            None
route.route.openshift.io/istio-ingressgateway   istio-ingressgateway-istio-system.apps.s310.example.com          istio-ingressgateway   http2                           None
route.route.openshift.io/jaeger-query           jaeger-query-istio-system.apps.s310.example.com                  jaeger-query           jaeger-query      edge          None
route.route.openshift.io/prometheus             prometheus-istio-system.apps.s310.example.com                    prometheus             http-prometheus                 None
route.route.openshift.io/tracing                tracing-istio-system.apps.s310.example.com                       tracing                tracing           edge          None

アプリケーションを作ってみます。Istioではinit containerでiptablesを利用するのでprivilegedコンテナにする必要があるのですが、コミュニティ版IstioをOpenShiftで利用するときにinit containerをprivilegedとしてinjectionしてくれない、という問題がありました。OpenShift製品版のIstioはprivilegedとしてinjectionしてくれるようです。

oc new-project test-istio
oc adm policy add-scc-to-user privileged -z default
oc new-app https://github.com/nekop/hello-sinatra
oc patch dc/hello-sinatra -p 'spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"'

namespaceのlabel istio-injection=enabledでのinjectionも軽く試してみたのですが、そちらは動作していないように見えます。OpenShiftではbuild podにinjectionされると問題となる(ビルドに必要な通信がIstioで許可されていなくて失敗するなど)ので、その関係で無効化されていそうです。

再デプロイされたpodはinit containerとproxy sidecarがinjectionされています。

$ oc get pod
NAME                    READY     STATUS      RESTARTS   AGE
hello-sinatra-1-build   0/1       Completed   0          9m
hello-sinatra-2-9p6gx   2/2       Running     0          7m
$ curl hello-sinatra.test-istio.svc:8080
hello

Prometheusを開いてhello_sinatraと入力したときに各種メトリクスが見えるようになっていれば問題なく動作しています。

子供にBluetooth trackerのTile Mateを持たせてみた

いま子供が6才と4才と1才なんだけど、幼児はショッピングモールなどの人混みやちょっと大きい公園に行ったりすると、大人ができる限り気を付けていてもちょくちょく居なくなってしまう。最近近隣で知り合いの迷子事例もいくつかあり、これは気をつけるというレベルでどうにかできる問題ではなさそうなので、技術的なアプローチをとってみることにした。

キャリアが提供しているGPSとSIM付きのキッズケータイが恐らく一番良いのだろうけど、幼児にはオーバースペックだ。ということでとりあえず一番ポピュラーなBluetooth trackerのTile Mateを持たせてみた。いわゆる忘れ物防止タグ。

Tileを持たせてみる、とはいっても幼児は基本的にモノをすぐ失くしてしまうので、生で持たせるのは問題外だ。カバンやケータイは動くのに邪魔になる大きさなので遊ぶのに外してしまう可能性がある。もっとぴたっと身につけるもの、腕時計タイプのものがベストかなぁ、と思っていたところで二の足を踏んでいたんだけど上の子が年長クラスになって移動ポケットをつけるようになり、下の子も欲しがったのでこれにトラッカー仕込めばいいじゃん、ということになり早速Tile Mate 3個パックを買ったのが二ヶ月ほど前。Tileを移動ポケットに入れて、基本的な機能を説明して大事なものだからお出かけするときはおやつを一個入れて必ず移動ポケット付けてね、と教えたところきちんと実践するようになった。おやつが多分ポイント。移動ポケットにはついでに連絡先カードも入れておこう。

Tile以外にはmamorioやTrackRも良さそうだったんだけど、現時点ではTileユーザのほうが多くてカバー範囲が広そうであることと、ケータイからTileの音を鳴らす機能がある、という2点でTileを選択。

Tileは音を鳴らして子供に合図を送れる、子供がTileをダブルクリックして親のケータイを鳴らせる(4才ちゃんは鳴らして遊んでしまうことが簡単に予想されるのでこの機能は教えていない)、という2点は使い勝手が良い。Tileから鳴る音は比較的小さめなケータイの着信音程度なので、大きな音が鳴って迷惑になったりはしなさそうだけど場合によっては鳴っていることには気付かないかもしれない。移動ポケットごとタンスの中に入っていたときに、音を鳴らしてもタンスにほぼ接触するくらい近づかないと音が聞こえなかった。

一方、Tileのアプリで子供の位置はなんとなくの範囲しかわからないので、精度の高い探索はあまりできなさそうだ。Tileアプリを開けば子供が居る方向くらいわかるかなー、と思ったけど自分のケータイを中心とした円が表示されてこの範囲に居ます、みたいな表示がほとんどなので多くの場合方向もわからない。たぶんTileのBluetoothを拾った自分のケータイのGPSの位置が報告されるだけかな。Bluetoothの情報は位置補正まではしていない雰囲気がある。距離取って円の範囲は調整してるかな。Tileが自分のケータイのBluetooth範囲にあるかどうかの確認と、ちょっと遠くに行った場合や一定距離はぐれた場合などに、他のTileユーザ網に引っかかってくれればOK、程度に思っておいたほうがよさそうだ。それでも安心度は格段に違う。

Tile Mateは通信距離30mで、Tile Pro SportとTile Pro Styleは約4000円と値段が倍になるけど通信距離60m、防水、音が大きいといった利点も揃っているので子供の迷子防止ならProでもいいかもしれないなー、と思っているところ。

【Amazon.co.jp限定】Tile Mate 3個パック 落としモノ/失くしモノ防止トラッカー 携帯GPS[日本正規代理店品](1年保証付) EC-06001-JC-3P

【Amazon.co.jp限定】Tile Mate 3個パック 落としモノ/失くしモノ防止トラッカー 携帯GPS[日本正規代理店品](1年保証付) EC-06001-JC-3P

OpenShiftでコンテナの詳細を調べる

OpenShift Origin（OKD）に、Node.jsアプリケーションをデプロイしていろいろ試すというエントリで「コンテナに引数を設定してみる」でargsを利用しているところで「ですがまあ、これは不正解な気がします。」と書いていてソース方面を見にいくという方法を取っていますが、それをOpenShift上できちんと裏付け調査する方法について書いておきます。

アプリケーションは以下のサンプルを利用しています。手元の環境ではOCP 3.9を利用していますがokd 3.10でも一緒です。

oc new-app https://github.com/sclorg/nodejs-ex

現在のコンテナで何が実行されるかはコンテナイメージメタデータのEntrypointとCmdを見る必要があります。コンテナイメージメタデータはImageStreamに入っていてImageStreamTagというvirtual objectを通して参照できるようになっています。

$ oc get istag
NAME               DOCKER REF                                                                                                                       UPDATED          IMAGENAME
nodejs-ex:latest   docker-registry.default.svc:5000/test-nodejs/nodejs-ex@sha256:7222ec78ef8e9f84a119fece9eeb49053718e4bd7fba6d203c23ea7fe30f99f5   36 minutes ago   sha256:7222ec78ef8e9f84a119fece9eeb49053718e4bd7fba6d203c23ea7fe30f99f5
$ oc export istag nodejs-ex:latest
apiVersion: v1
generation: 1
image:
  dockerImageLayers:
  - (省略)
  dockerImageMetadata:
    Config:
      Cmd:
      - /usr/libexec/s2i/run
      Entrypoint:
      - container-entrypoint
      Env:
      (以下省略)

ちなみにistagはvirtual objectであるせいか、oc export istagやoc get istag -o yamlというようにオブジェクト名の指定を省略した場合はコンテナメタデータなどの詳細を表示しないという挙動となるようです。上のようにoc export istag nodejs-ex:latestと指定する必要があります。ちょっとはまりました。

OpenShiftではクライアントサイドにocコマンドさえあれば、dockerなどがインストールされていなくてもこういったコンテナの詳細が調査できるのが便利です。

次にcontainer-entrypointと/usr/libexec/s2i/runは何か、という話になりますが、これはコンテナイメージ内を調査する必要があります。コンテナイメージ内の調査は場合によって以下の3種類のどれかを利用します。

  • 既存のPodにoc rsh (Entrypint, Cmdが既に実行されている状態の調査)
    • 例: oc rsh dc/node-ex
  • 既存のDeploymentConfigにoc debug (Entrypint, Cmd実行前の状態の調査)
    • 例: oc debug dc/node-ex
  • oc run (s2iイメージなどDeploymentConfigなどが存在しないイメージの調査)
    • 例: oc run foo --image=docker-registry.default.svc:5000/test-nodejs/nodejs-ex@sha256:7222ec78ef8e9f84a119fece9eeb49053718e4bd7fba6d203c23ea7fe30f99f5 --command -- tail -f /dev/null

今回は直接rshで問題ありません。

oc rsh dc/nodejs-ex

コンテナに入ったら必要なファイルなどを調査します。

sh-4.2$ which container-entrypoint
/usr/bin/container-entrypoint
sh-4.2$ cat $(which container-entrypoint)
#!/bin/bash
exec "$@"
$ cat /usr/libexec/s2i/run 
#!/bin/bash

# S2I run script for the 'nodejs' image.
# The run script executes the server that runs your application.
#
# For more information see the documentation:
#   https://github.com/openshift/source-to-image/blob/master/docs/builder_image.md
#

set -e

if [ -e "/opt/app-root/etc/generate_container_user" ]; then
  source /opt/app-root/etc/generate_container_user
fi

# Runs the nodejs application server. If the container is run in development mode,
# hot deploy and debugging are enabled.
run_node() {
  echo -e "Environment: \n\tDEV_MODE=${DEV_MODE}\n\tNODE_ENV=${NODE_ENV}\n\tDEBUG_PORT=${DEBUG_PORT}"
  if [ "$DEV_MODE" == true ]; then
    echo "Launching via nodemon..."
    exec nodemon --inspect="$DEBUG_PORT"
  else
    echo "Launching via npm..."
    exec npm run -d $NPM_RUN
  fi
} 

#Set the debug port to 5858 by default.
if [ -z "$DEBUG_PORT" ]; then
  export DEBUG_PORT=5858
fi

# Set the environment to development by default.
if [ -z "$DEV_MODE" ]; then
  export DEV_MODE=false
fi

# If NODE_ENV is not set by the user, then NODE_ENV is determined by whether
# the container is run in development mode.
if [ -z "$NODE_ENV" ]; then
  if [ "$DEV_MODE" == true ]; then
    export NODE_ENV=development
  else
    export NODE_ENV=production
  fi
fi

# If the official dockerhub node image is used, skip the SCL setup below
# and just run the nodejs server
if [ -d "/usr/src/app" ]; then
  run_node
fi

# Allow users to inspect/debug the builder image itself, by using:
# $ docker run -i -t openshift/centos-nodejs-builder --debug
#
[ "$1" == "--debug" ] && exec /bin/bash

run_node

起動はNPM_RUN環境変数を引数にしているようなので、これを調整するのが正解だとわかります。デフォルトの定義を調べます。

$ oc export istag nodejs-ex:latest | grep NPM_RUN
      - NPM_RUN=start

というわけで、 NPM_RUN='start arg1'と設定するのがこのイメージのお作法である、で正解です。

s2iに限らず、どのようなイメージでもoc import-imageとoc runしてしまえばImageStreamとDeploymentConfigが出来るのでOpenShift上でイメージの調査ができるようになります。

Kubernetes/OpenShiftのバージョンアップとクラスタをどのように分けるか問題

Kubernetes/OpenShiftのバージョンアップをどのようにするか、およびクラスタをどのように分けるかという問題はk8s関連のmeetupでよく出る話題です。昨日のレッドハット on Cloud Dayでも出たので、現時点での自分が知っている情報や考えを書いておきます。

現時点で自分が一番しっくりくるそれなりな規模の構成はdev, testing, staging, prodの4種類を2クラスタずつ用意、8クラスタの構成です。規模によってはtesting, stagingは一つにしてしまってもいいと思います。

各ステージのクラスタ、たとえばprod1, prod2はBlue-green deploymentのような形で利用します。たとえばprod1はk8s 1.7, prod2は一つ新しいk8s 1.8となっていて、新規のデプロイは全てバージョンの新しいほうであるprod2に行います。各アプリケーションへのトラフィックはLBでprod1, prod2へ振り分けを切り換えられるように構成します。また、アプリケーションがクラスタを移動する際にストレージのPVのデータの移行がストレートにできないので、その部分は何らかの仕組みを用意する必要があります。

移行期間を置いてprod1のアプリが全部prod2へ移行されたあと、prod1のアップグレードを行ったり、もしくはクリーンに作り直して再度利用可能にし(もちろん事前にprod3を作っておいてprod1を破棄でも良い)、新規のデプロイメントはこちらにデプロイするようにします。このような2クラスタに分ける構成では、片方のクラスタで障害があっても、もう片方のクラスタにすぐデプロイできる体制ができているはずなので、バックアップとしても機能します。また、k8sのアップグレードがアプリケーションに影響しない、もしくは常にクリーンインストールを行うことでアップグレードという作業自体をなくすことができる構成になります。ワークロードはクラスタを分けても分けなくても変わらない、デプロイされているアプリの総数は変わらないはずなので、コンピューティングノードのノード数のオーバヘッドはほどんどありません。

逆にdev, test, prodのワークロードをnode selectorで分けて全部ひとつのクラスタにするという構成もあります。リソース共有の効率化、集約度向上、運用負荷が非常に軽くなるなどの利点も多くありますが、いくつか懸念があります。

  • masterやetcdのバグで環境がダウンするリスク
  • masterやetcdのワークロードはdev, test, prodで共有することになるので、たとえばdevでk8s APIやネットワーク帯域を利用するアプリの負荷テストなどで環境ダウンのリスク
  • バージョンアップで動作しなくなる

k8sはソフトウェアなので当然バグはあります。最近のものを挙げるとmaster APIへのLBの数秒のメンテを行ったらノードが全てNodeNotReadyになってPodも全部NotReadyになるというようなクラスタごと使えなくなるようなバグもやはりあります。そのような状況を許容できる、泣かないのであればクラスタを分けないという選択肢もアリだとは思います。

もちろんクラスタを分けて複数クラスタを運用するコストも小さくはないので、どの程度のAvailabilityやResiliencyが必要かによって構成を選択しましょう。

バージョンアップの問題はさまざまです。master/etcdが起動しなくなるものや、Podのvalidationのルールが変わって以前のバージョンでは動いてたものが動かなくなったり、それらを消そうとしても新しいバージョンのvalidationに引っかかって消えないPodやnamespaceができたり、それら消えない中途半端なオブジェクトが残っているとバージョンアップのプロセスがエラーになって進まなかったり、というような感じです。根本的な解決にはetcdのデータを直接修正したり消したりというような、それなりの知識が必要かつ危険度の高いアクションが必要になることがあります。アップグレードの前に少なくともスナップショット取得、バックアップリストアは必ずテストしましょう。

あとはどのk8sを選択すればいいか、どのような運用体制が必要かという話があったのでついでに。

  • Non-managed k8s
    • 中規模から大規模
    • クラウド上のVMだけどManagedは使えないもしくはオンプレ必須となる特殊要件
    • k8s環境をゴリゴリカスタマイズしたい
    • インフラ5人フルタイム
  • OpenShift
    • どの規模でもオンプレでもクラウドでもいける
    • レールに乗ればとりあえず始められる、という状況が欲しい人。必要なコンポーネントが揃っていてこうやってつかえばいい、というユースケースがある程度用意されている
    • インフラ2人フルタイム
  • Managed k8s (GKE, AKS, EKS, etc)
    • インフラ専任いらない

なぜか小規模なのにオンプレNon-managed k8sを選択してしまって大変、という話をたまに聞きますが、Managed使った方がいいと思います。オンプレk8sは立ち上げのコストが高いので、安易に手を出すと時間が溶けやすいので注意しましょう。

また、Managedを使うにしてもGKE, AKS, EKS, etc.どれを使えばいいのですか、という話もありましたが、既にどれかクラウド環境を使っているような方はManagedなデータベースなど他の機能への連携もありますしとりあえずそのままそちらのサービスを使う、ということが多いのではないかと思います。そのような前提が無いのであれば、どれを利用しても良いんじゃないかと思います。

Container SIG Meet-up 2018 SummerでKubernetesのServiceとかIngressの話をしました

Container SIG Meet-up 2018 SummerでKubernetes Service, Ingress and OpenShift Routerというお題でお話しました。

資料は以下に置いています。

slide.comはRed Hatのコーポレートアカウントを使っているのですが、設定が変わったようでpublicの設定ができないようになっていて、token付きのexternalのURL共有でなんか微妙な感じに。slide.comはプレゼンテーション用に画像でインポートしたものなので、文字やリンクをクリックしたい場合はPDFを利用してください。

さて、最後にService IPでアクセスしてるとコネクションベースのヘルスチェックがないのでノードダウン時に40秒間くらいアクセスできたりできなかったりするので注意してね、という話をしたのですが、その生ログを一応載せておきます。

以下2 replicaのpodのClusterIPへのアクセスです。末尾kwgjfとbkz58の2つのPodが確認できます。

[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:51 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:51 EDT 2018
hello-sinatra-3-bkz58
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:53 EDT 2018
hello-sinatra-3-bkz58
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:54 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:55 EDT 2018
hello-sinatra-3-bkz58
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:56 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:22:57 EDT 2018
hello-sinatra-3-kwgjf

片方のPodが載っているノードをpoweroff -fしてダウンの状況にします。curlを再開するとハングしたりするのでCtrl-cしたりしないといけなくなったり、curl: (7) Failed connect to 172.30.81.27:8080; No route to hostが返却されたりするのが確認できます。生きているPodへ振り分けられた場合は問題なくレスポンスが返却されています。

$ date; ssh stack86-33 sudo poweroff -f
Wed May 23 03:24:06 EDT 2018
Powering off.
^CKilled by signal 2.
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:26 EDT 2018
^C
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:29 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:30 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:31 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:32 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:33 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:34 EDT 2018
^C  
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:38 EDT 2018
hello-sinatra-3-kwgjf
[cloud-user@stack86-32 ~]$ date; curl 172.30.81.27:8080/hostname; echo
Wed May 23 03:24:38 EDT 2018
curl: (7) Failed connect to 172.30.81.27:8080; No route to host

クライアント側で地道にタイムアウトとリトライができる場合はそれでいいのですが、既存のソフトウェアを動かしたいようなユースケースでそのあたりの設定ができない場合とか困ります。今のところこれをうまくハンドリングする定石みたいなものはないと思っているのですが、何か良い案があれば教えてください。OpenShiftのhttp/TLSトラフィックでの限定的なワークアラウンドとしては、Route作ってアクセスするとOpenShift RouterのHAProxyを通るのでHAProxyがヘルスチェックつきで接続管理とロードバランスしてくれます。将来的にはIstioとかがデフォルトでいい感じにハンドリングしてくれることを期待しています。

KubernetesのReadWriteOnceなvolume

よく聞かれるトピックでブログに書いてたと思ってたんだけど実は書いてなかったようだ。Amazon EBSとかGCEPersistentDiskとかAzureDiskとかGluster Block Storageとかを利用するReadWriteOnceのvolumeのお話。

https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes

access modeがReadWriteOnceというvolumeはいわゆるブロックデバイスタイプのvolumeであり、複数のホストから同時に同一のvolumeを利用することはできない(もし実際に複数ホストから同時に書き込まれるとデータが壊れる)。複数のホストから同時に利用できないので、ReplicaSetでスケールさせた場合にpodを複数ホストに分散させることはできない。このためReplicaSetで利用する場合はホスト障害やホストのメンテナンス停止への耐性はなく、ReadWriteOnceを利用するpodは必ず一旦停止してから別ノード上にRecreateされる必要があるためゼロダウンタイムでのpod再デプロイは不可能となる。後述するクラスタ対応ソフトウェアでStatefulSetであればReadWriteOnceを利用しても問題ない。

このようなReadWriteOnceのハンドリングは実際にはvolume pluginで実装されている。podを作成する時の前処理として、Amazon EBSなどのvolume pluginは、volumeをホストにattachする。逆に、podが削除されるときには、volumeをdetachするようになっている。正常な場合の再デプロイでは、コンテナ停止に伴いvolumeをコンテナが動作していたホストからdetach、コンテナ再スケジュール、作成に伴いvolumeをコンテナが動作するホストへattach、という流れで利用される。

https://github.com/kubernetes/kubernetes/tree/master/pkg/volume

volumeがattachされているホストが障害となったときは、volumeがdetach状態にならないまま利用中のステータスで残ることがある。ホスト障害とは言っても、単にネットワークが不通である可能性があるのでホストが実際にダウンしているかどうか判断することはできず、ホストの状態は「Unknown=不定」と考えなければならない。ホスト自体は実際には健康に動作していてvolumeにデータ書き込んでいるかもしれない。このような場合、volumeがdetachされずにpodが別ホストで再スケジュールされるような状況が発生するが、volumeが他ホストにattachされたままになっているのでpod作成時の前処理のvolumeのattachは失敗する。volumeを利用中のホストが本当にダウンしているかどうかもわからないため、強制的にdetachしてattachというわけにもいかない。このようなケースでは大抵マニュアルでの対処が必要となり、現在attachされているホストが停止していることを確認したのち、ブロックストレージの管理インタフェースなどからマニュアルでvolumeをdetachすることで再度そのvolumeが利用可能な状態になり、podの作成処理が進むようになる。volumeがattachされているホストが障害になったときに、自動でホストのダウンを確認してdetachしてくれるようなブロックストレージもあるかもしれないが、基本的にはそのような期待はしないほうがいい。

このように一見ReadWriteOnceはReadWriteManyより制約が多く劣っているように見えるが、劣っているのではなくストレージの性格が異なることを理解する必要がある。ReadWriteOnceのブロックデバイスはfsyncなどを利用するシビアなディスク書き込みを行うようなソフトウェア、いわゆるデータベースやデータストア系のソフトウェアのストレージとして適している。ReadWriteManyをサポートするNFSやGlusterFSのようなネットワークファイルシステムは、そのようなソフトウェアのストレージとして利用すると、一般的に不整合やデータ破損が発生しやすい。また、大抵このようなデータベース系ソフトウェアはReplicaSetでのpodのスケーリング、つまり同一のデータ領域を参照する複数インスタンスの同時起動をサポートしていないため、基本的にReadWriteManyにするユースケースがない。例えばOpenShiftのログ基盤で利用されているElasticSearchは、NFSやGlusterFSだとデータ破損が発生するので、NFSなどのネットワークストレージの利用をサポートしておらず、ReadWriteOnceのブロックデバイスを利用する必要がある。

分散を前提としていてクラスタリングをサポートしているetcd、ElasticSearch、Cassandraなどのソフトウェアでは、ネットワーク経由でのデータ複製や同期機能が備わっているので、PodごとにPVを割り当てることのできるStatefulSetを利用することにより、ReadWriteOnceのストレージを利用していてもスケール可能であり、適切に設定されている限りホスト障害などのときも必要な復旧作業と並行してリクエストに応答できるようになっているはずなのでダウンタイムなしで運用することができる。