kubeflow 설치 시 cert-manager 에러 (1) 에서 cert-manager-webhook 에러를 해결하는 방법으로 webhook 설정을 제거하는 방법을 사용했다.
하지만, 이후 istio를 설치할때도 같은 에러가 발생했고 모든 경우에 webhook 설정을 삭제할 수 없어서 근본적인 문제를 해결하려고한다.
분석
$ kustomize build common/cert-manager/kubeflow-issuer/base | kubectl apply -f -
Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded위 에러를 검색했을때, cert-manager 문제 혹은 flannel 문제라는 포스팅들이 대부분이었다. 처음에는 flannel 설정이 잘못되었나 의심해 여러버전을 사용해보고, helm 으로 배포도 해봤지만 해결되지 않았다.
클러스터 재생성도 해보고, 다른 물리적인 서버로 교체도 해봤으나 역시 해결되지 않았다.
위 에러를 보면 https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s로 웹훅요청이 가는데, 정상적으로 처리되지 않았다는것을 확인할 수 있다. cert-manager-webhook.cert-manager.svc 라는 도메인은 어디서 나온건지 의문이들었다. docker의 경우 같은 네트워크에 배포된 서비스의 이름을 도메인이름으로 사용하듯이 k8s도 pod, service를 namespace와 함께 도메인이름으로 사용할 수 있다는것을 확인했다.
Service Name: cert-manager-webhook
Namespace: cert-manager
Service: svc
하지만 위 내용만으로는 dns 문제인지 다른 네트워크 문제인지 정확하게 파악할 수 없다. cert-manager-webhook 이 호출될 때 kube-apiserver 의 로그를 확인해봤다.
I0108 10:39:24.428382 1 trace.go:205] Trace[246648600]: "Call mutating webhook" configuration:cert-manager-webhook,webhook:webhook.cert-manager.io,resource:cert-manager.io/v1alpha2, Resource=clusterissuers,subresource:,operation:CREATE,UID:e86c6841-20b0-4ac8-b72d-7cb8f576bf2f (08-Jan-2024 10:39:14.427) (total time: 10000ms):
Trace[246648600]: [10.000903021s] [10.000903021s] END
W0108 10:39:24.428520 1 dispatcher.go:182] Failed calling webhook, failing closed webhook.cert-manager.io: failed calling webhook "webhook.cert-manager.io": Post "https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s": context deadline exceeded
I0108 10:39:24.429122 1 trace.go:205] Trace[523796375]: "Create" url:/apis/cert-manager.io/v1alpha2/clusterissuers,user-agent:kubectl/v1.21.7 (linux/amd64) kubernetes/1f86634,client:192.168.1.166,accept:application/json,protocol:HTTP/2.0 (08-Jan-2024 10:39:14.426) (total time: 10002ms):
Trace[523796375]: [10.002318073s] [10.002318073s] END
E0108 10:39:30.256761 1 status.go:71] apiserver received an error that is not an metav1.Status: &url.Error{Op:"Get", URL:"https://192.168.1.203:10250/containerLogs/cert-manager/cert-manager-webhook-6b57b9b886-lvthj/cert-manager?tailLines=500×tamps=true", Err:(*net.OpError)(0xc006172be0)}: Get "https://192.168.1.203:10250/containerLogs/cert-manager/cert-manager-webhook-6b57b9b886-lvthj/cert-manager?tailLines=500×tamps=true": dial tcp 192.168.1.203:10250: i/o timeout
I0108 10:39:30.257129 1 trace.go:205] Trace[966194241]: "Get" url:/api/v1/namespaces/cert-manager/pods/cert-manager-webhook-6b57b9b886-lvthj/log,user-agent:node-fetch,client:127.0.0.1,accept:*/*,protocol:HTTP/2.0 (08-Jan-2024 10:39:00.253) (total time: 30003ms):
Trace[966194241]: ---"Transformed response object" 30001ms (10:39:30.257)
Trace[966194241]: [30.003125442s] [30.003125442s] END
E0108 10:39:35.913588 1 status.go:71] apiserver received an error that is not an metav1.Status: &url.Error{Op:"Get", URL:"https://192.168.1.203:10250/containerLogs/cert-manager/cert-manager-webhook-6b57b9b886-lvthj/cert-manager?tailLines=500×tamps=true", Err:(*net.OpError)(0xc006108280)}: Get "https://192.168.1.203:10250/containerLogs/cert-manager/cert-manager-webhook-6b57b9b886-lvthj/cert-manager?tailLines=500×tamps=true": dial tcp 192.168.1.203:10250: i/o timeout
I0108 10:39:35.914083 1 trace.go:205] Trace[258081290]: "Get" url:/api/v1/namespaces/cert-manager/pods/cert-manager-webhook-6b57b9b886-lvthj/log,user-agent:node-fetch,client:127.0.0.1,accept:*/*,protocol:HTTP/2.0 (08-Jan-2024 10:39:05.910) (total time: 30003ms):
Trace[258081290]: ---"Transformed response object" 30001ms (10:39:35.914)
Trace[258081290]: [30.003396549s] [30.003396549s] END로그를 보면 dial tcp 192.168.1.203:10250: i/o timeout 라는 에러를 확인할 수 있다. 즉, flannel을 통해 다른노드의 pod으로 라우팅을 시도했다는것을 확인할 수 있다. (정상적으로 라우팅된지는 알 수 없음)
dns 문제인가 싶어 coredns 로깅 설정 후 재시작한다.
.:53 {
log # <-- 여기 log 추가
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}그리고 로그를 확인하기 위해 coredns pod 에 접속하려 했는데, 마스터 노드의 pod에는 접근이 되는데 워커 노드의 pod에는 접근되지 않았다. 뭐지? 각 노드에서 다른 노드의 coredns pod에 ping을 날려봤는데 요청이 가지 않았다. 같은 노드의 pod으로는 요청이 정상적으로 간다.
다시 flannel 문제를 의심했는데, 앞서 할 수 있는 모든 시도를 해봤기 때문에 flannel 문제는 더이상 아닐거라 가정하고 혹시나 방화벽 문제인가싶어 클러스터 삭제, iptable 초기화 후 다시 설정했으나 해결되지 않았다.
즉, cni에서 해주는 설정외에 건든게 없는데 해결되지 않은 상황이다.
여기서 정말 많은 시간을 날렸는데... 문제는 ufw 설정이었다. 워커 노드에서 기본적으로 ufw가 활성화 되어있었고 요청이 제대로 라우팅되지 않은것이다.
해결
$ sudo ufw disable
Firewall stopped and disabled on system startup
$ ping 10.244.0.5
PING 10.244.0.5 (10.244.0.5) 56(84) bytes of data.
64 bytes from 10.244.0.5: icmp_seq=1 ttl=63 time=0.669 ms
64 bytes from 10.244.0.5: icmp_seq=2 ttl=63 time=0.742 ms
64 bytes from 10.244.0.5: icmp_seq=3 ttl=63 time=0.615 ms
64 bytes from 10.244.0.5: icmp_seq=4 ttl=63 time=0.613 ms
^C
--- 10.244.0.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3066ms
rtt min/avg/max/mdev = 0.613/0.659/0.742/0.052 ms
$ ping 10.244.1.9
PING 10.244.1.9 (10.244.1.9) 56(84) bytes of data.
64 bytes from 10.244.1.9: icmp_seq=1 ttl=64 time=0.069 ms
64 bytes from 10.244.1.9: icmp_seq=2 ttl=64 time=0.035 ms
64 bytes from 10.244.1.9: icmp_seq=3 ttl=64 time=0.069 ms
64 bytes from 10.244.1.9: icmp_seq=4 ttl=64 time=0.044 ms
^C
--- 10.244.1.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3055ms
rtt min/avg/max/mdev = 0.035/0.054/0.069/0.015 msiptable 설정과 별개로 ufw이 활성화되어있어 요청이 제대로 라우팅되지 않은것이다.
$ kustomize build common/cert-manager/kubeflow-issuer/base | kubectl apply -f -
clusterissuer.cert-manager.io/kubeflow-self-signing-issuer created이제 정상적으로 배포된다.
앞서 방화벽문제 역시 고려해 iptable과 ufw를 수동으로 이것저것 설정던게 문제였다. 당연히 방화벽문제는 아니겠거니 생각했는데 앞서 테스트할때는 설정이 잘못되었던 것이고, 이후 k8s 클러스터를 초기화할때는 ufw 설정을 초기화하지 않아 이런 문제가 발생했다.
