「Kubernetes」の記事 - Crieit

DockerとKubernetes

2022-05-04T05:16:16+09:00

0 前提

Oracle LinuxとWindows

1 環境構築

準備

1-1 Dockerオフラインインストール

参考にしたURLはhttps://qiita.com/kod314/items/e574ac12c23598e0d903。
オンラインインストールの場合は、
https://qiita.com/kichise/items/f8e56c6d2d08eaf4a6a0
の手順に従えば可能。

今回はオフラインインストールを実行しようと思う。社内規則によりDockerをインストールするサーバがインターネット接続できない場合がある。その場合、インターネット接続できる自席端末からネットに接続してDockerのインストーラーをダウンロード。それをDockerをインストールしたいサーバに転送して実行させる。

1-1-1 OS確認

まずはOSのversionを確認。

$ uname -a
Linux publicpc1 5.4.17-2136.305.5.3.el8uek.x86_64 #2 SMP Thu Mar 17 10:45:33 PDT 2022 x86_64 x86_64 x86_64 GNU/Linux

より詳細

#cat /etc/os-release
NAME="Oracle Linux Server"
VERSION="8.5"
ID="ol"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="8.5"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Oracle Linux Server 8.5"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:oracle:linux:8:5:server"
HOME_URL="https://linux.oracle.com/"
BUG_REPORT_URL="https://bugzilla.oracle.com/"
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.5
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.5

Linuxカーネルの確認

$ hostnamectl
Static hostname: publicpc1
Icon name: computer-vm
Chassis: vm
Machine ID: 4c3dc5bfa43b47b8b66789ce778a0711
Boot ID: 226a196eedc746e2848a6f15e9afeb0b
Virtualization: kvm
Operating System: Oracle Linux Server 8.5
CPE OS Name: cpe:/o:oracle:linux:8:5:server
Kernel: Linux 5.4.17-2136.305.5.3.el8uek.x86_64
Architecture: x86-64

x86_64と記載されているので、Intel(AMD)の64bitオペレーティングシステムであることがわかる。

1-1-2 Docker engineをインストール

Docker本体であるDocker Engineと、同時に複数のコンテナを操作するツールであるDocker Composeをダウンロードする。
参考にした公式：https://docs.docker.com/engine/install/binaries/

