お久しぶりです…！ 生きております…！
激動の10,11月だったため、更新が滞っておりました。来年こそはもっと密に更新していきたい…！
さて、裏では12/5にGAされたEKS for Fargateの検証をしておりました。あとは業務でDjangoいじったり、Lambda関数作ったり…
その時の記事がこちらのアドベントカレンダーで公開されておりますので、よろしければご覧いただき、「いいね！」いただけると泣いて喜びます！！
EKS for Fargate the Hard Way 〜 EKS for Fargateをeksctlに頼らず構築する
ちなみに、明日もう一個記事を公開します…！
お久しぶりです。生きております…！
最近はコンテナ基盤の監視やログ収集について勉強しておりました。定番のPrometheus+GrafanaやEFKスタックについてですね。前者ではcadvisor、node-exporterを使った一般的なDockerホスト監視やbackbox-exporterを使った外形監視、後者ではfluentdの設定ファイルの記述方法を勉強してコンテナやsystemdサービス、kernelログを収集する方法について学びました。
ところでEFKスタックでログ収集をしたら、ERRORやFAILなどの文字列を検出してSlack等に通知したくなりますよね…？ Elastic製品ではWatherという、x-pack(https://www.elastic.co/guide/jp/x-pack/current/index.html)内のコンポーネントを使ってこれを実現できるそうですが、x-packは有償なんです… OSSだけで同じことをやろうとしたら、KibanaをやめてGrafanaを使うという手もありますが、ログの検索/一覧性でGrafanaはKibanaには勝てない…
呆然とさまよっていたところで見つけたのがElastAlertというOSSです！ ElastAlertを使うとPrometheusのAlertManagerのようにYAMLベースで監視ルールを書いて、Slackを始めとした様々な媒体に通知することができます。またコンテナイメージやKibanaのプラグインがbitsensor社によって提供されているため、導入も簡単です。
使い方はbitsensor社のGitHubリポジトリ上の説明が丁寧なので全ては記載しませんが、概ね以下のように進めればOKです。
監視ルールはKibana上にElastAlertという項目が追加されているので、Creat ruleからエディタを起動し、以下のようなルールを書きます。
es_host: <Elasticsearchのホスト名/IPアドレス>
es_port: 9200
name: Alert on any error
index: logstash-*
timestamp_field: "@timestamp"
type: any
filter:
- query:
query_string:
query: "message:/ERROR/i"
alert_subject: "Error!!"
alert_text_type: alert_text_only
alert_text: "occur error on some components!"
alert:
- slack
slack_webhook_url: "https://hooks.slack.com/services/XXXXX/YYYYY/ZZZZZ"
Test ボタンで試験的にqueryを発行し、アラートを飛ばすことができます。意図したとおりであればSaveをクリックして、アラートを保存して完了です。
コンテナのセキュリティレベルを上げるためにホストOSとの分離レベルをあげようというモチベーションで開発されたプロダクトがいくつかあります。gVisorやrunV、kata containersなどがそれです。今回はその中のkata containersを検証してみました。kata containersはfirecrackerというAWSがFargateやLambdaの実行環境として利用しているVMMを利用することもできるので、合わせて使ってみたいと思います。
まず、docker ceをインストールします。kata containersのマニュアルに従い、バージョンは最新ではなく、18.06を用います。
sudo apt-get update
sudo apt-get -y install apt-transport-https \
ca-certificates \
curl \
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository \
"deb [arch=amd64] https://download.docker.com/linux/ubuntu \
$(lsb_release -cs) \
stable"
sudo apt-get install docker-ce=18.06.3~ce~3-0~ubuntu
次にkata containersとfirecrackerのバイナリをDLし、展開します。
wget https://github.com/kata-containers/runtime/releases/download/1.5.0/kata-static-1.5.0-x86_64.tar.xz sudo tar -xvf kata-static-1.5.0-x86_64.tar.xz -C /
Dockerのデフォルトruntimeの設定をkata containers + firecrackerとします。
sudo su -
cat <<EOF > /etc/docker/daemon.json
{
"default-runtime": "kata-fc",
"runtimes": {
"kata-fc": {
"path": "/opt/kata/bin/kata-fc"
}
},
"mtu": 1450,
"storage-driver": "devicemapper"
}
EOF
exit
sudo systemctl daemon-reload
sudo systemctl restart docker
最後に必須カーネルモジュールの読み込み設定をしてインストールは完了です。
sudo su - cat <<EOF > /etc/modules-load.d/vhost_vsock.conf vhost_vsock EOF exit sudo modprobe vhost_vsock
ではnginxを起動して、ホストからnginxプロセスが見えるか確かめてみましょう。
sudo docker run -d nginx sudo ps -ef | grep nginx
grepコマンドの結果のみになっているはずです。ちなみに、containerdで同じことをやると以下のようになりました。
root 8216 8194 0 22:02 ? 00:00:00 nginx: master process nginx -g daemon off; systemd+ 8275 8216 0 22:02 ? 00:00:00 nginx: worker process tatsuno+ 8278 5237 0 22:02 pts/0 00:00:00 grep --color=auto nginx
前回、Kubernetesのノード障害時の挙動について記事を書きました。このときはDeploymentを使って挙動を確かめていたですが、前回の記事を見た方から「StatefulSetだと挙動が違ったはず」とのご意見を頂戴しました。
https://twitter.com/tzkb/status/1116597587186814977
そこでStatefulSetだとノード障害時、どんな挙動になるか試してみました。
クラスタの状態は前回の状態からスタートします。
# kubectl get node NAME STATUS ROLES AGE VERSION test-cluster-7ajeznlcoium-master-0 Ready master 2d22h v1.14.0 test-cluster-7ajeznlcoium-minion-0 Ready <none> 2d22h v1.14.0 test-cluster-7ajeznlcoium-minion-1 Ready <none> 45h v1.14.0 test-cluster-7ajeznlcoium-minion-2 Ready <none> 2d16h v1.14.0
今回はElasticSearchのステートフルセットをデプロイしてみます。KubernetesのGitリポジトリをクローンします。
# cd ~ # git clone https://github.com/kubernetes/kubernetes
Cluster Add-Onからfluentd-elasticsearchディレクトリに入ります。
# cd kubernetes/cluster/addons/fluentd-elasticsearchds
デフォルトではElasticsearchのStatefulSetはvolumeClaimTemplatesを利用するように書かれていないので、以下のようにes-statefulset.yamlを書き換えます。
# Elasticsearch deployment itself
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: elasticsearch-logging
namespace: kube-system
labels:
k8s-app: elasticsearch-logging
version: v6.6.1
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
spec:
serviceName: elasticsearch-logging
replicas: 2
selector:
matchLabels:
k8s-app: elasticsearch-logging
version: v6.6.1
template:
metadata:
labels:
k8s-app: elasticsearch-logging
version: v6.6.1
kubernetes.io/cluster-service: "true"
spec:
serviceAccountName: elasticsearch-logging
containers:
- image: gcr.io/fluentd-elasticsearch/elasticsearch:v6.6.1
name: elasticsearch-logging
resources:
# need more cpu upon initialization, therefore burstable class
limits:
cpu: 1000m
requests:
cpu: 100m
ports:
- containerPort: 9200
name: db
protocol: TCP
- containerPort: 9300
name: transport
protocol: TCP
volumeMounts:
- name: elasticsearch-logging
mountPath: /data
env:
- name: "NAMESPACE"
valueFrom:
fieldRef:
fieldPath: metadata.namespace
# Elasticsearch requires vm.max_map_count to be at least 262144.
# If your OS already sets up this number to a higher value, feel free
# to remove this init container.
initContainers:
- image: alpine:3.6
command: ["/sbin/sysctl", "-w", "vm.max_map_count=262144"]
name: elasticsearch-logging-init
securityContext:
privileged: true
volumeClaimTemplates:
- metadata:
name: elasticsearch-logging
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi
ではおもむろにデプロイしてみます。
# kubectl apply -f es-statefulset.yaml # kubectl get pod -n kube-system -o wide -l k8s-app=elasticsearch-logging NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES elasticsearch-logging-0 1/1 Running 0 3m34s 10.100.2.221 test-cluster-7ajeznlcoium-minion-2 <none> <none> elasticsearch-logging-1 1/1 Running 0 99s 10.100.0.97 test-cluster-7ajeznlcoium-minion-0 <none> <none>
ここでtest-cluster-7ajeznlcoium-minion-2のkubeletを停止します。
(test-cluster-7ajeznlcoium-minion-2) # sudo systemctl stop kubelet
すると。。。
# kubectl get pod -n kube-system -o wide -l k8s-app=elasticsearch-logging NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES elasticsearch-logging-0 1/1 Terminating 0 11m 10.100.2.221 test-cluster-7ajeznlcoium-minion-2 <none> <none> elasticsearch-logging-1 1/1 Running 0 9m56s 10.100.0.97 test-cluster-7ajeznlcoium-minion-0 <none> <none>
StatefulSetの場合は、PodのTerminate処理が完了してから新しいPodが上がるので、kubeletが反応しない以上Terminate処理が完了できず、stuckしてしまうみたいです。
ではどうするか。。。その際の解の一つがTwitter上でご指摘いただいた方から教わったkube-fencingです。
kube-fencingを使うと、NotReadyなノードが生じた場合、その上のk8sオブジェクトを全て削除してノードをフェンシング(強制再起動)してくれます。k8sオブジェクトの削除対象にはNodeオブジェクトも含まれるので、その上に乗ったPodはTerminateどころかetcdから消えます。したがって新しいPodが間違いなく作られるという仕組みで回避しようというのです。
では早速インストールしてみましょう。ソースコードをDLします。
# cd ~ # git clone https://github.com/kvaps/kube-fencing
manifest群が置いてあるディレクトリに移動します。
# cd kube-fencing/examples
私が管理しているノード群はOpenStack上に乗っているので、openstackコマンドを使ってfencingを実現したいと思います。以下のようにfencing-script.yamlを書き換えます。
apiVersion: v1
kind: ConfigMap
metadata:
name: fencing-scripts
namespace: fencing
data:
fence.sh: |
#!/bin/bash
NODE="$1"
source /openstack/openrc-file
openstack server reboot --hard $1
fencing-scriptに与えるopenrcファイルを用意し、secretオブジェクトを作成します。Secretオブジェクトを作るために、fencingNamespaceも一緒に作ります。
# kubectl create ns fencing # kubectl create secret generic openrc-file --from-file=openrc-file=openrc-file -n fencing
作ったSecretをマウントするように、またimageもopenstackコマンドがインストールされたものを指定するようにfencing-agents.yamlを書き換えます。
apiVersion: apps/v1
kind: Deployment
metadata:
name: fencing-agents
namespace: fencing
spec:
replicas: 1
selector:
matchLabels:
app: fencing-agents
template:
metadata:
labels:
app: fencing-agents
spec:
nodeSelector:
node-role.kubernetes.io/master: ""
tolerations:
- key: node-role.kubernetes.io/master
operator: Exists
effect: NoSchedule
hostNetwork: true
containers:
- name: fencing-agents
image: bbrfkr0129/kube-fencing-agents
command: [ "/usr/bin/tail", "-f", "/dev/null" ]
volumeMounts:
- name: scripts
mountPath: /scripts
- name: openrc-file
mountPath: /openstack
volumes:
- name: scripts
configMap:
name: fencing-scripts
defaultMode: 0744
- name: openrc-file
secret:
secretName: openrc-file
defaultMode: 0400
manifestを適用します。
# kubectl apply -f .
ノードがNotReady時にfencingしてほしいノードはlabel付けをしておく必要があります。ワーカーノードをラベル付けしておきます。
# kubectl label node test-cluster-7ajeznlcoium-minion-0 fencing=enabled # kubectl label node test-cluster-7ajeznlcoium-minion-1 fencing=enabled # kubectl label node test-cluster-7ajeznlcoium-minion-2 fencing=enabled
これでインストール完了です！ 早速kubeletを停止させてみましょう。
(test-cluster-7ajeznlcoium-minion-2) # sudo systemctl stop kubelet
どうなるかというと。。。今度は新しいPodが上がってきません。。。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES elasticsearch-logging-0 1/1 Running 0 3m51s 10.100.0.98 test-cluster-7ajeznlcoium-minion-0 <none> <none> elasticsearch-logging-1 0/1 Init:0/1 0 53s <none> test-cluster-7ajeznlcoium-minion-0 <none> <none>
describeでログを見ると当然で、PVが違うインスタンスにアタッチされていて、移動できない旨のメッセージが表示されます。しかもたちの悪いことにノードオブジェクトは削除/再作成が行われているため、自分にPVがアタッチされていることを覚えていません。
ではやはりkube-fencingでもStatefulSetは救えないのか。。。というと、実は最後の砦があります。それは
もう諦めて、StatefulSetにはファイルシステムベース(NFSなど)のPVを使う、ということです。こうすれば、PVの取り合いが起きてもどのノードもPVをアタッチ/マウントできるので問題を回避できます。nfs-clientexternal-storage-provisionerなどを使って、興味がある方は試してみてください。
結論としては
ということでした。
Kubernetes上のアプリケーションの可用性について調べていたところ、ノード障害時に気をつけたほうが良い点を見つけたので記事にしてみます。
Kubernetesのノード障害時にはノードのステータスがNotReadyになります。Kubernetesクラスタが以下の通り構成されていたとしましょう。
# kubectl get node NAME STATUS ROLES AGE VERSION test-cluster-7ajeznlcoium-master-0 Ready master 147m v1.14.0 test-cluster-7ajeznlcoium-minion-0 Ready <none> 147m v1.14.0 test-cluster-7ajeznlcoium-minion-1 Ready <none> 147m v1.14.0 test-cluster-7ajeznlcoium-minion-2 Ready <none> 147m v1.14.0
さらに、Podは次のように起動していたとしましょう。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES httpd-6b77d6648-4jl4z 1/1 Running 0 20s 10.100.0.13 test-cluster-7ajeznlcoium-minion-0 <none> <none> httpd-6b77d6648-h7kjb 1/1 Running 0 20s 10.100.1.18 test-cluster-7ajeznlcoium-minion-1 <none> <none> httpd-6b77d6648-vd9xs 1/1 Running 0 20s 10.100.2.14 test-cluster-7ajeznlcoium-minion-2 <none> <none> nginx-7db9fccd9b-g8fjl 1/1 Running 0 26s 10.100.1.17 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-lp4fv 1/1 Running 0 26s 10.100.0.12 test-cluster-7ajeznlcoium-minion-0 <none> <none> nginx-7db9fccd9b-xdkfn 1/1 Running 0 27s 10.100.2.13 test-cluster-7ajeznlcoium-minion-2 <none> <none>
ここで、ワーカーノードtest-cluster-7ajeznlcoium-minion-2のkubeletサービスを停止します。
(test-cluster-7ajeznlcoium-minion-2) # sudo systemctl stop kubelet
40秒ほど経つと、STATUSがNotReadyになるはずです。
# kubectl get node NAME STATUS ROLES AGE VERSION test-cluster-7ajeznlcoium-master-0 Ready master 148m v1.14.0 test-cluster-7ajeznlcoium-minion-0 Ready <none> 149m v1.14.0 test-cluster-7ajeznlcoium-minion-1 Ready <none> 149m v1.14.0 test-cluster-7ajeznlcoium-minion-2 NotReady <none> 148m v1.14.0
ノードがNotReadyだから、Podも移動しているだろう。。。と思いませんか？
ですが。。。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES httpd-6b77d6648-4jl4z 1/1 Running 0 3m50s 10.100.0.13 test-cluster-7ajeznlcoium-minion-0 <none> <none> httpd-6b77d6648-h7kjb 1/1 Running 0 3m50s 10.100.1.18 test-cluster-7ajeznlcoium-minion-1 <none> <none> httpd-6b77d6648-vd9xs 1/1 Running 0 3m50s 10.100.2.14 test-cluster-7ajeznlcoium-minion-2 <none> <none> nginx-7db9fccd9b-g8fjl 1/1 Running 0 3m56s 10.100.1.17 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-lp4fv 1/1 Running 0 3m56s 10.100.0.12 test-cluster-7ajeznlcoium-minion-0 <none> <none> nginx-7db9fccd9b-xdkfn 1/1 Running 0 3m57s 10.100.2.13 test-cluster-7ajeznlcoium-minion-2 <none> <none>
2分経っても移動しません。。。
実は、v1.13.0からTaintBasedEvictionというPod退避機能がデフォルトで有効になったようです。この機能ではTaintとeffectがNoExecuteなTolerationを使って、Podを退避させます。具体的にはノードがNotReadyになると自動的にノードにtaint node.kubernetes.io/not-readyが付くようになり、加えて全てのPodに対してデフォルトのtolerationとしてこのtaintに対するNoExecute tolerationが付与されます。これにより当該機能を実現しています。
デフォルトではPod退避の猶予期間であるtolerationSecondsパラメータは300秒(5分)です。このため、デフォルトでは5分経たないとPodは再スケジューリングされなかったのです。この猶予期間を短くするには、kube-apiserverの起動オプションに以下を指定します。この例では30秒にしています。
--default-not-ready-toleration-seconds=30 --default-unreachable-toleration-seconds=30
では再チャレンジ。。。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES httpd-6b77d6648-7hf2x 1/1 Running 0 4m7s 10.100.0.14 test-cluster-7ajeznlcoium-minion-0 <none> <none> httpd-6b77d6648-dshdc 1/1 Running 0 4m8s 10.100.1.21 test-cluster-7ajeznlcoium-minion-1 <none> <none> httpd-6b77d6648-l9tkd 1/1 Terminating 0 4m7s 10.100.2.15 test-cluster-7ajeznlcoium-minion-2 <none> <none> httpd-6b77d6648-qjmfm 1/1 Running 0 12s 10.100.1.24 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-hh5gk 1/1 Terminating 0 4m1s 10.100.2.16 test-cluster-7ajeznlcoium-minion-2 <none> <none> nginx-7db9fccd9b-q9psw 1/1 Running 0 12s 10.100.1.23 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-r2td2 1/1 Running 0 4m1s 10.100.0.15 test-cluster-7ajeznlcoium-minion-0 <none> <none> nginx-7db9fccd9b-wq2hg 1/1 Running 0 4m1s 10.100.1.22 test-cluster-7ajeznlcoium-minion-1 <none> <none>
見事、30秒程度で退避できました！ でもちょっとまってください。もしこの状態でノードが復活したらどうなるでしょう。
NAME STATUS ROLES AGE VERSION test-cluster-7ajeznlcoium-master-0 Ready master 173m v1.14.0 test-cluster-7ajeznlcoium-minion-0 Ready <none> 174m v1.14.0 test-cluster-7ajeznlcoium-minion-1 Ready <none> 174m v1.14.0 test-cluster-7ajeznlcoium-minion-2 Ready <none> 173m v1.14.0
Podの稼動状態はこのようになりました。
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES httpd-6b77d6648-7hf2x 1/1 Running 0 5m51s 10.100.0.14 test-cluster-7ajeznlcoium-minion-0 <none> <none> httpd-6b77d6648-dshdc 1/1 Running 0 5m52s 10.100.1.21 test-cluster-7ajeznlcoium-minion-1 <none> <none> httpd-6b77d6648-qjmfm 1/1 Running 0 116s 10.100.1.24 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-q9psw 1/1 Running 0 116s 10.100.1.23 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-r2td2 1/1 Running 0 5m45s 10.100.0.15 test-cluster-7ajeznlcoium-minion-0 <none> <none> nginx-7db9fccd9b-wq2hg 1/1 Running 0 5m45s 10.100.1.22 test-cluster-7ajeznlcoium-minion-1 <none> <none>
test-cluster-7ajeznlcoium-minion-2には再スケジューリングされません。Podが片寄状態になってしまっています。もしこの状態でたくさんPodがのったノードが停止してしまうと。。。
という事態を防ぐためにdeschedulerというプロダクトがあります！
これはKubernetesのJobとして機能させることで、Podのスケジューリングの偏りを検知して、再スケジューリングをかけてくれます。早速導入してみます。
git clone https://github.com/kubernetes-incubator/descheduler
cd descheduler/kubernetes
kubectl apply -f rbac.yaml
kubectl apply -f configmap.yaml
cat <<EOF | kubectl apply -f -
apiVersion: batch/v1beta1
kind: CronJob
metadata:
labels:
run: descheduler-cronjob
name: descheduler-cronjob
namespace: kube-system
spec:
concurrencyPolicy: Allow
jobTemplate:
spec:
template:
metadata:
name: descheduler-pod
annotations:
scheduler.alpha.kubernetes.io/critical-pod: ""
spec:
containers:
- name: descheduler
image: bbrfkr0129/descheduler:latest
volumeMounts:
- mountPath: /policy-dir
name: policy-volume
command:
- "/bin/descheduler"
args:
- "--policy-config-file"
- "/policy-dir/policy.yaml"
- "--v"
- "3"
restartPolicy: "Never"
serviceAccountName: descheduler-sa
volumes:
- name: policy-volume
configMap:
name: descheduler-policy-configmap
schedule: '*/3 * * * *'
EOF
この例ではCronJobを用いて3分ごとに再スケジューリングするようにしています。
3分後、見事偏りがなくなりました。。。！！
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES httpd-6b77d6648-7hf2x 1/1 Running 0 14m 10.100.0.14 test-cluster-7ajeznlcoium-minion-0 <none> <none> httpd-6b77d6648-dshdc 1/1 Running 0 14m 10.100.1.21 test-cluster-7ajeznlcoium-minion-1 <none> <none> httpd-6b77d6648-zvznn 1/1 Running 0 44s 10.100.2.18 test-cluster-7ajeznlcoium-minion-2 <none> <none> nginx-7db9fccd9b-hqj72 1/1 Running 0 44s 10.100.2.20 test-cluster-7ajeznlcoium-minion-2 <none> <none> nginx-7db9fccd9b-q9psw 1/1 Running 0 10m 10.100.1.23 test-cluster-7ajeznlcoium-minion-1 <none> <none> nginx-7db9fccd9b-r2td2 1/1 Running 0 14m 10.100.0.15 test-cluster-7ajeznlcoium-minion-0 <none> <none>
3/12にRancher公式ブログで発表された、「Submariner」という新しいOSSを動かしてみましたので、軽く所感を書きます。
複数のKubernetesクラスタのPodネットワークおよびServiceネットワークを繋げるプロダクトです。NodePortサービスを作って外部公開せずとも、複数Kubernetesクラスタ内のPod同士で通信することが可能になります。
公式では以下の用途にマッチするとしています。
ここからは私が試した手順の概要を記載いたします。といっても公式GitHubが秀逸なので、特に面白い内容ではないですが。。。
submarinerを試すには最低限3つのKubernetesクラスタが必要です。２つは実際に接続したいクラスタ「west」と「east」、残りの1つは「broker」という、westとeastのネットワーク情報を同期する仲介役として動きます。 クラスタ要件として以下が求められるので、ユーザが自由に制御可能なバニラKubernetesで試すのがおすすめです。
* 任意のクラスタ間でpodネットワークcidrおよびserviceネットワークcidrおよびcluster local domainが異なること * 任意のクラスタ間でインターネットを通じて直接通信できるか、同じネットワークに所属していること
# helmの初期化
kubectl -n kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:tiller
helm init --service-account tiller
helm repo update
# submariner-brokerのインストール
SUBMARINER_BROKER_NS=submariner-k8s-broker
helm install submariner-latest/submariner-k8s-broker \
--name ${SUBMARINER_BROKER_NS} \
--namespace ${SUBMARINER_BROKER_NS}
SUBMARINER_BROKER_URL=$(kubectl -n default get endpoints kubernetes -o jsonpath="{.subsets[0].addresses[0].ip}:{.subsets[0].ports[0].port}")
SUBMARINER_BROKER_CA=$(kubectl -n ${SUBMARINER_BROKER_NS} get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='${SUBMARINER_BROKER_NS}-client')].data['ca\.crt']}")
SUBMARINER_BROKER_TOKEN=$(kubectl -n ${SUBMARINER_BROKER_NS} get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='${SUBMARINER_BROKER_NS}-client')].data.token}"|base64 --decode)
SUBMARINER_PSK=$(cat /dev/urandom | LC_CTYPE=C tr -dc 'a-zA-Z0-9' | fold -w 64 | head -n 1)
# eastクラスタに対する通信のゲートウェイとなるノードにラベル付け
kubectl label node <GATEWAY_NODE> "submariner.io/gateway=true"
# helmの初期化
kubectl -n kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:tiller
helm init --service-account tiller
# submarinerのインストール
helm install submariner-latest/submariner \
--name submariner \
--namespace submariner \
--set ipsec.psk="${SUBMARINER_PSK}" \
--set broker.server="${SUBMARINER_BROKER_URL}" \
--set broker.token="${SUBMARINER_BROKER_TOKEN}" \
--set broker.namespace="${SUBMARINER_BROKER_NS}" \
--set broker.ca="${SUBMARINER_BROKER_CA}" \
--set submariner.clusterId="west-cluster" \
--set submariner.clusterCidr="<westクラスタのpod network cidr>" \
--set submariner.serviceCidr="<westクラスタのservice network cidr>" \
--set submariner.natEnabled="false"
# westクラスタに対する通信のゲートウェイとなるノードにラベル付け
kubectl label node <GATEWAY_NODE> "submariner.io/gateway=true"
# helmの初期化
kubectl -n kube-system create serviceaccount tiller
kubectl create clusterrolebinding tiller \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:tiller
helm init --service-account tiller
# submarinerのインストール
helm install submariner-latest/submariner \
--name submariner \
--namespace submariner \
--set ipsec.psk="${SUBMARINER_PSK}" \
--set broker.server="${SUBMARINER_BROKER_URL}" \
--set broker.token="${SUBMARINER_BROKER_TOKEN}" \
--set broker.namespace="${SUBMARINER_BROKER_NS}" \
--set broker.ca="${SUBMARINER_BROKER_CA}" \
--set submariner.clusterId="east-cluster" \
--set submariner.clusterCidr="<eastクラスタのpod network cidr>" \
--set submariner.serviceCidr="<eastクラスタのservice network cidr>" \
--set submariner.natEnabled="false"
kubectl run nginx --image nginx kubectl expose deploy nginx --port 80
NGINX_SERVICE_IP=$(kubectl get svc nginx -o jsonpath="{.spec.clusterIP}")
kubectl run busybox --restart=Never --image busybox:1.28 -- sleep 3600
kubectl exec -it busybox -- wget -q -O - ${NGINX_SERVICE_IP}
無事、nginxのスタートページが表示されればOKです。
submarinerをざっと試してみましたが、そもそもKubernetesクラスタはプロジェクトやチームなど意味あるかたまりで分割されるであろうことから、そもそもpodネットワークやserviceネットワークをつなぎたい需要ってそんなにあるのかな？ と疑問に思っています。 Rancherの提示している使い方以外に使えるとすれば、PVのクラスタ間移行なんかには便利に使える気はしますね。
現時点ではクラスタ超えのDNSには対応していないので、クラウドネイティブに使うとなるとちょっと物足りないところ。今後の発展に期待です！
この度、Kubernetesの認定資格「CKA(Certified Kubernetes Administrator)」を取得いたしました！ 今後受ける方のお役に立てばと、受験レポートを残しておきます。
私の場合は、今まで培ってきたKubernetesの技術知識を試すことが目的でした。また副次的な目的で、社内でコンテナ技術推進活動をしているため、その発言に説得力をもたせる意味もありました。
「Kubernetesの技術を身につけるきっかけにする」というパターンの方もいるかと思います。
自分が受験をするぞ！と決めてやったことは以下の4つです。私の場合は既にKubernetesを結構触ってしまっていたので役に立つかわからないですが、かけた時間を括弧付けで示しておきます。
CKAを受験するには氏名がローマ字記載の写真付き身分証明書が必要になります。おそらくパスポート一択な気がします。
私は国際旅行等で海外に出たことが一回もなく、人生で初めてパスポートを取得しました。まさか資格試験のためにパスポートを取得することになろうとは…
パスポートの発行は私の居住する地域だと1週間程度かかりました。もし受験する熱意があるけどお持ちでない方は、受験予定日を決めたら早めに取得することをおすすめします。
ちなみに発行料は5年パスポートで1万円程度でした。
CKAの受験は準備も含めて3時間半程度、誰もいない、誰も入ってこない、静かで、机・椅子以外ほぼ何もないスペースが必要になります。
私の場合は会社の会議室で試験を実施するのが難しい事情があったため、貸し会議室を予約し、受験することにしました。
試験日のスケジューリングをしてから空いている会議室を探すのが良いと思います。2000円くらいあれば借りられると思います。
CKAは国際試験なので現状、試験に関する情報は英語になります。ですので、試験のレギュレーションを理解する時間をしっかり取りました。
先人の方々が残してくれた受験記はチラ見していましたが、なかなか実際の問題のイメージが膨らまなかったので、今まで触ってきた機能の復習は少々行いました。
具体的にはCyberAgentの青山さんが書いた本「Kubernetes完全ガイド」の4章〜12章くらいを見直したことと、Kubernetesクラスタをスクラッチで構築するハンズオン「 Kubernetes The Hard Way」を通しで1回、やり直してみました。
試験日当日の流れは以下のようになります。
試験当日は予約した会議室で試験サイトにアクセスし、試験官と英語のチャットでやり取りする形になります。まずはじめにWebカメラを有効化し、デスクトップを有効化するよう、指示されました。
Webカメラが有効になったら、カメラ経由でパスポートの顔写真が写っているページを試験官に見せます。ここはすんなり通りました。
次に試験を受験する部屋を一周くまなくカメラで見せるように指示があります。この際、特に机上を注意してみているようで、机上をゆっくり見せてほしいと指示がありました。
試験中は基本的に休憩を申し出ない限りは、受験用端末のスクリーンを見続けていなければなりません。
顔がきれいに試験官に見えていなかったのか、Webカメラを少し下げるように指示されました。ディスプレイに付属のカメラを使う人は辛いディスプレイの角度で受験することになるかもしれないです。私は許容範囲でしたが…
許容できなければ外部Webカメラがあるとよいかも…？！
以上の準備を終えて、試験官が試験ページを更新し、問題文とコンソールが表示されました。そしたら試験開始です。開始の合図は特にありませんでした。
私が考えるCKA合格に必要なことは以下の5点になります。
これが大前提になります。試験のルールは全て英語で記載されたHandbook、Important Tipsしかないので、抵抗がある方もいらっしゃるかと思いますが、禁止事項を理解しておかないと即時試験終了されてしまう恐れがあるので、HandbookとImportant Tipsの中身はよく理解するようにすると良いです。
特に、試験中に参照できるWebページの制限(k8sの公式ドキュメント、ブログ、公式GitHubのみ)には注意が必要です。Kubernetes公式ドキュメントからドキュメント検索をかけると、外部ページも引っかかるため、不意にそれらのページリンクをクリックしてしまうと不正行為になります。また、表示できるタブの数(試験サイト以外、一つのみ)も注意が必要なルールの一つです。
kubectlを使ってオブジェクトの名前だけをリストしたり、特定のラベルを持つオブジェクトだけを検索したりする等、普段使っていない方もkubectlの効率的な使い方は理解しておいたほうが良いでしょう。青山さんの本「Kubernetes完全ガイド」だと4章を網羅的に理解しておけば十分でしょう。
Deployment、ReplicaSet、Pod、各種Serviceなどの本当に基本的なオブジェクトの作り方から、マニフェストの書き方はしっかり押さえておくべきでしょう。マニフェストのサンプルはKubernetes公式ドキュメントから引っ張ってこれますし、kubectl run --dry-run -o yamlでも確認できるので、ゼロから作るというよりかは各パラメータの意味を理解してカスタマイズできるかが重要になります。
なおその他のオブジェクトについても、私が受けた感覚では「Kubernetes完全ガイド」の5章〜8章は可能な限り押さえ、余力があれば9章、10章を理解しておくぐらいで十分かなと思います。
Kubernetesを運用するための知識として、「Kubernetes完全ガイド」の11章の知識は押さえておきましょう。またnode selectorやtaint、tolerationなどを用いたPodスケジューリングは覚えておいて損はないと思います。
「kubeadm」などのツールを用いてしかKubernetesクラスタを構築したことがない方はぜひ一度Kubernetes The Hard Way」を1度実施してください。そしてオペレーションの一つ一つの意味を理解しておくほうが良いです。
上記準備で、無事CKAを取得することができましたが、スコアは80%と、合格ライン74%と比較してギリギリでした。一問以外はわからない問題ではなかったのですが、失点の理由が知りたいのがホンネ…
本レポートが今後CKAを受験する方のお役に立つことを願っております！