Kubernetes

kubectl kustomize     - kustomize ファイルからマニフェストを生成

https://stackoverflow.com/questions/47931771/is-there-a-way-to-make-a-kubernetes-service-name-set-as-prometheus-job-name-auto?rq=1

pod ∋ containers

service ∋ pods

1. サービスにはユニークな cluster-ip が割り当てられる。
   • サービスのライフスパン中は普遍

• 永続データの保存

実際のマシン(or vm)

[+] [-] 2.5.1. manifest

[+] [-] 2.5.2. controller

k8s パッケージマネージャ

https://github.com/kubernetes/minikube より

1. minikube

   $ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_1.3.1.deb && sudo dpkg -i minikube_1.3.1.deb

2. Hypervisor enable H/W?

   $ egrep -q 'vmx|svm' /proc/cpuinfo && echo yes || echo no

   yes と出たら ok
3. ここでは KVM で進める。 KVM タブを選択 > Ubuntu 16.04 を選択
   1. 64bit OS であることを確認

      $ uname -m

   2. KVM をインストール

      $ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

   3. libvirtd グループに追加

      $ sudo adduser `id -un` libvirtd

   4. lougout & login し、libvirtd グループに所属していることを確認:

      $ groups
      ... libvirtd ...

   5. インストールされたことを確認:

      $ virsh list --all
       Id    名前                         状態
      ----------------------------------------------------

      何も出なければ ok
   6. 動作確認

      $ virt-host-validate
      ...
      QEMU: 確認中 if IOMMU is enabled by kernel:
          警告 (IOMMU appears to be disabled in kernel. Add intel_iommu=on to kernel cmdline arguments)

      僕のPCでは ハード的には Hyper Threading Tech. は enabled になっている。 linux の boot option で対応する必要があった。/etc/default/grub:

      ...
      GRUB_CMDLINE_LINUX="... intel_iommu=on ..."

      なお、ググると「'on' よりも 'pt' が良い」と言う記述もあったけど、 僕の環境(Hard or OS)では pt では何も変わらなかった。 で、 on にして再度実行しても変わらないorz
   7. Driver install

      $ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2 \
          && sudo install docker-machine-driver-kvm2 /usr/local/bin/

   8. config

      $ minikube config set vm-driver kvm2

   9. start

      $ minikube start --vm-driver=kvm2

Kubectl の install

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
$ chmod +x ./kubectl 
$ sudo mv ./kubectl /usr/local/bin/

状態確認

$ kubectl version

$ kubectl cluster-info

$ kubectl get po -A

メモリ上限を 2G -> 4G (4G は今の環境ではやや重い? 3G 辺りが良いか？)

$ minikube config set memory 4096

ダッシュボード(ブラウザでダッシュボードが表示される)

$ minikube dashboard &

1. run

   $ kubectl run hello-minikube --image=k8s.gcr.io/echoserver:1.4 --port=8080

   echoserver なるイメージを 'hello-minikube' と名づけて実行。
   • dashboard を見ると、それらしい名前の pod が作成されている。
2. expose

   $ kubectl expose deployment hello-minikube --type=NodePort

   サービスを外部からアクセス可能とする。
3. access

   $ minikube service hello-minikube

start second local cluster(注! 激重)

$ minikube start -p cluster2

stop

$ minikube stop

delete

$ minikube delete

$ kubectl apply -f grafana-deployment.yaml
$ kubectl apply -f grafana-service.yaml

起動に少し時間がかかる模様(数分?)

$ minikube service --namespace=monitoring grafana

URL http://192.168.39.149:31688 にアクセスされる。

