涅槃を目指す in はてな

人生に迷う様を書きます

今年こそ本気出す 2022

あっという間に年が明けてしまったので、去年を振り返りつつ今年の意気込みを書きます

2021を振り返る

良かった

  • 3月に転職した会社が良い会社だった。未経験分野が多くチャレンジできそう
  • ずっとやろうと思ってたKubernetes The Hard Wayを完走できた

良くなかった

  • 自宅k8s環境が整えられなかった
  • CI/CD周りの習得が疎かだった
  • 一つのことをじっくり腰を据えてやる機会が少なかった

2022にやりたいこと

Kubernetes The Hard Way On VirtualBox 13日目

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの13日目。

Smoke Test

スモークテストとは、プログラムの必須機能が正常動作することを確認するためのテストです。

今回は作成したk8sクラスタの機能が正常動作することを確認します。

Data Encryption

ここでは、etcdに書き込むデータを暗号化する機能の確認をします。

まずsecretを作成します。

kubectl create secret generic kubernetes-the-hard-way \
>   --from-literal="mykey=mydata"

etcdに保存されているkubernetes-the-hard-wayシークレットの16進ダンプを出力します。

sudo ETCDCTL_API=3 etcdctl get \
>   --endpoints=https://127.0.0.1:2379 \
>   --cacert=/etc/etcd/ca.crt \
>   --cert=/etc/etcd/etcd-server.crt \
>   --key=/etc/etcd/etcd-server.key\

結果

