だいごろうのブログ

熊本出身で大阪、東京、パリを転勤して、今は福岡でデータエンジニアです

katacodaでService Mesh with Istio: ver3 Monitoring and Tracing

Monitoring and Tracing

Prometheus と Grafana使ってるみたい。 っというか、Kubernetes周りの3rd Partyはこの2つをけっこう使ってるケースを見る。オートスケールとかPrometheusにメトリクスもたせて行ってる実装をよく目にする。

www.katacoda.com

Code

実際にyamlファイルを作成し、Prometheusにmetricsを反映させることができるみたいやな。

istioctl create -f hogehoge.yml -n istio-system

openshiftだと、このコマンドでアクセスするためのURLを取得できるみたい。

oc get routes -n istio-system

kubernetesだとどげんすっとやろ。

https://istio.io/docs/tasks/telemetry/metrics/using-istio-dashboard/

ここ見たらわかりそう。

kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &

このコマンドのあとに、このURLにアクセスすると確認できた。たぶん、kubectlでポートを割り当てて、フォワードしてる。 http://localhost:3000/d/-vJFVqdWk/istio-mesh-dashboard?orgId=1

で、ちゃんと、メトリクスが追加されているか確認。 f:id:daigorowhite:20190903082032p:plain

Tips

  • kubectl port-forward どうやら、このコマンドは kubectlのローカルホストにフォワードする機能みたい。

使い方 Use Port Forwarding to Access Applications in a Cluster - Kubernetes

ちょっと詳細 Kubectl Reference Docs

あと、どうやって、このport forward止めるんだろうって、思ってたらどうやら、別に子プロセスをセッションに作ってるみたいだから、それをkillすればOK

$ jobs
[1]+  Running                 kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000 &
$ kill -9 %1
$ jobs
[1]+  Killed: 9               kubectl -n istio-system port-forward $(kubectl -n istio-system get pod -l app=grafana -o jsonpath='{.items[0].metadata.name}') 3000:3000

Training

OpenTracingとJaegerを利用してるみたい。これは使ったことない。 というか、ビッグデータ周りを最近やってて、このMicroServiceのトレース系をあまり触る機会がなかったな。 OpenTracingは非ベンダ依存のAPIフレームワークらしい、でJaegerはTrace用のデータを収集したり、保存、可視化したりするツール。でJaegerはOpenTracing を利用して、MicroServiceからデータの収集をしてるみたい。Zipkinを参考にJaegerが作られたみたい。何が違うのかは、別途勉強。

とりあえず、書いてあることを見ると、Istioが自動的にdataを集めて、Jaegerに送信するみたい。なので、アプリはOpenTracingとかJaegerを気にしなくて良い。

とりあえず、確認結果見れたことのキャプチャを貼っておく。 非常に便利だと思った。Zipkinと比べてみたいなぁ。なんとなく、Jaegerのほうがシンプルな感じがする。今度、勉強しよう。

Search

一つのServiceのアクセス結果リストページ。全体の結果を俯瞰的に見るときに役に立つ。 f:id:daigorowhite:20190906081226p:plain

Detail

一つのクエリの詳細ページ。極端に気になるものがあった場合のボトルネックを探せそう。 f:id:daigorowhite:20190906081302p:plain

Dependencies

APIのお互いの利用回数とか、依存関係も一目瞭然! f:id:daigorowhite:20190906081443p:plain

IstioのIngressGatewayの検証

[MEMO] katacodaでService Mesh with Istio: ver2 Istioctl - だいごろうのブログ こっちのブログポストで気になったので、 ingress gatewayを試してみようと思います。環境作成を前のブログを参考にしてください。

Ingress Gateway

KubernetesIngress Controllerと似たような機能を Istioとかで利用できるようにするのがIngress Gatewayっぽい。

とりあえず、ここを理解してみよう。 Istio / Ingress Gateways

Istio on Minikube

Istio / Minikube どうやら、デフォルトだとメモリやCPUが全然足りないみたいなので、増やす。最初、これをしてなくて、全然、podが起動しなくて、困った。 とりあえず、メモリとCPUを倍に増やしてみる。(まだ、足りないかも)あと、minikubeのデフォルトのVMがいっぱいいっぱいになってきたので、profile変えてみる。

