Problem running k0s with Traefik on arch-linux/wsl-2

All about k0s
#1

I’m using k0s versionv1.27.1+k0s.0 and following

Running k0s with Traefik - k0s Documentation (k0sproject.io)

on my k0s cluster which is running on arch linux/wsl-2

After setting up k0s.yaml and restarting my cluster the Traefik pod starts but not the metallb load balancer. What’s the best way to debug why. Are there log files generated when processing the config file how can I access these log files?

I’m still seeing an issue with config validation and updated “k0s config validate” does not use the config flag · Issue #2791 · k0sproject/k0s (github.com)

#2

As it’s the controller that processes the Helm extensions you should have some logs in the controller logs. Assumin you’re running on systemd based setup, you can access the logs via journalctl -u k0scontroller.

The controller also creates Chart objects in the API so you can also look at the status of those: kubectl get chart -A.

If the metallb chart is not creating any resources my guess would be malformed values input.

#3

Looking at log file I see:

can’t locate chart bitnami/metallb-2.5.4: chart "metallb" matching 2.5.4 not found in bit

My k0s.yam config file has:

apiVersion: k0s.k0sproject.io/v1beta1
kind: ClusterConfig
metadata:
creationTimestamp: null
name: k0s
spec:
api:
address: 172.19.216.155
k0sApiPort: 9443
port: 6443
sans:
- 172.19.216.155
- 172.18.0.1
- 172.17.0.1
- 10.244.0.1
- fe80::215:5dff:febb:3b09
- fe80::42:faff:fe3a:ae45
- fe80::981b:60ff:fe1b:6ad2
- fe80::3454:14ff:fe3c:e027
- fe80::ccc3:23ff:fe9d:9e2d
tunneledNetworkingMode: false
controllerManager: {}
extensions:
helm:
concurrencyLevel: 5
repositories:
- name: traefik
url: Traefik Charts | charts
- name: bitnami
url: https://charts.bitnami.com/bitnami
charts:
- name: traefik
chartname: traefik/traefik
version: “10.3.2”
namespace: default
- name: metallb
chartname: bitnami/metallb
version: “2.5.4”
namespace: default
values: |2
configInline:
address-pools:
- name: generic-cluster-pool
protocol: layer2
addresses:
- 192.168.0.5-192.168.0.10
storage:
create_default_storage_class: false
# type: external_storage
type: openebs_local_storage
installConfig:
users:
etcdUser: etcd
kineUser: kube-apiserver
konnectivityUser: konnectivity-server
kubeAPIserverUser: kube-apiserver
kubeSchedulerUser: kube-scheduler
konnectivity:
adminPort: 8133
agentPort: 8132
network:
calico: null
clusterDomain: cluster.local
dualStack: {}
kubeProxy:
iptables:
minSyncPeriod: 0s
syncPeriod: 0s
ipvs:
minSyncPeriod: 0s
syncPeriod: 0s
tcpFinTimeout: 0s
tcpTimeout: 0s
udpTimeout: 0s
metricsBindAddress: 0.0.0.0:10249
mode: iptables
kuberouter:
autoMTU: true
hairpin: Enabled
ipMasq: false
metricsPort: 8080
mtu: 0
peerRouterASNs: “”
peerRouterIPs: “”
nodeLocalLoadBalancing:
envoyProxy:
apiServerBindPort: 7443
image:
image: Quay
version: v1.24.1
konnectivityServerBindPort: 7132
type: EnvoyProxy
podCIDR: 10.244.0.0/16
provider: kuberouter
serviceCIDR: 10.96.0.0/12
scheduler: {}
storage:
etcd:
externalCluster: null
peerAddress: 172.19.216.155
type: etcd
telemetry:
enabled: true
status: {}

kubectl get all shows:

> NAME                            READY   STATUS    RESTARTS       AGE
> pod/local-ai-59db6b9c94-742qt   1/1     Running   1 (155m ago)   46h
> pod/traefik-778f995998-hvn76    1/1     Running   0              100m
> 
> NAME                 TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
> service/kubernetes   ClusterIP      10.96.0.1        <none>        443/TCP                      11d
> service/local-ai     ClusterIP      10.105.91.246    <none>        80/TCP                       46h
> service/traefik      LoadBalancer   10.109.154.133   <pending>     80:31506/TCP,443:31345/TCP   100m
> 
> NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
> deployment.apps/local-ai   1/1     1            1           46h
> deployment.apps/traefik    1/1     1            1           100m
> 
> NAME                                  DESIRED   CURRENT   READY   AGE
> replicaset.apps/local-ai-59db6b9c94   1         1         1       46h
> replicaset.apps/traefik-778f995998    1         1         1       100m
> Any suggestions on how to fix
#4

That sounds like the Bitnami chart museum does not have that version available.

metallb 4.5.2 · bitnami/bitnami implies that it nowadays has only 3.x.y onwards versions available.

#5

Simplifying my deployment I;m seeing:

kubectl get svc

> NAME                      TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
> kubernetes                ClusterIP      10.96.0.1        <none>        443/TCP                      4d
> metallb-webhook-service   ClusterIP      10.108.105.169   <none>        443/TCP                      4d
> traefik                   LoadBalancer   10.107.145.228   <pending>     80:31234/TCP,443:31699/TCP   4d

What’s the best way to determine why the external IP is pending?

#6

I tried to reset and reinstall k0s

> 
> sudo k0s reset
> WARN[2023-06-12 09:56:40] To ensure a full reset, a node reboot is recommended.
> 
> <reboot>
> mwoodpatrick@westie_arch:~$ sudo k0s install
> Install k0s on a brand-new system. Must be run as root (or with sudo)
> sudo whoami
> root

Why does k0s think its not being run as root, or how do I debug this

#7

I’d look at metallb logs to see if there’s any hint why it’s not able to do it’s job.

#8

k0s install is NOT a command of itself, it has two subcommands: k0s install worker ... and k0s install controller .... So what you are seeing is the help text.

#9

I’m running on WSL-2 and log shows:

{“caller”:“service.go:135”,“error”:“no available IPs”,“level”:“error”,“msg”:“IP allocation failed”,“op”:“allocateIPs”,“ts”:“2023-06-13T10:09:08Z”}

Any suggestions?

BTW does the container that’s included with k0s use runc or crun? If the former is there a reason for that?