[MEMO] katacodaでLearn Kubernetes ver10 Exam
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を担保するみたいな感じかな。
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
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を理解しよう
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さえあればどれでもいけるのか。 もうちょいそこの関係を勉強する必要あるな。
公式サイトみる
ピックアップ
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を作れば自動的にそれを利用するのかな。２つ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はオートスケールをしてるんだとおもう。
まとめ
Kubelessも初めて知ったときから、進化してるように感じる。本番での安定性とか気になるが、この実装の簡単さはいいですね。あと、Prometheus等との連携を考えると実運用でもかなり使えるんじゃないかなと思う。まぁ、すぐに使う用途がなさそうなことが悔しいですね。
余談
下記のコマンドでhttpアクセスへのproxyをローカルに建てれるみたいだけど、知らなかった。ちょっと、あとで調べよう
kubectl proxy --port 8080 &
[MEMO] katacodaでLearn Kubernetes ver8 Weave Scope
Installing Weave Scope on Kubernetes
説明見るだけで、魅力的、追加のモジュールとかコードとかなしに、pod感の通信を可視化する！
how to start
すでに、yamlが提供されてるみたいで、それをそのまま入れればいけるっぽい？
kubectl create -f 'https://cloud.weave.works/launch/k8s/weavescope.yaml'
これだけで、pod/service/daemonset/deployment/replicasetがBuildされた。
master $ kubectl get all -n weave NAME READY STATUS RESTARTS AGE pod/weave-scope-agent-ftrqd 1/1 Running 0 48s pod/weave-scope-app-77c6bbfd94-m77q7 1/1 Running 0 48s pod/weave-scope-cluster-agent-64cf585649-f8zlj 1/1 Running 0 48s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/weave-scope-app ClusterIP 10.109.55.227 <none> 80/TCP 48s NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE daemonset.apps/weave-scope-agent 1 1 1 1 1 <none> 48s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/weave-scope-app 1/1 1 1 48s deployment.apps/weave-scope-cluster-agent 1/1 1 1 48s NAME DESIRED CURRENT READY AGE replicaset.apps/weave-scope-app-77c6bbfd94 1 1 1 48s replicaset.apps/weave-scope-cluster-agent-64cf585649 1 1 1 48s
このDaemonSetがPodを全ホストに自動でデプロイするみたい。で、そのPodで全体のネットワークを可視化するみたい。こうすることで、他に何も変更せずに可視化できる。
アクセス
これだけだと、internalにしか公開されないので、externalにするみたい。ただpublic_ipに紐付けるのは推奨されないので、VPNでつなぎましょうと。
つなぐとこんな感じ
なにこれすごい。やばい、感動する。
ちょっと、もっと調べよう
Weave
Weave ScopeはWeaveWorksって会社のプロダクトのうちのひとつなのかな。
WeaveEnterprizeとOpenSourceに別れてるっぽい トップページからの引用
Automate Enterprise Kubernetes the GitOps way
Operate and manage production ready Kubernetes with Weaveworks' Enterprise Kubernetes Platform. GitOps unlocks cloud native agility, reliability and scalability.
監視、ログとか運用に必要なことをワンパッケージにしつつ、デプロイパイプラインをgitopsでシンプルにできる。みたいなサービスかな。たぶん、かいつまみすぎ。
gitopsのweave記事さくっと読んでみた GitOps
https://www.weave.works/technologies/gitops/#pull-pipeline GitOpsにはPush型とPull型があり、WeaveはPull型Pipelineらしい。
Push型 : Gitにコミットしたものをkubectlなどで、手動、もしくはジョブでkubernetesにapplyしていく。
Pull型 : Gitにコミットしたら、"Deployment Automator"なるものが、Gitを監視してて、変更があれば、それをkubernetesにapplyしていく。
なるほどね、Chefの適応と似てるなと思った、ChefServerのレシピに変更があれば、自動で適応していくのを思い出した。開発者とサーバの実作業のdependencyが剥がされて良い設計だなと思ってたけど、Pull型Pipelineっていうのか。
ほかのWeave Opensource
Weave Net
cloud native networking toolkitらしい。VirtualNetworkを複数のDockerホスト上に構築して、自動でdiscoveryをし、 ‘invisible infrastructure’を実現するみたい。（ちょっと、ぼくもまだ理解できてない。）
Weave Flux
- Gitopsをkubernetesクラスターでするためのオープンソース。”single source of truth ”に貢献する
Weave Cortex
TimeSerieaseDataBase。Scalabeで Cloud-native Prometheus ！で、データの永続化も大丈夫だぞ。みたいな。正直Prometheus を永続化問題で、サーバ立てて管理してるので、ちょっと、気になる。
Flagger
Automate and manage canary and other advanced deployments with Istio, Linkerd, AWS App Mesh or NGINX for traffic shifting. Integrated Prometheus metrics control canary deployment success or failure. https://www.weave.works/oss/flagger/
これ、すごいんじゃないかな。 Prometheusと連携して、メトリクスをコントロールしながら、 canaryリリースを可能にする。で、 Istioとかサービスメッシュとかを一緒に使うことができる。これも、もっと深くまで勉強したい。リリース周りの自動化が捗る。
eksctl
Create a cluster in minutes with just one command and manage the entire cluster lifecycle with GitOps. https://www.weave.works/oss/eksctl/
AWSのEKS上に、ワンクリックでgitopsのクラスターを構築するっていう、用途特化のツール。ただ、初期構築には、かなり便利なんじゃないかなー。正直、ちょっと、ブラックボックス感があるから、好きではないが、こういう自動化はいいよね。
あとで、読まねば
[MEMO] katacodaでLearn Kubernetes ver7 Kompose / Helm + Helm周りを調べてみた
今回は、kubenetesのyamlの管理ツール系の話。KomposeとHelmを読んで見てる。
https://github.com/kubernetes/kompose/releases
Kompose
docker-compose.yamlを用意し
kompose up
kompose upをすると自動で、kubernetesにそのdocker-composeにかかれている deployment,svc,pods,pvcなどを作成する。
kompose convert
kompose convertを利用することにより、 kubernetesのyamlファイルに変換してくれる。
kompose --provider openshift convertこのようにして他のproviderをサポートすることも可能みたい。
Helm
標準的なkubernetesのいくつかのパッケージ（charts）を簡単にkubernetesで実行できるようなものかな？結構ないろいろな会社とコミュニティが運営してるみたいで、今後の発展性も良さそうだな。
helm search {SEARCH_WORD}
chartsを検索する。
helm inspect {NAME}
対象のchartsの詳細を見る
helm install {NAME}
対象のchartsをkubernetes上で起動する。
helm ls
今helmから実行しているPodを確認
Helm in github
なんか、よくわからんから、githubを訳していく。 https://github.com/kubernetes/helm/releases
HelmはKubernetesのchartsを管理するツール. Chartsはpre-configured Kubernetes resourcesのパッケージです.
こういったケースに使います。
- よくあるパターンのソフトウェアのパッケージをHelm chartsでKubernetes上で実行したいとき
- Helm chartsで自分のアプリをシェアしたいとき
- Kubernetesのアプリケーションを再現可能なbuildにしたいとき。
- かしこくKubernetesのマニフェストを管理したい
- Helm packagesを管理したい
Helmは Kubernetesのapplicationsの管理とインストールを簡略化するツールです。apt/yum/homebrewのKubernetes版だと思ってください。
- Helmはclient (helm) and a server (tiller)のパーツに別れます
- TillerはKubernetes内で動作し、chartsのインストールなどを管理します。
- Helmは自分のPCやCI/CD上で起動します。
- Chartsは以下の２つを最低限含むHelm packages:
- パッケージの詳細 (Chart.yaml)
- 一つ以上のKubernetesのmanifestのテンプレートファイル
- ChartsはディスクやリモートChart repository(これなんだろう？) などに保存できます (like Debian or RedHat packages)
とりあえず、githubにのREADMEを訳してみた。わかるようなわからんような。 あとでここも、読んで理解しておこう。 helm.sh
自分で、Chartsを書くドキュメントも充実してるなぁ。 https://helm.sh/docs/developing_charts/#charts
なかなか良さそうだと思って、反論ブログも探してみた。 winderresearch.com まとめると、Securityの甘さと、管理の複雑さかな。 podとTillerあたりとsecretの保存周りが微妙かな。あと、gitopsでバージョン管理できてたのが、複雑になるとか、kubenetesのベストプラクティスではなくなるとか。テンプレートをしたかったらkustomizeとか、他のツールも検証してみなよって感じ。
所感
DockerのオーケストレーションでKubernetesだと思って、勉強したけど、CROIなどの登場で、KubernetesでDocker以外を使う選択肢も出てきたり、Kubernetesのオブジェクトを管理するためのツールも多々出てきて、熟成が始まった感があって、学習意欲が掻き立てられますな。
[MEMO] katacodaでLearn Kubernetes ver6 manage Secrets
Use Kubernetes to manage Secrets
Use Kubernetes to manage Secrets | Kubernetes | Katacoda
Secrets
create secret
こんな感じでシークレット用のyamlを作成することが可能
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
user: {user-name base64}
password: {password base64}
read from pod
podのyamlの中で、このように指定することでenvの中に埋め込むことが可能である。 ただ、メモリ上に配置することはセキュリティの観点からあまり好ましくない。
env:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: my-secret
key: user
また、こんなvolumeと組み合わせでファイルとして読み込むことも可能みたい。
apiVersion: v1
kind: Pod
....
spec:
volumes:
- name: {great-name-of-volume}
secret:
secretName: {your secrete name}
containers:
- ....
volumeMounts:
- name: great-name-of-volume
mountPath: /your/secret/path
Secrets from file
別途、ファイルを保存することも可能なようだ コマンドだと、こんな感じで。
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt
yamlだと、こんな感じになるみたい。(from version 1.14)
secretGenerator: - name: db-user-pass files: - username.txt - password.txt EOF
こんな感じ。
Etc
Secretの更新
Secretの更新頻度などはConfigMapAndSecretChangeDetectionStrategyで設定されてるみたい。更新までは、Cacheに乗ってるデータが使われるので、applyしてから反映まで少し時間かかるみたい。デフォルトどれくらいかは、調べてない。 https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/kubelet/config/v1beta1/types.go#L679-L684
SSH Keyの例
https://kubernetes.io/docs/concepts/configuration/secret/#use-case-pod-with-ssh-keys
Best Practice
あとで読む https://kubernetes.io/docs/concepts/configuration/secret/#best-practices
[MEMO] katacodaでLearn Kubernetes ver5 CRI-O and Kubeadm / Stateful Services on Kubernetes
Getting Started With CRI-O and Kubeadm
Container Runtime Interface (CRI) らしい。
なんで、CRIって必要なんだろうと思って調べてみた。これがわかりやすい。 コンテナランタイムの動向を整理してみた件 - Qiita
Docker以外のContainer RuntimeをKubernetesに導入、実装しようと思うと、現状敷居が高いらしく、１枚間に挟むことで、HighLevelのレイヤーができるみたい。
まぁ、いまのところ深くは勉強しないつもりだけど、Docker以外にもRuntimeはいろいろと出てきているみたいで、KubernetesがDocker以外にも導入しやすくしたことで、今後議論の余地が生まれそうだなぁ。
Running Stateful Services on Kubernetes
Running Stateful Services on Kubernetes | Kubernetes | Katacoda
このチャプターは、DockerでNFSのサーバを立てて、--net=hostとすることで、NFSののプロトコルをローカルホストで受けれるようにし、k8sからマウントするみたいだ。
引用
docker run -d --net=host \ --privileged --name nfs-server \ katacoda/contained-nfs-server:centos7 \ /exports/data-0001 /exports/data-0002
PersistentVolume
まだ、今回は読んでないけど、あとで読む Persistent Volumes - Kubernetes
PersistentVolumeで、NFSのサーバをマウントしてる感じかな
- persistentVolumeReclaimPolicyは選べる Retainedだとのこり、 Recycled だと消える。
kind: PersistentVolume
metadata:
name: your-nfs
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
- ReadWriteMany
persistentVolumeReclaimPolicy: Recycle
nfs:
server: ${IP}
path: ${PATH}
PersistentVolumeClaim
自動でPersistentVolumeをマウントするっぽい？
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: your-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
で次に、podの定義にこれを追加する。
spec:
volumeMounts:
- name: mount-volume-name
mountPath: /mount/path
volumes:
- name: mount-volume-name
persistentVolumeClaim:
claimName: your-claim
もし、PersistentVolumeClaimにPersistentVolumeがアサインされておらず、Pendingなら、PodもPending状態になる。
[MEMO] katacodaでLearn Kubernetes ver4 Liveness and Readiness
# Liveness and Readiness Healthchecks
Configure Liveness and Readiness Probes - Kubernetes
Liveness and Readiness Healthchecks | Kubernetes | Katacoda
## Liveness
Livenessはそのポッドのhealth checkをするための機能です。いわゆる、死活監視。
この条件を満たせなければ、podの再起起動を行う。
tcp,httpやファイルのアクセスなどでを設定することが可能
```
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 1
timeoutSeconds: 1
```
## Readiness
Readinessは、ポッドがアクセス可能になる条件を設定できる。ここに書いた条件を満たせば、Serviceがトラフィックを流すようになる。
## Prove parameter
ココらへんが、設定値。readinessもlivenessもパラメータは同じ。
initialDelaySeconds: コンテナがスタートして、何秒間待つか。
periodSeconds: 何秒ごとにテストするか
timeoutSeconds: 毎回とテストのタイムアウト。
successThreshold: 何回成功したら、良いのかのしきい値。最低１
failureThreshold: 何回失敗したら、Podが落ちてると判断するか。デフォルト３、最低１