minikube start --memory=4096 --cpus=4 -p istio

後で気づいたが、tunnelでistioにLoadBalancerを提供できるみたい。 後日検証。

sudo minikube tunnel

Istioの確認

kubectl get svc istio-ingressgateway -n istio-system
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)                                                                                                                                      AGE
istio-ingressgateway   LoadBalancer   10.110.94.62   <pending>     15020:32200/TCP,80:31380/TCP,443:31390/TCP,31400:31400/TCP,15029:32445/TCP,15030:30505/TCP,15031:30605/TCP,15032:31662/TCP,15443:30531/TCP   7d

このEXTERNAL-IPがNoneやpendingの場合は、NodePortでアクセスしてくれって書いてあるな。たぶん、LoadBalancer立ててないのと、minikubeのせいで、pendingになってんのかな。 external load balancer for the ingress gatewayがないと、あかんっぽいな。

minikube + nodeportの場合は、IPとポートをこんな感じで取得

export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
export SECURE_INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="https")].nodePort}')
export INGRESS_HOST=$(minikube ip -p istio)

公式に沿って、istio GatewayとVirtualService立てる

Gateway

kubectl apply -n istio-tutorial  -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: httpbin-gateway
  namespace: istio-tutorial
spec:
  selector:
    istio: ingressgateway # use Istio default gateway implementation
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "istio.tutorial.com"
EOF

VirtualService

kubectl apply -n istio-tutorial  -f - <<EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "istio.tutorial.com"
  gateways:
  - httpbin-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        port:
          number: 8080
        host: customer
EOF

確認

# ちゃんと設定できているかを確認
curl -I -HHost:istio.tutorial.com http://$INGRESS_HOST:$INGRESS_PORT/ -v

# アクセスを確認
kubectl logs pod/customer-59975dcff6-jwc7c -n istio-tutorial --all-containers=true -f

Ingress gatewayingress resources

Ingress gatewayingress resourcesの違いをちゃんと理解したい。今、認識ているところだと、ingress gatewayを使うと、Istioの旨味をGatewayでも利用できる点と、 既存のingress resourcesだとhttp/httpsしか、ハンドルできないんじゃないかな。

これも後でちゃんとよむ。 Ingress - Kubernetes

感想

思ったとおり、動いた!でも、Istioのインストールのときに、なぜか数分間いくつかのpodがうまく起動できなかったり、ちょっとハマった。まだ、わかってない点がおおいなぁ。kubernetesingressでも思ったが、簡単に使える点は良い。理解しなければいけないことは多いが、便利。

[MEMO] katacodaでService Mesh with Istio: ver2 Istioctl

istioctl

どうやらこのコマンドがistioの味噌みたい。 この章ではistioctl kube-injectをメインに勉強。

Deploy.yamlにkube-injectコマンドすることで、SideCarなどの設定を自動で入れてくれるみたい。

istioctl kube-inject -f {YAML}

こんな感じでおしゃれに渡してる。

kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n namespace

Kubernetesでやってみる

Katacodaの中身がocコマンドつまりredhatのopenshiftなので、minikube立ててローカルでkubernetesでやってみた。

とりあえず、Istioをkubenetesにapplyとistioctlインストールしておく

curl -L https://git.io/getLatestIstio | ISTIO_VERSION=1.2.2 sh -
cd istio-1.2.2
export PATH=$PWD/bin:$PATH

kubectl create namespace istio-system
for i in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply -n istio-system -f $i; done
 kubectl apply -f install/kubernetes/istio-demo.yaml
# 準備
git clone https://github.com/redhat-developer-demos/istio-tutorial/
minikube start
kubectl create namespace istio-tutorial


cd istio-tutorial
cd customer/kubernetes/

## istioctl kube-injectを確かめておこう
istioctl kube-inject -f Deployment.yml

## kubectlにappyする
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial
kubectl get all -n istio-tutorial
less kubernetes/Deployment.yml

