kubernetes-fqa

롤링 업데이트

Kubernetes에서 롤링 업데이트를 적용할 때, 오래된 파드를 종료하기 전에 새 파드를 먼저 시작합니다. 이 접근 방식은 업데이트 과정 중에 다운타임이 없도록 보장합니다. Kubernetes는 새 인스턴스로 파드 인스턴스를 점진적으로 업데이트하며, 새 파드는 오래된 파드가 여전히 실행 중인 동안 충분한 리소스를 갖춘 노드에 스케줄됩니다. 이 전략은 부드러운 전환을 가능하게 하며, 애플리케이션이 요청을 처리할 수 있도록 유지합니다. 새 파드가 준비되어 트래픽을 처리할 준비가 되면, 이후 오래된 파드는 우아하게 종료됩니다.

“Recreate” 정책

Kubernetes에서 "Recreate" 업데이트 전략은 새로운 파드를 생성하기 전에 모든 오래된 파드를 종료하는 배포 전략입니다. Recreate 전략을 사용하여 업데이트를 배포할 때, 새 버전이 배포되기 전에 애플리케이션의 모든 인스턴스가 중지되기 때문에 애플리케이션은 다운타임을 경험하게 됩니다. 이 전략은 여러 버전이 동시에 실행되는 것을 처리할 수 없는 상태를 유지하는(stateful) 애플리케이션에 유용하거나, 애플리케이션의 두 버전이 동시에 실행되지 않도록 하고 싶을 때 사용할 수 있습니다. 그 단순성에도 불구하고, 배포 과정 중 다운타임이 발생하는 단점이 있어, 높은 가용성을 요구하는 애플리케이션에는 덜 이상적입니다.

우아한 종료

Kubernetes에서 파드를 우아하게 종료하면서 업데이트할 때, 과정은 보통 파드가 "종료 중"으로 표시되면서 시작됩니다. 이 단계 동안 Kubernetes는 내부 엔드포인트 목록을 업데이트하여, 서비스가 트래픽을 전달하는 활성 엔드포인트 목록에서 종료 중인 파드를 제거합니다. 이는 서비스가 종료 중인 파드로 새 요청을 보내지 않을 것임을 의미합니다. 그러나 파드는 종료 유예 기간이 만료될 때까지 기존 연결이나 요청을 계속 처리합니다.

Kubernetes 서비스는 각 노드에서 실행되는 kube-proxy에 의존하여, 서비스의 현재 활성 엔드포인트 목록을 기반으로 파드 IP 주소로 트래픽을 라우팅하기 위한 iptables 규칙이나 IPVS를 관리합니다. 파드가 종료로 표시되면, 그 엔드포인트는 서비스에서 제거되고 kube-proxy는 그에 따라 iptables 또는 IPVS 규칙을 업데이트합니다. 이는 새로운 연결이 종료 중인 파드로 가는 것을 방지하지만, 기존 연결이 유예 기간 내에 완료될 수 있도록 합니다.

이러한 접근 방식은 파드가 진행 중인 요청을 처리를 마칠 수 있도록 하면서 새로운 요청은 받지 않게 함으로써, 업데이트나 파드 교체 동안 서비스의 중단을 최소화하면서 파드의 우아한 종료를 보장합니다.

Pod가 공유하는 네임스페이스

IPC, Network, UTS

그외

  • Cgroup

  • Mount

  • PID

  • Syslog

  • Time

  • User

Pause 컨테이너와 보는 방법

sudo ctr --namespace k8s.io containers ls

Kubernetes에서 "pause" 컨테이너는 파드의 "인프라" 컨테이너로 작용하여, 파드의 네트워크 및 프로세스 네임스페이스의 앵커 역할을 합니다. 그 주요 역할로는:

  1. 네트워크 네임스페이스를 유지: 파드 내의 컨테이너가 중지되고 시작될 때도 네트워크 설정(예: IP 주소)이 유지되도록 합니다.

  2. 파드의 PID 1로서 역할: 모든 파드 내의 컨테이너의 부모가 되며, 이는 신호 처리와 프로세스 회수에 중요할 수 있습니다.