まずはdocker本体
https://download.docker.com/linux/static/stable/x86_64/
→バージョンがいろいろあるので、最新のdocker-20.10.9.tgz をダウンロードしてみた。
自分の端末(クライアント側にダウンロードしたファイルをLinuxサーバに転送してから解凍する。

$ ls -al /home/opc/docker-20.10.9.tgz
-rw-r--r--. 1 opc opc 63350495 May  4 04:23 /home/opc/docker-20.10.9.tgz

展開

$ tar zxvf docker-20.10.9.tgz

すると、カレントディレクトリにdockerディレクトリが作成される。
dockerディレクトリの中身を/usr/bin/配下にコピーする。

$ sudo cp docker/* /usr/bin/

試しに起動するには

$ sudo dockerd &

1-1-3 Docker Composeをインストール

続いてはdocker-compose
インストール手順は以下に記載されているので以降この指示に従う。
https://github.com/docker/compose/blob/v2/README.md

さきほど(1-1-1節)でOSとCPUを確認したので、
それに従ってdocker-compose-linux-x86_64をダウンロードする。
https://github.com/docker/compose/releases

自分のwindows端末(クライアント側）にダウンロードしたdocker-compose-linux-x86_64をdockerをインストールしたLinuxサーバに転送。
転送したら、バイナリファイルの名前をdocker-composeにリネーム。

$ mv docker-compose-linux-x86_64 docker-compose

docker-composeをいどうする。移動する先は目的に応じて移動先が異なる。
今回は

$ sudo mv docker-compose /usr/local/bin/
$ sudo chmod +x /usr/local/bin/docker-compose
$ docker-compose -v
Docker Compose version v2.5.0

1-1-4 Docker イメージのオフラインで利用する

$ tar zxvf helloworld_img.tar.gz
$ docker load < helloworld_img # dockerイメージをload
$ docker images # hello-worldイメージが存在することを確認

1-1-5 Dockerグループ作成

Docker daemonはrootユーザで実行しなければならず、毎回sudoを使うのは面倒である。
その場合、dockerグループを作成してそこに任意のユーザを所属させてあげる。

groupadd docker
usermod -aG docker opc

1-1-6 トラブルシュート

docklerをサービスでenebleにしようと思ったができなかった。

[root@publicpc1 system]# systemctl enable docker
Failed to enable unit: Unit file docker.service does not exist.

以下のサイトを参考に対応してみた。
https://jhooq.com/docker-daemon-centos/

/usr/lib/systemd/system配下にdocker.socketファイルを作成し以下の内容を記載した。

[Unit]
Description=Docker Socket for the API

[Socket]
ListenStream=/var/run/docker.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

続いて、/usr/lib/systemd/system/配下にdocker.serviceを作成する。

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network-online.target docker.socket firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket containerd.service

[Service]
Type=notify
#the default is not to use systemd for cgroups because the delegate issues still
#exists and systemd currently does not support the cgroup feature set required
#for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

#Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
#Both the old, and new location are accepted by systemd 229 and up, so using the old location
#to make them work for either version of systemd.
StartLimitBurst=3

#Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
#Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
#this option work for either version of systemd.
StartLimitInterval=60s

#Having non-zero Limit*s causes performance problems due to accounting overhead
#in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

#Comment TasksMax if your systemd version does not support it.
#Only systemd 226 and above support this option.
TasksMax=infinity

#set delegate yes so that systemd does not reset the cgroups of docker containers
Delegate=yes

#kill only the docker process, not all processes in the cgroup
KillMode=process
OOMScoreAdjust=-500

[Install]
WantedBy=multi-user.target

この中身をみるとRequires=docker.socket containerd.serviceと記載されている通り、containerd.serviceが必要。なので/usr/lib/systemd/system配下にcontainerd.serviceサービスを作成する必要がある。

#Copyright The containerd Authors.
#Licensed under the Apache License, Version 2.0 (the "License");
#you may not use this file except in compliance with the License.
#You may obtain a copy of the License at
#http://www.apache.org/licenses/LICENSE-2.0
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an "AS IS" BASIS,
#WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
#See the License for the specific language governing permissions and
#limitations under the License.

[Unit]
Description=containerd container runtime
Documentation=https://containerd.io
After=network.target local-fs.target

[Service]
ExecStartPre=-/sbin/modprobe overlay
ExecStart=/usr/bin/containerd

Type=notify
Delegate=yes
KillMode=process
Restart=always
RestartSec=5
#Having non-zero Limit*s causes performance problems due to accounting overhead
#in the kernel. We recommend using cgroups to do container-local accounting.
LimitNPROC=infinity
LimitCORE=infinity
LimitNOFILE=infinity
#Comment TasksMax if your systemd version does not supports it.
#Only systemd 226 and above support this version.
TasksMax=infinity
OOMScoreAdjust=-999

[Install]
WantedBy=multi-user.target

上記を作成する。

ちゃんとリロードしとく。

systemctl daemon-reload

1-2.Kubernetesの準備

1-2-1. インストール

オフライン環境でKubernetesを構築する手順。
手順の参考にしたのは以下
https://docs.genesys.com/Documentation/GCXI/latest/Dep/DockerOffline

まずはネットにつながる端末から

$ pwd
/etc/yum.repos.d
$ cat kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

以下のコマンドを実行してファイルをダウンロード。
の部分は自分で適当なディレクトリを作成して
そこのパスを指定。

yumdownloader --assumeyes --destdir= --resolve yum-utils kubeadm-1.21.* kubelet-1.21.* kubectl-1.21.* ebtables

続いて、ダウンロードしたファイルをインストールしていく。

yum install -y --cacheonly --disablerepo=* /*.rpm

インストールする際、バージョンが異なるファイルが存在してインストールエラーになるかもしれない。
その場合は、必要のないバージョンのファイルは削除してから
再度インストールするとうまくいく。
うまくいくと以下のようになる。

Complete!

必要なイメージが揃っているか確認してみよう。

$ kubeadm config images list
I0504 23:15:36.977910  309762 version.go:254] remote version is much newer: v1.24.0; falling back to: stable-1.21
k8s.gcr.io/kube-apiserver:v1.21.12
k8s.gcr.io/kube-controller-manager:v1.21.12
k8s.gcr.io/kube-scheduler:v1.21.12
k8s.gcr.io/kube-proxy:v1.21.12
k8s.gcr.io/pause:3.4.1
k8s.gcr.io/etcd:3.4.13-0
k8s.gcr.io/coredns/coredns:v1.8.0

1-2-2. kubectlの概要

参考URL:https://kubernetes.io/ja/docs/reference/kubectl/_print/
Kubernetesクラスタを操作するコマンド

2.Docker入門

GKE を upgrade したら network plugin が死んだので対応した作業記録

2020-10-14T22:58:44+09:00

Qrunch から引っ越し

※ GKE のネガキャンではありません。むしろ好きでちゃんと運用したいからこそ残しているものです。

軽い気持ちで GKE を 1.11.2-gke.18 から 1.11.3-gke.18 に upgrade した。

そして何気なく Deployment を作ったが Pod が起動しない。
kubectl describe pod で見るとおかしな event が記録されているのが分かった。

Events:
  Type     Reason                  Age               From                                            Message
  ----     ------                  ----              ----                                            -------
  Normal   Scheduled               3m                default-scheduler                               Successfully assigned xyz/hoge-5b4db95bf5-krmjc to gke-gke01-preemptible01-e5cc132c-77fz
  Warning  FailedCreatePodSandBox  3m                kubelet, gke-gke01-preemptible01-e5cc132c-77fz  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "af7579fb0a4ad73cfaeb083ef47de36b7f84aed7f160685384354ed0d8512339" network for pod "hoge-5b4db95bf5-krmjc": NetworkPlugin cni failed to set up pod "hoge-5b4db95bf5-krmjc_xyz" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/
  Warning  FailedCreatePodSandBox  3m                kubelet, gke-gke01-preemptible01-e5cc132c-77fz  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "56c9b914c9f3c940c8d5479807820814e43f6716a263ca5c9a1bf53cef6ae252" network for pod "hoge-5b4db95bf5-krmjc": NetworkPlugin cni failed to set up pod "hoge-5b4db95bf5-krmjc_xyz" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/
  Warning  FailedCreatePodSandBox  3m                kubelet, gke-gke01-preemptible01-e5cc132c-77fz  Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "10bdc42cc20617283e18f67a4e4d171eecb4182dd0e9f7114465c4047e5f3c12" network for pod "hoge-5b4db95bf5-krmjc": NetworkPlugin cni failed to set up pod "hoge-5b4db95bf5-krmjc_xyz" network: stat /var/lib/calico/nodename: no such file or directory: check that the calico/node container is running and has mounted /var/lib/calico/

このクラスタは NetworkPolicy を有効にしているため、Calico が動作している。
kube-system namespace の Pod を見てみると、何やらひどいことが起きているようだ。

$ kubectl -n kube-system get pod | grep -E '^NAME|calico'
NAME                                                  READY     STATUS             RESTARTS   AGE
calico-node-974fs                                     1/2       CrashLoopBackOff   9          24m
calico-node-fx464                                     1/2       CrashLoopBackOff   9          24m
calico-node-kzhsr                                     1/2       CrashLoopBackOff   9          24m
calico-node-q4ktd                                     1/2       CrashLoopBackOff   9          24m
calico-node-qwqsx                                     1/2       CrashLoopBackOff   9          24m
calico-node-vertical-autoscaler-547d98499d-l7rd2      1/1       Running            0          6h
calico-typha-5977794b76-dmxjr                         0/1       CrashLoopBackOff   9          24m
calico-typha-horizontal-autoscaler-5ff7f558cc-2ksbc   1/1       Running            0          19h
calico-typha-vertical-autoscaler-5d4bf57df5-hp8r6     1/1       Running            0          6h

network plugin が動作しなくなっているため、既存 Pod はまだ生き延びられるが、新規 Pod が起動しない状態になっているようだ。

calico-node の DaemonSet を YAML で出力して中身をみると、v2.6.11 だったはずの calico のイメージが v3.2.4 に上がっていた。
(バージョンを確認したのは、別件で GKE の問い合わせをしていて Calico のバージョンが変わりそうな気配を感じていたため)

別途 NetworkPolicy を有効にした新規クラスタを作成してみて、そちらでは問題無く動作することを確認。

問題が起きている方のクラスタで calico-node の Pod のログを見ると以下のようになっていた。

2018-12-05 05:16:41.622 [INFO][8] startup.go 252: Early log level set to info
2018-12-05 05:16:41.623 [INFO][8] startup.go 268: Using NODENAME environment for node name
2018-12-05 05:16:41.623 [INFO][8] startup.go 280: Determined node name: gke-gke00-preemptible01-df3d5d39-m2h6
2018-12-05 05:16:41.624 [INFO][8] startup.go 303: Checking datastore connection
2018-12-05 05:16:41.638 [INFO][8] startup.go 327: Datastore connection verified
2018-12-05 05:16:41.638 [INFO][8] startup.go 100: Datastore is ready
2018-12-05 05:16:41.651 [INFO][8] startup.go 1052: Running migration
2018-12-05 05:16:41.651 [INFO][8] migrate.go 866: Querying current v1 snapshot and converting to v3
2018-12-05 05:16:41.651 [INFO][8] migrate.go 875: handling FelixConfiguration (global) resource
2018-12-05 05:16:41.658 [INFO][8] migrate.go 875: handling ClusterInformation (global) resource
2018-12-05 05:16:41.658 [INFO][8] migrate.go 875: skipping FelixConfiguration (per-node) resources - not supported
2018-12-05 05:16:41.658 [INFO][8] migrate.go 875: handling BGPConfiguration (global) resource
2018-12-05 05:16:41.658 [INFO][8] migrate.go 600: Converting BGP config -> BGPConfiguration(default)
2018-12-05 05:16:41.677 [INFO][8] migrate.go 875: skipping Node resources - these do not need migrating
2018-12-05 05:16:41.677 [INFO][8] migrate.go 875: skipping BGPPeer (global) resources - these do not need migrating
2018-12-05 05:16:41.677 [INFO][8] migrate.go 875: handling BGPPeer (node) resources
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping HostEndpoint resources - not supported
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping IPPool resources - these do not need migrating
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping GlobalNetworkPolicy resources - these do not need migrating
2018-12-05 05:16:41.687 [INFO][8] migrate.go 875: skipping Profile resources - these do not need migrating
2018-12-05 05:16:41.688 [INFO][8] migrate.go 875: skipping WorkloadEndpoint resources - these do not need migrating
2018-12-05 05:16:41.688 [INFO][8] migrate.go 875: data converted successfully
2018-12-05 05:16:41.688 [INFO][8] migrate.go 866: Storing v3 data
2018-12-05 05:16:41.688 [INFO][8] migrate.go 875: Storing resources in v3 format
2018-12-05 05:16:41.752 [INFO][8] migrate.go 1151: Failed to create resource Key=BGPConfiguration(default) error=resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
2018-12-05 05:16:41.753 [ERROR][8] migrate.go 884: Unable to store the v3 resources
2018-12-05 05:16:41.753 [INFO][8] migrate.go 875: cause: resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
2018-12-05 05:16:41.753 [ERROR][8] startup.go 107: Unable to ensure datastore is migrated. error=Migration failed: error storing converted data: resource does not exist: BGPConfiguration(default) with error: the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
2018-12-05 05:16:41.753 [WARNING][8] startup.go 1066: Terminating

新規構築したクラスタの calico-node の Pod のログと見比べると migrate.go の行が存在しない。
2018-12-05 05:16:41.651 [INFO][8] startup.go 1052: Running migration という部分が鍵と思われる。

startup.go は projectcalico/node を見れば良さそうだが、
migrate.go は projectcalico/libcalico-go にあるようだ。
libcalico-go のバージョンはどれを使っているのか分からないが、ログから BGPConfiguration を作れていない様子がうかがえる。

Kubernetes における Calico は CustomResourceDefinition として設定を管理しているらしいので、crd の定義を調べる

$ kubectl get crd
NAME                                          AGE
backendconfigs.cloud.google.com               22h
clusterinformations.crd.projectcalico.org     22h
felixconfigurations.crd.projectcalico.org     22h
globalbgpconfigs.crd.projectcalico.org        22h
globalfelixconfigs.crd.projectcalico.org      22h
globalnetworkpolicies.crd.projectcalico.org   22h
globalnetworksets.crd.projectcalico.org       22h
hostendpoints.crd.projectcalico.org           22h
ippools.crd.projectcalico.org                 22h
networkpolicies.crd.projectcalico.org         22h
scalingpolicies.scalingpolicy.kope.io         22h

ログには
the server could not find the requested resource (post BGPConfigurations.crd.projectcalico.org)
と出ていて、実際に bgpconfigurations.crd.projectcalico.org は存在しない。

とりあえず手動で CRD を追加してみたい。
内容が分からないので適当にググると https://github.com/projectcalico/libcalico-go/blob/master/test/crds.yaml が見つかった。

元の CRD を残しておきつつ、この crds.yaml を適用してみる。

$ kubectl get crd -o yaml > crd-backup.yaml
$ curl -LO https://raw.githubusercontent.com/projectcalico/libcalico-go/master/test/crds.yaml
$ kubectl apply -f crds.yaml
customresourcedefinition.apiextensions.k8s.io "globalfelixconfigs.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "globalbgpconfigs.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "ippools.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "bgppeers.crd.projectcalico.org" created
customresourcedefinition.apiextensions.k8s.io "globalnetworkpolicies.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "hostendpoints.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "felixconfigurations.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "bgpconfigurations.crd.projectcalico.org" created
customresourcedefinition.apiextensions.k8s.io "clusterinformations.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "networkpolicies.crd.projectcalico.org" configured
customresourcedefinition.apiextensions.k8s.io "globalnetworksets.crd.projectcalico.org" configured

bgppeers.crd.projectcalico.org と bgpconfigurations.crd.projectcalico.org が新規作成されたようだ。
CRD が作られたので、CrashLoopBackOff になっていた calico-node や calico-typha の Pod を消して再作成させる。

$ kubectl -n kube-system get pod -l k8s-app=calico-node
$ kubectl -n kube-system delete pod -l k8s-app=calico-node
$ kubectl -n kube-system get pod -l k8s-app=calico-typha
$ kubectl -n kube-system delete pod -l k8s-app=calico-typha

これでしばらく放置しておくと、calico-node や calico-typha の Pod が起動し、他の Pod も起動するようになった。

migrate.go が成功した部分のログは以下のようなものだった。

2018-12-05 05:45:51.223 [INFO][8] startup.go 1052: Running migration
2018-12-05 05:45:51.223 [INFO][8] migrate.go 866: Querying current v1 snapshot and converting to v3
2018-12-05 05:45:51.223 [INFO][8] migrate.go 875: handling FelixConfiguration (global) resource
2018-12-05 05:45:51.232 [INFO][8] migrate.go 875: handling ClusterInformation (global) resource
2018-12-05 05:45:51.232 [INFO][8] migrate.go 875: skipping FelixConfiguration (per-node) resources - not supported
2018-12-05 05:45:51.232 [INFO][8] migrate.go 875: handling BGPConfiguration (global) resource
2018-12-05 05:45:51.232 [INFO][8] migrate.go 600: Converting BGP config -> BGPConfiguration(default)
2018-12-05 05:45:51.245 [INFO][8] migrate.go 875: skipping Node resources - these do not need migrating
2018-12-05 05:45:51.245 [INFO][8] migrate.go 875: skipping BGPPeer (global) resources - these do not need migrating
2018-12-05 05:45:51.245 [INFO][8] migrate.go 875: handling BGPPeer (node) resources
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping HostEndpoint resources - not supported
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping IPPool resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping GlobalNetworkPolicy resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping Profile resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: skipping WorkloadEndpoint resources - these do not need migrating
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: data converted successfully
2018-12-05 05:45:51.255 [INFO][8] migrate.go 866: Storing v3 data
2018-12-05 05:45:51.255 [INFO][8] migrate.go 875: Storing resources in v3 format
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: success: resources stored in v3 datastore
2018-12-05 05:45:51.324 [INFO][8] migrate.go 866: Migrating IPAM data
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: no data to migrate - not supported
2018-12-05 05:45:51.324 [INFO][8] migrate.go 866: Data migration from v1 to v3 successful
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: check the output for details of the migrated resources
2018-12-05 05:45:51.324 [INFO][8] migrate.go 875: continue by upgrading your calico/node versions to Calico v3.x
2018-12-05 05:45:51.324 [INFO][8] startup.go 1056: Migration successful

本来は GKE 側で修正されることではないかと思うが、どうなるのだろう。

後日確認・追記 (12/14)

GKE の Release Notes の Known Issues (抜粋):
> Users upgrading to GKE 1.11.3 on clusters that use Calico network policies may experience failures due to a problem recreating the BGPConfigurations.crd.projectcalico.org resource. This problem does not affect newly-created clusters. This is expected to be fixed in the coming weeks.
>
> To work around this problem, you can create the BGPConfigurations.crd.projectcalico.org resource manually:
Google の Issue Tracker: URGENT: after upgrading master nodes to 1.11.3 calico stopped working
Calico の Issue: #2324
Kubernetes の PullRequest: #71868, #71682
- release-1.11 ブランチへのマージ: #71918
- release-1.12 ブランチへのマージ: #71882
- release-1.13 ブランチへのマージ: #71883
- v1.13.1 のリリースで修正済み Changelog
  > Include CRD for BGPConfigurations, needed for calico 2.x to 3.x upgrade. (#71868, @satyasm)
- 他のバージョンも次リリースされた時に修正されているはず。GKE もどこかで修正されることだろう。

GKE の kube-proxy が drain されない理由

2020-10-14T22:57:52+09:00

Qrunch から引っ越し

kubectl drain した時、テストで作った ownerReference の無い Pod がいたために怒られた。
(これらの Pod は --force オプションで削除させることができる)

ふと kube-proxy のことを思い出し、気になって調べた。

GKE だと kube-proxy は /etc/kubernetes/manifests から起動されていて ownerReference は無いはずなのだが、どうやって drain を回避しているのだろうか。

ファイルの manifest から起動しているのでそもそも API server 経由で実際の Pod 削除はできないのだが、Pod の定義だけ (一時的に) 削除することはあり得るのでは？

pkg/kubectl/cmd/drain.go を読むと分かる。

RunDrain()
  deleteOrEvictPodsSimple()
    getPodsForDeletion()
    deleteOrEvictPods()

kubectl drain コマンドにはいくつかのフィルタ条件があり、それらが適用されて残った Pod が
deleteOrEvictPods() に渡される。

各フィルタは getPodsForDeletion() の中で適用される。

// getPodsForDeletion receives resource info for a node, and returns all the pods from the given node that we
// are planning on deleting. If there are any pods preventing us from deleting, we return that list in an error.
func (o *DrainOptions) getPodsForDeletion(nodeInfo *resource.Info) (pods []corev1.Pod, err error) {
    labelSelector, err := labels.Parse(o.PodSelector)
    if err != nil {
        return pods, err
    }

    podList, err := o.client.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{
        LabelSelector: labelSelector.String(),
        FieldSelector: fields.SelectorFromSet(fields.Set{"spec.nodeName": nodeInfo.Name}).String()})
    if err != nil {
        return pods, err
    }

    ws := podStatuses{}
    fs := podStatuses{}

    for _, pod := range podList.Items {
        podOk := true
        for _, filt := range []podFilter{o.daemonsetFilter, mirrorPodFilter, o.localStorageFilter, o.unreplicatedFilter} {
            filterOk, w, f := filt(pod)

            podOk = podOk && filterOk

-l, --selector='' は drain 対象の Node をフィルタするもので、Pod に作用するものではない。
--pod-selector='' で drain で処理する Pod をフィルタする。
例えば、特定のラベルを持つ Pod を evict/delete 対象から外すには --pod-selector='key!=value' をつける
--ignore-daemonsets は DaemonSet から作成された Pod を除外する。(daemonsetFilter)
--delete-local-data は emptyDir ボリュームを持つ Pod を除外する。(localStorageFilter)

ownerRefernece の有無は unreplicatedFilter で判定されるが、kube-proxy が除外されるのは mirrorPodFilter だった。

func mirrorPodFilter(pod corev1.Pod) (bool, *warning, *fatal) {
    if _, found := pod.ObjectMeta.Annotations[corev1.MirrorPodAnnotationKey]; found {
        return false, nil, nil
    }
    return true, nil, nil
}

annotation の定義は pkg/apis/core/annotation_key_constants.go を参照する。

    // MirrorAnnotationKey represents the annotation key set by kubelets when creating mirror pods
    MirrorPodAnnotationKey string = "kubernetes.io/config.mirror"

kubernetes.io/config.mirror という annotation を持っているかどうかでフィルタされているようだ。

Mirror Pod って何だ？と思ってググると

Statis Pod が API server 側で見えるようになっているもの (見えるだけで API から制御できないもの) のことを指すらしい。

Static Pod は kubelet が API server ではなくファイルや HTTP 経由で渡された manifest を元に作成・起動した Pod のこと => Static Pods

調べてから見つけたが、詳しく説明している記事があった => Draining Kubernetes nodes

minikubeを使ってみよう【その2】

2019-06-22T23:35:52+09:00

レプリカの数を増やしてみよう

レプリカとは

アプリケーションコンテナのクローンです。
レプリカを2に設定すると、同じアプリケーションコンテナが2つ起動します。
以下のような用途があります。

コンテナの起動に失敗した場合
- 残りのコンテナでサービスを継続する
アプリケーションのアップデート中にサービスを中断したくない場合
- 更新途中のコンテナ以外でサービスを継続する

レプリカの数を増やす

運用で言う所の系の数ですね。

# hello-minikubeというコンテナを4つに増やす
$ kubectl scale deployments/hello-minikube --replicas=4

# 結果を確認する
$ kubectl get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-minikube   4         4         4            4           23h

# podの中身を確認する
$ kubectl get pods -o wide
NAME                              READY     STATUS    RESTARTS   AGE       IP           NODE
hello-minikube-78c9fc5f89-68jtm   1/1       Running   0          14m       172.17.0.7   minikube
hello-minikube-78c9fc5f89-6gsm8   1/1       Running   0          14m       172.17.0.8   minikube
hello-minikube-78c9fc5f89-nwgvw   1/1       Running   1          23h       172.17.0.4   minikube
hello-minikube-78c9fc5f89-x7m9g   1/1       Running   1          23h       172.17.0.2   minikube

アプリケーションをアップデートする

hello-minikubeというdockerイメージを使っていたpod内のアプリケーションをjocatalin/kubernetes-bootcampというイメージに置き換えてみます。

$ kubectl set image deployments/hello-minikube hello-minikube=jocatalin/kubernetes-bootcamp:v2

# podの状況を取得する
$ kubectl get pods -o wide
NAME                              READY     STATUS              RESTARTS   AGE       IP           NODE
hello-minikube-5dbc4c9877-c57t4   0/1       ContainerCreating   0          8s               minikube
hello-minikube-5dbc4c9877-v78sv   0/1       ContainerCreating   0          8s               minikube
hello-minikube-78c9fc5f89-68jtm   1/1       Running             0          21m       172.17.0.7   minikube
hello-minikube-78c9fc5f89-nwgvw   1/1       Running             1          23h       172.17.0.4   minikube
hello-minikube-78c9fc5f89-x7m9g   1/1       Running             1          23h       172.17.0.2   minikube

更新作業中はいくつかコンテナを残した状態で順番に更新されていきます。

アプリケーションのロールバック

rollout undoコマンドで元に戻します。

$ kubectl rollout undo deployments/hello-minikube
deployment.apps "hello-minikube" 

# podの状況を確認する
$ kubectl get pods
NAME                              READY     STATUS              RESTARTS   AGE
hello-minikube-5dbc4c9877-7zsqq   1/1       Terminating         0          6m
hello-minikube-5dbc4c9877-c57t4   1/1       Running             0          6m
hello-minikube-5dbc4c9877-jspcm   1/1       Terminating         0          6m
hello-minikube-5dbc4c9877-v78sv   1/1       Terminating         0          6m
hello-minikube-78c9fc5f89-5rfzt   0/1       ContainerCreating   0          2s
hello-minikube-78c9fc5f89-cf2lk   1/1       Running             0          4s
hello-minikube-78c9fc5f89-jrprp   1/1       Running             0          4s
hello-minikube-78c9fc5f89-k7pq4   0/1       ContainerCreating   0          1s

並行してロールバックが行われているのがわかります。

参考リンク

[第4回]Kubernetesの公式チュートリアルをやって基本を押さえる -アプリのアップデート

minikubeを使ってみよう【その1】

2019-06-22T00:21:08+09:00

kubernetesって？

dockerなどを使ってコンテナ化したアプリケーションの管理を行うOSSのオーケストレーションツール。

kubernetesのアイコン、何に見えますか？

船の舵だと思った方、正解です。
dockerは多数のコンテナを積んだ貨物船、kubernetesは装舵手です。

minikubeって？

公式
開発・テスト向けのKubernetes環境を構築するツール。

macにminikubeをインストール

前提

virtualboxがインストールされていること。

brewでインストール

$ brew cask install minikube

minikubeの起動

$ minikube start

minikube v1.1.1 on darwin (amd64)
💿  Downloading Minikube ISO ...
 131.29 MB / 131.29 MB [============================================] 100.00% 0s
🔥  Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...
🐳  Configuring environment for Kubernetes v1.14.3 on Docker 18.09.6
💾  Downloading kubelet v1.14.3
💾  Downloading kubeadm v1.14.3
🚜  Pulling images ...
🚀  Launching Kubernetes ... 
⌛  Verifying: apiserver proxy etcd scheduler controller dns
🏄  Done! kubectl is now configured to use "minikube"

minikubeイメージのダウンロードとvirtual box VMのcreateが始まるので多少時間がかかります。

コンテナ起動

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

k8s.gcr.io/echoserver:1.4のイメージを使って8080ポートでhello-minikubeというコンテナを起動する。

podの状態確認

$ kubectl get pod
NAME                              READY     STATUS    RESTARTS   AGE
hello-minikube-78c9fc5f89-x7m9g   1/1       Running   0          1m

deploymentの状態確認

$ kubectl get deployment
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
hello-minikube   1         1         1            1           1m

コンテナを外部に公開

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

hello-minikubeというコンテナをNodePortを使って外部に公開します。

サービスの削除・deploymentの削除

$ kubectl delete service hello-node
$ kubectl delete deployment hello-node

minikubeの仮想マシン(VM)を停止:

$ minikube stop

minikubeのVMを削除

$ minikube delete

(番外編)minikubeのdashboardを見る

$ minikube dashboard