# 既存がClusterIPで外部から見れないので、NodePortも作る
cp Service.yml Servicenp.yml
vi Servicenp.yml
diff Service.yml Servicenp.yml
4c4
<   name: customer
---
>   name: customernp
6c6
<     app: customer
---
>     app: customernp
7a8
>   type: NodePort

kubectl apply -f Service.yml -n istio-tutorial
kubectl apply -f Servicenp.yml -n istio-tutorial


## アクセスしたいので, ip portを調べる
kubectl get service/customernp -n istio-tutorial  -owide

# nodeのIPがわからんかったから、 cluster-infoから引っ張ってくる
kubectl cluster-info
curl https://192.168.99.100:32318

## ほかもapply
## curlのレスポンスが変わっていくのが確認できる
cd ../../preference/kubernetes/
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial
kubectl apply -f Service.yml -n istio-tutorial
curl http://192.168.99.100:32318

cd ../../recommendation/kubernetes/
kubectl apply -f <(istioctl kube-inject -f Deployment.yml) -n istio-tutorial
kubectl apply -f Service.yml -n istio-tutorial
curl http://192.168.99.100:32318

最終的にはこんな感じ

kubectl get all -n istio-tutorial
NAME                                     READY   STATUS    RESTARTS   AGE
pod/customer-59975dcff6-7k8rr            2/2     Running   0          27m
pod/preference-v1-8578c48ff-mjhln        2/2     Running   0          9m7s
pod/recommendation-v1-85474b59d5-5hhg4   2/2     Running   1          7m15s

NAME                     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
service/customer         ClusterIP   10.106.206.127   <none>        8080/TCP         19m
service/customernp       NodePort    10.111.254.169   <none>        8080:32318/TCP   20m
service/preference       ClusterIP   10.102.211.153   <none>        8080/TCP         8m57s
service/recommendation   ClusterIP   10.105.191.131   <none>        8080/TCP         7m11s

NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/customer            1/1     1            1           27m
deployment.apps/preference-v1       1/1     1            1           9m7s
deployment.apps/recommendation-v1   1/1     1            1           7m15s

NAME                                           DESIRED   CURRENT   READY   AGE
replicaset.apps/customer-59975dcff6            1         1         1       27m
replicaset.apps/preference-v1-8578c48ff        1         1         1       9m7s
replicaset.apps/recommendation-v1-85474b59d5   1         1         1       7m15s

どんな感じで、コードの方は定義されてんやろう。どうやって、istioを利用してるんだろう。

customer -> preferenceで名前解決してるところはどうやら単純に、preferenceをhostとして指定するだけみたい。

preferences.api.url=http://preference:8080

https://github.com/redhat-developer-demos/istio-tutorial/blob/master/customer/java/springboot/src/main/resources/application.properties

同じnamespaceのserviceにservice名でアクセスできる感じかな。あとでもっと理解する必要ありそう。ただ、docker-composeと同じように名前をつけれるので、ローカルではdocker-composeで開発して、kubernetesデプロイ時にはistioに名前解決させるで良さそう。

ingress gateway

よく考えたら、serviceのnodeport使わなくても、 ingress gatewayからアクセスとかできるんじゃないかな。ちょっと検証してみよう。ただ、長くなってきたから、別のブログポストにまとめます。

TBD

まとめ

istioのサポートがアツい。kubernetesへの導入の簡単さ、違和感なくkubernetesを使えてる感じ。すごい。

あとで読む。 https://istio.io/docs/concepts/traffic-management/

[更新中] Docker初心者向けコンテンツまとめ

ゴール

社内でDockerを勉強した人がいたので、ちょっと、情報をまとめてみた。 今(2019/08/01)、僕の認識してるところだと、大きな障壁が英語である。DockerとかはVMとの違いは何かなどの考え方の違いの理解が多く必要だと思うので、英語に慣れていない人だとハンズオン系のものが足りなく感じるので、このページで、どこらへんを見て勉強すれば良いかの目印を作れればと思う。 このページは、Docker自体については、記述しないし、今現在の情報を載せるつもりです。こういうのもあるよってあれば、教えてほしいです。