전통적으로, 모든 Kubernetes 파드는 다른 컨테이너가 시작되기 전에 이러한 네임스페이스를 설정하고 유지하기 위해 pause 컨테이너로 시작됩니다. 이 메커니즘은 pause 컨테이너에 의해 생성된 네트워크 및 프로세스 네임스페이스를 파드 내의 다른 컨테이너가 공유할 수 있게 합니다.

그러나 모든 Kubernetes 설정이나 시나리오에서 파드를 실행하기 위해 항상 pause 컨테이너가 필요한 것은 아닙니다. Kubernetes 아키텍처와 컨테이너 런타임 구현은 네임스페이스 처리 및 pause 컨테이너의 필요성에 영향을 줄 수 있습니다. 예를 들어, 특정 CRI(컨테이너 런타임 인터페이스) 구현 또는 특정 구성은 네임스페이스 공유를 다르게 처리할 수 있으며, 이는 pause 컨테이너에 대한 의존도를 줄일 수 있습니다.

대부분의 표준 Kubernetes 배포에서는 pause 컨테이너가 사용되는 컨테이너 런타임에 의해 자동으로 포함되고 관리되므로, 사용자가 수동으로 처리할 필요가 없습니다.

UTS 네임스페이스

Linux UTS(UNIX Time-Sharing) 네임스페이스의 이름은 시간과의 연결을 암시하는 것처럼 보이지만, 역사적으로 그 기능은 시간 공유나 시간 관리와 직접적으로 관련이 없습니다. "UNIX Time-Sharing System"이라는 이름은 여러 사용자 간의 시간 공유를 위해 설계된 초기 컴퓨팅 개념과 UNIX 시스템의 개발에서 유래합니다.

Linux의 UTS 네임스페이스는 실제로 시스템 식별자 - 구체적으로, 호스트 이름과 NIS 도메인 이름의 시스템을 격리하는 역할을 합니다. 새로운 UTS 네임스페이스가 생성될 때, 그 네임스페이스 내의 프로세스가 네임스페이스 외부의 것들과 다른 호스트 이름과 NIS 도메인 이름을 보고 수정할 수 있게 하여, 전역 시스템 설정에 영향을 주지 않습니다. 이러한 격리는 Docker와 Kubernetes와 같은 컨테이너 환경에서 특히 유용하며, 각 컨테이너나 파드마다 별도의 식별자를 가짐으로써 충돌을 방지하고 그들 사이의 격리 수준을 보장하는 것이 필요합니다.

UTS 네임스페이스가 시간 공유나 시간 관리와 관련 없음에도 불구하고 호스트 이름과 도메인 이름 관리를 포함하는 이유는 기능적인 면보다는 역사적이고 용어적인 측면에서 더 큽니다.

‘Containerd’와 ‘RunC’

**containerd**와 **runc**는 컨테이너 기술의 생태계에서 밀접하게 관련되어 있으며 계층적인 관계를 가집니다. 이들의 상호작용은 다음과 같습니다:

  1. runc: 가벼우며 이동성이 뛰어난 컨테이너 런타임으로, OCI (Open Container Initiative) 사양에 따라 컨테이너를 실행합니다. **runc**는 컨테이너의 실제 생성 및 실행을 담당합니다. 컨테이너의 생명주기(생성, 시작, 정지, 삭제)를 관리하는 하위 수준 작업을 수행합니다. **runc**는 컨테이너를 관리하기 위해 독립적으로 사용될 수 있지만 이미지 관리와 같은 고급 기능은 제공하지 않습니다.

  2. containerd: runc 위에 구축된 고급 컨테이너 런타임입니다. **containerd**는 컨테이너의 전체 생명주기를 관리하는 데 필요한 추가 기능을 제공합니다. 이미지 전송 및 저장, 컨테이너 실행 및 감독, 네트워크 및 저장소 설정 등의 기능을 처리합니다. **containerd**는 OCI 표준에 따른 컨테이너 실행의 하위 수준 세부 사항을 관리하기 위해 **runc**와 상호작용합니다.