(或いは、後述の ingress 経由であれば https://[minikube-IP]/grafana でも ok。 ここで [minikube-IP] は minikube ip で知ることの出来る IP)。

[+] [-] 4.1.1. 設定

ノード(サーバ(オンプレ、vm問わず))からのデータ収集 フォーマットさえ合っていれば実装は何でも良い。

全 node (minikube の場合は 1 node)に node exporter をデプロイする:

$ kubectl apply -f node-exporter-daemonset.yml

spec.revisionHistoryLimit: 3 にして apply する。

$ kubectl -n monitoring get deployment,rs,pods

deployment - 変わらず

rs before

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.extensions/prometheus-59b8c86b6    1         1         1       38m
replicaset.extensions/prometheus-6bcbdd76d9   0         0         0       26h
replicaset.extensions/prometheus-b9c59df75    0         0         0       49m
replicaset.extensions/prometheus-d67d7ddd8    0         0         0       59m

after

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.extensions/prometheus-59b8c86b6    0         0         0       40m
replicaset.extensions/prometheus-6d4668b58b   1         1         1       114s
replicaset.extensions/prometheus-b9c59df75    0         0         0       51m
replicaset.extensions/prometheus-d67d7ddd8    0         0         0       61m

一番古い rs が消えている。

pods - 新しい rs で稼働している

grafana にアクセスする際、

$ minikube service -n monitoring grafana

URL は http://192.168.39.149:31688 とかなのだけど、この IP はどこから来るのだろうか？

ちなみに pod に入って IP を表示してみると

$ kubectl -n monitoring exec -it grafana-f7ff858d6-8p6rc bash
# ip a
...
eth0@if17:  mtu 1500 qdisc noqueue state UP group default 
  link/ether 02:42:ac:11:00:07 brd ff:ff:ff:ff:ff:ff
  inet 172.17.0.7/16 brd 172.17.255.255 scope global eth0

と全然別物。

minikube ホストマシンで ifconfig すると

virbr1    Link encap:イーサネット  ハードウェアアドレス fe:f4:e8:d6:55:a3  
          inetアドレス:192.168.39.1  ブロードキャスト:192.168.39.255  マスク:255.255.255.0
...

なので、 KVM で動作している仮想環境の模様。

$ kubectl -n monitoring get services
NAME         TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
grafana      NodePort   10.110.200.181           3000:31688/TCP   26h

なので、KVM -> service

詳細は下記

$ kubectl describe -n monitoring services/grafana
...
NodePort:                   31688/TCP

IP は minikube 自身の vm

$ minikube ip
192.168.39.149

なるほど、この IP にアクセスする、ということか。

https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/expose/expose-interactive/ が参考になる。"type: NodePort" とはそういうことらしい。

$ kubectl describe deployment -n monitoring

label を知る:

$ kubectl describe deployment -n monitoring
...
Labels:  name=grafana

label でアクセス:

$ kubectl get pods -n monitoring -l name=grafana
NAME                      READY   STATUS    RESTARTS   AGE
grafana-f7ff858d6-8p6rc   1/1     Running   3          41h

https://developers.freee.co.jp/entry/kubernetes-ingress-controller

NodePort LoadBalancer Ingress 比較記事

• https://medium.com/google-cloud/kubernetes-nodeport-vs-loadbalancer-vs-ingress-when-should-i-use-what-922f010849e0
  • 和訳記事 http://chidakiyo.hatenablog.com/entry/2018/09/10/Kubernetes_NodePort_vs_LoadBalancer_vs_Ingress%3F_When_should_I_use_what%3F_%28Kubernetes_NodePort_%E3%81%A8_LoadBalancer_%E3%81%A8_Ingress_%E3%81%AE%E3%81%A9%E3%82%8C%E3%82%92%E4%BD%BF%E3%81%86 から知った。

[+] [-] 5.4.1. Cluster IP

$ kubectl proxy

pods 一覧

$ kubectl get pods -n monitoring -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}'
...
grafana-f7ff858d6-8p6rc

API? proxy? 経由で accss

http://localhost:8001/api/v1/namespaces/monitoring/pods/grafana-f7ff858d6-8p6rc/proxy

注: これ の URL は正しくなさ気。

proxy 経由は debug 目的に限定とのこと。

ノードの IP/host名 に依存しているので production には向かない。

[+] [-] 5.7.1. Ingress

[+] [-] 6.1.1. 複数pod に対する kubectl logs

[+] [-] 6.1.2. 古いのはスキップして今から

$ kubectl desc nodes                                                    # all nodes
$ kubectl desc nodes ip-172-23-129-135.ap-northeast-1.compute.internal  # specific node

Configuration Best Practice によると、関連するグループで1つの yaml にまとめるのが良いとのこと:

Group related objects into a single file whenever it makes sense

pod 名を知り...:

$ kubectl get pods --all-namespaces
NAMESPACE     NAME                                    READY   STATUS    RESTARTS   AGE
default       hello-minikube-64c7df9db-h4d5q          1/1     Running   0          163m

bash を起動:

$ kubectl exec -it hello-minikube-64c7df9db-h4d5q bash

[+] [-] 6.5.1. minikube

[+] [-] 6.5.2. EKS

1. nginx-ingress の pod 名を名前空間を知り、変数 ingress_pod にセット

   $ kubectl get pods --all-namespaces
   ...
   kube-system   nginx-ingress-controller-5d9cf9c69f-bqv8w   1/1     Running   5          3d
   $ ingress_pod='-n kube-system nginx-ingress-controller-5d9cf9c69f-bqv8w'

2. kubectl exec でファイルにアクセス

   $ kubectl exec $ingress_pod cat /etc/nginx/nginx.conf

3. ingress のバージョンを知る

   $ kubectl logs $ingress_pod | lv
   -------------------------------------------------------------------------------
   NGINX Ingress controller
     Release:    0.25.0
     Build:      git-1387f7b7e
     Repository: https://github.com/kubernetes/ingress-nginx
   -------------------------------------------------------------------------------
   ...

• 'monitoring' 名前空間内の prometheus-core deployment を再起動
  1. 名前を確認

     $  kubectl get deploy -n monitoring
     NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
     ...
     prometheus-core      1/1     1            1           7d20h

  2. 再起動!

     $ kubectl scale deployment prometheus-core --replicas=0 -n monitoring
     $ kubectl scale deployment prometheus-core --replicas=1 -n monitoring

[+] [-] 6.8.1. Import & Export