ハンズオン系

英語

katacoda

今の所、一番好き。オンラインでできるので、dockerのインストールもいらないし、どんな環境からもやりやすい。Katacoda内にkubernetesもあるし、幅広いコンテンツもあるので、 www.katacoda.com

learndocker

VideoとQuizzeに分かれていて、理解度を確認しながら進めるみたい。 githubのアカウント連携を求められる。

f:id:daigorowhite:20190801084228p:plain
learndocekr
learndocker.online

sample code

Dockerの公式。サンプルコードがたくさんあるし、Tutorial labsのチャプターで自分のユースケースに合わせて、勉強すれば感覚がつかめるんじゃなかろうか。 docs.docker.com

日本語

入門 Docker

パット見た限りであるが、初心者向けには良さそうでさる。絵を使って概念の説明と、利用コマンド例が入ってる。資料にそって、練習するだけで基本は身につきそう。 y-ohgi.com

Video

英語

youtube

12分で、Dockerの基本を紹介してる。初めてだときついかも。 Learn Docker in 12 Minutes 🐳 - YouTube

udemy

Udemy。Docker,Kubernetesまでをカバーしており、今の所一番人気っぽい?1万円くらい。 https://www.udemy.com/docker-and-kubernetes-the-complete-guide/

日本語

udemy

Udemy。1万円くらいするが、日本語で教えてくれると思うと安い。 https://www.udemy.com/docker-k/

他の紹介サイト

さすが、英語だと大量にコンテンツある hackr.io

引き続き更新していきます。2019/08/01

[MEMO] katacodaでService Mesh with Istio: ver1 Istio Introduction

前回までKubenetesをやってたんですが、続いて、ServiceMeshも正しく理解したくて今回から別のコースをやって行きたいと思います。

