본문 바로가기

CKA &. CKAD/Troubleshooting

Network Troubleshooting

[Network Plugin in kubernetes]

 

Kubernetes uses CNI plugins to setup network. The kubelet is responsible for executing plugins as we mention the following parameters in kubelet configuration.

 

Kubernetes는 CNI Plugin을 사용하여 네트워크를 설정한다. kubelet은 kubelet 구성에서 다음 매개 변수를 언급하므로 플러그인 실행을 담당한다.

 

- cni-bin-dir:  Kubelet은 기동 시 이 디렉토리에서 플러그인에 대해 조사한다. 

- network-plugin: cni-bin-dir에서 사용할 네트워크 플러그인이다. plugin 디렉토리에서 검색된 plugin과 이름이 일치해야 한다.

 

몇가지 가능한 Plugin 들에 대한 설치 내용들이다.

 

1. Weave Net

kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"


2. Flannel

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml

 

3. Calico

 

curl https://docs.projectcalico.org/manifests/calico.yaml -O
kubectl apply -f calico.yaml

 

CKA 및 CKAD 시험에서는 cni 플러그인을 설치하라는 메시지가 표시되지 않는다. 그러나 요청을 받으면 설치를 위한 정확한 URL이 제공된다. 그렇지 않은 경우 문서에서 weave net을 설치할 수 있다.

https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

[DNS in Kubernetes]

 

Kubernetes는 CoreDNS를 사용한다. CoreDNS는 Kubernetes 클러스터 DNS 역할을 할 수 있는 유연하고 확장 가능한 DNS 서버이다.

 

ㅁ Memory and POD

 대규모 Kubernetes 클러스터에서 CoreDNS의 메모리 사용량은 주로 클러스터의 POD 및 Service 수의 영향을 받는다. 다른 요인으로는 DNS 응답 캐시의 크기와 CoreDNS 인스턴스 당 수신된 쿼리 속도(QPS)가 있다.

 

coreDNS용 Kubernetes 리소스는 다음과 같다.

 

1. coredns라는 service account

2. coredns 와 kube-dns라는 cluster-role

3. coredns 및 kube-dns라는 clusterrolebindings

4. coredns deployment

5. coredns라느느 configmap 및 kube-dns라는 서비스 이름.

 

coreDNS Deployment를 분석하는 동안 Corefile 플러그인이 configmap으로 정의된 중요한 configuration으로 구성으로 되어 있음을 알 수 있다.

 

Port 53 은 DNS resolution을 위해 사용된다.

kubernetes cluster.local in-addr.arpa ip6.arpa {
  pods insecure
  fallthrough in-addr.arpa ip6.arpa
  ttl 30
}

이것은 closter.local 및 reverse domain에 대한 k8s의 백엔드이다.

proxy . /etc/resolv.conf

Cluster Domain 외부에서 권한있는 DNS 서버로 직접 전달한다.

 

coreDNS와 관련된 Troubleshooting 가이드

 

1. pending 상태에 있는 CoreDNS pods를 찾으면 먼저 네트워크 플러그인이 설치되어 있는지 확인한다.

 

2. coredns pods에 CrashLoopBackOff 또는 오류 상태가 있는지 확인한다.

 

만약 이전 버전의 Docker와 함께 SELinux를 실행하는 노드가 있는 경우 coredns 포드가 시작되지 않는 시나리오가 발생할 수 있다. 이를 해결하려면 다음 옵션 중 하나를 시도해 본다.

 

 a) 최신 버전의 Docker로 업그레이드 한다.

 b) SELinux를 비활성한다.

 c) cordns 배포를 수정하여 allowPrivilegeEscalation을 true로 설정한다.

kubectl -n kube-system get deployment coredns -o yaml | \
  sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
  kubectl apply -f -

 

d) CoreDNS가 CrashLoopBackOff를 갖는 또 다른 원인은 Kubernetes에 배포된 CoreDNS Pod가 Loop를 감지하는 경우이다.

이 문제를 해결하는 방법에는 여러가지가 있으며 일부는 다음과 같다.

 

 - kubelet config yaml에 다음을 추가한다.