00000000  2f 72 65 67 69 73 74 72  79 2f 73 65 63 72 65 74  |/registry/secret|
00000010  73 2f 64 65 66 61 75 6c  74 2f 6b 75 62 65 72 6e  |s/default/kubern|
00000020  65 74 65 73 2d 74 68 65  2d 68 61 72 64 2d 77 61  |etes-the-hard-wa|
00000030  79 0a 6b 38 73 3a 65 6e  63 3a 61 65 73 63 62 63  |y.k8s:enc:aescbc|
00000040  3a 76 31 3a 6b 65 79 31  3a ac 17 6e c5 3f 70 3b  |:v1:key1:..n.?p;|
00000050  0f b6 c8 07 87 3d d3 09  ef 54 18 7c ad 88 fd 15  |.....=...T.|....|
00000060  f2 9b 50 6c fa 6f 41 1c  a9 38 bc 6c 97 3b 0c 1d  |..Pl.oA..8.l.;..|
00000070  00 9a b0 f9 bc 93 7b dd  df fe fd 1b 09 88 f8 9e  |......{.........|
00000080  7a 1c 28 5b 0d 66 e9 a1  3d 31 cd 98 15 d4 94 49  |z.([.f..=1.....I|
00000090  8a 8e ea 33 c2 84 73 80  fb b1 87 e4 65 3e 16 83  |...3..s.....e>..|
000000a0  ec 69 6f 21 39 bd 69 13  86 82 1a 09 8f 1d df 09  |.io!9.i.........|
000000b0  34 c7 ba cf 7b 60 69 16  a8 85 07 e3 51 38 02 f3  |4...{`i.....Q8..|
000000c0  da cb fd d3 4c 79 30 70  d2 e2 61 96 24 96 f9 f1  |....Ly0p..a.$...|
000000d0  56 6b 46 ee 75 13 26 53  2b fa 2d c1 b9 65 15 3e  |VkF.u.&S+.-..e.>|
000000e0  b1 9c e5 48 8c 4d fc 7e  03 63 63 10 ac f9 0a 25  |...H.M.~.cc....%|
000000f0  4e 06 3d 32 10 b8 f2 49  80 9b fe 39 f9 c9 67 a5  |N.=2...I...9..g.|
00000100  a2 88 30 1d 8d 0b d6 b9  50 99 4d b6 74 c9 9f 89  |..0.....P.M.t...|
00000110  be 0c eb a1 bc d7 e5 67  70 5d f7 cc 62 4b 0d 00  |.......gp]..bK..|
00000120  9f ea 67 00 fc a2 29 ea  f3 95 d0 aa ed c1 f2 b3  |..g...).........|
00000130  e3 30 15 37 de df 77 3b  db bc 10 1a 8c 0d 27 af  |.0.7..w;......'.|
00000140  36 34 32 b4 c9 f2 a8 ad  8a 83 cb 44 39 c1 72 47  |642........D9.rG|
00000150  ce 81 6f 09 8a 8d 15 51  2d 0a                    |..o....Q-.|
0000015a

etcdキーの前にk8s:enc:aescbc:v1:key1を付ける必要があります。これは、aescbcプロバイダーがkey1暗号化キーでデータを暗号化するために使用されたことを示します。

確認が終わったら掃除しましょう。

kubectl delete secret kubernetes-the-hard-way

Deployments

ここではDeploymentの作成、管理機能を確認します。

nginxのDeploymentを作成します。

kubectl create deployment nginx --image=nginx

nginx Deploymentが作成したPodを確認します。

kubectl get pods -l app=nginx

以下のように出力されればOKです。

NAME                     READY   STATUS    RESTARTS   AGE
nginx-6799fc88d8-5z585   1/1     Running   0          43s

Services

ここではServiceの作成、管理機能を確認します。

nodeのPortを公開するnginxのサービスを作成します。

kubectl expose deploy nginx --type=NodePort --port 80
PORT_NUMBER=$(kubectl get svc -l app=nginx -o jsonpath="{.items[0].spec.ports[0].nodePort}")

curlで確認してみましょう

curl http://worker-1:$PORT_NUMBER
curl http://worker-2:$PORT_NUMBER

以下のように出力されればOKです。

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Logs

ここでは、コンテナのログを取得する機能を確認します。

まずnginxPodのフルネームを取得します。

POD_NAME=$(kubectl get pods -l app=nginx -o jsonpath="{.items[0].metadata.name}")

logを取得します。

kubectl logs $POD_NAME

以下のように出力されます

vagrant@master-1:~$ kubectl logs $POD_NAME
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2021/12/27 23:59:44 [notice] 1#1: using the "epoll" event method
2021/12/27 23:59:44 [notice] 1#1: nginx/1.21.4
2021/12/27 23:59:44 [notice] 1#1: built by gcc 10.2.1 20210110 (Debian 10.2.1-6) 
2021/12/27 23:59:44 [notice] 1#1: OS: Linux 4.15.0-163-generic
2021/12/27 23:59:44 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 1048576:1048576
2021/12/27 23:59:44 [notice] 1#1: start worker processes
2021/12/27 23:59:44 [notice] 1#1: start worker process 31

Exec

ここではコンテナ内でコマンドを実行できるか確認します。

nginx コンテナでnginx -vコマンド実行し、バージョンを出力させてみます。

kubectl exec -ti $POD_NAME -- nginx -v

以下のように出力されます

vagrant@master-1:~$ kubectl exec -ti $POD_NAME -- nginx -v
nginx version: nginx/1.21.4

今回はここまで!

お読み頂き有難うございました。

Kubernetes The Hard Way On VirtualBox 12日目

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの12日目。

Deploying the DNS Cluster Add-on

今回は Kubernetesクラスタ内部にCoreDNSを使った名前解決の仕組みをデプロイします。DNSベースのサービスディスカバリのためです。

The DNS Cluster Add-on

corednsアドオンをデプロイします。

kubectl apply -f https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml

実行結果

vagrant@master-1:~$ kubectl apply -f https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml
serviceaccount/coredns created
configmap/coredns created
deployment.apps/coredns created
service/kube-dns created
unable to recognize "https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml": no matches for kind "ClusterRole" in version "rbac.authorization.k8s.io/v1beta1"
unable to recognize "https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml": no matches for kind "ClusterRoleBinding" in version "rbac.authorization.k8s.io/v1beta1"

あー、rbac.authorization.k8s.io/v1beta1rbac.authorization.k8s.io/v1になってる問題か!

修正したいので、

wget https://raw.githubusercontent.com/mmumshad/kubernetes-the-hard-way/master/deployments/coredns.yaml

でcoredns.yamlを落としてきて、rbac.authorization.k8s.io/v1beta1rbac.authorization.k8s.io/v1に置換しました。

実行結果

vagrant@master-1:~$ kubectl apply -f coredns.yaml serviceaccount/coredns unchanged
clusterrole.rbac.authorization.k8s.io/system:coredns created
clusterrolebinding.rbac.authorization.k8s.io/system:coredns created
configmap/coredns unchanged
deployment.apps/coredns unchanged
service/kube-dns unchanged

OKOK!

kube-dns デプロイメントによって作られたpodを確認できます。

kubectl get pods -l k8s-app=kube-dns -n kube-system

実行結果

vagrant@master-1:~$ kubectl get pods -l k8s-app=kube-dns -n kube-system
NAME                       READY   STATUS    RESTARTS       AGE
coredns-5cccc7b6cc-l2w6g   1/1     Running   2 (2m4s ago)   6m34s
coredns-5cccc7b6cc-nsp28   1/1     Running   2 (2m4s ago)   6m34s

Verification

busybox podを作成ます。公式だと --generator=run-pod/v1 というオプションがついてますが、kubernetes v1.18以降では不要です。

kubectl run busybox --image=busybox:1.28 --command -- sleep 3600

作成されたpodを確認

kubectl get pods -l run=busybox

実行結果

vagrant@master-1:~$ kubectl get pods -l run=busybox
NAME      READY   STATUS    RESTARTS   AGE
busybox   1/1     Running   0          23s

作成したpodの名前解決が出来るか、kubernetesサービスにDNS Lookupをしてみましょう

kubectl exec -ti busybox -- nslookup kubernetes

実行結果

vagrant@master-1:~$ kubectl exec -ti busybox -- nslookup kubernetes
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

出来ているようですね!

今回はここまで! お読み頂き有難うございました!

Kubernetes The Hard Way On VirtualBox 11日目

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの11日目。

今日はRBACの設定です。

RBAC for Kubelet Authorization

今回はRBACの設定をして、Kubernetes API Serverが各workerノードのKubelet APIにアクセス出来るようにします。 Kubelet APIにアクセスするのは、メトリクスやログの収集やコマンドの実行に必要です。

Kubelet APIにアクセスし、Podの管理に関連する最も一般的なタスクを実行するための権限を持つsystem:kube-apiserver-to-kubelet ClusterRoleを作成します。

master-1,master-2で以下のコマンドを実行します。

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

こんなエラーが出た

error: unable to recognize "STDIN": no matches for kind "ClusterRole" in version "rbac.authorization.k8s.io/v1beta1"

ClusterRoleがない?いやドキュメントにも有るし、そんな訳ないよな。

と思いきや、Deprecated API Migration Guide | Kubernetesによると

The rbac.authorization.k8s.io/v1beta1 API version of ClusterRole, ClusterRoleBinding, Role, and RoleBinding is no longer served as of v1.22.

とあるな。ワイのバージョンは

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T18:03:20Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.0", GitCommit:"c2b5237ccd9c0f1d600d3072634ca66cefdf272f", GitTreeState:"clean", BuildDate:"2021-08-04T17:57:25Z", GoVersion:"go1.16.6", Compiler:"gc", Platform:"linux/amd64"}

1.22だからダメなんか?

Migrate manifests and API clients to use the rbac.authorization.k8s.io/v1 API version, available since v1.8.

rbac.authorization.k8s.io/v1 を使うのか。

コマンドを以下のよう修正。

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
rules:
  - apiGroups:
      - ""
    resources:
      - nodes/proxy
      - nodes/stats
      - nodes/log
      - nodes/spec
      - nodes/metrics
    verbs:
      - "*"
EOF

実行結果

vagrant@master-1:~$ cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
> apiVersion: rbac.authorization.k8s.io/v1
> kind: ClusterRole
> metadata:
>   annotations:
>     rbac.authorization.kubernetes.io/autoupdate: "true"
>   labels:
>     kubernetes.io/bootstrapping: rbac-defaults
>   name: system:kube-apiserver-to-kubelet
> rules:
>   - apiGroups:
>       - ""
>     resources:
>       - nodes/proxy
>       - nodes/stats
>       - nodes/log
>       - nodes/spec
>       - nodes/metrics
>     verbs:
>       - "*"
> EOF
clusterrole.rbac.authorization.k8s.io/system:kube-apiserver-to-kubelet created

OKOK!

Kubernetes API Serverは、--kubelet-client-certificateフラグで定義されたクライアント証明書を使用して、system:kube-apiserverユーザーとしてKubeletに認証をかけます。

system:kube-apiserver-to-kubeletクラスターロールをsystem:kube-apiserverユーザにバインドさせます。

コレも先ほどと同様、公式はapiVersion: rbac.authorization.k8s.io/v1beta1でしたけど、apiVersion: rbac.authorization.k8s.io/v1に変えてます

cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: system:kube-apiserver
  namespace: ""
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: kube-apiserver
EOF

今日はここまで! お読み頂き有難うございました!

Kubernetes The Hard Way On VirtualBox 10日目

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの10日目。

今日はネットワーク設定です。

Provisioning Pod Network

今回、kubernetesのネットワークはCNI weave プラグインを使います。

CNIとは何か

containernetworking/cni: Container Network Interface - networking for Linux containers

CNIは(Container Network Interface)の略で、コンテネットワークのAPIです。コンテナのネットワークをInterfaceとして切り出したので様々なベンダーやプロジェクトでプラグインが作成されています。 今回はweaveプラグインを使います。

Install CNI plugins

worker-1worker-2 で、プラグインをダウンロードします・

wget https://github.com/containernetworking/plugins/releases/download/v1.0.1/cni-plugins-linux-amd64-v1.0.1.tgz

/opt/cni/bin/ ディレクトリに解凍します

sudo tar -xvzf cni-plugins-linux-amd64-v1.0.1.tgz --directory /opt/cni/bin/

Deploy Weave Network

weaveをデプロイします。 master-1 で以下のコマンドを実行

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"

Verification

masterノードから、weave Podの起動を確認できます。

vagrant@master-1:~$ kubectl get pods -n kube-system
NAME              READY   STATUS    RESTARTS        AGE
weave-net-szm6v   2/2     Running   1 (8m28s ago)   8m39s
weave-net-wdcjr   2/2     Running   1 (8m28s ago)   8m39s

ずっと NotReady だったNodeのステータスも変わりました

vagrant@master-1:~$ kubectl get node
NAME       STATUS   ROLES    AGE   VERSION
worker-1   Ready    <none>   60d   v1.22.0
worker-2   Ready    <none>   25d   v1.22.0

今日はここまで! お読み頂き有難うございました。

Observability とOracle Cloud について考える

この記事は、 JPOUG Advent Calendar 2021 14日目の記事です。

13日目は wmo6hashさんの記事『「働き方の新しいスタイル」への仕事場の最適化』でした。

本記事ではObservabilityというものについて考え、Oracle Cloudでどう実現したら良いのか考えてみます。

Observabilityとは何か

まずは歴史的経緯を見てみましょう。こちらのサイトがとてもよくまとまっていました。

www.humio.com

そのサイトによると

  • 1960年に電気工学の制御理論の中で「Observability」という考えが出てきた
  • 2013年にObservability at Twitterという記事でITシステムにObservabilityという言葉が使われた
  • 2017年にMetrics, tracing, and loggingの3つの柱の重要性が解かれた
  • 2019年に3つの柱を見直す動きがあり(特にログはマイクロサービスではデータ量が肥大化する)、活発な議論が今でもされている

という事がわかりました。3つの柱が重要なのは事実ですが、扱い方にフォーカスが移っているようです。

システムの内部状態を理解でき、探索できるようにし、何が起きたのかという疑問に答えられるようにすること。それがObservabilityだと結んでいます。

記事中で私が最も興味を持ったのが以下のツイートです。

Charity Majorsさんは一連のツイートの中で、イベント を中心に考えないと3つの柱は意味がないと言っています。盲目的に3つの柱を推奨するのはやめましょうと。

ログ、メトリクス、トレースはイベントから生まれるもので、ログやメトリクスをいくら集めてもイベントにはならない。ツールありきだと何種類ものツールを行ったり来たりすることになると(強めの口調で)言われています。

Charity Majorsさんはhoneycomb.ioと言う会社のCTOで、コーポレートサイトのブログは、参考になる記事が多いです。

その中でFramework for an Observability Maturity Modelという記事があるので紹介します。

www.honeycomb.io

これは組織のObiservability成熟度レベルに関する記事です。

ざっくり紹介しますけど、本文にはチェックリストもあるのでぜひ読んでみてください。

Framework for an Observability Maturity Model

  • Observabilityのゴール
    • サステナブルなシステムとエンジニアの幸福
      • 観測可能なシステムは所有と維持が容易で、エンジニアが楽になる
      • エンジニアの幸福度が上がれば離職率も下がり、新規採用コストを下げる事ができる
    • ビジネスニーズの充足と顧客の幸福
      • Observabilityはビジネスを成功させるためのもの
      • 可視性の高いシステムがあれば顧客に必要なものを理解でき、効率よく安全に提供できるようになる
    • 観測性は、コンピュータシステムだけの特性でもなければ、人間だけの特性でもない。
    • Observabilityに関する議論は、装置、ストレージ、クエリなどの技術的な部分にのみ焦点が当てられ、システムが実際にどのように使用されているかについては議論されないことが多い。
    • チームが問題解決のためにツールを使用することに違和感を感じたり、不安を感じたりすると、結果を出すことができない。ツールの品質は、機能の追加が容易かどうか、十分な粒度でデータを取り込むことができるかどうか、人間が発する質問に答えられるかどうか、などの要素によって決まる。
  • Observabilityの品質が影響をもたらすもの
    • システム障害に対して、回復性(resilience)を持たせる
      • Observabilityの質を上げると
        • チーム内にスキルが分散しているので、全員が障害に対応できる
        • 対応不要な偽アラートがなく、ストレスが少ない
        • トレーサビリティの高い監視で問題を迅速に解決できる
    • 高品質なコードをデリバリ
      • Observabilityの質を上げると
        • どこでエラーになったのか容易に確認できる
        • 豊富なテレメトリを提供することでエンジニアはユーザの目に触れる前に修復できる
    • 複雑性と技術的負債の管理
      • Observabilityの質を上げると
        • 障害や遅延の原因を素早く発見できるようになる
        • 勘や推測ではなく最適化すべきコードを特定できる
    • 流れを予測できるリリース
      • Observabilityの質を上げると
        • ビルドやデプロイの問題に早く気づける
        • 新旧のビルドIDを比較することで、コードの変化が意図したものかどうか確認できる
    • ユーザの振る舞いを知る
      • Observabilityの質を上げると
        • イベントドリブンなデータ分析と予測可能なリリースサイクルを構築できる
        • プロダクトマネージャは自分たちの変更がどれだけビジネス目標を達成したか理解し、反復して機能開発できる

Observabilityって結局なんなの?

今も議論されているので明確な定義はないのでしょうが、私個人の見解としては、『仕組みと組織が、「何が起きたのか」というシステムへの問いかけに対してどのくらい答えられるか』ですかね?

ログを集約させたけど誰もみてないとか、無視していいアラートが多いとかっていうケースは割とよくある気がしてて、目的をしっかり持ってツールを入れないとダメだと思ってます。

昔、社内研修用にObservabilityとか監視に関する以下の資料を作った事があるんですが、当時とあまり考えは変わってないのかなという気もしてます。

現在、私の職場ではDatadogを使っています。非常に高機能な製品で文句の付け所がありません。

が、我々の使い方はモニタリングツールとして使っている比率が高くて、障害発生時の調査や分析という使い方が十分出来ているとは思っていません。

だからといって無闇矢鱈とDatadogに集約させると言うよりかは、課題をしっかりと定義して解決策の1つとして使っていけたら良いのかなと思ってます。

Oracle Cloud におけるObservability

Oracle Cloud にはOracle Cloud Observability and Management Platformというものがあります。

www.oracle.com

プレスリリースや紹介記事を見てると

  • マルチクラウドの監視ができる
  • FluentdやGrafana,PagerDutyなどと連携可能
  • マイクロサービスやJavaK8sのトレースが可能

などの特徴があるようです。Javaアプリケーションであればトレース・エクスプローラ で、前述したようなイベントベースの分析が可能になるように思います。

またはResource Managerを使うことで、インフラレイヤのデリバリを高速化出来るかもしれません。

いくら便利なツールがあってもツールはあくまでも組織の加速装置だし、アラートに対して対応するかどうかは最終的には人間が判断する事です。

皆さんも何が課題で、どうやってその課題を解決するのか検討してObservabilityを育てていきましょう。

お読みいただきありがとうございました。

Kubernetes The Hard Way On VirtualBox 9日目

Kubernetesを雰囲気で使わないための修行Kubernetes The Hard Way On VirtualBoxの9日目。

今日はリモートアクセス用のkubectlの設定です。

Configuring kubectl for Remote Access

今回は adminユーザの証明書を元に、kubectlコマンドのためのkubeconfigファイルを作成します。

The Admin Kubernetes Configuration File

kubeconfgには、接続するKUbernetesAPIServerが必要です。高可用性をサポートするために、外部ロードバランサのIPアドレスを使用します。

{
  KUBERNETES_LB_ADDRESS=192.168.5.30

  kubectl config set-cluster kubernetes-the-hard-way \
    --certificate-authority=ca.crt \
    --embed-certs=true \
    --server=https://${KUBERNETES_LB_ADDRESS}:6443

  kubectl config set-credentials admin \
    --client-certificate=admin.crt \
    --client-key=admin.key

  kubectl config set-context kubernetes-the-hard-way \
    --cluster=kubernetes-the-hard-way \
    --user=admin

  kubectl config use-context kubernetes-the-hard-way
}

Verification

接続して確認

kubectl get componentstatuses

以下のように出力されればOK

vagrant@master-1:~$ kubectl get componentstatusesWarning: v1 ComponentStatus is deprecated in v1.19+
NAME                 STATUS    MESSAGE                         ERROR
scheduler            Healthy   ok                              
etcd-0               Healthy   {"health":"true","reason":""}   
etcd-1               Healthy   {"health":"true","reason":""}   
controller-manager   Healthy   ok  

最後までお読み頂き有難うございました。