본질적으로, **containerd**는 실행 계층으로 **runc**를 사용하여 컨테이너 실행의 구체적인 사항을 처리하면서, 이미지, 저장소, 네트워크 설정 관리와 같은 기능을 추가합니다. 이러한 관계는 **runc**가 컨테이너 실행에 있어 최고가 되는 데 집중하는 동시에, **containerd**가 생산 환경에서 컨테이너를 관리하기 위해 필요한 기능을 확장하는 모듈식 접근 방식을 가능하게 합니다.

워커노드로 윈도우 서버 사용

Yes, it is possible to use Windows Server as a worker node in a Kubernetes cluster. Kubernetes supports Windows worker nodes alongside Linux master nodes, allowing for a mixed-node environment where some workloads run on Windows and others on Linux.

There are a few key points to keep in mind when integrating Windows Server as a worker node in Kubernetes:

  1. Container Orchestration: Windows Server containers can be orchestrated by Kubernetes, enabling the deployment, scaling, and management of Windows-based applications.

  2. Version Compatibility: Ensure that the version of Windows Server you're using is compatible with your Kubernetes cluster version. Kubernetes documentation provides specific guidance on supported versions and configurations.

  3. Networking: Networking for Windows containers might require specific configurations due to differences in networking between Linux and Windows. Kubernetes supports several network plugins that work with Windows.

  4. Workload Separation: While you can have a mixed environment with both Linux and Windows nodes, you must specify the appropriate node selector in your pod specifications to ensure that Windows containers run on Windows nodes and Linux containers run on Linux nodes.

  5. Limitations and Considerations: There are certain features and functionalities of Kubernetes that are limited or differently implemented on Windows, including some aspects of networking, storage, and security. It's important to review these limitations to ensure that they won't impact your specific use case.

Integrating Windows Server as a worker node into a Kubernetes cluster allows for greater flexibility in deploying a wide range of applications, making it a powerful option for environments that require running both Windows and Linux-based applications.

Windows 노드에서의 Kubernetes 네트워킹은 iptables에 대한 기본 지원이 없기 때문에 Linux와 다르게 작동합니다. iptables 대신 Windows 서버는 HNS(Host Networking Service)와 VFP(Virtual Filtering Platform)의 조합을 사용하여 컨테이너의 네트워킹을 관리합니다. 다음은 Linux iptables의 대안으로 Windows 서버에서 Kubernetes 네트워킹, 예를 들어 서비스가 어떻게 지원되는지에 대한 설명입니다:

  1. 오버레이 네트워킹: Windows 노드는 일반적으로 오버레이 네트워크를 사용하여 Kubernetes 네트워킹을 활성화합니다. 오버레이 네트워크는 다른 노드의 컨테이너가 마치 같은 물리적 네트워크에 있는 것처럼 서로 통신할 수 있게 합니다. Kubernetes는 이러한 통신을 관리하기 위해 Windows에서 VXLAN과 네트워크 정책을 사용합니다.

  2. Windows에서의 Kube-proxy: Kube-proxy는 Windows 노드에서 실행되어 Kubernetes 서비스 추상화를 구현합니다. 그러나 Linux에서처럼 iptables를 사용하는 대신, Windows에서 kube-proxy는 HNS를 사용하여 VFP를 프로그래밍하며, 이후 VFP가 서비스 IP의 패킷 라우팅과 로드 밸런싱을 처리합니다. 이 접근 방식은 서비스가 Linux 환경에서와 유사한 방식으로 작동하도록 하여 클러스터 전반에 걸친 팟에 네트워크 연결성을 제공합니다.

  3. 로드 밸런싱: 로드 밸런싱을 위해 Windows는 HNS와 Windows 서버의 내장 로드 밸런서의 조합을 사용하여 팟 간의 트래픽을 분산합니다. Windows의 kube-proxy 구성 요소는 이러한 규칙을 구성하여 서비스 요청이 백엔드 팟에 적절히 분산되도록 합니다.

  4. 네트워크 정책: Windows 서버에서 네트워크 정책을 구현하는 것은 HNS와 VFP를 사용하여 달성됩니다. 전반적인 기능은 Linux의 iptables와 유사하게 목표로 하지만, 기반 플랫폼의 차이로 인해 정책이 정의되고 집행되는 방식에는 일부 차이가 있습니다.

  5. 호환성 및 CNI 플러그인: Windows는 컨테이너 네트워킹 인터페이스(CNI) 플러그인을 여러 개 지원하여 Kubernetes 클러스터의 컨테이너에 네트워킹을 제공합니다. 이러한 플러그인은 Windows 네트워킹 구성 요소(예: HNS)와 호환되어야 하며 오버레이 네트워크, IPAM(IP 주소 관리), 라우팅 규칙을 구성하는 책임이 있습니다.

