だいごろうのブログ

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

[MEMO] katacodaでLearn Kubernetes ver8 Weave Scope

kubernetes katakoda memo エンジニア

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でつなぎましょうと。

つなぐとこんな感じ

f:id:daigorowhite:20190719084138p:plain
weave scope example

なにこれすごい。やばい、感動する。

ちょっと、もっと調べよう

Weave

Weave ScopeはWeaveWorksって会社のプロダクトのうちのひとつなのかな。

www.weave.works

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

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のクラスターを構築するっていう、用途特化のツール。ただ、初期構築には、かなり便利なんじゃないかなー。正直、ちょっと、ブラックボックス感があるから、好きではないが、こういう自動化はいいよね。

あとで、読まねば

www.weave.works

[MEMO] katacodaでLearn Kubernetes ver7 Kompose / Helm + Helm周りを調べてみた

MEMO kubernetes katakoda memo エンジニア

今回は、kubenetesのyamlの管理ツール系の話。KomposeとHelmを読んで見てる。

www.katacoda.com

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で実行できるようなものかな？結構ないろいろな会社とコミュニティが運営してるみたいで、今後の発展性も良さそうだな。

www.katacoda.com

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 Docs | Helm

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

katakoda kubernetes memo エンジニア

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

katakoda kubernetes memo エンジニア

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

MEMO katakoda kubernetes memo エンジニア

# 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が落ちてると判断するか。デフォルト３、最低１

[MEMO] katacodaでLearn Kubernetes ver3 ingress

katakoda kubernetes memo エンジニア

Create Ingress Routing

Create Ingress Routing | Kubernetes | Katacoda

Ingress - Kubernetes

Ingressとは

Ingressはkubernetes外部にHTTP/HTTPSのプロトコルアクセスを公開するためのものです。もし、それ以外を公開したければ、 Service.Type=NodePortかService.Type=LoadBalancerを使うことが多いです。

前提

Ingress controlerを作る必要があります。ingress-nginxが一番有名っぽい？かな。 複数持つことも可能。ただ、複数の種類を使うのは少し難しい。

Ingress Controllers - Kubernetes

Kind ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: index-ingress
spec:
  rules:
  - http:
      paths:
      - path: /indexpage
        backend:
          serviceName: index
          servicePort: 80
      - backend: # pathを指定しなければ、他全部あつかい
          serviceName: no-page
          servicePort: 80

[MEMO] katacodaでLearn Kubernetes ver2 Service / Networking

MEMO kubernetes エンジニア katakoda memo

Deploy Containers Using YAML

memo

apiVersion: extensions/v1beta1
kind: Deployment
kind: Service
spec:
  type: NodePort

kubectl create -f {file}
kubectl apply -f {file}

Service

  • kubernetes内部でお互いのpodsにselectorを使って、ポートを割り当てることができる。selectorを使わずに、Endpointsを使って、外部に対するアクセスを割り当てることができる。基本的には、kubenetesのpods通しでのアクセスをサポートするために使われる。

https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors

Type

読んだことメモ。

  • ClusterIP: クラスター内でアクセスできるIPを作る。デフォルト
  • NodePort: StaticPortを割り当てる。外部からもそのNodeのIPとPortを指定すればアクセスできる。 :.
  • LoadBalancer: クラウドプロバイダーのLBを使って外部に公開できる。（？）NodePortとClusterIPが自動で作られる
  • ExternalName: サービスを外部のドメインに紐付ける。

https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

Networking Introduction

f:id:daigorowhite:20190711081933p:plain

  • Cluster IP

ClusterIPは内部のPodに対して、内部からのアクセスをロードバランスするIP、ポートを用意すること

portだけをしているすると、podのポートとserviceのポート両方が同じポートになる。 targetPortを指定すると、podのポートはtargetPortが利用される。

 spec:
  ports:
  - port: 8080
    targetPort: 80
  • NodePort

ClusterIPとTargetPortは内部からのアクセスに対応した手法である。NodePortは外部からのアクセスを可能にするStaticIPを用意する。すべてのノードのPortを専有するかも？要検証。

spec:
  type: NodePort
  ports:
  - port: 80
    nodePort: 30080

同じポートを指定するNodePortを作ろうとしたが、エラー出たのでたぶん、全Nodeであってる。

master $ cat nodeport2.yaml  | grep nodePort -A2 -B2
  ports:
  - port: 80
    nodePort: 30080
  selector:
    app: webapp2-nodeport
master $ cat nodeport.yaml  | grep nodePort -A2 -B2
  ports:
  - port: 80
    nodePort: 30080
  selector:
    app: webapp1-nodeport
master $ kubectl create -f nodeport2.yaml
Error from server (Invalid): error when creating "nodeport2.yaml": Service "webapp2-nodeport-svc" is invalid: spec.ports[0].nodePort: Invalid value: 30080: provided port is already allocated
Error from server (AlreadyExists): error when creating "nodeport2.yaml": deployments.extensions "webapp2-nodeport-deployment" already exists
  • External IPs

指定のIPのポートを外部公開し、内部のPodにアクセスする。

spec:
  ports:
  - port: 80
  externalIPs:
  - {NODE_IP}
  • Load Balancer

GCPやAzure、AWSなどで外部のロードバランサーを通してLBSする機能。それがない場合でも、quay.io/munnerz/keepalived-cloud-provider:0.0.1このimageを使うことで、cloudproviderを内部に作成できるみたい。 https://github.com/munnerz/keepalived-cloud-provider

spec:
  type: LoadBalancer
  ports:
  - port: 80