해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.
⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.
Network Plugin in Kubernetes
쿠버네티스는 CNI 플러그인을 사용하여 네트워크를 설정합니다. kubelet은 플러그인을 실행할 책임이 있습니다.
- cni-bin-dir: kubelet은 시작 시 이 디렉터리에서 플러그인을 검색합니다.
- network-plugin: cni-bin-dir에서 사용할 네트워크 플러그인. 플러그인 디렉토리에서 프로브된 플러그인이 보고한 이름과 일치해야 합니다.
사용 가능한 플러그인은 여러 가지가 있으며 아래는 몇 가지 플러그인입니다.
1. Weave Net:
To install,
kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml
네트워크 플러그인에 대한 자세한 내용은 다음 문서에서 확인할 수 있습니다. :
https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy
2. Flannel :
To install,
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml
참고: 현재 flannel은 쿠버네티스 네트워크 정책을 지원하지 않습니다.
3. Calico :
To install,
curl https://docs.projectcalico.org/manifests/calico.yaml -O
Apply the manifest using the following command.
kubectl apply -f calico.yaml
Calico is said to have most advanced cni network plugin.
CKA 및 CKAD 시험에서는 CNI 플러그인을 설치하라는 메시지가 표시되지 않습니다. 그러나 만약 요청을 받으면 설치할 수 있는 정확한 URL을 제공받게 됩니다.
참고: 디렉터리에 여러 개의 CNI 구성 파일이 있는 경우, kubelet은 사전순으로 이름 앞에 오는 configuration 파일을 사용합니다.
DNS in Kubernetes
Kubernetes는 CoreDNS를 사용합니다. CoreDNS 는 유연하고 확장 가능한 DNS 서버로, Kubernetes 클러스터 DNS 역할을 할 수 있습니다.
Memory and Pods
대규모 쿠버네티스 클러스터에서, 코어DNS의 메모리 사용량은 주로 클러스터의 파드 및 서비스 수에 의해 영향을 받습니다. 다른 요인으로는 filled DNS 응답 캐시의 크기와 CoreDNS 인스턴스당 쿼리 수신 속도(QPS)가 있습니다.
Kubernetes resources for coreDNS are:
- a service account named coredns,
- cluster-roles named coredns and kube-dns
- clusterrolebindings named coredns and kube-dns,
- a deployment named coredns,
- a configmap named coredns and a
- service named kube-dns.
coreDNS 배포를 분석하는 동안 코어파일 플러그인이 configmap으로 정의된 중요한 구성으로 구성되어 있음을 알 수 있습니다.
Port 53 is used for for DNS resolution.
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
이것은 cluster.local 및 역방향 도메인에 대한 k8s의 백엔드입니다.
proxy . /etc/resolv.conf
클러스터 도메인에서 권한이 있는 올바른 DNS 서버로 직접 포워딩합니다.
Troubleshooting issues related to coreDNS
1. If you find CoreDNS pods in pending state first check network plugin is installed.
2. coredns pods have CrashLoopBackOff or Error state
If you have nodes that are running SELinux with an older version of Docker you might experience a scenario where the coredns pods are not starting. To solve that you can try one of the following options:
a)Upgrade to a newer version of Docker.
b)Disable SELinux.
c)Modify the coredns deployment to set allowPrivilegeEscalation to true:
1. pending인 상태의 CoreDNS 파드를 발견하면 먼저 네트워크 플러그인이 설치되어 있는지 확인합니다.
2. 코어DNS 파드가 CrashLoopBackOff 또는 오류 상태입니다.
이전 버전의 Docker로 SELinux를 실행하는 노드가 있는 경우 coredns 파드가 시작되지 않는 시나리오가 발생할 수 있습니다. 이 문제를 해결하려면 다음 옵션 중 하나를 시도해 볼 수 있습니다:
a)최신 버전의 Docker로 업그레이드합니다.
b)SELinux를 비활성화합니다.
c)허용 권한 확장을 true로 설정하도록 coredns 배포를 수정합니다:
kubectl -n kube-system get deployment coredns -o yaml | \
sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | \
kubectl apply -f -
d) 쿠버네티스에 배포된 CoreDNS 파드가 루프를 감지할 때 CoreDNS에 크래시루프백오프가 발생하는 또 다른 원인이 있습니다.
이 문제를 해결하는 방법에는 여러 가지가 있으며, 그 중 일부는 아래와 같습니다:
- Add the following to your kubelet config yaml: resolvConf: <path-to-your-real-resolv-conf-file> This flag tells kubelet to pass an alternate resolv.conf to Pods. For systems using systemd-resolved, /run/systemd/resolve/resolv.conf is typically the location of the "real" resolv.conf, although this can be different depending on your distribution.
- Disable the local DNS cache on host nodes, and restore /etc/resolv.conf to the original.
- A quick fix is to edit your Corefile, replacing forward . /etc/resolv.conf with the IP address of your upstream DNS, for example forward . 8.8.8.8. But this only fixes the issue for CoreDNS, kubelet will continue to forward the invalid resolv.conf to all default dnsPolicy Pods, leaving them unable to resolve DNS.
3. CoreDNS 파드와 kube-dns 서비스가 정상적으로 작동한다면, kube-dns 서비스에 유효한 엔드포인트가 있는지 확인합니다.
kubectl -n kube-system get ep kube-dns
서비스에 대한 엔드포인트가 없는 경우, 서비스를 검사하고 올바른 셀렉터와 포트를 사용하는지 확인합니다.
Kube-Proxy
kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시이며, 노드에서 네트워크 규칙을 유지 관리합니다. 이러한 네트워크 규칙은 클러스터 내부 또는 외부의 네트워크 세션에서 파드로의 네트워크 통신을 허용합니다.
kubeadm으로 구성된 클러스터에서는 데몬셋으로 kube-proxy를 찾을 수 있습니다.
kubeproxy는 각 서비스와 관련된 서비스 및 엔드포인트를 감시합니다(watching). 클라이언트가 가상 IP를 사용하여 서비스에 연결하려고 할 때, 실제 파드로 트래픽을 전송하는 것은 kubeproxy가 담당합니다.
kubectl describe ds kube-proxy -n kube-system을 실행하면 kube-proxy 컨테이너 내부에서 다음 명령어로 kube-proxy 바이너리가 실행되는 것을 확인할 수 있습니다.
/usr/local/bin/kube-proxy
--config=/var/lib/kube-proxy/config.conf
--hostname-override=$(NODE_NAME)따라서 configuration 파일(예: /var/lib/kube-proxy/config.conf)에서 구성을 가져오고 호스트 이름을 파드가 실행 중인 노드 이름으로 override할 수 있습니다.
configuration파일에서 클러스터CIDR, kubeproxy 모드, ipvs, iptables, bindaddress, kube-config 등을 정의한다.
Troubleshooting issues related to kube-proxy
1. Check kube-proxy pod in the kube-system namespace is running.
2. Check kube-proxy logs.
3. Check configmap is correctly defined and the config file for running kube-proxy binary is correct.
4. kube-config is defined in the config map.
5. check kube-proxy is running inside the container
# 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-proxyReferences:
Debug Service issues:
https://kubernetes.io/docs/tasks/debug-application-cluster/debug-service/
DNS Troubleshooting:
https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/
'MLOps > Doker & Kubernetes' 카테고리의 다른 글
| Udemy CKA 강의 정리 268: Solution - Mock Exam -2 (optional) (1) | 2023.02.02 |
|---|---|
| Udemy CKA 강의 정리 267: Mock Exam -2 (0) | 2023.02.02 |
| Udemy CKA 강의 정리 254: Worker Node Failure (0) | 2023.02.01 |
| Udemy CKA 강의 정리 251: Control Plane Failure (0) | 2023.01.31 |
| Udemy CKA 강의 정리 248: Application Failure (0) | 2023.01.30 |
댓글