Windows에서의 Kubernetes 네트워킹은 Linux에서 사용 가능한 기능을 밀접하게 반영하지만, 운영 체제의 네트워킹 스택으로 인해 기반 기술과 구현 세부 사항이 다릅니다. 관리자는 이러한 차이를 이해하고 이것이 Windows 노드에서 Kubernetes 서비스 및 워크로드의 배포 및 운영에 어떻게 영향을 미칠 수 있는지 파악하는 것이 중요합니다.

Pod의 QoS

맞습니다. 팟 내의 어떤 컨테이너라도 CPU나 메모리에 대한 리소스 요청이나 제한을 지정한 경우, 그 팟은 BestEffort QoS 클래스에 해당되지 않습니다. Kubernetes는 컨테이너에 설정된 요청과 제한을 기반으로 팟에 QoS 클래스를 할당합니다:

  • 팟의 어떤 컨테이너도 요청이나 제한을 지정하지 않은 경우 BestEffort QoS 클래스가 할당됩니다.

  • 팟 내의 최소한 한 컨테이너가 요청이나 제한을 설정했지만, 모든 컨테이너가 요청과 제한을 같은 값으로 설정하지 않은 경우 Burstable QoS 클래스가 할당됩니다.

  • 팟 내의 모든 컨테이너가 메모리와 CPU 요청을 설정하고, 그 요청이 제한과 동일한 경우 Guaranteed QoS 클래스가 할당됩니다.

따라서, BestEffort 범주에 속하기 위해서는 팟 내의 어떤 컨테이너도 요청이나 제한을 지정하지 않아야 합니다. 최소한 한 컨테이너가 CPU나 메모리에 대해 요청이나 제한을 지정하는 경우, 팟의 QoS 클래스는 팟 내의 다른 컨테이너의 리소스 구성에 따라 Burstable 또는 **Guaranteed**가 됩니다.

Iptables의 Pod 서비스 분배율

The behavior you're observing is due to how Kubernetes sets up iptables rules for services. When a service is created in Kubernetes, it sets up iptables rules to handle load balancing across the pods that back that service. The iptables rules use a probabilistic mechanism to distribute incoming connections across the pods.

However, the way iptables implements this probabilistic load balancing is not perfectly even. The first rule in the iptables chain for the service gets a probability of 1/N, the second rule gets a probability of 1/(N-1), and so on, until the last rule which gets a probability of 1. This is because each rule in the chain is only evaluated if the previous rules have not been matched.

So, in your case with 3 pods, the first pod gets a 1/3 chance, the second pod gets a 1/2 chance (because it's only considered if the first pod was not chosen), and the third pod gets a 1/1 chance (because it's only considered if neither of the first two pods were chosen). This is why you're seeing a pod with a 0.5 probability in the iptables rules.

This mechanism provides a reasonable approximation of even load balancing, but it's not perfectly even, especially when the number of pods is small. As the number of pods increases, the distribution of traffic becomes more even.

당신이 관찰하는 행동은 쿠버네티스가 서비스를 위한 iptables 규칙을 설정하는 방식 때문입니다. 쿠버네티스에서 서비스가 생성되면, 그 서비스를 지원하는 파드들 사이에서 로드 밸런싱을 처리하기 위한 iptables 규칙을 설정합니다. iptables 규칙은 확률적 메커니즘을 사용하여 들어오는 연결을 파드들 사이에 분산시킵니다.

