Kubernetes Engine 문제 해결
본 문서는 Kubernetes Engine 서비스와 관련된 주요 문제와 해결 방법을 정리한 문서입니다.
kubectl: Namespace is forbidden
kubectl 제어 설정을 모두 완료했지만, kubectl 명령어를 사용하면 다음의 에러가 발생합니다.
Error from server (Forbidden): namespaces is forbidden: User "<user_email@example.com>" cannot list resource "namespaces" in API group "" at the cluster scope
해당 에러는 사용자가 액세스 키를 발급할 때 선택한 프로젝트와 제어해야 할 클러스터의 프로젝트가 일치하지 않을 때 발생합니다.
▶️ 해결 방법: 액세스키 생성 시 프로젝트를 지정할 때 제어할 클러스터가 속한 프로젝트를 지정해야 합니다. 자세한 액세스 키 생성 방법은 액세스 키 발급을 참고하시기 바랍니다.
Kubelet: Nameserver limits exceeded
Kubernetes Engine 클러스터에서 노드 풀을 생성한 후, kublet log 부분에 다음의 에러가 발생합니다.
카카오클라우드의 Kubernetes Engine을 통해 생성된 노드는 Linux(Ubuntu) 기반으로 3개의 DNS nameserver 레코드까지 추가가 가능하며,
Kubernetes는 1개의 DNS nameserver 레코드를 사용해야 합니다.
이러한 제약 상황에서 만약 노드가 이미 3개의 네임서버를 사용하고 있다면, Nameserver limit exceeded
에러가 발생합니다.
Jul 15 16:42:22 {Node-name} kubelet[6020]: E0715 16:42:22.417041 6020 dns.go:153] "Nameserver limits exceeded" err="Nameserver limits were exceeded, some nameservers have been omitted, the applied nameserver line is: ~ ~ ~"
▶️ 해결 방법: 노드 풀 생성 시 [고급 설정] > [사용자 스크립트] 등을 통해 네임서버를 resolv.conf
파일에 추가했는지 확인하고, nameserver 레코드 수를 조정합니다.
DNS 서버 레코드 제한에 대한 이슈는 쿠버네티스 공식 가이드를 참고해 주세요.
kubectl: Please enter Username
kubectl 제어 설정을 모두 완료했지만 kubectl 명령어를 사용하면 다음의 에러가 발생합니다.
Please enter Username:
이 에러는 kubeconfig 파일의 내용 중 contexts > context > cluster > user
에 설정된 클러스터의 이름과 users > name
에 설정된 이름과 싱크가 맞지 않아 발생합니다.
▶️ 해결 방법: contexts > context > cluster > user
에 설정된 클러스터의 이름과 users > name
에 설정된 이름을 동일하게 설정합니다.
kubectl: Unable to connect to the server
kubectl 제어 설정을 모두 완료했지만, kubectl 명령어를 사용하면 다음의 에러가 발생합니다.
Unable to connect to the server: getting credentials: exec: executable kic-iam-auth failed with exit code 1
사용자 인증은 kubeconfig 파일의 users > user > exec > env
에 설정된 액세스 키의 정보를 활용합니다. 위 에러는 이 액세스 키의 정보가 일치하지 않아 발생합니다.
▶️ 해결 방법: 사용자 인증 설정을 참고하여 사용자 인증을 재설정합니다.
CSI Provisioner deployment, pod
cinder-csi 설치 완료 후 파드 상태가 CrashLoopBackOff
로 표시되며, 다음의 에러가 발생합니다.
E0123 07:54:11.985138 1 openstack.go:102] Failed to open OpenStack configuration file: open /etc/kubernetes/cloud.conf: no such file or directory
E0123 07:54:11.985145 1 openstack.go:144] GetConfigFromFiles [/etc/kubernetes/cloud.conf] failed with error: open /etc/kubernetes/cloud.conf: no such file or directory
이 에러는 helm chart 설치 시 필요한 파라미터를 추가하지 않아 발생합니다.
▶️ 해결 방법: helm install cinder-csi 설치 진행 시 필수 파라미터 입력 후 재설치합니다.
$ helm install cinder-csi cpo/openstack-cinder-csi \
--version 2.3.0 \
--set secret.enabled=true \ #필수 파라미터
--set secret.name=cloud-config \ #필수 파라미터
--namespace kube-system
helm: kubernetes cluster unreachable
helm 설치하여 CLI를 통해 명령어 실행 시 Kubernetes cluster unreachable 에러가 발생합니다.
Kubernetes cluster unreachable: Get "http://localhost:8080/version": dial tcp [::1]:8080: connect: connection refused
helm은 쿠버네티스 클러스터와 연결에 필요한 정보를 등록해야 하지만 클러스터 정보를 가지고 있는 kubeconfig를 찾지 못해 에러가 발생합니다.
▶️ 해결 방법: kubeconfig.yaml 파일을 $KUBECONFIG 변수로 등록하는 방법과 --kubeconfig
옵션을 사용하는 방법은 다음과 같습니다.
$KUBECONFIG
환경변수 등록export KUBECONFIG="{kubeconfig path}
--kubeconfig
옵션 사용$ helm --kubeconfig={Download_Path/kubeconfig.yaml} list
Istio: failed to call Webhook
이 에러는 Istio를 Kubernetes Engine으로 구성 시, 마스터와 워커 노드 간 네트워크 통신이 되지 않을 때 발생합니다.
Error creating: Internal error occurred: failed calling webhook "namespace.sidecar-injector.istio.io": failed to call webhook: Post "https://istiod.istio-system.svc:443/inject?timeout=10s": context deadline exceeded
Master 노드들은 컨테이너 네트워크에 포함되어 있지 않기 때문에 https://instiod/validate(validation webhook)
와 통신이 불가하여 에러 발생합니다.
▶️ 해결 방법: hostNetwork: true
설정을 istiod
에 추가하여 노드 간 직접 통신이 가능하도록 설정합니다.
또한 hostNetwork: true
를 사용하는 경우 dnsPolicy: ClusterFirstWithHostNet
으로 명시적으로 설정해야 합니다.
$ kubectl edit deployment -n istio-system istiod
***
spec:
hostNetwork: true # 추가
dnsPolicy: ClusterFirstWithHostNet
containers:
***
dnsPolicy 설정 정보
dnsPolicy: Default
노드의 '/etc/resolv.conf' 파일에 있는 설정을 사용하여 DNS 쿼리를 처리합니다.dnsPolicy: ClusterFirst
클러스터 도메인 접미사(예:'.cluster.local')와 일치하지 않는 모든 DNS 쿼리는 DNS 서버에 의해 상위 네임 서버로 전달됩니다.dnsPolicy: ClusterFirstWithHostNet
hostNetwork: true
를 사용하는 pod의 경우dnsPolicy: ClusterFirstWithHostNet
으로 명시적으로 설정해야 합니다.
만약hostNetwork: true
를 사용하는 pod가dnsPolicy: ClusterFirst
정책을 사용하면 실제로는dnsPolicy: Default
정책의 동작으로 전환됩니다. 즉, 호스트 네트워크 모드로 실행되는 Pod가 클러스터 DNS 설정을 유지하기 위한 설정입니다.dnsPolicy: None
이 정책은 Pod가 Kubernetes 환경에서의 DNS 설정을 무시하도록 허용합니다.
사용자 정의 DNS 서버 사용이 필요한 Pod에 사용합니다.
- 자세한 사항은 (Kubernetes Documentation)에서 확인하시기 바랍니다.