Edited at

Helm stable/spinnakerをKubernetes 1.9.4以上のminikubeやDocker for Desktopで動かす

More than 1 year has passed since last update.

2018/05/09追記

PRが無事にmergeされたので、この記事の目的が変わって、Spinnaker Helm Chart v0.4.1を導入するための記事になります。

元々、v0.4.0は古いKubernetesでしか動作せず、これはマズイと思って記事を起こしていました。

2018/04/25現在、Helm stable/spinnaker v0.4.0 はKubernetes 1.9.4以上では動作できません。

ので、それを動作できるようにするための改修ポイントを紹介します。


TL;DR


  • Spinnaker Helm Chart v0.4.1(すぐにv0.4.2に上がりますが方法は変わりません)をインストールする方法を記します


対象読者 or 前提条件 or 環境


  • 対象


    • Spinnakerをサクッと試したい人

    • SpinnakerをminikubeやDocker for Desktop(Windows, Mac)で動かしたい人(GKEとかでも全然OKですけど、その場合はHalyardもチェックして、どちらのインストール方法が良いかを比較してからにしてください)




1.さくっとインストール

minikube, Docker for Macなどいくつかの環境で、Kubernetes 1.9.4, 1.10.0で動作確認しました。

次の手順でhelm installしてください。

# helm stable repositoryの更新

helm update

# バージョンの確認 -> "CHART VERSION"が0.4.1以上であることを確認してください
helm search spinnaker

# install. 結構時間がかかるので、タイムアウトを延長します
helm install stable/spinnaker --namespace spinnaker --timeout 600

installが無事に成功すると、以下のようなメッセージが表示されます。ただし、全てのコンポーネントの起動が完了して表示されるメッセージではないので、kubectl get all -n spinnakerなどを使って全てがRunningになるまでは待つことになります。2cpu core, 8192 memの環境で7分程度かかりました。

NOTES:

1. You will need to create 2 port forwarding tunnels in order to access the Spinnaker UI:
export DECK_POD=$(kubectl get pods --namespace spinnaker -l "component=deck,app=jazzed-gecko-spinnaker" -o jsonpath="{.items[0].metadata.name}")
kubectl port-forward --namespace spinnaker $DECK_POD 9000

2. Visit the Spinnaker UI by opening your browser to: http://127.0.0.1:9000

For more info on the Kubernetes integration for Spinnaker, visit:
http://www.spinnaker.io/docs/kubernetes-source-to-prod

提示されているコマンドを実行し、Spinnakerへアクセスしてください。ClusterIPではなくNodeIPを指定した場合はコマンドは不要で、kubectl get svc -n spinnakerより、どのport番号かをチェックしてKubernetes Nodeへアクセスしてください。

Spinnaker上の操作などは別の記事に譲ります。

(2018/04/25追記)

SpinnakerのDeploy中にServiceAccount「spinnaker:default」(spinnakerというnamespaceの場合)が作成されるのですが、そのServiceAccountのClusterRoleBindingが設定されない不具合(?)もありました。影響範囲としては、SpinnakerはこのServiceAccountによってKubernetesの情報を閲覧・操作することになるので、これを行わないと何も出来ないSpinnakerが出来上がっていたという感じです。(ただ、設定されない理由もあって、権限をHelmが勝手に指定するとユーザにとって意図しない権限が付いてしまうことになるので、これはこれで良い仕様かなとも思ったりしています)

以下のコマンドを実行し、ClusterRoleBindingを作成してください。cluster-adminというpreparedなClusterRoleを利用します。このRoleはKube-Systemなど、どのnamespaceも参照できてしまうので、気を付けてください。初めてSpinnakerを利用する人にとっては、SpinnakerのWeb UIでKube-Systemがどのように見られるかを参照することができればSpinnakerの理解がより早く深まると思って、cluster-adminを使う方法を紹介することにしました。本番環境ではClusterRoleの設計を行い、操作範囲を限定するようにしてBindingを設定してください。

kubectl create clusterrolebinding spinnaker-admin-binding \

--clusterrole=cluster-admin \
--serviceaccount=spinnaker:default