그러나, iptables가 이 확률적 로드 밸런싱을 구현하는 방식은 완벽하게 균등하지 않습니다. 서비스를 위한 iptables 체인의 첫 번째 규칙은 1/N의 확률을 얻고, 두 번째 규칙은 1/(N-1)의 확률을 얻습니다, 그리고 이런 식으로 마지막 규칙이 1의 확률을 얻을 때까지 계속됩니다. 이는 체인 내의 각 규칙이 이전 규칙들이 일치하지 않은 경우에만 평가되기 때문입니다.

따라서, 당신의 경우에는 3개의 파드가 있으므로, 첫 번째 파드는 1/3의 확률을 얻고, 두 번째 파드는 1/2의 확률을 얻습니다(첫 번째 파드가 선택되지 않은 경우에만 고려되기 때문입니다), 그리고 세 번째 파드는 1/1의 확률을 얻습니다(첫 두 파드 모두 선택되지 않은 경우에만 고려되기 때문입니다). 이것이 iptables 규칙에서 0.5 확률의 파드를 보는 이유입니다.

이 메커니즘은 균등한 로드 밸런싱을 합리적으로 근사화하지만, 완벽하게 균등하지는 않습니다, 특히 파드의 수가 적을 때는 그렇습니다. 파드의 수가 증가하면, 트래픽의 분포는 더욱 균등해집니다.

“Pause” 컨테이너가 “kubectl”이나 “k9s”에서 안 보이는 이유

The "pause" container, also known as the "infrastructure" or "sandbox" container, is a hidden container that Kubernetes uses for each pod to set up the network namespace and keep it alive. While it's a crucial part of Kubernetes' operation, it's not typically something that users need to interact with directly, so it's not displayed in the output of commands like kubectl get pods or in interfaces like k9s.

The "pause" container is managed by the container runtime (like Docker or containerd) on each node, not by the Kubernetes API server. Therefore, it's not represented in the Kubernetes API, and tools that interact with the Kubernetes API (like kubectl and k9s) don't show it.

However, you can see the "pause" containers if you look at the containers running on a node at the system level. For example, if you're using Docker as your container runtime, you can use the docker ps command on the node to see all containers, including the "pause" containers. Similarly, the command you selected (sudo ctr --namespace k8s.io containers ls) is a way to list all containers managed by containerd, including the "pause" containers.

"pause" 컨테이너는 "인프라" 또는 "샌드박스" 컨테이너라고도 알려져 있으며, 쿠버네티스가 각 파드에 대해 네트워크 네임스페이스를 설정하고 유지하기 위해 사용하는 숨겨진 컨테이너입니다. 이는 쿠버네티스의 작동에 있어 중요한 부분이지만, 일반적으로 사용자가 직접 상호작용할 필요가 없는 것이므로 kubectl get pods와 같은 명령어의 출력이나 k9s와 같은 인터페이스에는 표시되지 않습니다.

"pause" 컨테이너는 각 노드의 컨테이너 런타임(예: Docker 또는 containerd)에 의해 관리되며, 쿠버네티스 API 서버가 아닙니다. 따라서 쿠버네티스 API에는 표현되지 않으며, 쿠버네티스 API와 상호작용하는 도구(kubectl 및 k9s 등)는 이를 표시하지 않습니다.

그러나 시스템 수준에서 노드에서 실행 중인 컨테이너를 살펴보면 "pause" 컨테이너를 볼 수 있습니다. 예를 들어, Docker를 컨테이너 런타임으로 사용하는 경우, 노드에서 docker ps 명령어를 사용하여 "pause" 컨테이너를 포함한 모든 컨테이너를 볼 수 있습니다. 마찬가지로 선택한 명령어(sudo ctr --namespace k8s.io containers ls)는 containerd가 관리하는 모든 컨테이너, "pause" 컨테이너를 포함하여 나열하는 방법입니다.

PreviousKubernetes Operational View 설치하기 Kubernetes Operational View 설치하기Next마이크로서비스 CI/CD 파이프라인 설정

Last updated