勝手に名言「正しい判断は正しい知識から。」( ー`дー´)キリッ

www.katacoda.com

公式も後で読もう。 istio.io

Istion/ServiceMesh Introduction

ServiceMeshはMicroServiceのネットワークあたりの用語としてよく使われる。 MicroServiceが増えてくるとdiscovery, load balancing, failure recovery, metrics, and monitoringあたりが必要かつ難しくなってくる。また、ここらへんも求められちゃう A/B testing, canary releases, rate limiting, access control, and end-to-end authentication。

Istio

Istioはservice meshの振る舞いのInsightや運用管理を可能とする。

  • traffic管理 : Service感の通信の管理
  • 管理能力 : どのpodがどのservice使ってんの
  • Policyの施行 : serviceを超えてpolicyをひとまとめに管理できる的な? Meshの設定でそれを管理するので、全体でフェアなリソース管理になるって感じかな
  • Serviceのidentityとセキュリティ : サービスの認証あるから、セキュリティも担保しやすい。てきな

Istioは最初Kubernetesのために作られたが今はMesosなどにも対応してるし、onPre,Cloudどちらもおーけー。あと、Policyなどはカスタマイズ可能で、ACLs, logging, monitoring, quotas, auditing ここらへんを自由に付け替え可能らしい。

DataPlane / ControlePlane

https://istio.io/docs/concepts/what-is-istio/#architecture

data plane

intelligent proxies (Envoy) のセットで、SideCarとしてデプロイされる。MicroService間のネットワークをコントロール。proxyの仲介を行う。Mixerから設定を読み取るっぽい。 (TODO SideCar勉強しないと。)

control plane

control planeはproxyの管理を行う。Mixerの調整を行う。

Envoy

Envoyはhigh-performance proxyです。PodのSideCar としてデプロイされるDataPlane。 Pilotから設定を受け取りServiceのインバウンド・アウトバウンド両方のTrafficの仲介・管理・監視を行うっぽい。

Mixer

MixerはPlatform非依存のコンポーネント。ServiceMeshの中で、アクセスコントロールとポリシーの利用を強制する役割を持つ。Proxy(Envoy)からそれらの設定へのアクセスを一任する MixerはControl planeの一つのAPIでProxyの設定の保持とData Planeへの公開を担当してるみたい。

Pilot

Pilot はEnvoySidecar向けのサービスディスカバリ, intelligent routingのためのTraffic管理能力を提供してる。まぁ、つまり、それらの設定をproxy(Envoy)に配布する役割 Pilotを使うことで、Trafficの管理ができる。5%はこのサービスに送るとかCanaryリリースが可能。特定のTrafficはこっちのバージョンに送るとか。

Citadel

Citadelはサービス間やユーザの認証とCredential管理を行う。Citadelを利用することで、ネットワークの制御でなく、Serviceの認証による管理が可能になる。的な。

[MEMO] katacodaでLearn Kubernetes ver10 Exam

www.katacoda.com

Kubernetesの理解度テストがあるのでそれをやってみた。 pod/deployment/serviceとかyamlの書き方などの基本の基をやる感じのてすとでしたわ。ただ、こういう実経験があるとやっぱり、自分のまだ理解してないことが出てくる。

知らんかったり、理解を深めたり

completion

これで、保管できるようになるらしい。

source <(kubectl completion bash)

Daemon Set

DaemonSet は全ノードでdeploymentが動いてるのを保証するオブジェクト。メトリクスを集めるのに適してる。

top command

こんな感じで、各nodeやpodのリソース使用率を管理できるみたい。 知らんかった!

master $ kubectl top node
NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
master   160m         4%     1029Mi          54%
node01   68m          1%     683Mi           17%
master $ kubectl top pod
NAME                            CPU(cores)   MEMORY(bytes)
examplehttpapp-58f66848-8tw4m   1m           0Mi
examplehttpapp-58f66848-j2zv5   0m           1Mi
examplehttpapp-58f66848-qv5rq   0m           0Mi
examplehttpapp-58f66848-rpfmh   0m           0Mi
examplehttpapp-58f66848-z5pwc   0m           0Mi

ReplicaSet and Deployment

この違いを正しく理解したかったのでちょっと調べたらこのページがわかりやすそう。DeploymentがReplicaSetを管理し、ReplicaSetがpodのScaleを担保するみたいな感じかな。

cstoku.dev

Deploymentはrollout戦略をサポートし、imageのバージョンなどを変更したときに、どうやって、ReplicaSetを作り変えるかを管理する。 また、これらのコマンドでそれを管理できる。

kubectl rollout status deployment hogehoge
kubectl rollout history deploy hogehoge

もちろん、rollbackもワン・コマンド!すげぇ!

kubectl rollout undo deployment hogehoge

[MEMO]katacodaでLearn Kubernetes ver9 Kubeless

www.katacoda.com

Kubeless

build up kubeless service

KubelessはKubenetes上で、Serverlessを構築するOSS

kubelessのネームスペース作り、オフィシャルに配布されてるYamlを適応させれば、環境を作れるみたい。

kubectl create ns kubeless
kubectl create -f https://github.com/kubeless/kubeless/releases/download/v1.0.0-alpha.8/kubeless-v1.0.0-alpha.8.yaml

cli

kubelessっていうクライアントがいて、それを用いて、functionのデプロイができるみたい。

Deployの仕方。Runtimeは他に何があるんだろう

kubeless function deploy hogehoge --runtime python2.7 \
                              --handler hogehoge.handler \
                              --from-file hogehoge.py

hogehoge.pyの中身はこんな感じになるっぽい。割とシンプルですな。 公式ページ読んでわかったが、 handlerは"XXXX.YYYY" XXXXはdeploy名で YYYYはfrom-fileの中から呼びたいメソッド名になるっぽい。

def handler(event, context):
   print event
   return event['data']

kubelessからもコールできるので、これは検証用って感じかな。

kubeless function call hogehoge --data '{"hello":"world"}'

あと、kubectl proxyでproxy立てて、そこからアクセスも可能。

curl --data '{"hello":"world"}' localhost:8080/api/v1/namespaces/default/services/hogehoge:8080/proxy/ --header "Content-Type:application/json"

CONTINUE
Terminal   
toy-7c8fc67549-knc52

ログ見たり、詳細見たり。

kubeless function logs hogehoge
kubeless function describe hogehoge

Kubelessについて詳しく調べる

いつもどおり、公式とgithubを理解しよう

github.com

Readme

kubelessは custom-resource-definitionsを使って、kubenetes上に作られてるみたい。 Extend the Kubernetes API with CustomResourceDefinitions - Kubernetes 現状、HTTPかPubSub mechanismに対応してる。 PubSubはKafkaとか。

強豪で、 fissionとfunktion等がいるらしいが、kubelessが一番kubernetes naitiveだと信じてるって書いてあるわ。こういう、思想みたいなのは好きだなぁ。技術選択のときに、こういう開発者の信念とか書いてあると、プロダクトの方向性がわかっていいですよね。

実行環境

実際に、実行して見るときはここに気をつけて。 kubernetesのバージョンの互換性がある。僕が見たとき2019/07/25だと、 1.9以上っていうのがあるみたい。 https://github.com/kubeless/kubeless#compatibility-matrix-with-kubernetes

Sample code

https://github.com/kubeless/kubeless/tree/master/examples ballerina golang java nodejs php python ruby

結構なサポートある。Runtimeさえあればどれでもいけるのか。 もうちょいそこの関係を勉強する必要あるな。

公式サイトみる

kubeless.io

ピックアップ

  • AWS Lambda CLI互換。
  • Kafka messaging and HTTP events対応
  • Prometheus監視をデフォルトでサポート。function callとlatency

Kubernetesは最近はPrometheusを利用するケースが多いみたい。 weaveもそうだったし。

Kafkaを紐付けるのどうするんだろう

https://kubeless.io/docs/pubsub-functions/

公式からの引用だが、このコマンドを用いることによって、kafkaへのtriggerを作るらしい。このケースはtestってfunctionを先に作っておいて、test-topicのEventに紐付けるみたい。

$ kubeless trigger kafka create test --function-selector created-by=kubeless,function=test --trigger-topic test-topic

Kafkaを登録する方法はここを参照 https://kubeless.io/docs/use-existing-kafka/

kubelessネームスペースにkafka-trigger-controllerという名のDeployを作り、その中で、特定のpodをbroker名とcert系の設定を持って、Objectを作れば自動的にそれを利用するのかな。2つKafkaを使いたい場合はどうするんだろう。もっと調べなければ。

Autoscale

Kubelessにはpodのautoscaleの機能が備わっていて、cpuやqpsのしきい値を超えたらスケーするようなことが可能なようだ。便利だなこれも。

kubeless autoscale create --help
automatically scale function based on monitored metrics

Usage:
  kubeless autoscale create <name> FLAG [flags]

Flags:
  -h, --help               help for create
      --max int32          maximum number of replicas (default 1)
      --metric string      metric to use for calculating the autoscale. Supported
      metrics: cpu, qps (default "cpu")
      --min int32          minimum number of replicas (default 1)
  -n, --namespace string   Specify namespace for the autoscale
      --value string       value of the average of the metric across all replicas.
      If metric is cpu, value is a number represented as percentage. If metric
      is qps, value must be in format of Quantity

https://kubeless.io/docs/autoscaling/

ただ、そもそもKubernetesにも"Horizontal Pod Autoscaler"というものがあり、それを用いることでCPUベースで自動スケール設定を入れることが可能なようだ。 で、Custom MetricsでCPU以外でもしきい値を設定できるみたいなので(1.6以降)、それを用いて、 kubelessはオートスケールをしてるんだとおもう。

kubernetes.io

まとめ

Kubelessも初めて知ったときから、進化してるように感じる。本番での安定性とか気になるが、この実装の簡単さはいいですね。あと、Prometheus等との連携を考えると実運用でもかなり使えるんじゃないかなと思う。まぁ、すぐに使う用途がなさそうなことが悔しいですね。

余談

下記のコマンドでhttpアクセスへのproxyをローカルに建てれるみたいだけど、知らなかった。ちょっと、あとで調べよう

kubectl proxy --port 8080 &