2017-12-22 7 views
1

저는 Kubernetes를 배우고 있으며 현재 고 가용성에 깊이 관여하고 있으며 로컬 (또는 원격) 등의 고 가용성 제어 플레인 (API 서버, 컨트롤러, 스케줄러)을 고 가용성으로 설정할 수 있음을 알고 있습니다. 미니언 세트 (Kubernetes 자체를 통해), 나는 아직도이 개념 서비스가 어디에 위치하는지 확신 할 수 없다.Kubernetes에서 서비스는 어디에서 살고 있습니까?

컨트롤 플레인에있는 경우 : 유용성이 높도록 설정할 수 있습니다.

특정 노드에 거주하는 경우 : 확인,하지만 다른 방법으로 노드가 다운되거나 사용할 수 없게되면 어떻게됩니까?

내가 알고 있듯이로드 밸런싱뿐 아니라 인터넷에 내 포드를 노출시키는 서비스가 필요합니다. 따라서 HA 서비스가 없기 때문에 (시스템의 다른 측면에서도 매우 유용 할 수도 있음에도 불구하고) 내 애플리케이션에 도달 할 수 없다는 위험이 있습니다.

답변

0

는 Kubernetes 서비스에 꽤 좋은 통찰력을 제공는 K8S 클러스터의 다른 REST 개체입니다. 다음과 같은 유형의 서비스가 있습니다. 이들 각각은 클러스터에서 다른 용도로 사용됩니다. 포드에 게이트웨이의 단일 지점을 제공하는 서비스

    • ClusterIP
    • NodePort
    • 로드 밸런서
    • 헤드리스

    근본적인 목적

  • 개로드 밸런싱 포드
  • 포드 다이 다른 IP 재시작 수
  • 가 안정성을 제공
  • 인터 포드 통신

가 상기 단일 소스 인 이러한 개체 가 etcd에 저장된 클러스터의 진실.

Kube-proxy는 이러한 개체를 생성합니다.선택기와 레이블을 사용합니다.

예를 들어 각 pod 객체에는 레이블이 있으므로 서비스 객체에는 이러한 레이블과 일치하는 선택자가 있습니다. 또한 각 포드에는 끝점이 있으므로 기본적으로 kube-proxy는 이러한 끝점 (IP : 포트)을 서비스 (IP : 포트)로 할당합니다 .Kube-proxy는 IP-Tables 규칙을 사용하여이 마법을 수행합니다.

Kube-Proxy는 각 클러스터 노드에 DaemonSet으로 배포되므로 etcd를 사용하여 서로를 인식합니다.

+0

좋아,하지만 kubernetes.io/docs/concepts/services-networking/service/...에 따르면 내 서비스에 대해 하나의 IP 주소를 요청할 수 있습니다. 이것은 내 이해에 따라 특정 노드에서 단 하나의 kube-proxy로 이어질 것입니다. 아니면 실제로 서비스의 레이블 선택기와 일치하는 노드에서 실행중인 모든 kube-proxy에 api-server에 매핑됩니까? –

+0

Kube-proxy와 Kubelet은 Etcd의 모든 현재 상태를 저장하는 Kube-api Server와 통신합니다. 예를 들어, 우리는 kubelet의 도움을 받아 3 개의 다른 노드에서 실행중인 3 개의 포드를 가지고 있습니다. 이 모든 것들이 끝점을 가지고 있습니다. 이제 서비스 목록을 배포하는 경우 kube-proxy는 서비스 끝점이 IPTABLES 마술 인 포드 끝점과 정렬되어 있는지 확인합니다. Kube-proxy는 api-server와 통신하고 etcd를 업데이트합니다. –

+0

Kube-proxy는 이름 대신 레이블을 사용하여 창을 찾습니다. 그러므로 셀렉터와 라벨은 k8의 강력한 요소입니다. 또한 Kube-proxy는 Kube-api 서버와 통신하여 포드의 상태 나 서비스 변경을 확인합니다. –

2

서비스는 내부 (일부 경우에는 외부)로드 밸런서라고 생각할 수 있습니다. 정의는 Kubernetes API 서버에 저장되지만, 실제로 존재한다는 사실은 무언가가 그것을 구현하지 않는다면 아무 것도 의미하지 않는다. 서비스와 함께 작동하는 가장 일반적인 구성 요소는 iptables를 사용하는 노드에서 서비스를 구현하는 kube-proxy입니다 (모든 노드는 로컬 iptables 규칙에 구현 된 모든 서비스를 포함 함). Ingress Controller 구현은 API의 서비스 개념을 사용하여 엔드 포인트를 찾아서 트래픽을 직접 전송하므로 iptables 구현을 건너 뜁니다. 마지막으로 linkerd 또는 istio과 같은 서비스 메쉬 솔루션은 자체적으로 서비스 정의를 활용할 수 있습니다.

대부분의 구현에서 포드 사이의 부하 균형을 조정합니다. 즉, 하나의 백업 포드가 있고 용량이 충분한 한 "서비스"가 응답합니다 (따라서 HA도 얻습니다. 특히 준비/무엇보다도 서비스에서 건강에 해로운 포드를 제거합니다 생동감 프로브)

는 Kubernetes Service 내용은 해당

관련 문제