ベアメタルkubernetesへingress実装

GitLab実践ガイドのチュートリアルをベアメタルk8sでやろうとしたらうまくいかない。
Addressが割り当たっておらず、ingressの問題っぽかったので色々調べる。

$ kubectl describe ingress quarkus-app -n test
Name:             quarkus-app
Labels:           <none>
Namespace:        test
Address:
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host                     Path  Backends
  ----                     ----  --------
  quarkus-app.example.com
                           /   quarkus-app:8080 (10.0.4.94:8080)
Annotations:               <none>
Events:                    <none>

あごし

この記事ではingress controllerがないことが原因と書いてある。

いつまでたっても EXTERNAL-IP が <pending> のままでロードバランサーが作られることはありません。というのも Kubernetes の中でロードバランサーを作成し、Service の EXTERNAL-IP をロードバランサーの IP アドレスに設定する、という処理を担当する controller が動いていないからです。（いないから。

確かにServiceのEXTERNAL-IPは記事と同じく、pending状態になっている。だけどpendingになっているのはingress-controllerのはず。type:LoadBalancerにはcontrollerが必要、controller自体がtype:LoadBalancerなのでうまく動かない？？？混乱中。

$ kubectl get svc -n u6s-infra
NAME                                 TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx-controller             LoadBalancer   10.104.211.36    <pending>     80:32222/TCP,443:31628/TCP   3d16h
ingress-nginx-controller-admission   ClusterIP      10.106.84.219    <none>        443/TCP                      3d16h

あごし

k8sのロードバランサと言えばmetallb。metallbを入れる必要があるのか？

あごし

metalLBはL4、ingressはL7。両方必要なわけではない気がする。ingressだけで頑張れば良いか？

あごし

ingress使うにはmetalLB(L4)が前提っぽい。

あごし

ここに書いてありました。ingressはL4整備済みが前提。

また、Ingress-Nginx Controllerは Type: Loadbalancer を指定した Service を作ることができる
k8sでなければ上手く動作しません。今回は、MetalLBを採用している環境を想定しています。

あごし

ingress使うためにまずはmetalLBを入れようとしたけど、自前のk8sはkube-vipでcontrol planeをクラスタリングしている。kube-vipとmetalLBは同時に使ってはいけないとの記事が。

https://qiita.com/YasuhiroABE/items/004f7c6413168dfd0792

https://zenn.dev/bitcat/articles/8116d951f2e6e0
もしどうしてもMetalLBなどを別で使いたいのであれば、競合してしまうので、

servicesオプションを消すこと。
L4はkube-vipを使った方が良さそう。

あごし

kube-vip使ってるならingressうまく動いていたはずでは？という疑問があるが、デフォルトではアプリケーション用には使える様になってないみたい。

Tanzu Kubernetes Grid (TKG) 2.1 では、NSX Advanced Load Balancer (NSX ALB) が、推奨の LB 製品ではありますが、NSX ALB が無い場合には、Kubernetes クラスタのコントロールプレーン用の LB として、Kube-Vip が利用できます。
ただし、デフォルト設定では Kube-Vip は、コントロールプレーン (kube-apiserver) 用のみの LB として構成されるため、ユーザーワークロード、例えば、ユーザーが展開したアプリ用の Service (type=LoadBalancer) には利用できません。そのため、Kube-Vip の構成で、Management Cluster をデプロイした際には、ユーザーワークロード用の LB は、別途用意する必要があります。

あごし

kube-vipをloadalancerとして使っている方がいた。
公式ドキュメントとほぼ変わらないやり方だけど、日本語で書いていただけるだけで一気に解決した感がある。
英語が苦手すぎることに絶望。。。

あごし

そのまんまだけど、以下でinstall &セッティング。
kube-system上にインストールされるので、namespaceを気にする必要はない。

$ kubectl apply -f https://raw.githubusercontent.com/kube-vip/kube-vip-cloud-provider/main/manifest/kube-vip-cloud-controller.yaml

$ kubectl patch configmap kubevip -n kube-system -p '{"data":{"range-global": "192.168.1.210-192.168.1.230"}}'

あごし

ちなみに使ってないIPアドレスレンジを調べるためにこんなpowershellスクリプトを書いた。

param (
    [int]$arg1,
    [int]$arg2
)
$start = $arg1
$end   = $arg2

$allFailed = $true
for ($i = $start; $i -lt $end + 1; $i++) {
    $pingResult = Test-Connection -ComputerName 192.168.1.$i -Count 1 -Quiet
    if ($pingResult) {
        $allFailed = $false
        Write-Output "192.168.1.$i is used."
    }
}

if ($allFailed) {
    Write-Output "IP addresses is nobody used from $start to $end."
} else {
    Write-Output "IP addresses is used from $start から $end."
}

あごし

GitLab実践ガイドのチュートリアルをリトライしたところAdderssにIPアドレスが採番された。やったー。

$kubectl describe ingress quarkus-app -n test
Name:             quarkus-app
Labels:           <none>
Namespace:        test
Address:          192.168.1.210
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host                     Path  Backends
  ----                     ----  --------
  quarkus-app.example.com  
                           /   quarkus-app:8080 (10.0.4.94:8080)
Annotations:               <none>

あごし

チュートリアルではAddress: <ELB Front Domain>となっているので、EKSでやるとFQDNが表示されるんだろうな。ベアメタル環境でFQDNにするにはExternal DNSの設定が必要になると思われる。
そのうちチャレンジしたいと思う。