コマンドの説明よりManifestを提示した方が早いと思うので下記参照してください。これを使ってkubectl apply -f spinnaker-admin-binding.yamlでも構いません。得られる結果は上記コマンドと同じです。


spinnaker-admin-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRoleBinding
metadata:
name: spinnaker-admin-binding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: default
namespace: spinnaker


2.修正点

(2018/05/09追記)

Helm Chart Version 0.4.1が取り込まれたので、以降の記事は不要になりました。PRの内容が気になる方だけ参照することにしてください。


2.1.helm minio chart versionの修正

minioはAWS S3互換のObject Storageです。APIもAWS S3と同じ実装がなされています。

minikubeやDocker for Desktopの方はこれが動作し、Spinnakerのデータ保存場所として稼働してくれます。

さて、minioの修正点について書いていきます。

minioもHelmで公開されています。: stable/minio

stable/spinnakerではHelm ChartのRequirementsとしてstable/minioが参照されるのですが、バージョンが古くKubernetes 1.9.4で入った脆弱性対応に対応しておらずエラーが出てCLBFに陥り、Helm Installが失敗します。

参照:

stable/minio chart version 1.0.0にこれらの対応がなされていますが、その他の改修も入っているので1.1.1が使えるようにrequrements.yamlを以下のように修正します(修正箇所のみ記載)。(versionを0.4.3 -> 1.1.1)


requrements.yaml

- name: minio

version: 1.1.1
repository: https://kubernetes-charts.storage.googleapis.com/
condition: minio.enabled


2.2.service name変更に伴うアクセスURLの修正

上記修正にてminioが稼働できるようになったのですが、minioのchart version 1.0.0以降でservice.nameが変わってしまったことでdns名も変わり、minioへのアクセスが出来ないため修正します。


  • before: http://{{ .Release.Name }}-minio-svc:9000

  • after: http://{{ .Release.Name }}-minio:9000

service名の後ろが若干変わっています。


templates/configmap/spinnaker-config.yaml(358行目を修正)

        s3:

enabled: true
endpoint: http://{{ .Release.Name }}-minio:9000

CronjobでBucketを作成しているのですが、こちらもminioへアクセスしていますので、修正します。(他にも変わっている箇所がありますが後述します)


templates/hooks/create-bucket.yaml(29行目を修正)

        image: "minio/mc:RELEASE.2018-03-25T01-22-22Z"

command:
- sh
- -c
- "mc config host add {{.Release.Name}}-minio http://{{.Release.Name}}-minio:9000 {{ .Values.minio.accessKey }} {{ .Values.minio.secretKey }} S3v4 && mc mb -p {{.Release.Name}}-minio/spinnaker"


2.3.CronJobの修正

minioがDeployされた後、CronJobでBucketを作成しているのですが、たまにタイミングが悪いと失敗したように見えて実はBucketが作成されていることがあるのですが、再実行では「Your previous request to create the named bucket succeeded and you already own it.」というエラーが連続しCLBFに陥ってしまいます。

ここで、minio clientのあるバージョンから、Bucketを作成するmc mbサブコマンドにおいて--ignore-existing / -pというオプションが用意されるようになり、今回もこれを使うようにするとCLBFが起きる可能性の一つを潰すことができます。mkdir -pと同じ発想ですね。

ただ、stable/spinnakerで利用しているminio clientのDocker Imageはこのオプションが利用できないmcバージョンが実装されているので、imageを修正します。minioより出ていますので、これを使い、mc mb -pを指定してBucketを作成するようにします。


templates/hooks/create-bucket.yaml(25行目,29行目を修正)

        image: "minio/mc:RELEASE.2018-03-25T01-22-22Z"

command:
- sh
- -c
- "mc config host add {{.Release.Name}}-minio http://{{.Release.Name}}-minio:9000 {{ .Values.minio.accessKey }} {{ .Values.minio.secretKey }} S3v4 && mc mb -p {{.Release.Name}}-minio/spinnaker"

ここまで修正したら、前章に戻り、コマンドを実行して動作することを確認してください。


さいごに

ありがとうございました。