resolvConf: <path-to-your-real-resolv-conf-file>

  이 플래그는 kubelet에게 대체 resolv.conf를 Pod에 전달하도록 지시한다.

  systemd-resolved를 사용하는 시스템의 경우 배포 버전에 따라 다를 수 있지만 일반적으로 /run/systemd/resolv/resolv.conf는 실제   resolv.conf의 위치이다.

 

 - 호스트 Node에서 로컬 DNS Cache를 비활성화하고 /etc/resolv.conf를 원본으로 복원한다.

 

 - 빠른 수정 방법은 Corefile을 편집하여 forward . /etc/resolv.conf를 업스트림 DNS의 IP 주소(예: forward .8.8.8.8)로 바구는 것이다.       그러나 이렇게 하면 CoreDNS에 대한 문제만 해결된다. kubelet은 게속해서 모든 기본 dnsPolicy Pods에 잘못된 resolve.conf를
   전달하여 DNS를 확인할 수 없게 된다.

 

3. CoreDNS Pod 및 kube-dns 서비스가 제대로 동작하는 경우 kube-dns 서비스에 유효한 endpoint가 있는지 확인해라.

kubectl -n kube-system get ep kube-dns

service에 대한 endpoint가 없는 경우 service를 검사하고 올바른 selector와 port를 사용하는지 확인해라.


[Kube-Proxy]

 

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시이다. kube-proxy 노드에서 네트워크 규칙을 유지한다. 이러한 네트워크 규칙은 Cluster 내부 또는 외부의 네트워크 Session에서 Pod로의 네트워크 통신을 허용한다.

 

kubeadm으로 구성된 클러스터에서 kube-proxy를 Daemonset으로 찾을 수 있다.

 

kubeproxy는 각 service와 관련된 service 및 endpoint를 감시한다. 클라이언트가 가상 IP를 사용하여 서비스에 연결하려고 할 때 kubeproxy는 트래픽을 실제 Pod로 전송해야 한다.

 

kubectl describe ds kube-proxy -n kube-system

를 실행하면 kube-proxy 바이너리가 kube-proxy 컨테이너 내에서 다음 명령으로 실행되는 것을 볼 수 있다.

    Command:
      /usr/local/bin/kube-proxy
      --config=/var/lib/kube-proxy/config.conf
      --hostname-override=$(NODE_NAME)

따라서 구성 파일(예: /var/lib/kube-proxy/config.conf)에서 구성을 가져오며 포드가 실행중인 노드 이름으로 호스트 이름을 재정의할 수 있다.

 

config 파일에서 clusterCIDR, kubeproxy mode, ipvs, iptables, bindaddress, kube=config등을 정의한다.

 

kube-proxy와 관련된 Troubleshooting 가이드

 

1. kube-system namespace에서 kube-proxy 포드가 실행중인지 확인

2. kube-proxy 로그를 확인

3. configmap이 올바르게 정의되어 있고 kube-proxy 바이너리를 실행하기 위한 구성 파일이 올바른지 확인한다.

4. kube-config가 config map에 정의되어 있는지 확인한다.

5. kube-proxy가 컨테이너 내부에서 실행중인지 확인한다.

# netstat -plan | grep kube-proxy
tcp        0      0 0.0.0.0:30081           0.0.0.0:*               LISTEN      1/kube-proxy
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      1/kube-proxy
tcp        0      0 172.17.0.12:33706       172.17.0.12:6443        ESTABLISHED 1/kube-proxy
tcp6       0      0 :::10256                :::*                    LISTEN      1/kube-proxy

Reference

Debug Service issues:

https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/

 

Debug Services

An issue that comes up rather frequently for new installations of Kubernetes is that a Service is not working properly. You've run your Pods through a Deployment (or other workload controller) and created a Service, but you get no response when you try to

kubernetes.io

DNS Troubleshooting:

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

 

Debugging DNS Resolution

This page provides hints on diagnosing DNS problems. Before you begin You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by

kubernetes.io

 

'CKA &. CKAD > Troubleshooting' 카테고리의 다른 글

kubelet 주요 이슈 확인  (0) 2021.04.08
Practice Test - Node Failure (kubelet)  (0) 2021.04.01
Worker Node Failure  (0) 2021.04.01
Control Plane Failure  (0) 2021.04.01
Application Failure  (0) 2021.04.01