本番環境用にmanifestファイルを作成する

mktkhr commented 4 months ago

目的

kubernetes移行に伴い，docker compose から manifestファイルに移行する
- 将来的にhelmに移行したいが，一旦通常のmanifestを作成する

期待結果

nginx(frontend)，java(backend)のmanifestファイルが作成されていること
- postgres，redisはクラスター外に配置するため，manifestは不要で，docker composeのままとする

mktkhr commented 4 months ago

DBについて

本来クラスター外に出しておきたいが，クラスター内のpodからコントロールプレーンのホスト上の特定のportにアクセスする手段が分からないため，一旦persistent volumeとしてクラスター内にDBを構築する方針で進める
control-planeにのみデプロイするため，control-planeのTaints設定を解除する
- kubectl taint nodes kube-controlplane-01 node-role.kubernetes.io/control-plane:NoSchedule-
postgresはamd64のcontrol planeに配置するため，imageをbuildする際は，docker build --platform linux/amd64 で指定する or Dockerfile側で指定しないと pod が crashloop するので注意

mktkhr commented 4 months ago

Backendについて

DBはamd64でimageをビルドしたが，backendはラズパイのnodeに配置するので，arm64でビルドする必要がある
- --platform=linux/arm64
DockerfileでARGをそのままCMDで使用すると，コンテナ起動時には存在しないので起動に失敗する
[SpringBoot起動時にロゴが表示された後，それ以降の起動処理が進まない
- WARN以上のみ出力するように設定していたため

mktkhr commented 4 months ago

Frontend(nginx) について

[調査中]metallb + ingress(LoadBalanceer) + nginx(service[clusterIP] + deployment) の構成でdeploy後数分で接続できなくなる

speakerのログ

{"caller":"node_controller.go:46","controller":"NodeReconciler","level":"info","start reconcile":"/ems-raspberrypi-4b","ts":"2024-05-12T01:17:39Z"}
{"caller":"node_controller.go:69","controller":"NodeReconciler","end reconcile":"/ems-raspberrypi-4b","level":"info","ts":"2024-05-12T01:17:39Z"}

一時的な改善案

nginxとnginx-serviceを再デプロイ or metallbのiptableの再デプロイなど
- ただし，これらを行なっても数分でルーティングされなくなる

正常にルーティングできている場合のspeakerのログ

{"caller":"service_controller.go:64","controller":"ServiceReconciler","level":"info","start reconcile":"default/nginx-service","ts":"2024-05-12T01:29:17Z"}
{"caller":"service_controller.go:115","controller":"ServiceReconciler","end reconcile":"default/nginx-service","level":"info","ts":"2024-05-12T01:29:17Z"}

NodePortでnginxのserviceを立て，nodeのIPでアクセスする分には継続してアクセスできる

LoadBalancerのIPが 192.168.0.170 となっていることを確認

$ kubectl get svc nginx-service                                             
NAME            TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
nginx-service   LoadBalancer   10.104.172.214   192.168.0.170   80:32705/TCP,443:32602/TCP   20m

期待値としては 192.168.0.170 にアクセスすれば，nginx-service 経由で 継続的に nginx のコンテナにルーティングされること実際は 1分から1分30秒程度でルーティングされないようになる

途中からルーティングできなくなる様子(途中からunreachableになる)

mktkhr commented 3 months ago

calicoをflannelに変えてみる calicoの削除 kubectl delete -f custom-resources.yaml kubectl delete -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.3/manifests/tigera-operator.yaml 上記で一部消えない，削除が完了しないものがあったので，手動で削除 kubectl get all --all-namespaces | grep calico

calico-system          pod/calico-typha-fbf9df98f-49mv4                   1/1     Running     0               19d
calico-system          pod/calico-typha-fbf9df98f-phb4g                   1/1     Running     0               19d
calico-system          service/calico-typha                         ClusterIP      10.104.178.224   <none>          5473/TCP                     19d
calico-system          deployment.apps/calico-typha                2/2     2            2           19d
calico-system          replicaset.apps/calico-typha-fbf9df98f                 2         2         2       19d

上記コマンドで出てきたリソースを強制削除しようとするか消えないので，クラスターをリセットするリセットすると，coreDNSが起動しなくなった

NICがめちゃくちゃになっており，同居しているシステムに影響が出るため，EKSに移行する

mktkhr / stamp-iot