다른 유형의 서비스와 구별하기 위해 서비스 이름을 lbservice 또는 기타로 변경해야 합니다.

그 일환으로 핵심 apiserver에서 서비스 개체를 제거하고 HAProxy 및 nginx와 같은 다른 로드 밸런서의 사용을 촉진합니다.

서비스의 논리적 정의(쿼리 및/또는 전역 이름)가 여러 방식으로 사용/특화될 수 있다면 좋을 것입니다. 인프라를 통해 설치된 단순한 로드 밸런서, nginx와 같은 더 많은 기능을 갖춘 완전한 로드 밸런서 또는 인프라에서 제공하는 haproxy는 통합자가 폴링/대기할 수 있는 쿼리 가능한 끝점(GET /services/foo -> { endpoints: [{host, port}, ...] }) 또는 호스트에서 사용할 수 있는 정보로 제공됩니다. 로컬 로드 밸런서를 노출합니다. 분명히 이들은 여러 다른 사용 사례가 될 수 있고 자체 리소스로 분할될 수 있지만 메커니즘과 구별되는 의도(lb 아래 통합)를 지정할 수 있는 유연성이 있으면 광범위한 요구 사항을 더 쉽게 충족할 수 있습니다.

@smarterclayton 정책과 메커니즘을 분리하는 데 동의합니다.

우리가 필요로 하는 프리미티브:

1. 레이블 선택기로 식별된 세트를 폴링/시청하는 기능. 아직 제기된 문제가 있는지 확실하지 않습니다.
2. 포드 IP 주소를 쿼리하는 기능(#385).

이것은 다른 이름 지정/검색 메커니즘 및/또는 로드 밸런서로 구성하기에 충분합니다. 그런 다음 일반적인 패턴을 간단한 API와 묶는 코어 위에 더 높은 수준의 레이어를 구축할 수 있습니다.

@bgrant0607 이 설명한 두 가지 기본 요소가 이 문제를 계속 열어둘 가치가 있습니까? 아니면 제출할 수 있는 더 구체적인 문제가 있습니까?

사육사가 해결되었다고 생각하지 않습니다. 각 컨테이너에 고유한 식별자가 필요하기 때문입니다. 제 생각에는 3개의 개별 복제 컨트롤러(인스턴스당 하나씩) 또는 복제 컨트롤러의 모드로 이 작업을 수행할 수 있다고 생각합니다.

서비스 디자인은 Brian이 언급한 것처럼 약간의 논의가 필요하다고 생각합니다. 현재 레이블 쿼리를 사용하여 노출 메커니즘(모든 컨테이너의 환경 변수)과 인프라 추상화(로컬 프록시)를 연결합니다. L7 호스트/경로를 가져와 레이블 쿼리와 균형을 이루는 에지 프록시와 http(s) 및 웹 소켓과 같은 지원 프로토콜에 대해 동등하게 유효한 사용 사례가 있습니다. 또한 서비스에는 현재 전체 클러스터(할당된 IP의 양)에서 공유되는 60,000개의 백엔드라는 엄격한 확장 제한이 있습니다. 해당 호스트의 컨테이너가 필요로 하는 서비스만 프록시하는 미니언에서 로컬 프록시를 실행할 수 있어야 하고 컨테이너가 외부 포트에 대해 알아야 하는 것을 방지할 수 있어야 합니다. 필요한 경우 이 토론을 #494로 이동할 수 있습니다.

마스터-슬레이브 복제 데이터베이스, 고정 크기 피어 그룹이 있는 키-값 저장소(예: etcd, 사육사) 등과 같은 고정 복제를 사용하여 싱글톤 서비스 및 자동 확장되지 않는 서비스의 문제 해결

고정 복제 사례에는 예측 가능한 배열과 같은 동작이 필요합니다. 피어는 서로를 발견하고 개별적으로 해결할 수 있어야 합니다. 이러한 서비스에는 일반적으로 자체 클라이언트 라이브러리 및/또는 프로토콜이 있으므로 인스턴스를 개별적으로 주소 지정 가능하게 만드는 것 외에 클라이언트가 연결해야 하는 인스턴스를 결정하는 문제를 해결할 필요가 없습니다.

제안: 우리는 하나가 아닌 N개의 IP 주소를 매핑하는 카디널 서비스라는 새로운 형태의 서비스를 만들어야 합니다. 카디널 서비스는 레이블 선택기가 대상으로 하는 N개의 인스턴스에 이러한 IP 주소를 안정적으로 할당합니다(즉, 많은 대상이 존재하는 것이 아니라 지정된 N). DNS( #1261, #146 )가 있으면 제공된 접두사를 기반으로 예측 가능한 DNS 이름을 할당하고 접미사는 0에서 N-1까지입니다. 할당은 대상 포드의 주석 또는 레이블에 기록될 수 있습니다.

이렇게 하면 표준 애플리케이션 구성 메커니즘에서 사용할 수 있는 안정적인 이름과 IP 주소를 제공하면서 포드 및 복제 컨트롤러의 ID에서 역할 할당의 분리를 유지합니다.

다양한 유형의 로드 밸런싱에 대한 논의 중 일부는 서비스 v2 설계: #1107에서 발생했습니다.

마스터 선거에 대해서는 별도의 호를 제출하겠습니다.

/cc @smarterclayton @thockin

할당은 일부 환경 매개변수화 메커니즘을 통해 파드로 전달되어야 합니다(거의 확실히).

etcd 예제의 경우 다음을 생성합니다.

• 복제 컨트롤러 카디널리티 1:1 포드, 안정적인 스토리지 볼륨 A를 가리키는
• 복제 컨트롤러 카디널리티 2: 안정적인 스토리지 볼륨 B를 가리키는 1개의 포드
• 복제 컨트롤러 카디널리티 3: 안정적인 스토리지 볼륨 C를 가리키는 1개의 포드
• 포드를 가리키는 기본 서비스 'etcd'

포드 2가 죽으면 복제 컨트롤러 2가 새 복사본을 만들어 볼륨 B에 다시 연결합니다. 카디널 서비스 'etcd'는 해당 포드가 새 것임을 알고 있지만 카디널리티 2(저장된 데이터에서 가져옴)여야 한다는 것을 어떻게 알 수 있습니까? 볼륨 B)?

3개의 복제 컨트롤러가 아닌 샤딩 컨트롤러가 필요한 이유는 무엇입니까?
결정을 내릴 때 "kubernetes.io/ShardIndex"와 같은 레이블을 확인합니다. 만약에
3방향 샤딩을 원하면 인덱스 0, 1, 2가 있는 3개의 포드를 만듭니다.
이것은 전에 격추되었지만, 그로 인해 발생한 문제를 재구성할 수 없습니다.
내 머리.

상대적으로 사용자에게 부담을 주는 것은 잘못된 것 같습니다.
일반적인 시나리오.

특정 포드의 명목 IP가 다음으로 인해 변경되는지 여부가 중요하다고 생각하십니까?
세트의 관련 없는 변경 사항은 무엇입니까? 예를 들어:

시간 0에서 포드(A, B, C)는 IP와 함께 기본 서비스를 구성합니다.
각각 10.0.0.{1-3}

시간 1에서 포드 B를 호스팅하는 노드가 종료됩니다.

시간 2에서 B를 구동하는 복제 컨트롤러는 새 포드 D를 생성합니다.

시간 3에서 기본 서비스는 IP가 10.0.0인 (A, C, D)로 변경됩니다.{1-3}
각기

주의: 포드 C의 "안정된 IP"는 설정 시 10.0.0.3에서 10.0.0.2로 변경되었습니다.
멤버십이 변경되었습니다. 나는 이것이 달리기에 나쁜 영향을 줄 것이라고 기대한다
사이.

이것을 피하려면 서수 값을 지정해야 합니다.
서비스 외부 또는 다른 영리한 것. 괜찮을 수도 있지만
사람들이 그것을 다루어야 하는 경우 연약하고 잘못되기 쉬운 것처럼 보입니다.

2014년 10월 2일 목요일 오전 10시 17분, Clayton Coleman [email protected]
썼다:

할당은 일부를 통해 포드로 전달되어야 합니다.
환경 매개변수화 메커니즘(거의 확실함).

etcd 예제의 경우 다음을 생성합니다.

• 복제 컨트롤러 카디널리티 1:1 포드, 안정을 가리키는
  스토리지 볼륨 A
• 복제 컨트롤러 카디널리티 2: 1 포드, 안정을 가리키는
  스토리지 볼륨 B
• 복제 컨트롤러 카디널리티 3: 1 포드, 안정을 가리키는
  스토리지 볼륨 C
• 포드를 가리키는 기본 서비스 'etcd'

포드 2가 죽으면 복제 컨트롤러 2가 새 복사본을 만들고
이를 볼륨 B에 다시 연결합니다. 기본 서비스 'etcd'는 해당 포드가
새롭지만 카디널리티 2여야 한다는 것을 어떻게 알 수 있습니까?
볼륨 B에 저장된 데이터)?

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

나는 샤딩 컨트롤러가 의미가 있고 아마도 기본 서비스의 맥락에서 더 유용할 것이라고 생각합니다.

멤버쉽에 따른 IP 변경이 무섭고 퇴보한 엣지 케이스를 많이 생각할 수 있다고 생각합니다. 그러나 카디널리티가 포드와 함께 저장되면 결정이 덜 어렵습니다.

우선, 나는 이것을 샤딩에 대해 의도한 것이 아닙니다 -- 그것이 #1064입니다. 샤딩 논의를 그곳으로 옮겨보자. 우리는 샤딩에 유사한 메커니즘을 사용하려는 많은 경우를 보았고 이것이 샤딩을 구현하는 최선의 방법이 아니라는 결론을 내렸습니다.

둘째, N개의 복제 컨트롤러를 실행할 필요가 없도록 하려는 것입니다. 필요한 수는 배포 세부 정보(카나리아, 여러 릴리스 트랙, 롤링 업데이트 등)에 따라 다르지만 하나만 사용할 수 있어야 합니다.

셋째, 이것이 지속 가능한 데이터 제안(#1515) -- @erictune 과 상호 작용하는 방식을 고려해야 한다는 데 동의합니다.

넷째, 아이덴티티를 포드에 반영해야 한다는 데 동의합니다. #386에 따라 IP 및 DNS 이름 할당을 포드에서 볼 수 있도록 하는 데 이상적으로는 표준 메커니즘이 사용됩니다. IP 및 호스트 별칭은 일반적으로 Linux에서 어떻게 표시됩니까?

다섯째, 레이블이나 주석을 통해 Pod에 할당을 기록하여 할당 안정성을 보장할 것을 제안했습니다.

여섯째, 복제 컨트롤러를 대체하는 "샤딩 컨트롤러"의 문제는 이미지/환경 관리에서 역할 할당을 분리하고 싶다는 것입니다. 복제 컨트롤러가 후자를 제공한다고 생각합니다(https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564 참조).

#1515에 따른 내구성 데이터의 경우:

1. 내구성 있는 포드의 경우 이 제안이 제대로 작동합니다. 내구성 포드에 대한 할당은 안정적입니다.
2. 별도의 데이터 개체의 경우 기본 서비스는 데이터 개체에 대한 역할 할당도 관리해야 하며 데이터와 일치할 때까지 포드에 대한 역할 할당을 연기합니다. 나는 이것이 간단할 것이라고 생각한다.

/cc @erictune

나는 당신이 대화를 더 쉽게 하려고 노력했다고 생각하지만 그것이 효과가 있었는지 확신할 수 없습니다.

Re: 샤딩 - "고유한 ID를 가진 복제본 세트"는 기본적으로 샤딩이 아닙니까?

Re: 1 복제 컨트롤러 - 오늘 인덱스를 할당하는 복제 컨트롤러가 없습니다. 나는 우리가 그것을 원하는 것 같지 않습니다, 그렇죠?

Re: 포드에 고유한 ID를 알리기 - 서비스는 포드보다 깨끗한 계층입니다. 임박한 포드가 존재하기 전에 IP를 할당할 수 있도록 임박한 포드에 대해 서비스에 알리는 것은 지저분할 것입니다. ID는 ShardIndex 레이블과 같은 포드의 일부여야 한다고 생각합니다. 우리는 그것을 포드에 (어쨌든) 반영할 수 있고 서비스는 IP를 할당하는 데 사용할 수 있습니다. Cardinal 서비스가 스스로 수행하도록 하면 포드가 할당될 때 이미 포드가 시작된 것입니다. GCE의 VM과 같이 포드당 메타데이터를 가질 수 있지만 이는 더 큰 제안입니다.

아니요, 안정적이고 뚜렷한 ID를 제공하는 것은 샤딩에 필요하지도 충분하지도 않습니다. 방금 추가한 자세한 내용은 #1064를 참조하세요.

아니요, 복제 컨트롤러가 인덱스를 할당하는 것을 원하지 않습니다. 나는 의도적으로 카디널 서비스가 그것을 대신하도록 제안했습니다.

예, 포드에 역할(인덱스)이 할당되기 전에 포드가 존재하고 잠재적으로 시작되었을 것으로 예상합니다. 그것은 의도적이었습니다. 또한 할당을 취소할 수 있어야 합니다.

가능한 ID 접근 방식: 컨테이너에 비영구적 IP 별칭을 만들고 DNS 구현에서 역방향 DNS 조회를 제공합니다.

그러나 ID를 포드 컨테이너에 연결하는 것이 많은 사용 사례에서 필수적이라고 생각하지 않습니다. 응용 프로그램이 자체 등록을 사용하는 경우 이 메커니즘이 필요하지 않을 수 있습니다.

서비스 관리자가 어떤 상태를 제외하고 기꺼이 유지하려는 경우
현재 우리는 이전에 만들어진 매핑을 기억할 수 있습니다.
그리고 그들을 존중하려고 노력하십시오.

2014년 10월 2일 목요일 오후 8시 59분에 bgrant0607 [email protected]에서 다음과 같이 썼습니다.

가능한 ID 접근 방식: 비영구적 IP 별칭 생성
컨테이너를 만들고 DNS 구현에서 역방향 DNS 조회를 제공합니다.

그러나 ID를 포드 컨테이너에 연결하는 것은
많은 사용 사례에 필수적입니다. 응용 프로그램이 사용 중인 경우
자체 등록, 아마도 이 메커니즘이 필요하지 않을 것입니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

답장. 매핑을 기억하고 동의합니다. https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787을 참조

하지만 그것이 당신이 응답한 댓글과 어떻게 관련이 있는지 모르겠습니다.

GitHub와 이메일은 섞이지 않습니다. 죄송합니다

2014년 10월 2일 목요일 오후 9시 39분에 bgrant0607 [email protected]에서 다음과 같이 썼습니다.

답장. 매핑을 기억하고 동의합니다 -- #260(댓글) 참조
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

하지만 그것이 당신이 응답한 댓글과 어떻게 관련이 있는지 모르겠습니다.

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Tim은 "명목상"을 제안했는데, 나는 그것이 더 적합하다는 데 동의합니다.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

명목상도 좋아합니다. 사용자에게 설명하는 것을 싫어하지만 구성 생성 항목에 사용되는 경우가 매우 많습니다(예: 명목 mongodb 복제 세트는 복제 컨트롤러, 명목 서비스, 볼륨이 될 것이므로 이미 다소 복잡합니다).

----- 원본 메시지 -----

Tim은 "명목상"을 제안했는데, 나는 그것이 더 적합하다는 데 동의합니다.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

내가 보는 두 가지 문제:

1. 역할 할당에는 포드당 최소한 환경 변수 또는 볼륨 설정 설정이 포함됩니다(즉, 첫 번째 포드는 볼륨 a를 가져와야 하고, 삭제된 경우 교체하려면 동일한 볼륨이 필요함).
2. 명목 서비스의 포드가 단일 repl 컨트롤러에서 제공되는 경우 템플릿은 생성 후 포드가 바인딩되기 전에 수정되어야 합니다.

이것은 역할 할당이 워크플로 단계로 apiserver와 스케줄러 사이에 위치하는 컨트롤러임을 의미하는 것 같습니다. 또한 역할 할당이 없는 템플릿이 반드시 의미가 없는 것과 같이 템플릿의 변형 또는 재정의의 일부 형태를 의미합니다.

샤드 컨트롤러는 더 복잡한 역할 할당을 위한 이 문제의 변형처럼 보입니다.

인스턴스당 하나의 서비스로 사육사를 실행하는 예: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

그래서 나는 이것이 오래된 스레드라는 것을 알고 있지만 그것은 나에게 가깝고 소중한 주제를 칩니다 ;-)

시스템이 NAT가 아닌 "명목 서비스"에 대한 레코드를 앞으로 푸시하고 해당 서비스를 사용하는 포드에 ENV 주입으로 이름을 사용할 수 있다면 다른 제한 사항이 있습니까?

쿼럼의 모든 요소가 다른 요소를 사용하는 ZK의 경우에는 약간 이상하게 보일 수 있습니다. 예:
zk1 사용: zk2, zk3
zk2 사용: zk1, zk3
zk3 사용: zk1, zk2

그러나 이론상으로는 제대로 작동해야 합니까? 명목 서비스에 대한 역 레코드를 추가할 수 있다면.

@ bgrant0607 내가 뭔가를 놓치고 있습니까?

다른 응용 프로그램이 제공하는 전체 서비스를 사용하려는 경우 약간 이상해집니다. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc 당신이 제안한 것은 zk1, zk2, zk3가 서비스라면 적어도 한 번은 다중 포트 서비스가 지원된다면 작동할 것입니다.

예, 하지만 여기에 못생긴 것이 있습니다.

실행 중인 포드는 어떤 서비스가 "앞에" 있는지 모릅니다. 예: 서비스 제공
하나의 백엔드 인스턴스에서 서비스에 액세스하는 데 사용된 VIP는
백엔드(서비스를 알고 그 정보를 찾지 않는 한
이름). 명목 서비스(N)에는 N개의 백엔드와 N개의 VIP가 있습니다.
아마도 N개의 DNS 이름 또는 N-주소 이름), 그러나 백엔드는 여전히
자신의 VIP를 모릅니다. 그들은 DNS 이름 풀을 관찰할 수 있지만
어느 것이 자기 자신인지 (탐색 없이) 모릅니다. 이것은 당신의 ZK를 만들 것입니다
VIP를 사용하기 어려운 경우(VIP도 현재 관찰 가능하게 프록시됨).

대안:

1) 1개의 서비스(N)를 설정하고 각 인스턴스가 모든 VIP를 자체적으로 조사하도록 합니다.

2) N service(1) 인스턴스를 설정하고 레이블 및 cmdline 플래그를 사용하여
수동으로 인덱스를 할당하고 각 ZK 백엔드가 (선험적으로) DNS 이름을 알도록 합니다.
서로의 ZK 백엔드

3) 레이블 선택기에 대해 DNS를 수행하고, ZK 복제 세트에 DNS 이름을 할당하고,
클라이언트가 DNS를 올바르게 사용하기를 바랍니다.

4) kubernetes 엔드포인트를 동기화하는 각 ZK와 함께 kube2zk 브리지 실행 ->
ZK 구성

5) 더 많은 VIP 또는 지수를 할당하는 대체 방법을 설계하십시오.
서비스 중심보다 교체 컨트롤러 중심입니다. 브랜든과 나
얼마 전에 여기에 몇 가지 아이디어를 브레인스토밍했지만 따라할 시간이 없었습니다.
올라가서.

역방향 DNS의 경우 - 그 역할이 확실하지 않습니까? 나는 반대하지 않는다
그것을 지원합니다(즉, @bketelsen 에게 지원을 요청
여기에 적용됩니다. 트래픽은 서비스 IP "에서" 오지 않습니다.

팀

2015년 3월 7일 토요일 오후 8시 56분, Brian Grant 알림 @github.com
썼다:

@timothysc https://github.com/timothysc 제안한 내용은 다음과 같은 경우 작동합니다.
zk1, zk2 및 zk3은 서비스였으며 적어도 한 번은 다중 포트 서비스가
지원.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) 이 제안처럼 들립니다.

나는 5의 열렬한 팬입니다. 자신의 역할이 1단계라는 것을 알고 있는 포드, DNS 식별을 갖는 고유한 포드 또는 엔드포인트를 사용하여 다른 IP를 가져오고 이에 반응하는 포드는 2입니다. 안정적인 역할 ID로 엔드포인트에서 포드 IP를 조회할 수 있는 것은 세 번째입니다.

2015년 3월 8일 오전 11시 6분에 Tim Hockin [email protected] 은 다음과 같이 썼습니다.

예, 하지만 여기에 못생긴 것이 있습니다.

실행 중인 포드는 어떤 서비스가 "앞에" 있는지 모릅니다. 예: 서비스 제공
하나의 백엔드 인스턴스에서 서비스에 액세스하는 데 사용된 VIP는
백엔드(서비스를 알고 그 정보를 찾지 않는 한
이름). 명목 서비스(N)에는 N개의 백엔드와 N개의 VIP가 있습니다.
아마도 N개의 DNS 이름 또는 N-주소 이름), 그러나 백엔드는 여전히
자신의 VIP를 모릅니다. 그들은 DNS 이름 풀을 관찰할 수 있지만
어느 것이 자기 자신인지 (탐색 없이) 모릅니다. 이것은 당신의 ZK를 만들 것입니다
VIP를 사용하기 어려운 경우(VIP도 현재 관찰 가능하게 프록시됨).

대안:

1) 1개의 서비스(N)를 설정하고 각 인스턴스가 모든 VIP를 자체적으로 조사하도록 합니다.

2) N service(1) 인스턴스를 설정하고 레이블 및 cmdline 플래그를 사용하여
수동으로 인덱스를 할당하고 각 ZK 백엔드가 (선험적으로) DNS 이름을 알도록 합니다.
서로의 ZK 백엔드

3) 레이블 선택기에 대해 DNS를 수행하고, ZK 복제 세트에 DNS 이름을 할당하고,
클라이언트가 DNS를 올바르게 사용하기를 바랍니다.

4) kubernetes 엔드포인트를 동기화하는 각 ZK와 함께 kube2zk 브리지 실행 ->
ZK 구성

5) 더 많은 VIP 또는 지수를 할당하는 대체 방법을 설계하십시오.
서비스 중심보다 교체 컨트롤러 중심입니다. 브랜든과 나
얼마 전에 여기에 몇 가지 아이디어를 브레인스토밍했지만 따라할 시간이 없었습니다.
올라가서.

역방향 DNS의 경우 - 그 역할이 확실하지 않습니까? 나는 반대하지 않는다
그것을 지원합니다(즉, @bketelsen 에게 지원을 요청
여기에 적용됩니다. 트래픽은 서비스 IP "에서" 오지 않습니다.

팀

2015년 3월 7일 토요일 오후 8시 56분, Brian Grant 알림 @github.com
썼다:

@timothysc https://github.com/timothysc 제안한 내용은 다음과 같은 경우 작동합니다.
zk1, zk2 및 zk3은 서비스였으며 적어도 한 번은 다중 포트 서비스가
지원.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

그럼 시간을 좀 더 벌어서 이 아이디어를 작성해야겠습니다.

2015년 3월 8일 일요일 오전 10시 25분, Clayton Coleman [email protected]
썼다:

나는 5의 열렬한 팬입니다 - 그들의 역할이 1단계라는 것을 알고 있는 포드, 포드
고유한 DNS 식별을 갖거나 엔드포인트를 사용하여 다른 사람의 IP를 가져오고
그것에 대한 반응은 두 가지입니다. 엔드포인트에서 팟(Pod) IP를 조회할 수 있음
안정적인 역할 ID는 세 번째입니다.

2015년 3월 8일 오전 11:06, Tim Hockin [email protected]
썼다:

예, 하지만 여기에 못생긴 것이 있습니다.

실행 중인 포드는 어떤 서비스가 "앞에" 있는지 모릅니다. 예를 들어
서비스
하나의 백엔드 인스턴스 중 서비스에 액세스하는 데 사용된 VIP를 알 수 없음
~에 의해
백엔드(서비스를 알고 그 정보를 찾지 않는 한
이름). 명목 서비스(N)에는 N개의 백엔드와 N개의 VIP가 있습니다.
(그리고
아마도 N개의 DNS 이름 또는 N-주소 이름), 그러나 백엔드는
아직
자신의 VIP를 모릅니다. 그들은 DNS 이름 풀을 관찰할 수 있지만
어느 것이 자기 자신인지 (탐색 없이) 모릅니다. 이것은 당신의 ZK를 만들 것입니다
VIP를 사용하기 어려운 경우(VIP도 현재 관찰 가능하게 프록시됨).

대안:

1) 1개의 서비스(N)를 설정하고 각 인스턴스가 모든 VIP를 자체적으로 조사하도록 합니다.

2) N service(1) 인스턴스를 설정하고 레이블 및 cmdline 플래그를 사용하여
수동으로 인덱스를 할당하고 각 ZK 백엔드가 (선험적으로) DNS를 알도록 합니다.
이름
서로의 ZK 백엔드

3) 레이블 선택기에 대해 DNS를 수행하고, ZK 복제 세트에 DNS 이름을 할당하고,
클라이언트가 DNS를 올바르게 사용하기를 바랍니다.

4) kubernetes 엔드포인트를 동기화하는 각 ZK와 함께 kube2zk 브리지를 실행합니다.
->
ZK 구성

5) 더 많은 VIP 또는 지수를 할당하는 대체 방법을 설계하십시오.
서비스 중심보다 교체 컨트롤러 중심입니다. 브랜든과 나
얼마 전에 여기에서 몇 가지 아이디어를 브레인스토밍했지만 할 시간이 없었습니다.
따르다
올라가서.

역방향 DNS의 경우 - 그 역할이 확실하지 않습니까? 나는 반대하지 않는다
그것을 지원합니다(즉, @bketelsen 에게 지원을 요청
여기에 적용됩니다. 트래픽은 서비스 IP "에서" 오지 않습니다.

팀

2015년 3월 7일 토요일 오후 8시 56분, Brian Grant 알림 @github.com
썼다:

@timothysc https://github.com/timothysc 당신이 제안한 것이 효과가 있을 것입니다
만약
zk1, zk2 및 zk3은 서비스였으며 적어도 한 번은 다중 포트 서비스가
지원.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: 역 DNS, 그냥 손을 흔들고 요구 사항이라고 생각합시다.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

생성하는 각 포드에 고유한 레이블(members=#)을 적용하고 N개의 복제본까지 시퀀스 생성을 시도한 RC 및 "구성원" 레이블(# .service.namespace.local), 여기서 루트는 모든 service.namespace.local -> 라운드 로빈 -> 1.service.namespace.local, 2.service.namespace.local을 로컬로 제공합니다.

개별 DNS 레이블에 대해 엄격한 포드 IP를 _사용_할 수 있습니다. 각각에 대해 가짜 IP를 만드는 것은 비용이 많이 들고 컨테이너는 자신의 IP를 누군가에게 보낼 수 없습니다.

----- 원본 메시지 -----

@thockin re: 역 DNS, 손을 흔들고 생각해 봅시다.
요구 사항.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: 역 DNS - 역 DNS가 무엇입니까? 소스-IP
사이? 그 중 어느 것도 kube에서 작동하지 않습니다. 서비스를 통한 연결은
프록시 처리되므로 source-ip가 처음부터 작동하지 않습니다(고칠 수 있음).

나는 ZK를 모른다 - 그들이 역으로 얻으려고 하는 것을 설명할 수 있니?
DNS? 매우 연약한 가정처럼 보입니다.

2015년 3월 9일 월요일 오전 9시 5분, Timothy St. Clair [email protected]
썼다:

@thockin https://github.com/thockin re: 역 DNS, 그냥 흔들자
우리의 손에 대한 요구 사항을 고려합니다.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

내 경험(및 Tim의 경우)은 오늘날 대부분의 클러스터형 소프트웨어가 다음을 기대한다는 것입니다.

• 각 노드에는 안정적인 ID가 있습니다.
• 해당 ID는 DNS 이름입니다.
• 기본 ID의 IP가 안정적일 필요는 없습니다.
• 노드는 안정적인 ID(DNS) 또는 공용 IP를 통해 다른 노드에 대해 자신을 식별할 것으로 기대합니다.
• 클러스터된 소프트웨어 중 일부는 클라이언트가 도달한 노드의 IP가 IP와 일치하기 위해 클러스터의 다른 사용자에게 자신을 알릴 수 있고 해당 IP에 도달할 수 있을 것으로 예상합니다.

----- 원본 메시지 -----

@timothysc re: 역 DNS - 역 DNS가 무엇입니까? 소스-IP
사이? 그 중 어느 것도 kube에서 작동하지 않습니다. 서비스를 통한 연결은
프록시 처리되므로 source-ip가 처음부터 작동하지 않습니다(고칠 수 있음).

나는 ZK를 모른다 - 그들이 역으로 얻으려고 하는 것을 설명할 수 있니?
DNS? 매우 연약한 가정처럼 보입니다.

2015년 3월 9일 월요일 오전 9시 5분, Timothy St. Clair [email protected]
썼다:

@thockin https://github.com/thockin re: 역 DNS, 그냥 흔들자
우리의 손에 대한 요구 사항을 고려합니다.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

2015년 3월 9일 월요일 오후 12:49 Clayton Coleman
[email protected] 은 다음과 같이 썼습니다.

생성하는 각 포드에 고유한 레이블(구성원=#)을 적용하고 최대 시퀀스 생성을 시도하는 RC
N개의 복제본과 "구성원"의 각 값에 대해 A 및 CNAME 이름을 생성한 헤드리스 서비스
레이블(#.service.namespace.local), 여기서 루트는 모든 service.namespace.local -> 라운드를 제공했습니다.
robin -> 1.service.namespace.local, 2.service.namespace.local이 로컬인 것 같습니다.

Brendan과 내가 뒹굴고 있다는 생각은 기본적으로 수영장이었습니다.
토큰, 아마도 RC의 일부일 수도 있고 아닐 수도 있습니다. RC의 각 요소는
배정될 것입니다. 해당 토큰이 주어지면 다른 것이 할당될 수 있습니다.

• VIP, PD, 일반 인덱스 등 좋은 점은 포드가
  죽으면 토큰이 풀로 반환되고 해당 포드가 교체될 때
  해당 토큰은 재사용됩니다.

문제는 "임의 토큰"을
의미있는 것.

개별 DNS 레이블에 대해 엄격한 포드 IP를 _사용_할 수 있습니다. 각각에 대해 가짜 IP를 만드는 것은 비용이 많이 들고 컨테이너는 자신의 IP를 누군가에게 보낼 수 없습니다.

시도하지는 않았지만 명목 서비스가 전체 SNAT를 수행하도록 할 수 있습니다.
및 DNAT는 1:1이므로. 안정을 취하는 방법이 될 것입니다.
마이그레이션 가능한 IP가 없는 포드당 IP.

----- 원본 메시지 -----

@thockin re: 역 DNS, 손을 흔들고 생각해 봅시다.
요구 사항.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

내가 상류로 헤엄치는 것은 거리가 멀다 - 충분한 앱이 실제로 DNS가
이 방식으로 작동하면 이 방식으로 작동할 수 있습니다.

스케치:

복제 컨트롤러 만들기 R은 DNS 이름 "$R.rc"를 만듭니다.
해당 RC "아래"에 있는 포드 IP 풀. 각 포드 P는 DNS 이름을 얻습니다.
"$P.$R.rc". 그러나 P는 무엇입니까? 단순한 지수일 수 있지만
우리를 내부적으로 세게 물었습니다. GenerateName과 같은 임의의 문자열일 수 있습니다.
그러나 그들은 포드 사망/재시작에서 살아남아야 합니다(아마도 포드 호스트 이름은
성냥?).

2015년 3월 10일 화요일 오전 7:59, Clayton Coleman [email protected]
썼다:

내 경험(및 아마도 Tim의 경우)은 대부분의 클러스터가
오늘날 소프트웨어는 다음을 기대합니다.

• 각 노드에는 안정적인 ID가 있습니다.
• 해당 ID는 DNS 이름입니다.
• 기본 ID의 IP가 안정적일 필요는 없습니다.
• 노드는 안정적인
  ID(DNS) 또는 해당 공용 IP
• 클러스터된 소프트웨어 중 일부는 노드의 IP를 클라이언트로 예상합니다.
  자신을 다른 사람에게 알릴 수 있는 IP와 일치하도록 도달
  클러스터 및 해당 IP에 연결할 수 있습니다.

----- 원본 메시지 -----

@timothysc re: 역 DNS - 역 DNS가 무엇입니까? 소스-IP
사이? 그 중 어느 것도 kube에서 작동하지 않습니다. 서비스를 통한 연결은
프록시 처리되므로 source-ip가 처음부터 작동하지 않습니다(고칠 수 있음).

나는 ZK를 모른다 - 그들이 역으로 얻으려고 하는 것을 설명할 수 있니?
DNS? 매우 연약한 가정처럼 보입니다.

2015년 3월 9일 월요일 오전 9:05, Timothy St. Clair <
알림@github.com>
썼다:

@thockin https://github.com/thockin re: 역 DNS, 그냥 흔들자
우리의 손에 대한 요구 사항을 고려합니다.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

나는 DNS가 RC가 아닌 명목 서비스에 연결되는 것을 좋아합니다.

내부적으로 단순 지수의 애로점은 무엇이었습니까? 피 > 5000?

----- 원본 메시지 -----

내가 상류로 헤엄치는 것은 거리가 멀다 - 충분한 앱이 실제로 DNS가
이 방식으로 작동하면 이 방식으로 작동할 수 있습니다.

스케치:

복제 컨트롤러 만들기 R은 DNS 이름 "$R.rc"를 만듭니다.
해당 RC "아래"에 있는 포드 IP 풀. 각 포드 P는 DNS 이름을 얻습니다.
"$P.$R.rc". 그러나 P는 무엇입니까? 단순한 지수일 수 있지만
우리를 내부적으로 세게 물었습니다. GenerateName과 같은 임의의 문자열일 수 있습니다.
그러나 그들은 포드 사망/재시작에서 살아남아야 합니다(아마도 포드 호스트 이름은
성냥?).

2015년 3월 10일 화요일 오전 7:59, Clayton Coleman [email protected]
썼다:

내 경험(및 아마도 Tim의 경우)은 대부분의 클러스터가
오늘날 소프트웨어는 다음을 기대합니다.

• 각 노드에는 안정적인 ID가 있습니다.
• 해당 ID는 DNS 이름입니다.
• 기본 ID의 IP가 안정적일 필요는 없습니다.
• 노드는 안정적인
  ID(DNS) 또는 해당 공용 IP
• 클러스터된 소프트웨어 중 일부는 노드의 IP를 클라이언트로 예상합니다.
  자신을 다른 사람에게 알릴 수 있는 IP와 일치하도록 도달
  클러스터 및 해당 IP에 연결할 수 있습니다.

----- 원본 메시지 -----

@timothysc re: 역 DNS - 역 DNS가 무엇입니까? 소스-IP
사이? 그 중 어느 것도 kube에서 작동하지 않습니다. 서비스를 통한 연결은
프록시 처리되므로 source-ip가 처음부터 작동하지 않습니다(고칠 수 있음).

나는 ZK를 모른다 - 그들이 역으로 얻으려고 하는 것을 설명할 수 있니?
DNS? 매우 연약한 가정처럼 보입니다.

2015년 3월 9일 월요일 오전 9:05, Timothy St. Clair <
알림@github.com>
썼다:

@thockin https://github.com/thockin re: 역 DNS, 그냥 흔들자
우리의 손에 대한 요구 사항을 고려합니다.

ZK는 다른 많은 분산 시스템과 마찬가지로 이것이 없으면 중단됩니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

특수 케이스 1:1 VIP에 +1. 나는 그것이 일반적인 경우라고 생각합니다.

나는 여전히 DNS 매핑을 동적으로 변경하는 것에 대해 걱정하고 있습니다. 나는 그것이 필요하지 않은 접근 방식을 선호합니다.

대안을 평가할 때 염두에 두어야 할 점은 결국 동일한 역할을 하는 2개의 포드가 동시에 공존할 필요가 있을 것이라고 100% 확신한다는 것입니다. 따라서 역할은 개체 이름이나 고유해야 하고 포드 생성 시 고정적으로 설정되어야 하는 다른 것에 연결될 수 없습니다.

역할 할당 메커니즘을 복제 컨트롤러에 연결하면 롤링 업데이트, 카나리아 등을 거의 배제할 수 있습니다. 가능하면 이를 피하고 싶습니다.

@smarterclayton 단순 인덱스는 규모로 인해 문제가 되지 않습니다. 바로 모델 때문입니다. 몇 분 전에 내 의견을 참조하십시오. 포드 및 RC ID와 독립적으로 동적으로 할당할 수 있는 경우 간단한 인덱스를 사용하는 것이 좋습니다.

문제 중 하나가 시스템 지향적인 가정이라는 점을 감안할 때 여기에서 Linux가 우리를 위해 할 수 있는 일이 있습니까? 예를 들어, 서비스 VIP용 컨테이너에 IP 별칭을 만들 수 있습니까?

얘들 아,

이번 주 내내 외출 중입니다. 이것은 정말 재미있는 대화이지만,
내가 가진 시간보다 더 많은 시간. 나는 앉아서 진짜로 토론하게 되어 기쁩니다.
다음주 시간.

2015년 3월 10일 화요일 오후 3시 56분, Brian Grant 알림 @github.com
썼다:

문제 중 하나가 시스템 지향적 가정이라는 점을 감안할 때
여기에서 Linux가 우리를 위해 무엇을 할 수 있습니까? 예를 들어 IP를 만들 수 있습니까?
서비스 VIP의 컨테이너에 별칭 또는 기타가 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

나는 다음 2일 동안 주머니가 없다 - 다음 주이다.

2015년 3월 10일 오후 11시 33분에 Tim Hockin [email protected]이 다음과 같이 썼습니다.

얘들 아,

이번 주 내내 외출 중입니다. 이것은 정말 재미있는 대화이지만,
내가 가진 시간보다 더 많은 시간. 나는 앉아서 진짜로 토론하게 되어 기쁩니다.
다음주 시간.

2015년 3월 10일 화요일 오후 3시 56분, Brian Grant 알림 @github.com
썼다:

문제 중 하나가 시스템 지향적 가정이라는 점을 감안할 때
여기에서 Linux가 우리를 위해 무엇을 할 수 있습니까? 예를 들어 IP를 만들 수 있습니까?
서비스 VIP의 컨테이너에 별칭 또는 기타가 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

다음 주에 +1, 아마도 행아웃일 것입니다.

관련 주제 팝업으로 인해 이 스레드를 다시 파고듭니다(https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902). , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, #6393).

1. 단일 또는 명목 집합의 일부일 수 있는 개별 포드에 네트워크 ID(DNS 이름 및/또는 IP 주소)를 어떻게 할당합니까?
2. 파드 내의 컨테이너에 아이덴티티를 어떻게 전달할 것인가?

행아웃을 예약해야 할까요, 아니면 주간 커뮤니티 행아웃을 사용해야 할까요?

또한 https://github.com/openshift/mongodb/pull/14 멤버쉽 세트 초기화를 위한 일반 패턴의 프로토타입을 시작하고 있습니다(컨테이너나 라이브러리에 넣을 수 있는 것 또는...)

@danmcp @mfojtik

----- 원본 메시지 -----

관련 주제 팝업으로 인해 이 스레드를 다시 파고듭니다.
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393).

1. 네트워크 ID(DNS 이름 및/또는 IP 주소)를 할당하는 방법
   싱글톤 또는 명목 집합의 일부일 수 있는 개별 포드는 무엇입니까?
2. 파드 내의 컨테이너에 아이덴티티를 어떻게 전달할 것인가?

행아웃을 예약해야 할까요, 아니면 주간 커뮤니티 행아웃을 사용해야 할까요?

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, 그 퍼즐의 한 조각은 마스터 선거 #1542입니다.

예, 우리는 그것에 대해 논의했습니다. 자체 선택을 수행할 수 있는 대부분의 클러스터의 경우 멤버십이 가장 중요하지만(Kube 엔드포인트에서 멤버십 감지, 클러스터에 적용) 항상 다른 방식으로 접근합니다. 예를 들어, Cassandra는 기본적으로 Kube를 멤버십에 대한 외부 소스로 사용하므로 SEP이며 이는 리더십 선출을 더 쉽게 만듭니다. 회원이 지연되는 방식에 따라 회원이 플랩되면 파티션으로 끝날 수 있다고 생각합니다.

mongo의 경우 각 구성원에게 연락하여 기존 클러스터에 가입하거나 새 클러스터를 형성하도록 합니다. 여러 클러스터가 존재하는 경우 클러스터를 악화시키고 싶지 않습니다.

서비스 IP를 컨테이너와 통신하는 문제는 외부 IP를 VM에 통신하는 것과 유사합니다( https://cloud.google.com/compute/docs/networking). GCE는 외부 주소를 내부 주소로 변환하고 외부 주소는 메타데이터 서버를 통해 전달됩니다. http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS도 비슷합니다: http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton mongo 프로토타입 PR을 업데이트했습니다: https://github.com/openshift/mongodb/pull/17

이제 replicaSet을 초기화하는 원샷 파드를 사용하고 있습니다.

답장. 이 메커니즘을 복제/샤드 컨트롤러에 연결:

복제 컨트롤러 및/또는 포드 개체 이름에 DNS 이름을 시도하면 현재 위치 업데이트 모델이 강제 실행됩니다. 완전히 다른 종류의 "인플레이스(in-place)" 롤링 업데이트를 구현하는 동시에 단일 컨트롤러로 여러 템플릿을 동시에 지원해야 합니다. 또한 일부 종류의 업데이트(새 호스트로 이동 포함)를 수행하려면 포드를 삭제한 다음 동일한 이름으로 다시 생성해야 하므로 새로운 호스트를 추가하는 접근 방식에 비해 가동 중지 시간이 늘어납니다. 오래된 것을 버리기 전에 포드.

토큰 풀 아이디어는 훌륭합니다. 나는 그것이 RC에서 분리되어야한다고 생각합니다.

이것은 우리가 하나를 추가한다면 더 높은 수준의 컨트롤러에 연결될 수 있습니다. #1743 및/또는 #503에 대해 더 자세히 설명합니다.

이것은 #1743에서 제안한 DeploymentController와 실제로 결합되어서는 안됩니다. 여러 독립 릴리스 트랙의 시나리오나 제안된 이름 교체 롤링 업데이트와 같은 다른 메커니즘으로 롤아웃을 제어하려는 경우에는 작동하지 않습니다. 비슷한 이유로 DNS 이름을 pod/RC/DC 개체 이름에 연결하지 않습니다.

그래서 우리는 서비스의 일부 또는 완전히 별도의 컨트롤러로 돌아갑니다. 아마도 끝점 컨트롤러가 서비스 끝점에 인덱스를 할당할 수 있습니까? Endpoints 자체가 이 데이터를 기록하기에 충분히 신뢰할 수 있습니까? 손실된 경우 모든 포드가 다시 인덱싱됩니다.

포드의 컨테이너에 대한 ID 통신을 용이하게 하려면(예: #2316에서 논의된 환경 변수 대체를 통해) 하위 리소스를 통해 역할이 할당/할당 해제될 때 포드에 필드를 설정하는 것이 유용할 것입니다. 내구성 문제도 해결할 수 있습니다.

명목 인스턴스(#6666)를 위해 DNS 스키마에 공간을 예약해야 합니다.

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406에 따라 포드 IP를 사용하고 명목 인스턴스에 대해 DNS를 다시 매핑할 수 있다는 것을 구입할 수 있습니다.

또한 2월에 1.0 마일스톤에서 제거했지만(roadmap.md는 아님) #6393의 논의에 따르면 다시 추가될 수 있습니다.

@thockin 제안: DNS(PTR 레코드)를 사용한 역방향 조회는 포드 IP에서 명목 DNS 이름으로 이동하는 합리적인 방법처럼 보입니다.
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

예, 표준 이름 도구를 통해 "나는 누구인가"를 정말 쉽게 만들 수 있습니다.

2015년 4월 10일 오후 8시 11분에 Brian Grant [email protected]이 다음과 같이 썼습니다.

@thockin 제안: DNS(PTR 레코드)를 사용한 역방향 조회는 포드 IP에서 명목 DNS 이름으로 이동하는 합리적인 방법처럼 보입니다.
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

/구독하다

더 이상 여기의 요구 사항을 이해하고 있는지 잘 모르겠습니다.

서비스와 파드 사이에는 고유한 N 대 M 관계가 있습니다.
시스템의 디자인. 역방향 DNS와 같은 것들은 일반적으로 다음을 얻을 것으로 기대합니다.
단일 응답: 파드의 IP가 주어지면 정식 이름을 얻습니다. 작성된 모든 문서
DNS에 대해 "여러 역방향 레코드를 반환하지 마십시오"라고 말합니다. 포드가 될 수 있기 때문에
N 서비스에서 이 단일 응답은 실제로 서비스와 관련될 수 없습니다. 우리
정식 이름에 대해 역방향 조회를 수행한 다음 그에 대한 TXT 조회를 수행할 수 있습니다.
"어떤 서비스를 받고 있는지"에 대한 이름이지만 유지하기 어렵고
어쨌든 본질적으로 사용자 정의 프로토콜입니다.

내가 RC에 명목상의 무엇이든 첨부하려고 생각한 이유는 그것이
보다 구체적인 관계. 하지만 그렇지도 않습니다. 포드는 다음으로 생성할 수 있습니다.
하나의 RC는 고아이고 다른 RC에 의해 채택되고 그에 의해 파괴됩니다. 또는
수동으로 파괴

그래서 나는 우리가 이것으로 무엇을 하고 싶은지 잘 모르겠습니다.
서비스의 포드는 "아래"일 수 있습니다. 이는 끔찍하게 들립니다.

행동 요구 사항은 무엇입니까? 우리는 무엇을 달성하려고 합니다. 우리
DNS 및 헤드리스 서비스로 간단한 집합 의미를 제공할 수 있습니다. 그렇습니까
충분한? 그렇지 않다면 그 이유는 무엇입니까?

우리는 극단적으로 가서 SNAT/DNAT 포드에 iptables 규칙을 설정할 수 있습니다.
VIP에서 서로를 볼 수 있도록 서비스를 제공합니다. 예: 포드 세트 제공
(P1, P2, P3) VIP(V1, V2, V3)를 얻습니다. P1에서 V2로의 트래픽은
V1 등에서 오는 것으로 보입니다. 클라이언트는 V{1,2,3}에 액세스합니다. 근데 뭐
문제가 해결됩니까? 안정적인 IP를 주는데 이거 아닌가
헤드리스 서비스 전반에 대한 일반적인 문제?

2015년 4월 21일 화요일 오후 2:17 David Oppenheimer < 알림 @github.com

썼다:

/구독하다

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

목표는 매우 구체적이었습니다. 실제 클러스터형 시스템에는 노드 오류가 있는 경우에도 계속될 것으로 예상되는 "ID"가 있는 구성원이 있습니다. 해당 ID는 영구 디스크 또는 "이름"에 연결될 수 있지만 다른 시스템에 대한 식별 이름은 변경할 수 없습니다.

예를 들어 사육사는 노드당 ID를 갖습니다. 해당 ID는 클러스터 구성원에서 안정적으로 유지되어야 합니다. 자신이 host1이라고 생각하는 두 개의 포드가 _가능_할 수 있지만 host1이 사라지면 host435가 이를 대체할 수 없습니다. 한 장소에서 다른 장소로 이동하는 해당 포드에 대해 재사용된 영구 디스크가 있을 수 있지만 그럴 때 포드는 해당 ID를 정의할 수 있어야 합니다. 그러나 우리는 그 #을 할당하는 방법이 필요합니다.

명목 서비스에 대해 생각하는 방식은 완전히 유연한 수백 가지 사용 사례가 아니라 항상 소규모(3/5/7) 구성원으로 기존 소프트웨어를 활성화하는 것이라고 생각합니다. 아마도 우리는 이 토론에서 그 사용 사례를 분리해야 할 것입니다.

2015년 4월 22일 오전 1시 59분에 Tim Hockin [email protected] 은 다음과 같이 썼습니다.

더 이상 여기의 요구 사항을 이해하고 있는지 잘 모르겠습니다.

서비스와 파드 사이에는 고유한 N 대 M 관계가 있습니다.
시스템의 디자인. 역방향 DNS와 같은 것들은 일반적으로 다음을 얻을 것으로 기대합니다.
단일 응답: 파드의 IP가 주어지면 정식 이름을 얻습니다. 작성된 모든 문서
DNS에 대해 "여러 역방향 레코드를 반환하지 마십시오"라고 말합니다. 포드가 될 수 있기 때문에
N 서비스에서 이 단일 응답은 실제로 서비스와 관련될 수 없습니다. 우리
정식 이름에 대해 역방향 조회를 수행한 다음 그에 대한 TXT 조회를 수행할 수 있습니다.
"어떤 서비스를 받고 있는지"에 대한 이름이지만 유지하기 어렵고
어쨌든 본질적으로 사용자 정의 프로토콜입니다.

내가 RC에 명목상의 무엇이든 첨부하려고 생각한 이유는 그것이
보다 구체적인 관계. 하지만 그렇지도 않습니다. 포드는 다음으로 생성할 수 있습니다.
하나의 RC는 고아이고 다른 RC에 의해 채택되고 그에 의해 파괴됩니다. 또는
수동으로 파괴

그래서 나는 우리가 이것으로 무엇을 하고 싶은지 잘 모르겠습니다.
서비스의 포드는 "아래"일 수 있습니다. 이는 끔찍하게 들립니다.

행동 요구 사항은 무엇입니까? 우리는 무엇을 달성하려고 합니다. 우리
DNS 및 헤드리스 서비스로 간단한 집합 의미를 제공할 수 있습니다. 그렇습니까
충분한? 그렇지 않다면 그 이유는 무엇입니까?

우리는 극단적으로 가서 SNAT/DNAT 포드에 iptables 규칙을 설정할 수 있습니다.
VIP에서 서로를 볼 수 있도록 서비스를 제공합니다. 예: 포드 세트 제공
(P1, P2, P3) VIP(V1, V2, V3)를 얻습니다. P1에서 V2로의 트래픽은
V1 등에서 오는 것으로 보입니다. 클라이언트는 V{1,2,3}에 액세스합니다. 근데 뭐
문제가 해결됩니까? 안정적인 IP를 주는데 이거 아닌가
헤드리스 서비스 전반에 대한 일반적인 문제?

2015년 4월 21일 화요일 오후 2:17 David Oppenheimer < 알림 @github.com

썼다:

/구독하다

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

어떤 종류의 컨트롤러는 포드의 일부 필드를 동적으로 설정/해제할 수 있습니다. 그것은 단지 포드나 RC 아이덴티티와 융합될 수 없습니다. 네트워크 ID를 포드 또는 RC ID에 묶는 것은 완전히 깨졌습니다.

나는 일반 또는 헤드리스 서비스에 대해 역방향 DNS 조회를 작동시키려고 시도하지 않을 것이며, 다른 유형의 서비스를 전혀 제한할 필요가 없는 포드당 최대 하나의 명목 서비스를 부과하는 것이 비합리적이라고 생각하지 않습니다. .

장기적으로 푸시하고자 하는 DNS 제한 사항이 많이 있습니다(캐시 무효화, 긴 폴링 지원 등). 여러 PTR 레코드는 해당 목록에 추가된 또 다른 항목일 수 있습니다.

다른 대안은 명목 서비스의 각 포드에 서비스 IP를 부여한 다음 발생하는 문제를 해결할 수 있다는 것입니다.

----- 원본 메시지 -----

어떤 종류의 컨트롤러는 포드의 일부 필드를 동적으로 설정/해제할 수 있습니다. 그것
포드 또는 RC ID와 병합할 수 없습니다. 네트워크 ID 연결
포드 또는 RC ID가 완전히 손상되었습니다.

일반 또는 헤드리스에 대해 역방향 DNS 조회가 작동하도록 하려고 하지 않습니다.
최대 하나의 명목상을 부과하는 것이 불합리하다고 생각하지 않습니다.
포드당 서비스 -- 다른 유형의 서비스를 제한할 필요가 없습니다.
모두.

장기적으로 추진하고자 하는 많은 DNS 제한 사항이 있습니다.
(캐시 무효화, 긴 폴링 지원 등). 여러 PTR 레코드
아마도 그 목록에 추가된 또 다른 항목일 것입니다.

다른 대안은 각 포드에 서비스 IP를 부여할 수 있다는 것입니다.
명목상의 서비스를 제공한 다음 발생하는 문제를 해결합니다.

이러한 많은 서비스는 자신이 가진 IP(이름)가 연결된 IP로 해석될 것으로 예상합니다. 따라서 172.1.1.1에서 X에 연결하면 X는 172.1.1.1로 생각합니다. 그것이 모든 소프트웨어가 아니라 일부입니다. 일반적으로 DNS 이름이므로 IP가 아래에서 변경될 수 있습니다.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

이 모든 것이 저에게는 아직 약간 추상적입니다.

실제 클러스터형 시스템에는 "ID"가 있는 구성원이 있습니다.
노드 오류가 있는 경우에도 계속될 것으로 예상됩니다. 그 아이덴티티
영구 디스크 또는 "이름"에 연결될 수 있지만 이름은
다른 시스템으로 식별할 수 없습니다.

이것은 요구 사항이 아닙니다. 구현이 불가능할 정도로 모호합니다.

예를 들어 사육사는 노드당 ID를 갖습니다. 그 아이덴티티는 남아있어야 한다
클러스터 멤버쉽에서 안정적

신원이란 무엇입니까? IP 주소? 소프트웨어에 전달된 문자열 플래그?
그리고 환경 변수? zk 프로세스는 자체 ID가 무엇인지 어떻게 학습합니까?

일종의 컨트롤러가 포드의 일부 필드를 동적으로 설정/해제할 수 있습니다.

그러면 해당 포드가 다시 시작되지만 여전히 응답하지 않습니다.
어떤 필드, 어떤 값, 어떤 논리를 포드에 알릴 것인지에 대한 질문은 무엇입니까?

주석을 명령줄 플래그로 확장하는 것과 같은 것을 볼 수 있습니다.
(env vars에 대해 논의하는 것처럼) 또는 env vars로. 예
컨트롤러 쓰기 주석["zookeeper.com/index"] = 9, 변환
$.metdata["zookeeper.com/index"]를 ZK_INDEX 환경으로 하지만 나는 이것을 만들고 있다.
정확히 사육사(또는
무엇이든) 필요합니다.

최대 하나의 명목 서비스를 부과하는 것이 불합리하다고 생각하지 않습니다.
포드당

나는 그러한 제한을 구현하기 어려울 것이라고 생각합니다. 시스템이 그렇다
느슨하게 결합되고 이러한 제한을 부과하는 것이
문제를 해결할 뿐입니다.

명목 서비스의 각 포드에 서비스 IP를 부여할 수 있습니다.

여기에서 시작했지만 ...

이러한 서비스 중 상당수는 자신이 보유한 IP(이름)를 기대합니다.
연결하는 IP로 해석됩니다. 따라서 172.1.1.1에서 X에 연결하면
그러면 X는 172.1.1이라고 생각합니다.

서비스 IP는 다음과 같이 더 깊이 있는 작업을 수행하지 않는 한 이를 충족하지 않습니다.
SNAT/DNAT로 언급했습니다. 그리고 그마저도 실질적인 단점이 있습니다.

나는 목을 아프게 하려는 것이 아니라 단지 우리에게 아주 약간의 통증이 있다는 것뿐입니다.
1.0까지의 시간이 필요합니다.
개념 증명조차도 제대로 구현하지 못합니다.

나는 우리가 경험하고 싶은 것을 정확히 찾아내서 볼 수 있도록 노력하고 있습니다.
우리가 구현할 수 있는 것. DNS에 대한 반복적인 참조를 감안할 때
여기서 무슨 일이 일어나고 있는지 알 때까지 DNS 재작업을 중단하십시오.

2015년 4월 22일 수요일 오전 10시 12분, Clayton Coleman [email protected]
썼다:

----- 원본 메시지 -----

어떤 종류의 컨트롤러는 일부 필드를 동적으로 설정/해제할 수 있습니다.
꼬투리. 그것
포드 또는 RC ID와 병합할 수 없습니다. 네트워크 묶기
신원
포드 또는 RC ID가 완전히 손상되었습니다.

일반 또는 헤드리스에 대해 역방향 DNS 조회가 작동하도록 하려고 하지 않습니다.
최대 1개의 서비스를 부과하는 것이 불합리하다고 생각하지 않습니다.
명사 같은
포드당 서비스 -- 다른 유형의 서비스를 제한할 필요가 없습니다.
모두.

우리가 장기적으로 추진하고자 하는 많은 DNS 제한 사항이 있습니다.
운영
(캐시 무효화, 긴 폴링 지원 등). 여러 PTR
기록
아마도 그 목록에 추가된 또 다른 항목일 것입니다.

다른 대안은 각 포드에 서비스 IP를 부여할 수 있다는 것입니다.
명목상의 서비스를 제공한 다음 발생하는 문제를 해결합니다.

이러한 서비스 중 상당수는 자신이 보유한 IP(이름)가 해결될 것으로 기대합니다.
그들이 연결하는 IP에 - 따라서 172.1.1.1에서 X에 연결하면 X
172.1.1.1이라고 생각합니다. 그것이 모든 소프트웨어가 아니라 일부입니다. 보통은
그러나 DNS 이름은 IP가 아래에서 변경될 수 있음을 의미합니다.

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

대부분의 다중 포트 예 는 클러스터형 시스템입니다. 예를 들어:
ZK : 구성 파일의 확인 가능한 호스트 이름 또는 IP 주소와 파일의 "id"(즉, 인덱스: 1, 2, 3, ...)

일부 DB도 살펴봐야 합니다.

우리가 무엇을 하든 모든 일에 효과가 있는 것은 아닙니다. 우리는 스위트 스폿을 찾기만 하면 됩니다.

----- 원본 메시지 -----

이 모든 것이 저에게는 아직 약간 추상적입니다.

실제 클러스터형 시스템에는 "ID"가 있는 구성원이 있습니다.
노드 오류가 있는 경우에도 계속될 것으로 예상됩니다. 그 아이덴티티
영구 디스크 또는 "이름"에 연결될 수 있지만 이름은
다른 시스템으로 식별할 수 없습니다.

이것은 요구 사항이 아닙니다. 구현이 불가능할 정도로 모호합니다.

예를 들어 사육사는 노드당 ID를 갖습니다. 그 아이덴티티는 남아있어야 한다
클러스터 멤버쉽에서 안정적

신원이란 무엇입니까? IP 주소? 소프트웨어에 전달된 문자열 플래그?
그리고 환경 변수? zk 프로세스는 자체 ID가 무엇인지 어떻게 학습합니까?

일종의 컨트롤러가 포드의 일부 필드를 동적으로 설정/해제할 수 있습니다.

그러면 해당 포드가 다시 시작되지만 여전히 응답하지 않습니다.
어떤 필드, 어떤 값, 어떤 논리를 포드에 알릴 것인지에 대한 질문은 무엇입니까?

주석을 명령줄 플래그로 확장하는 것과 같은 것을 볼 수 있습니다.
(env vars에 대해 논의하는 것처럼) 또는 env vars로. 예
컨트롤러 쓰기 주석["zookeeper.com/index"] = 9, 변환
$.metdata["zookeeper.com/index"]를 ZK_INDEX 환경으로 하지만 나는 이것을 만들고 있다.
정확히 사육사(또는
무엇이든) 필요합니다.

최대 하나의 명목 서비스를 부과하는 것이 불합리하다고 생각하지 않습니다.
포드당

나는 그러한 제한을 구현하기 어려울 것이라고 생각합니다. 시스템이 그렇다
느슨하게 결합되고 이러한 제한을 부과하는 것이
문제를 해결할 뿐입니다.

명목 서비스의 각 포드에 서비스 IP를 부여할 수 있습니다.

여기에서 시작했지만 ...

이러한 서비스 중 상당수는 자신이 보유한 IP(이름)를 기대합니다.
연결하는 IP로 해석됩니다. 따라서 172.1.1.1에서 X에 연결하면
그러면 X는 172.1.1이라고 생각합니다.

서비스 IP는 다음과 같이 더 깊이 있는 작업을 수행하지 않는 한 이를 충족하지 않습니다.
SNAT/DNAT로 언급했습니다. 그리고 그마저도 실질적인 단점이 있습니다.

나는 목을 아프게 하려는 것이 아니라 단지 우리에게 아주 약간의 통증이 있다는 것뿐입니다.
1.0까지의 시간이 필요합니다.
개념 증명조차도 제대로 구현하지 못합니다.

나는 우리가 경험하고 싶은 것을 정확히 찾아내서 볼 수 있도록 노력하고 있습니다.
우리가 구현할 수 있는 것. DNS에 대한 반복적인 참조를 감안할 때
여기서 무슨 일이 일어나고 있는지 알 때까지 DNS 재작업을 중단하십시오.

나는 그것이 현명하다고 생각합니다. 우리는 알려진 예제 세트를 푸는 데 특히 시간을 할애해야 합니다. kube/examples의 기존 예제뿐만 아니라 구체적인 예제(MongoDB 복제본 세트, Zookeeper, Mysql Master/Slave)에 활용할 수 있는 3가지가 있습니다. 아마도 작업 세션은 항목을 해시하고, 해결할 수 없는 문제에 대한 경계를 설정하고, 무엇이 남아 있는지 식별합니다.

분할 작업에 샤드 ID 번호를 할당하는 데에도 사용할 수 있으므로 이 기능의 이름을 변경하는 것이 좋습니다.

배치 작업은 요구 사항이 약간 다르기 때문에 별도로 유지하고 싶습니다.

사육사의 예: https://github.com/openshift/origin/pull/1965

명목 서비스 ish 요구사항의 예 https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

특히 Google 직원의 경우 방향이 아직 명확하지 않은 이유가 다소 혼란스럽습니다. Google은 수년 동안 Borg에서 스테이트풀(Stateful) 서비스를 실행해 왔으며 이러한 유형의 워크로드에 필요한 것이 무엇인지는 분명합니다.

• "shard"(동일하지 않은 복제본) 세트 중 하나가 현재 포드를 나타내는 안정적인 식별자입니다(borg에서는 "작업 번호" - 단순 정수). 이 식별자는 포드 일정 변경/다시 시작 시 일정하게 유지되어야 합니다.
• 어떤 방식으로든 안정적인 식별자를 사용하여 모든 "피어" 샤드를 열거하고 연결하는 방법(borg에서는 작업 번호와 함께 통통한 접두사)

.. 그리고 우리는 끝났습니다.

참고: 각 샤드에 대해 리소스 제외가 중요한 경우 오류/재시작 중에 파드 수명이 겹칠 가능성이 항상 있으므로 애플리케이션은 자체 분산 잠금을 수행해야 합니다(아마도 샤드 식별자를 기반으로 하는 etcd 잠금 사용). 잠재적인 이국적인 기능 확장은 중복/로드를 위해 각 샤드 내에서 둘 이상의 동일한 복제본을 허용하는 것입니다.

이것은 각 샤드에 대해 고유한 서비스/포트를 생성하고 replicas:1 로 복제 컨트롤러를 실행하여 지금 위조할 수 있지만 이와 같이 "수동으로" 많은 수의 샤드를 관리하는 것은 약간 서투릅니다.

Kubernetes에서 이것을 구현하는 자연스러운 방법은 다음과 같습니다.

• 파드는 자체 샤드 인덱스(정수)와 샤드의 총 수를 제공하는 추가 환경 변수를 얻습니다(또는 하향 API를 통해 통신할 수 있습니까?).
• ReplicationController는 "shards" 수(기본값: 1)를 가져오고 "replicas"는 "replicas within each shard"(기본값: 1)를 의미하도록 재해석됩니다. 복제본 세트를 축소할 때 끝에서 종료해야 합니다(샤드 인덱스를 연속적으로 유지하기 위해). "샤드"를 변경하려면 "총 샤드" 환경 변수를 업데이트하기 위해 제어된 포드를 계속해서 다시 시작해야 합니다.
• 서비스는 인접한 포트 범위를 일반 선택기와 암시적 "샤드 인덱스" 선택기에 매핑하는 유사한 "샤드" 수를 얻습니다.
• Pod는 SERVICE_PORT(또는 일부 새로운 env var?) + 샤드 인덱스 오프셋을 사용하여 다른 샤드를 찾을 수 있습니다.

위의 내용은 shards=1일 때 현재 동작으로 정상적으로 저하됩니다.

나는 일반적으로 이것에 동의합니다(그리고 당신이 말했듯이, 그것은 Borg에서 시간의 테스트를 제공했습니다), 비록 나는 샤드당 여러 복제본의 "이국적인 기능 확장"을 사용하지 말라고 조언하고 싶습니다(비록 우리는 아래에서 이와 같은 것이 필요할 수 있지만 마이그레이션 커버).

앞서 언급했듯이 이것은 정적 작업 할당이 있는 일괄 작업을 지원하기 위해 수행해야 하는 작업과 밀접하게 관련되어 있습니다(여기에서 "유형 1"이라고 부르는 것: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142)

RC를 변경한 경우(또는 새로운 기능을 추가한 경우) 조정해야 하는 다른 기능은 배포가 적합한 방식, 특히 다음과 같습니다.

롤링 업데이트를 수행하려면 어떻게 해야 합니까?

1. 일반 RC
2. PerNodeController
3. 샤딩된 RC
4. 일괄 작업?

단순한 RC에 대해서만 작동하는 배포에는 몇 가지 문제가 있다고 생각하기 때문에 각각에 대한 스트로우맨이 있을 때까지 배포 구현을 보류하고 싶을 수도 있습니다.

----- 원본 메시지 -----

나는 일반적으로 이것에 동의합니다.
Borg에서) "이국적인 기능을 사용하지 말라고 조언하지만
샤드당 여러 복제본의 확장"(아마도 무언가가 필요할 수 있지만
마이그레이션에 대한 커버 아래에서와 같이).

앞서 언급했듯이 이것은 우리가 해야 할 일과 밀접하게 관련되어 있습니다.
정적 작업 할당으로 일괄 작업 지원(내가 "유형 1"이라고 부른 것)
여기:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

인스턴스당 하나의 서비스, RC 및 영구 볼륨 클레임을 생성하는 것과 같은 여러 해결 방법이 있기 때문에 1.0에 대해 이(및 자동으로 생성된 영구 볼륨 클레임)의 우선 순위를 지정하지 않기로 결정했습니다.

Borg에서 조밀하고 정적으로 할당된 작업 인덱스가 매우 널리 사용되는 반면, 우리는 이러한 인덱스에 여러 가지 단점이 있다는 것을 알게 되었고 지난 몇 년 동안 대안을 개발하는 데 시간을 보냈습니다. 많은 문제는 인덱스가 작업 자체의 수명 주기 및 ID와 연결되어 있다는 사실에서 비롯됩니다. 이로 인해 여러 배포 전략, 마이그레이션, 동적 작업 관리 및 기타 여러 시나리오를 구현하기가 어렵습니다. 다른 복잡성은 사전 배포 각 작업에 대해 인덱스당 구성을 정적으로 생성하는 데서 비롯됩니다. 이는 인덱스 값당 하나의 RC를 생성하는 것과 같습니다. 그것은 누군가가 정말로 하고 싶은 일이라면 간단할 것입니다. 레이블은 여전히 ​​전체 세트를 분해하는 데 사용할 수 있습니다.

노드별/데몬 컨트롤러: 좋은 지적입니다. 조밀하게 할당된 인덱스는 이 경우에 좋지 않은 모델입니다. 예를 들어 노드가 영구적으로 사라지면 어떻게 합니까? 인덱스가 희박해집니다. 나는 우리가 그것을 지원하지 않는 것이 좋습니다.

일괄 작업: #1624에서 논의된 것처럼 현재 실행 중인 포드가 아닌 완료를 기반으로 인덱스를 할당하려고 합니다.

위에서 논의한 바와 같이 인덱스 할당은 영구 볼륨 클레임과 같은 관련 스토리지를 고려해야 합니다. ID는 네트워크 ID(DNS 이름 및/또는 IP 주소) 및 스토리지에서 비롯됩니다.

할당은 단일 복제 컨트롤러로 구동할 수 없습니다. 이것은 단순히 작동하지 않습니다. 복제 컨트롤러는 내구성 있는 개체가 아니며 카나리아, 롤링 업데이트, 여러 릴리스 트랙, 여러 클러스터 등에 대해 서비스당 여러 RC가 있을 것으로 예상합니다. 제안된 배포 개체(#1743)에도 올바른 범위가 없습니다. .

할당에는 3가지 대안이 있습니다.

1. 할당을 특별한 종류의 서비스와 연결합니다. 서비스에는 정확한 범위가 있습니다. (우리는 결국 지역 서비스도 필요하게 될 것입니다.) 이것은 일종의 일반 서비스와 헤드리스 서비스 간의 하이브리드입니다. 내가 처음에 이 메커니즘을 제안했을 때 구상했던 것입니다. 할당은 Endpoints에 기록됩니다. 엔드포인트 및/또는 헤드리스형 DNS는 모든 피어를 열거하는 확실한 방법입니다.
2. Service와 유사하지만 명목 서비스만을 위한 새로운 유형의 개체를 만듭니다. 할당을 기록하려면 새 개체도 필요할 것입니다. 이렇게 하면 API 표면이 불필요하게 확장됩니다(IMO).
3. '밀다'가 아니라 '당긴다'. Pod는 노드 제약 조건(선택기) 또는 제안된 반선호도 메커니즘 중 하나(https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529)가 있는 경우에도 명시적 컨트롤러 없이 호스트하도록 예약됩니다. 이는 서비스 VIP 할당과 유사합니다. 우리는 명목 서비스에 대해 비슷한 것을 할 수 있습니다. 포드(또는 포드 템플릿)는 인덱스를 할당하려는 인덱스 풀을 지정합니다. 일반 서비스와 달리 포드에 서로 다른 풀의 여러 인덱스를 할당할 필요는 없습니다. 할당은 포드 사양에 기록됩니다.
4. 장점: 사용자에게 더 간단합니다. 다른 개체가 필요하지 않습니다. 사용자가 할당할 수 있습니다.
5. 단점: 다른 종류의 서비스와 다릅니다.

PVC 할당은 이상적으로는 동일한 모델을 사용합니다.

포드 마이그레이션 #3949가 어떻게 조정될 것인지도 고려해 볼 가치가 있습니다. 컨테이너 상태를 전송하기 위해 교체되는 포드를 삭제하기 전에 교체 포드를 생성해야 합니다(MUST). 이것은 풀 모델을 약간 문제가 되게 만들 수 있습니다. 그럼에도 불구하고 할당 메커니즘은 마이그레이션을 인식해야 합니다.

기타 고려 사항:

1. 인덱스/ID를 피어에게 전달하는 방법. DNS는 분명한 답입니다.
2. 포드의 컨테이너에 인덱스/ID를 전달하는 방법입니다. 환경 변수, 역 DNS, ... 할당된 인덱스는 동적으로 변경되지 않지만 포드가 여전히 존재하는 동안 DNS 바인딩이 변경될 수 있습니다. 애플리케이션이 이미 다른 환경에서 작동할 것으로 예상하는 메커니즘을 선택하고 싶습니다. 더 광범위한 하향 API 논의(#386)와 마찬가지로 애플리케이션을 Kubernetes 특정 환경 변수에 결합하고 싶지 않지만 새로운 EnvVarSource env var 대체(#7936)는 이를 방지하는 데 도움이 됩니다.

나는 당신이 말한 것 중 일부에 동의하지 않지만 1.0 이후까지 이 논의를 계속하기 위해 기다리겠습니다.

질문을 하기 위해 이 오래된 스레드를 되살립니다. 복제 컨트롤러 명명 정책에 관심이 있습니까? 특히 위에서 설명한 대로 명목상의 이름을 지정합니다. 여기서 이 복제 컨트롤러가 제어하는 ​​모든 Pod에는 0001, 0002 ...와 같은 접미사 번호가 지정됩니다.

예제 사용 사례는 도메인 이름으로 이러한 포드 세트를 가리키는 nginx 로드 밸런서입니다. 따라서 포드가 왔다 갔다 할 때 도메인 이름은 항상 xxx-0001에서 xxx-000N으로 고정되어야 합니다.

@ravigadde 이 문제에 대한 내 마지막 댓글을 읽어주세요: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

RabbitMQ 컨테이너를 설정하는 동안 이 문제가 발생했습니다. Rabbit의 지속성은 호스트 이름에 따라 달라지므로 호스트 이름이 가변적이라는 것은 컨테이너를 다시 시작할 때 Mnesia 데이터베이스가 손실된다는 것을 의미합니다.

이미지 구성(직접 호스트 이름 및 Rabbit), ENV 변수 및 Downward API로 수정을 시도했습니다. 문제를 해결하기 위해 아무 것도 가져올 수 없었습니다. Rabbit은 여전히 ​​생성된 Pod 이름을 선택합니다. @mikedanese 제안에 따라 복제 컨트롤러 사용에서 전환하여 일시적으로 해결합니다.

내가 올바르게 이해한다면 celerey-rabbit 예제의 rabbitmq 포드(복제 컨트롤러로 생성)는 데이터가 영구 디스크에 저장되어 있어도 포드 오류가 발생하면 데이터를 잃게 됩니다. Rabbitmq 문서에서:

RabbitMQ는 시스템의 현재 호스트 이름을 사용하여 데이터베이스 디렉토리의 이름을 지정합니다. 호스트 이름이 변경되면 비어 있는 새 데이터베이스가 생성됩니다. 데이터 손실을 방지하려면 고정되고 확인 가능한 호스트 이름을 설정하는 것이 중요합니다.

지금은 이에 대한 좋은 솔루션이 없지만 마이그레이션 가능한 영구 디스크로 포드(rc에 바인딩되지 않음)를 만들 수 있습니다. 주의할 점은 포드는 특정 실패의 경우 수동으로 일정을 다시 잡아야 합니다. 그것이 내가 생각할 수 있는 유일한 호스트 이름을 정적으로 유지하는 방법입니다.

또는 시작 시 호스트 이름 dir을 안정적인 위치에 심볼릭 링크합니다.

2015년 7월 11일 오후 5시 26분에 Mike Danese [email protected]이 다음과 같이 썼습니다.

내가 올바르게 이해한다면 Rabbitmq 포드(복제
컨트롤러) clerey-rabbit에서
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
예제는 데이터가
영구 디스크. Rabbitmq 문서에서:

RabbitMQ는 현재 호스트 이름을 사용하여 데이터베이스 디렉토리의 이름을 지정합니다.
체계. 호스트 이름이 변경되면 비어 있는 새 데이터베이스가 생성됩니다. 피하기 위해
데이터 손실 고정되고 확인 가능한 호스트 이름을 설정하는 것이 중요합니다.

지금은 이에 대한 좋은 솔루션이 없지만 포드를 만들 수 있습니다(
rc에 바인딩됨) 마이그레이션 가능한 영구 디스크가 있는 경우, 주의 사항은 포드입니다.
특정 실패의 경우 수동으로 일정을 조정해야 합니다. 그게
내가 생각할 수 있는 유일한 방법은 호스트 이름을 정적으로 유지하는 것입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

이것이 호스트 이름이 포드 이름에서 파생되어서는 안되는 이유의 예입니다 -- #4825

약간의 킥을 주기 위해:

해결해야 할 몇 가지 근본적인 문제가 있습니다.

1. 일부 구성 요소에는 디스크의 저장소에 연결된 포드당 고유 ID가 있어야 합니다.
   
   
   
   1. 추가 주름으로, 그 중 일부(경우에 따라 사육사)에는 호스트 이름이 해석 가능하고 일치해야 합니다.
   
   
2. 확장된 일부 구성 요소에는 포드별로 다른 영구 저장소가 있어야 합니다(포드는 포드별로 다른 PVC를 가리키고 ID에 다시 연결됨).
   
   
   
   1. 때때로 이러한 볼륨은 확장 시 필요에 따라 생성되어야 합니다.
   
   
   2. 때때로 해당 볼륨은 풀에서 재사용되어야 하며 다시 생성되지 않아야 합니다.
   
   
3. 일부 구성 요소는 할당된 개별 ID를 추적하는 것이 비실용적인 경우 수만 개의 인스턴스로 확장될 수 있습니다.
   
   
   
   1. 명목에 대한 대부분의 사용은 아마도 포드의 2-7개 인스턴스 사이일 것입니다(가장 최근의 확장 가능한 DB, 대부분의 샤딩된 다중 마스터 설정)
   
   
4. 일부 구성 요소는 자체 마스터 선택을 구현할 필요가 없지만 ID 중 하나를 임의적으로 만들어 플랫폼에서 관리하도록 합니다(ID 1이 마스터가 됨).
5. 이러한 문제를 해결할 때 사용자는 여전히 포드에 대한 변경 사항을 롤아웃(배포를 통해)하고 모든 ID가 보존되거나 재할당되도록 해야 합니다.

이 모든 것이 반드시 동일한 솔루션에서 해결되어야 하는 것은 아닙니다. 예를 들어, 소규모 클러스터 ID(2-7)와 대규모 클러스터 ID(>7) 사이에는 상당한 차이가 있다고 생각합니다. 예를 들어, 큰 경우 해당 소프트웨어는 격차에 대해 덜 우려하거나 기존 합의/멤버십 프로토콜이 있습니다. 작은 경우에는 소프트웨어가 ID를 설정하는 데 더 많은 도움이 필요합니다. 이를 클라우드 네이티브(>7) 및 기존 클러스터형(2-7) 소프트웨어로 구분합니다.

1a, 1b, 2a에 동의합니다. 2b는 다른 문제처럼 들리지만 솔루션은 동일한 패턴을 재사용할 수 있습니다.

규모 (3)은 주로 하나의 서비스와 인스턴스당 RC에 대한 해결 방법이 적절하지 않다는 것을 시사한다고 생각하지만 클라우드 네이티브와 그렇지 않은 것의 차이에는 동의합니다.

마스터 선거(4)는 별도로 처리할 수 있습니다.

또한 (5)에 동의합니다.

이 시점에서 대부분의 설계 요구 사항이 명확하다고 생각합니다.

남은 설계 질문:

I. VIP를 할당하거나 IP 변경을 허용합니까? VIP는 현재 시스템을 통해 검색할 수 없기 때문에 컨테이너가 Linux를 통해 자체 IP를 검색할 수 있어야 하는지 여부는 이것과 밀접하게 관련되어 있습니다. 나는 그들이 그들의 IP를 발견할 수 있어야 한다고 가정하지만 pod IP(#12595)와 같이 하향 API를 사용할 수 있습니다. IP 변경을 허용하면(포드 IP 사용으로 인해) DNS TTL 및 캐싱 "버그"로 인해 IP 변경 속도가 제한됩니다. 그러나 언젠가는 포드 IP를 마이그레이션할 수 있도록 만들 계획이므로(#3949) IP 변경이 영구적인 것은 아닙니다.

Ⅱ. 푸시(포드로) vs. 풀(포드에서). 서비스와 RC는 의도적으로 포드에 느슨하게 연결되므로 둘 다 "푸시" 모델을 사용합니다. 명목 서비스는 본질적으로 포드 ID에 더 많이 연결됩니다(영구적으로는 아니지만 포드는 교체 가능해야 함). 결과적으로 푸시 모델에 대한 동기 부여가 덜한 것으로 보입니다. 스케줄링, esp와 같은 할당의 다른 경우. 영구 볼륨에 대한 영구 볼륨 클레임과 같은 배타적 바인딩은 "풀(pull)"이라고도 하는 요청/확인 모델을 사용합니다. 그것이 현재 내가 명목상의 서비스에 대해 선호하는 모델입니다.

(나)에 대해 의견이 있는 사람이 있습니까?

마스터 선택은 #1542이며 HA 구현의 일부로 논의되고 있습니다(예: #12884).

밀고 당기는게 무슨말인지 모르겠네요.

나는 이 문제의 대부분을 다시 읽었으며
해결책. 우리는 다음과 같은 다리를 구축하기 위해 일련의 기능이 필요합니다.
이러한 종류의 앱.

일단 포드가 실행되면 실제로 할 수 없다는 공리로 시작하겠습니다.
실행 중인 포드를 변경합니다. 여기에는 몇 가지 예외가 있습니다(예: 가상
파일 시스템 내용) 그러나 중요해 보이는 것들(env vars, IP,
hostname) 무엇으로 시작하든 막히게 됩니다.

나는 또한 느슨한 결합이
서비스 및 Pod는 유지, 우리가 이야기하는 것을 실제가 아닌 것으로 만듭니다.
서비스. Pod는 서비스가 앞에 있는 것을 실제로 알지 못합니다. 우리가 변한다면
즉, 더 이상 서비스가 아닙니다.

나는 의식의 흐름을 따라가서 냄새가 나지 않는 것을 볼 것입니다.

아이디어 1: ThingPools 및 패치.

새로운 API 객체 또는 다음의 풀을 정의할 수 있는 것을 정의하십시오.
것들. 물건이란? Thing은 문자열(또는 JSON blob)입니다.
열거형이 있습니다. 사물과 사물의 풀을 만들 수 있습니다.
사용할 수 있습니다. 사물 유형에는 VUID(호스트 이름), 문자열, VIP가 포함됩니다.

생성 작업에 전달할 수 있는 새 API 구성을 정의합니다.
반점. 패치는 적용 중인 개체를 패치하는 방법에 대한 지침입니다.
만들어진. 패치 옵션 중 하나는 "ThingPool에서 할당"입니다.

이것들을 합치려면:

ThingPool 정의 { meatadata.name: my-quorum-hostnames, 유형: VUID,
autogenerate: 5, } // 5개의 유효한 VUID 풀을 생성합니다.

RC 정의 { 복제본: 5 ...}

RC의 생성(POST)에서 Patch: { what:
"podTemplate.spec.containers[*].metadata.VUID", 풀: "my-quorum-hostnames"
}

POST 작업은 RC에 패치를 적용합니다 - 하나의 VUID 할당
ThingPool의 컨테이너당 포드가 죽고 다시 생성될 때마다
VUID가 풀로 반환되고 시작될 다음 포드가 VUID를 가져옵니다.

이것을 사용하여 문자열 풀("0" ~ "99")을 생성하고
그것들을 환경 변수에 넣습니다. 이를 사용하여 VIP 풀을 할당하고
그런 다음 해당 VIP를 포드에 할당합니다(새로운 기능이 될 것입니다 - 내구성 포드
IP - 이것이 어떻게 확장되는지 확실하지 않습니다. :) 다음의 풀을 생성할 수 있습니다.
PersistentVolumeClaim은 각 포드가 사용하는 클레임 ​​볼륨의 이름을 지정하고 패치합니다.

이 아이디어는 여러 면에서 불완전하지만
포드 세트를 완전히 정의하지 않고 포드 세트에 대한 아이디어.

아이디어 2: 포드 세트를 정의합니다. 서비스인 척 하지 마세요. 더 가깝다
보그 잡으로. RC와 비슷하지만 포드에 순서를 할당합니다.
컨트롤 - 샤드 번호. VUID 풀을 제어합니다(그러나 우리는
사용자가 설정할 수 있는 호스트 이름, 흠...).

더 많은 아이디어가 있다고 생각했지만 그렇지 않습니다. 나는 추상화와 씨름하고 있다
및 구현 - 우리가 할 수 없는 추상화를 정의하는 것은 무의미합니다.
구현하다. 명목상의 VIP는 훌륭하게 들리지만
iptables의 한계 포드 세트에 안정적인 호스트 이름 세트 제공
세트에 대한 스토리지 세트와 함께 가장 중요한 것 같습니다.
꼬리에 뜨거운 꼬투리.

2015년 8월 18일 화요일 오후 7시 28분, Brian Grant 알림 @github.com
썼다:

1a, 1b, 2a에 동의합니다. 2b는 다른 문제처럼 들리지만
아마도 솔루션은 동일한 패턴을 재사용할 수 있습니다.

규모 (3)은 주로 하나의 서비스에 대한 해결 방법과
인스턴스당 RC는 적절하지 않지만
클라우드 네이티브 vs.

마스터 선거(4)는 별도로 처리할 수 있습니다.

또한 (5)에 동의합니다.

이 시점에서 대부분의 설계 요구 사항이 명확하다고 생각합니다.

남은 설계 질문:

I. VIP를 할당하거나 IP 변경을 허용합니까? 이것과 밀접하게 관련되어 있는지 여부
컨테이너는 Linux를 통해 자체 IP를 검색할 수 있어야 합니다.
VIP는 현재 시스템을 통해 검색할 수 없기 때문입니다. 나는 그들이 할 것이라고 가정합니다
그들의 IP를 발견할 수 있어야 하지만 하향 API를 사용할 수 있습니다.
포드 IP 사용(#12595 https://github.com/kubernetes/kubernetes/pull/12595).
IP 변경을 허용하면(포드 IP 사용으로 인해) 속도에 제한이 있음을 의미합니다.
DNS TTL 및 캐싱 "버그"로 인한 IP 변경. 어느 순간 우리는
또한 포드 IP를 마이그레이션할 수 있도록 만들 계획입니다(#3949
https://github.com/kubernetes/kubernetes/issues/3949), 따라서 IP 변경
영원하지 않을 것입니다.

Ⅱ. 푸시(포드로) vs. 풀(포드에서). 서비스 및 RC는
의도적으로 포드에 느슨하게 연결되므로 둘 다 "푸시"를 사용합니다.
모델. 명목 서비스는 본질적으로 포드 아이덴티티에 더 연결됩니다.
(영구적이지는 않지만 -- 포드는 교체 가능해야 함). 결과적으로 나는 본다
푸시 모델에 대한 동기 부여가 적습니다. 다음과 같은 기타 할당 사례
일정, 특히. 영구 볼륨 클레임과 같은 배타적 바인딩
영구 볼륨의 경우 "풀(pull)"이라고도 하는 요청/확인 모델을 사용합니다. 그것은 현재
명목상의 서비스를 선호하는 모델.

(나)에 대해 의견이 있는 사람이 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

나는 아마도 당신이 생각하는 것처럼 진정한 총선을 의미하지 않았을 것입니다.
인스턴스 세트를 초기화해야 하는 기능을 구축할 때
(명시적으로 조정하지 않고)
일반적으로 클러스터를 부트스트랩하는 데는 다른 팟(Pod)과의 "1" 대화로 충분합니다. 안
예는 복제본 세트를 시작해야 하는 mongodb입니다.
그들이 "2" 또는 "3" 시작이라고 생각하는 경우, 다음과 같은 경우에 얻을 수 있습니다.
분할을 시작합니다. 그러나 "1"은 매번 안전하게 초기화될 수 있으며,
다른 구성원(영구 상태를 사용하여
이미 클러스터의 일부인지 확인). 에 따라
신원 서비스에서 제공하는 보증은 실제로 얻지 못할 수도 있습니다.
클러스터는 성공적이지만 외부에 별도의 포드를 생성할 필요가 없습니다.
서비스를 초기화하십시오(심지어 나쁘지는 않지만).

2015년 8월 18일 화요일 오후 11:59, Brian Grant 알림 @github.com
썼다:

마스터 선거는 #1542입니다.
https://github.com/kubernetes/kubernetes/issues/1542 , 현재
HA 구현의 일부로 논의됨(예: #12884
https://github.com/kubernetes/kubernetes/pull/12884).

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

@smarterclayton 명목상의 서비스 문제는 제쳐두고 있지만 설명하는 것처럼 부트스트랩하는 것은 안전하지 않습니다. "1"이 새 시스템에서 다시 시작되고 기존 노드에 도달할 수 없으면 다시 부트스트랩되고 이제 두 개의 mongodb가 권한이 있다고 주장합니다. 부트스트랩이 완료된 후 부트스트랩 기능을 제거하려면 작업 정의를 변경해야 합니다.

@thockin 이 암시하는 것처럼 여기에서 유사하지만 다른 몇 가지 기능을 불필요하게 통합하고 있다고 생각합니다. 그리고 우리는 k8 수준에서 엄격하게 필요한 것보다 더 많이 포함하고 있습니다.

위에서 설명한 두 가지 매우 다른 사용 사례가 있습니다. 출처에 따라 다릅니다.

_Prescriptive:_ "N개의 샤드를 실행하고 싶고, 그보다 많거나 적은 경우 변경하여 N으로 되돌리십시오."
_Descriptive:_ "사용 가능한 모든 조각을 자동으로 검색하고 싶고, 어떻게든 조각이 왔다 갔다 하면 알려드리겠습니다."

나는 이것들이 다르고 다르게 설명되어야 한다고 생각합니다(실제로 실행 중인 포드에 유사한 메타데이터를 제공할 수 있지만).

토론에는 리소스 펜싱 및 단일 액세스 보장도 포함되었습니다. Afaics, k8s 내에서 이것이 수행되어야 하는 _only_ 경우는 원격 영구 볼륨을 마운트하는 것이며(fs 마운트는 컨테이너 외부에서 수행되어야 하기 때문에) 기본 원격 볼륨 서비스가 ' 이미 내부적으로 울타리를 제공하고 있습니다. 다른 모든 경우는 분산 잠금 서비스(또는 내부적으로 잠금을 제공하는 서비스에 액세스)를 사용하여 사용자 작업 자체에서 처리할 수 있습니다. 작업에 자체 잠금을 수행하도록 요청하면 모든 종류의 패턴(고정 할당, 기회주의적 할당, "핫 스페어" 등)과 도달 불가능/복구 전략(하드 실패, 마지막으로 알려진 것으로 계속 등)이 열립니다.

이 버그에서 일반 리소스 펜싱 기능 요청을 옮기는 것이 좋습니다(그리고 우리는 k8 자체에 더 이상 관여하지 않고 k8에서 다양한 분산 잠금 서비스를 실행하기 위한 레시피를 제공함으로써 펜싱을 구현합니다).

알림: 단일 VIP 뒤에 _많은_ 포트가 있습니다. 기본 네트워크에서 대규모로 어렵게 들리고 네트워크가 장애/복구 에지 케이스 동안 임시 중복을 처리하는 것이 어색하기 때문에 우리가 IP를 마이그레이션하고 싶지 않다는 데 동의합니다. 그러나 매우 큰 작업의 경우에도 각 샤드 구성원에 고유한 서비스 포트를 할당하고 각 포드 인스턴스에 프록시 데이터를 할당하는 것이 _가능하다고 생각합니다. (이 제안은 프록시가 여전히 우리가 k8s로 가고자 하는 방향이라고 가정하는 것입니다 - 이 영역에 대한 최근 논의를 따라가지 못했습니다)

푸시란 서비스나 컨트롤러와 같은 다른 리소스가 레이블 선택기를 통해 포드 세트를 모니터링하고 "사물"(확인 가능한 DNS 이름, VIP, PVC)을 제공한다는 것을 의미했습니다.

pull은 포드가 "사물" 할당을 명시적으로 요청한 다음 /binding과 같은 것을 통해 바인딩된다는 것을 의미했습니다.

실행 중인 포드 변경 관련: 생성 후 포드를 변경하는 것은 실행 중인 컨테이너가 있는 포드를 변경하는 것과 다릅니다. 스케줄러는 비동기를 수행합니다. 예를 들어 초기화. PodIP도 늦게 할당됩니다. #3585에서 더 일반적으로 논의됩니다.

이것이 정말로 "서비스"인지 아닌지에 관하여:

• Pod 집합에 걸쳐 할당해야 하는 항목
• 사물(예: DNS 이름)은 본질적으로 포드의 리소스 이름에 연결되어서는 안 됩니다.
• 한 포드에서 다른 포드로 물건을 전송할 수 있어야 합니다.
• 포드는 할당된 항목(특히 DNS 이름 및 VIP)을 "알아야"(또는 하향 API를 통해 알아낼 수 있어야 함)해야 합니다.
• 우리가 지원해야 하는 한 가지는 확인 가능한 DNS입니다.
• 우리에게 VIP가 필요한지 여부는 저의 가장 중요한 질문이었습니다. 저는 VIP 안쓰는게 좋습니다.
• 이상적이지는 않지만 사용자는 DNS 및/또는 끝점을 통한 피어 검색을 위해 전체 세트를 대상으로 하는 두 번째 헤드리스 서비스를 만들 수 있습니다.

아이디어 (1), ThingPools + Patches는 흥미로운 아이디어입니다. 나는 그것을 "당기기" 접근 방식으로 설명할 것입니다. ThingPool이 나쁘지는 않지만 Patches가 사용하기 어려울까봐 걱정되고 시스템 내부의 패치에서 의미론적 정보를 리버스 엔지니어링하여 스토리지 수명 주기 등에 대한 허용 가능한 동작을 제공하고 싶지 않습니다. I' d 더 도메인 특정적인 것을 선호합니다. 또한 DNS 이름과 PVC에 대한 독립적인 ThingPools는 함께 할당되어야 하므로 작동하지 않습니다.

아이디어 (2)를 "푸시" 접근 방식으로 설명합니다. RC 및 배포 작업을 복제하고 싶지 않으므로 다른 포드 컨트롤러를 도입해서는 안 됩니다. 할당자는 괜찮지만 필요 이상으로 느슨하게 결합되어 할당을 처리하는 방법에 대한 전례와 일치하지 않습니다.

답장. env vars에 정보 채우기: 이것은 Job에도 적용되었습니다. 정보를 주석에 채우고 특정 주석을 요청할 수 있도록 하향 API를 확장하고 싶습니다. 사용자가 필요한 정보만 요청하고 환경 변수 이름을 선택할 수 있도록 계속 허용하고 싶습니다.

답장. 각 인스턴스에 다른 포트 할당: 많은 레거시 앱에서는 작동하지 않으며 시스템 설계와도 호환되지 않습니다.

답장. 규범적: N을 계속 실행하는 것은 ReplicationController가 하는 일입니다.

답장. 설명: 이미 존재하는 헤드리스 서비스입니다.

답장. 잠금: 예, 진행 중인 임대 API입니다.

스토리지 프로비저닝은 #6773(푸시) 및 #12450(풀)에서 논의되고 있습니다.

지금은 너무 늦었지만 어떻게든 시간을 내서 좀 자고 나서 프러포즈를 하려고 합니다.

빠른 관찰: 헤드리스 서비스는 VIP를 할당하지 않습니다.

DNS 게시에서 할당/할당을 분리할 수 있습니다. 잠시 동안 할당/할당이 발생하는 방식을 무시하고 호스트 이름을 나타내는 포드의 일부 필드에서 이름을 가져오는 헤드리스 서비스의 특별한 특징을 가질 수 있습니다.

그리고 내구성 있는 로컬 스토리지 문제는 관련이 있습니다. #7562, #1515, #598

내가 주로 다른 PR 리뷰를 수행하므로 더 빠른 업데이트:

서비스 사용의 한 가지 이점은 서비스가 DNS에 게시된 이름의 범위를 지정하기 때문에 포드에 대해 요청된 호스트 이름이 전역적으로 고유하다고 보장할 필요가 없다는 것입니다.

답장. 할당/할당: ReplicationController, Deployment, Daemon 등에 더 많은 템플릿 유형을 추가하는 것을 피하고 스토리지 및 이름이 포드(사용자가 원하는 경우)만큼 쉽게 컨트롤러 간에 마이그레이션할 수 있기를 바랍니다.

2015년 8월 19일 오전 1시 4분에 Angus Lees [email protected] 은 다음과 같이 썼습니다.

@smarterclayton https://github.com/smarterclayton
명목상의 서비스 문제가 있지만 부트스트랩하는 것은 안전하지 않습니다.
설명. "1"이 새 컴퓨터에서 다시 시작되고 수행할 수 없는 경우
기존 노드에 도달하면 다시 부트스트랩되며 이제 두 개의 노드가 있습니다.
mongodb가 권위적이라고 주장합니다. 직업을 바꿔야 한다
부트스트랩 후 부트스트랩 기능을 제거하는 정의는
완벽한.

이 경우 겹칠 가능성이 있지만 대부분의 경우
잠금이 있는 영구 저장소에 대해 이야기하는 경우 차단할 수 있습니다.
어쨌든 gce/AWS가 울타리를 해제하고 연결할 수 있을 때까지. 그래서
부트스트래핑 시 가용성을 희생하지만 런타임 시에는 반드시 그렇지는 않습니다.
(당신이 울타리가 없는 스토리지에 있지 않는 한 나는 이것이 그렇지 않을 것이라는 데 동의합니다.
안전한)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

2015년 8월 19일 오전 1시 35분에 Angus Lees [email protected] 은 다음과 같이 썼습니다.

@thockin https://github.com/thockin 이 암시하는 것처럼 제 생각에는
여기에 유사하지만 다른 몇 가지 기능을 불필요하게 통합하고 있습니다.

• 그리고 우리는 k8 수준에서 엄격하게 필요한 것보다 더 많이 포함하고 있습니다.

위에서 설명한 두 가지 매우 다른 사용 사례가 있습니다. 소스에 따라 다름
진실의:

_Prescriptive:_ "N개의 샤드를 실행하고 싶습니다.
그런 다음 변경하여 N으로 되돌리십시오."
_Descriptive:_ "사용 가능한 모든 샤드를 자동 검색하고
그들이 오고 가는 동안 어떻게든 내가 알아내게 해줘."

나는 이것들이 다르고 다르게 설명되어야 한다고 생각합니다(비록

실제 실행 중인 포드와 유사한 메타데이터를 제공할 수 있음).

토론에는 리소스 펜싱 및 단일 액세스도 통합되었습니다.
보장. Afaics, 이것이 k8s 내에서 수행되어야 하는 _only_ 경우
(afaics)가 원격 볼륨을 마운트하고 있습니다 - fs 마운트를 수행해야 하기 때문에
컨테이너 외부. 다른 모든 경우는 사용자 작업에서 처리할 수 있습니다.
분산 잠금 서비스를 사용하여(또는
내부적으로 잠금 제공). 작업이 자체 잠금을 수행하도록 요청
모든 종류의 패턴(고정 할당, 기회 주의적 할당, "핫
스페어" 등) 및 도달 불가능/복구 전략(하드 페일,
마지막으로 알려진 대로 계속 등).

일반 리소스 펜싱 기능 요청을 여기에서 옮기는 것이 좋습니다.
버그 (그리고 우리는 단순히 실행 레시피를 제공하여 펜싱을 구현합니다.
더 이상의 개입 없이 k8에 대한 다양한 분산 잠금 서비스
k8s 자체).

특정 유형의 실행을 위해 목표를 분리할 수 없다고 생각합니다.
소프트웨어 출력 - 설계에는 명목상의 서비스가 표시되어 있지만 사용 사례는
설명은 ID와 디스크를 재사용하고 있습니다. 동의합니다. 펜싱은
볼륨 - 하지만 볼륨 획득을 특정 자산에 연결
포드 인스턴스는 그렇지 않습니다.

알림: 단일 VIP 뒤에 _많은_ 포트가 있습니다. 동의합니다
기본 네트워크에서 어렵게 들리므로 IP를 마이그레이션하고 싶지 않습니다.
규모가 크고 네트워크가 임시 복제본을 처리하는 데 어색함
장애/복구 에지 케이스 동안. 그러나 나는 그것이 _가능하다고 생각합니다.
각 샤드 구성원에 고유한 서비스 포트를 할당하고 각 샤드 구성원에 프록시 데이터를 할당합니다.
포드 인스턴스 - 매우 큰 작업의 경우에도 마찬가지입니다. (이 제안은
프록시는 여전히 우리가 k8s로 가고자 하는 방향입니다.
이 영역에 대한 최근 논의와 함께)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

@thockin 의 ThingPool + Patches 아이디어를 약간 변형:

템플릿: 리소스 목록 + 매개변수 및 대체. 영감을 얻으려면 https://github.com/openshift/origin/blob/master/pkg/template/api/types.go 를 참조

템플릿 풀. 기본적으로 ThingPool. 복제본 수 대신 온디맨드로 템플리트의 조밀하게 인덱싱된 인스턴스를 생성합니다.

재미/일관성을 위해: v2 ReplicationController는 포드 대신 임의의 템플릿을 복제할 수 있습니다. 참조 #170(일종의). 모든 할당이 포드 복제에 의해 구동되는 경우 필요하지 않을 수 있습니다.

주요 대안은 호스트 이름 및 PVC 풀에 중점을 둔 보다 도메인 특정적이지만 각각에 대한 별도의 풀은 작동하지 않습니다. 단일 풀은 호스트 이름의 튜플과 (여러 개의 잠재적인) PVC를 할당할 수 있어야 합니다. TemplatePool의 한 가지 장점은 누군가가 이를 사용하여 복제본당 하나의 서비스(외부)를 할당하여 현재 Zookeeper 해결 방법을 자동화할 수 있다는 것입니다. 누군가가 포드와 1:1 유사하게 복제하고 싶어하는 다른 리소스가 있을지 모르지만 API가 성장하는 속도를 감안할 때 없을 것이라고 장담합니다.

@smarterclayton 참고로 이메일을 통해 인라인 댓글로 답장하면 gmail과 github에서 응답을 읽을 수 없습니다. Gmail에는 줄 바꿈이 없고 github에는 인용 접두사가 없으므로 인용된 텍스트와 별도로 응답을 놀리기가 어렵습니다.

예, Gmail + github + iPhone에 문제가 있습니다.

2015년 8월 20일 목요일 오후 2시 24분, Brian Grant 알림 @github.com
썼다:

@smarterclayton https://github.com/smarterclayton 참고로 답장할 때
인라인 댓글이 포함된 이메일을 통해 응답을 읽을 수 없습니다.
gmail 및 github에서. Gmail에는 줄 바꿈이 없고 github에는
인용 접두사가 없으므로 귀하의 응답은
인용되는 텍스트.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

우리는 오늘 간단한 채팅을 했습니다. 몇 가지 주요 사항은 다음과 같습니다.

앱의 세 가지 클래스에 대해 이야기했습니다.

• 상태 비저장 웹 앱인 앱(RC에서만 작동)
• 외부 마스터를 사용하고 기존 일관성이 있는 거대한 규모의 앱
  합의를 처리하기 위한 프로토콜(Cassandra, Infiniband)
• Mongodb, rethinkdb, volt 등과 같은 소규모 클러스터 상태 저장 소프트웨어,
  잘 작동하려면 몇 가지 패턴이 필요한 사육사, riak, redis 클러스터
  
  
  
  • 고유 ID(일반적으로)
  
  
  • 재사용되는 인스턴스당 고유 영구 볼륨(일반적으로)
  
  
  • 안정적인 IP 주소 또는 DNS 이름(일반적으로) - DNS 이름은 일반적으로
    
    안정적인 IP 주소의 약자
  
  
  • 안정적인 호스트 이름(드물게)
  
  

오늘은 N을 가짐으로써 고유한 아이덴티티와 영구 볼륨을 해결할 수 있습니다.
복제 컨트롤러, N 서비스가 있는 안정적인 IP 주소. 우리는 원한다
이러한 사용 사례 중 일부에 대해 N개의 RC 및 서비스가 필요하지 않습니다.

우리는 특정한 순서 없이 Tim과 Brian의 제안에 대해 이야기했습니다.

• TemplatePool은 리플리케이터가
  클러스터 전체에 걸쳐 객체를 생성할 수 있는 권한과
  모든 API 엔드포인트가 있는 곳입니다.
  
  
  
  • 템플릿 엔드포인트를 인스턴스화할 수 있지만 여전히
    
    권한 위임 문제 해결(서비스 계정으로?)
  
  
  • 개체를 찾고 권한을 제한하는 것은 장기적인 문제입니다.
  
  
• 우리가 이야기한 vuid 필드라고도 하는 "포드 ID" - 주장이 만들어졌습니다.
  그리고 일반적으로 전 세계적으로 고유할 필요는 없다는 데 동의합니다.
  포드가 사용할 것으로 예상되는 도메인 내에서 고유합니다.
  
  
  
  • 가상 인덱스 할당자(희소 또는 밀집)는 해당 값을 설정할 수 있습니다.
    
    생성 후 kubelet은 포드가 생성될 때까지 포드 시작을 기다릴 수 있습니다.
    
    신원(자신이 하나를 기다리고 있음을 표시해야 할 수도 있음)
  
  
  • 조밀한 인덱스는 일반적으로 간단한 일에 유용하지만 이것이
    
    생성 후이며 kubelet에서 분리되어 다른 값을 가질 수 있습니다.
    
    할당 알고리즘 유형(조밀한 숫자, 일관된 해시 링,
    
    랜덤 등)
  
  
• 포드에 대한 간단한 템플릿은 시작하기에 좋은 장소처럼 보이지만 다음이 필요합니다.
  기존 도구 체인과 일치하지 않는 방식으로
  완전히 부숴
  
  
  
  • ID 필드를 사용하여 다른 필드 템플릿화
  
  
• 사용자가 스스로 설정할 수 있는 호스트 이름 필드를 포드 사양에 추가하고
  ID로 매개변수화
• 헤드리스 서비스가 엔드포인트에 대한 DNS 쿼리에 응답하도록 허용
  ID(엔드포인트 컨트롤러가 포드에서 ID를 구체화하도록 합니다.
  약간의 안정성을 보장합니다.
• 어떻게든 영구 볼륨 클레임을 매개변수화하거나 다음으로 변경할 수 있습니다.
  풀에서 가져오기(또는 풀 컨트롤러가 각 당 하나의 볼륨이 있는지 확인
  ID 또는 ID 컨트롤러가 풀에서 가져오도록 함), 생각이 필요합니다.
• 환경/하향 API를 쉽게 변환할 수 있는 도구가 필요합니다.
  구성 파일(직교이지만 더 쉬워야 함)
• 여전히 패턴에 대한 몇 가지 우려

2015년 8월 20일 목요일 오후 3시 34분, Clayton Coleman [email protected]
썼다:

예, Gmail + github + iPhone에 문제가 있습니다.

2015년 8월 20일 목요일 오후 2시 24분, Brian Grant 알림 @github.com
썼다:

@smarterclayton https://github.com/smarterclayton 참고로 답장할 때
인라인 댓글이 포함된 이메일을 통해 응답을 읽을 수 없습니다.
gmail 및 github에서. Gmail에는 줄 바꿈이 없고 github에는
인용 접두사가 없으므로 귀하의 응답은
인용되는 텍스트.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

클레이튼 콜먼 | 수석 엔지니어, OpenShift

또 다른 문제: 명목 서비스 회원을 위한 TLS 인증서

일반적으로 서비스에 대한 TLS 인증서도 좋은 것입니다(서명된
요청 시 클러스터 CA에서 자동으로 제공).

2015년 8월 20일 목요일 오후 5시 19분에 Brian Grant [email protected]이 다음과 같이 썼습니다.

또 다른 문제: 명목 서비스 회원을 위한 TLS 인증서

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

예: #11725

답장:

• 사용자가 스스로 설정할 수 있는 호스트 이름 필드를 포드 사양에 추가하고
  ID로 매개변수화
• 헤드리스 서비스가 엔드포인트에 대한 DNS 쿼리에 응답하도록 허용
  ID(엔드포인트 컨트롤러가 포드에서 ID를 구체화하도록 합니다.
  약간의 안정성을 보장합니다.

컨테이너에 표시되는 호스트 이름을 다른 컨테이너에서 확인할 수 있도록 포드 사양에 설정된 호스트 이름(해당 기능을 추가하면 해당 ID로 매개변수화될 수 있음)을 사용하여 dns를 지원해야 한다는 데 동의했다고 생각합니다.

하위 도메인을 설정하려면 명시적이든 암시적이든 어떤 서비스가 하위 도메인을 대상으로 삼았는지 포드에 알려야 합니다. 명시적의 단점은 더 많은 구성 글루/템플릿이 필요하다는 것입니다. 묵시적 방법의 단점은 시스템의 느슨한 결합으로 인해 발생하는 문제(생성 순서 경쟁 및 불일치, 1:1 시행 어려움 등)가 발생하기 쉽다는 것입니다. 저는 명시적 방식을 선호합니다. 우리는 상호 참조 범위를 개선하기 위해 노력해야 합니다.

다음과 같은 것:

Hostname string
Subdomain string

PodSpec의 HostNetwork 위에 있습니다.

하위 도메인이 올바른 유형의 서비스와 일치하는 경우에만 호스트 이름 기반 DNS를 제공합니다. 우리는 또한 두 개를 단일 필드로 스무딩할 수 있습니다.

제 생각에는 문제 #4825를 다시 사용하고 누군가가 작업을 하도록 해야 한다고 생각합니다. 다른 것보다 훨씬 더 구체적이고 덜 일합니다.

어떻게든 영구 볼륨 클레임을 매개변수화하거나 다음으로 변경할 수 있습니다.
풀에서 가져오기(또는 풀 컨트롤러가 각 당 하나의 볼륨이 있는지 확인
ID 또는 ID 컨트롤러가 풀에서 가져오도록 함), 생각이 필요합니다.

여기에서 도움이 될 수 있는 청구에 대한 두 가지 사항:

1. 바인딩을 1:1에서 1:N으로 변경
   
   
   
   1. pvc.Spec.VolumeName에서 pvc.Spec.VolumeNames[]를 바인딩 참조로 사용
   
   
2. 클레임이 공유를 위해 정확히 한 번 바인딩되어야 하는지 아니면 클레임이 여러 번 바인딩되어야 하는지를 나타내는 pvc.Spec.Singelton 부울입니다.

RC는 필요에 따라 새 볼륨에 바인딩할 수 있습니다. 바인더에서 이것을 처리하는 방법을 알아낼 것입니다.

올바른 볼륨을 올바른 포드에 맞추는 것은 여전히 ​​중요합니다.

볼륨 이름에 대한 ID 맵이 있어야 합니다.

2015년 8월 21일 금요일 오후 3시 17분, Mark Turansky [email protected]
썼다:

어떻게든 영구 볼륨 클레임을 매개변수화하거나 다음으로 변경할 수 있습니다.
풀에서 가져오기(또는 풀 컨트롤러가 각 당 하나의 볼륨이 있는지 확인
ID 또는 ID 컨트롤러가 풀에서 가져오도록 함), 생각이 필요합니다.

여기에서 도움이 될 수 있는 청구에 대한 두 가지 사항:

1. 바인딩을 1:1에서 1:N으로 변경
   
   
   
   1. pvc.Spec.VolumeName을 pvc.Spec.VolumeNames[]에 바인딩으로
      
      참조
   
   
2. 클레임이 바인딩되어야 하는지 여부를 나타내는 pvc.Spec.Singelton 부울
   공유를 위해 정확히 한 번 또는 청구가 여러 번 바인딩되도록 허용합니다.

RC는 필요에 따라 새 볼륨에 바인딩할 수 있습니다. 나는 이것을 처리하는 방법을 알아낼 것이다
바인더에.

올바른 볼륨을 올바른 포드에 맞추는 것은 여전히 ​​중요합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

2015년 8월 21일 금요일 오전 12시 56분에 Brian Grant [email protected]이 다음과 같이 썼습니다.

하위 도메인을 설정하려면 어떤 서비스가 대상으로 삼았는지 포드에 알려야 합니다.
명시적으로 또는 암시적으로. 명시적의 단점은 더 많은 것을 필요로 한다는 것입니다.
구성 접착제 / 템플릿. 암시적의 단점은
시스템에서 느슨한 결합으로 인해 발생하는 문제에 취약합니다.
주문 인종 및 불일치, 1:1 집행 어려움 등
명시적인 쪽으로. 우리는 상호 참조 범위를 개선하기 위해 노력해야 합니다.

분명히 합시다. 하위 도메인을 설정하지 않으면 사용자가 제공할 수 없습니다.
자신의 호스트 이름. 하위 도메인을 설정하는 경우
고유한 방법(DNS 공간에서 현재
네임스페이스). 하위 도메인을 서비스 이름으로 만드는 것은
충분히 독특하다.

DNS(단일 TLD)의 몇 가지 제한 사항을 감안할 때 이것은
현실적으로는 사용자에게 두 개의 DNS_LABEL 필드(호스트 이름)를 제공한다는 의미입니다.
그리고 명목상 세트. 구체적인 예:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

그러면 포드에 다음이 표시됩니다.

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

foo.bar.my-app.nom.cluster.local 대한 A 및 PTR 레코드를 제공하는 DNS

이것은 현재 DNS 구조보다 한 단계 더 깊지만 제 생각에는
우리의 현재 ndots=5는 이것을 다룹니다. 또는 다음과 같이 말할 수 있습니다.
네임스페이스는 성이며 사용자가 고유한 이름을 할당하도록 다시 지정합니다.
네임스페이스의 호스트 이름. DNS 결과는
foo.my-app.pod.cluster.local 서비스를 미러링합니다. 우리는 할 수 있었다
서비스에 선택적 호스트 이름 필드를 추가하여 더 비슷하게 만들 수 있습니다.

하위 도메인이 다음과 일치하는 경우에만 호스트 이름 기반 DNS를 제공합니다.
올바른 유형의 서비스. 우리는 또한 두 개를 단일 필드로 스무딩할 수 있습니다.

이 중 가장 마음에 들지 않는 부분은 Pod가 "나는 일부입니다.
of Service 'bar'"(위의 예에서). 앞. 선험적.

미끄러운 경사면이 일반적으로 허용되지 않는 이유는 무엇입니까? 그것은 것
오늘날 가정할 수 없는 많은 것들을 단순화합니다(왜냐하면
느슨한 결합) 실제로는 단일 Pod를 거의 볼 수 없지만
둘 이상의 서비스 뒤에 있습니다. 모든 Pod가 0 또는 1 미만인 경우
서비스, ​​시스템이 단순해 졌습니까?

제 생각에는 문제 #4825를 다시 사용하고 누군가가 작업을 하도록 해야 한다고 생각합니다. 다른 것보다 훨씬 더 구체적이고 덜 일합니다.

그것은 확실히 바로 시작할 수 있는 일이지만 (그들에게는
집에서 따라하기) 포드를 구현하기 위한 메커니즘일 뿐입니다.
ID 집합을 관리하는 정책이 아니라 ID입니다.

2015년 8월 21일 금요일 오후 3시 17분에 Mark Turansky [email protected] 은 다음과 같이 썼습니다.

여기에서 도움이 될 수 있는 청구에 대한 두 가지 사항:

1. 바인딩을 1:1에서 1:N으로 변경

여기에서 시작했지만...

2015년 8월 21일 금요일 오후 12시 38분, Clayton Coleman
[email protected] 은 다음과 같이 썼습니다.

볼륨 이름에 대한 ID 맵이 있어야 합니다.

네. 이것은 실제로 템플릿 문제로 판명되었습니다.
문제를 일부가 포함된 "포드 템플릿"으로 생각하는지 여부
필드에는 "대체 튜플"로 채워진 자리 표시자가 있습니다.
런타임에 풀에서 가져오거나 완전히 구체화된 포드로 생각하는 경우
풀에서 가져온 "대체 튜플"로 "패치된" 사양
런타임 시 - 동형이며 똑같이 불쾌합니다.

그러나 이것이 우리가 해결해야 할 더 큰 문제 중 하나라고 생각합니다.
우리는 이것들을 위한 밀짚맨 제안을 시작해야 합니까?

2개 또는 3개의 서비스 아래에 있는 포드의 몇 가지 예가 있습니다.
하나는 노출용이고 하나는 노출 테스트용입니다.

ID와 관련하여 데몬 컨트롤러에 의해 생성된 각 포드에는 노드 ID 및 컨트롤러 ID에서 파생된 ID가 할당되어야 합니다. 이것은 ID가 명백하고(호스트 y의 포드 x가 ID f(y)를 가짐) 데몬 책임의 일부인 경우일 수 있습니다.

@smarterclayton 따라서 여기에서 공통적(보편적이지는 않음) 요구는 안정적이고 정렬된 그룹 구성원 목록을 유지하는 것입니다. ID가 포드가 예약된 노드에 연결되어 있으면 어떻게 작동할까요?

데몬 컨트롤러 _only_는 포드가 있는 노드 컨텍스트에서 ID를 가집니다.
계속되다. 복제 컨트롤러와 서비스는 다릅니다. 악마
컨트롤러는 "각 노드에서 이들 중 하나가 실행 중이어야 합니다"라고 말합니다. 거기
포드가 노드를 제외하고 가질 수 있는 다른 ID는 없습니다.

2015년 9월 11일 금요일 오전 1시 13분, Angus Lees [email protected]
썼다:

@smarterclayton https://github.com/smarterclayton 그래서 일반적입니다 (그러나
보편적인) 여기서 필요는 그룹의 안정적이고 정렬된 목록을 유지하는 것입니다.
회원. 나는 그것이 정체성이
포드가 예약된 노드입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

@smarterclayton 아, 이 문제는 분명히 원래 기능 요청보다 더 많은 문제로 변형되었습니다. 여기서 무엇을 만들려고 했는지 잊어버렸으므로 계속해서 노이즈를 추가하기보다는 물러나겠습니다...

죄송합니다. 요점이 관련이 없다는 의미는 아닙니다. 문제는 세트를 정의하고 파드에 전파해야 한다는 것입니다. 포드가 세트의 구성원 자격에 반응해야 합니다(세트의 포드 ID와 일치하는 마운트 볼륨 X). 미해결 질문이 있습니다. 포드가 동시에 두 세트의 구성원이 될 수 있고 둘 중 하나에서 고유한 ID를 가질 수 있습니까?

데몬 컨트롤러에 의해 실행되는 포드에 "명백한" ID가 있는 경우일 수 있습니다(데몬 컨트롤러는 노드 집합에서 작동하고 RC는 포드 집합에서 작동).

ID의 한 가지 요구 사항은 집합에서 고유해야 한다는 것입니다. 포드 이름과 포드 이름 생성을 활용하여 고유성을 보장할 수 있습니까? 예를 들어, RC는 임의의 이름을 생성합니다. RC가 선택한 포드 세트를 기반으로 결정적인 방식으로 포드의 이름을 생성할 수 있습니까?

레이블이 a=b인 팟(Pod)을 선택하는 RC를 고려하십시오. 생성할 다음 포드를 계산하려면 포드를 가져와서 개수로 줄여야 합니다. 고유한 이름 집합으로 축소한 다음 RC가 해당 집합 내에서 이름 생성 패턴을 따르려고 하면 어떻게 될까요? 겹치지 않지만 서비스 레이블로 팟(Pod)을 생성한 두 개의 RC는 고유한 이름을 생성할 수 없습니다(이름을 놓고 싸울 수 있지만 암시적임). 이름을 삭제한 후 다시 사용할 수 있습니다.

그런 다음 포드의 영구 볼륨은 포드 이름을 기반으로 PVC를 사용할 수 있습니다. pvc 풀러는 관찰된 RC 풀에 대한 충분한 클레임이 있는지 확인할 수 있습니다. 데몬 컨트롤러는 노드 이름에 대해 결정적인 이름을 선택할 수 있습니다. 일부 패턴을 기반으로 서비스의 포드 이름에 DNS 이름을 연결할 수도 있습니다.

이것은 포드에 고유한 ID 필드를 추가하는 것보다 더 간결하게 느껴집니다. 이는 포드가 여전히 애완동물이 아니지만 이름은 애완동물일 수 있음을 의미합니다(불합리한 진술은 아님). 동일한 포드 프로세스의 두 인스턴스가 클러스터에서 동시에 실행되는 것을 막을 수는 없지만 이름이 오늘날 한 곳에서만 사용된다는 것을 확실히 보장할 수 있습니다.

위의 "관찰된 이름 풀"을 의미했습니다. 끝점 DNS는 hashpodname.ept.service.namespace.svc.cluster.local입니다. 엔드포인트에 이미 포드 이름이 있으므로 아무것도 추가할 필요가 없습니다.

가능한 다음 반복으로 이 문제의 해결을 제안하는 https://github.com/kubernetes/contrib/tree/master/service-loadbalancer 관련

여기에서 DaemonSet에 대해 논의하는 이유는 무엇입니까? 그것은 #12893, IMO에 의해 해결되었습니다.

@smarterclayton 포드 이름에서 ID를 파생하거나 RC를 사용하여 ID를 할당하는 방법을 다시 살펴보겠습니다. 이러한 접근 방식의 문제는 여기에서 논의되었습니다. https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

한 가지 가능성은 원하는 경우 @smarterclayton이 설명하는 방식으로 이름을 생성할 수 있는 RC 옵션과 옵션 설정 방법에 따라 사용할 수 있는 고유한 기능 세트를 갖는 것입니다. 따라서 "작업 색인" 접근 방식으로 구현하기 어려운 것은 옵션을 활성화하면 사용할 수 없지만 여기에 설명된 기능은 사용할 수 있습니다. 반대로 기본 동작(옵션 비활성화)은 다른 기능을 제공하지만 여기에 설명된 기능은 제공하지 않습니다.

Borg 태스크 인덱스 추상화와 같은 유틸리티가 _특정 사용 사례에 대해 계속해서 나타나는 것 같으며, 우리가 그것을 옵션으로 제공할 수 없는 이유가 명확하지 않습니다.

DaemonSet 분산 파일 시스템 스토리지 케이스를 해결하지 못한다고 생각합니다.
(Gluster) 재결합을 위해 각 호스트가 일관된 ID를 가져야 하는 경우
클러스터. 더 파고들겠지만 여전히 뭔가가 필요할 것 같아
#260의 필요 - 다시 연결하면 호스트 이름이 충분한지 모르겠습니다.
새 인스턴스의 호스트 디스크. DaemonSet이 무엇인지 이해하지 못했을 수도 있습니다.
제공되고 #12893이 배송되었지만 그것이
디스크를 재사용하려는 시스템 호스트.

2015년 9월 16일 수요일 오전 12:22, Brian Grant 알림 @github.com
썼다:

@smarterclayton https://github.com/smarterclayton 다시 방문하지 말자
포드 이름에서 ID를 파생하거나 RC를 사용하여 ID를 할당하지 않습니다.
이러한 접근 방식의 문제는 여기에서 논의되었습니다. #260(댓글)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

구체적인 예로 etcd 클러스터를 상상해 보십시오. 7개의 인스턴스와 7개의 인스턴스가 있습니다.
볼륨. 나는 (인수를 위해) 이름과 볼륨 etcd-1을 원합니다.
etcd-7 및 etcd-pvc-1부터 etc-pvc-7까지.

롤링 배포에는 MaxUnavailable 90%(또는 동등), MaxSurge 0%가 있습니다. 그것
이전 RC를 축소하고 새 RC를 확장합니다. 우아하게 오래된 RC
etcd-5를 삭제합니다. 그것은 즉시 유효 RC 세트에서 사라집니다. 새로운
RC는 (설정된 간격을 관찰하여) etcd-5를 생성하려고 시도합니다. 그것은 수신
"이미 존재하는 예외". 이를 백오프 및 대기열로 처리합니다. 한번
etcd-5가 정말로 사라졌습니다. 계속 진행할 수 있습니다. etcd-5가 준비되면 DC
다음 단계로 이동합니다.

대안 - 포드에 설정된 ID - 이전 RC가 축소됩니다. ㅏ
새 포드는 새 이름으로 즉시 생성됩니다. 새 포드를 실행할 수 없습니다.
어떤 PVC를 마운트할지 파악하려면 ID 세트가 필요하기 때문입니다.
용량. Kubelet에서 대기 루프로 들어갑니다. ID 컨트롤러
일부 레이블 선택기 세트를 감시하고 식별 등을 관찰합니다. etcd-5는 그렇지 않습니다.
할당됨. ID etcd-5를 새 포드에 설정합니다. kubelet은 다음을 관찰합니다.
그런 다음 마운트할 PVC를 파악하고 포드를 시작합니다.
(볼륨이 다른 노드에서 분리되었다고 가정).

구조적으로 이들은 매우 유사합니다. 후자는 시작 겹침을 허용합니다.
둘 다 PVC 매핑이 필요합니다.

2015년 9월 16일 수요일 오전 12:39, Clayton Coleman [email protected]
썼다:

DaemonSet 분산 파일 시스템 스토리지 케이스를 해결하지 못한다고 생각합니다.
(Gluster) 재결합을 위해 각 호스트가 일관된 ID를 가져야 하는 경우
클러스터. 더 파고들겠지만 여전히 뭔가가 필요할 것 같아
#260의 필요 - 다시 연결하면 호스트 이름이 충분한지 모르겠습니다.
새 인스턴스의 호스트 디스크. DaemonSet이 무엇인지 이해하지 못했을 수도 있습니다.
제공되고 #12893이 배송되었지만 그것이
디스크를 재사용하려는 시스템 호스트.

2015년 9월 16일 수요일 오전 12:22, Brian Grant 알림 @github.com
썼다:

@smarterclayton https://github.com/smarterclayton 다시 방문하지 말자
포드 이름에서 ID를 파생하거나 RC를 사용하여 ID를 할당하지 않습니다.
이러한 접근 방식의 문제는 여기에서 논의되었습니다. #260(댓글)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

클레이튼 콜먼 | 수석 엔지니어, OpenShift

이 문제를 어렵게 만드는 것은 안정적이고 고유한 이름 풀을 생성하거나 PD 풀을 사용하지 않는다는 것입니다. 문제는 두 가지를 동시에 수행하는 것입니다. 그리고 그것을 확장하면 사양의 어떤 식별자도 이와 같이 풀링할 수 없는 이유는 무엇입니까?

내가 아는 한(대부분 중고) 압축 인덱스 문제는 해결 가능하다고 생각합니다(특히 David가 제안한 대로 수행하고 다른 기능과 상호 배타적으로 만드는 경우). 그러나 또한, 더 많이 끓일수록, 어떤 멍청이가 게시한 패치 아이디어가 더 싫어집니다.

이 문제는 계속 지속되어 왔으며 분석 마비가 온 것 같습니다.

다른 풀링 사용 사례의 예가 더 많았으면 합니다. 나는 Gluster를 생각했다
다를 수 있지만
cassandra/etcd/mongo/zookeeper "볼륨을 재사용하고 싶습니다.
내가 전에 누구라고 말했는지 기억하십시오." 우리는 실제로 역할 기반이 없었습니다.
첫 번째 N개의 포드 코디네이터와 다음 M개의 작업자를 만들고 싶습니다) 예제
활용합니다.

2015년 9월 16일 수요일 오전 12시 46분, Tim Hockin [email protected]
썼다:

나에게 이 문제를 어렵게 만드는 것은 안정적인
고유한 이름 풀 또는 PD 풀 사용 문제는 두 가지를 모두 수행하는 것입니다.
동시. 그리고 당신이 그것을 확장하면 왜 아무 것도 할 수 없습니다
사양의 식별자는 다음과 같이 풀링됩니까?

내가 아는 한 (대부분 중고) 팩 인덱스 문제,
그들이 살 수 있다고 생각하십시오(특히 우리가 David가 제안하고
다른 기능과 상호 배타적임). 하지만 역시 끓일수록
그건 그렇고, 어떤 멍청이가 게시한 패치 아이디어를 덜 싫어합니다.

이 문제는 계속해서 계속되고 있으며 우리가 분석을 가지고 있는 것 같아 두렵습니다.
마비.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

데몬세트:

12893 호스트 네트워킹을 사용할 때 포드 호스트 이름을 노드의 호스트 이름으로 설정합니다. 이는 DaemonSet에 사용하기에 완전히 합당합니다. 그렇지 않으면 어쨌든 hostPort를 사용하기 때문입니다.

또한 암시적 무기한 용서 #1574를 제공하고 일반적으로 노드에 대해 활성화된 스케줄링 이전에 "스케줄링"을 활성화하기 위해 DaemonSet을 노드 컨트롤러와 통합하려는 의도입니다. 암시적 우선 순위 지정도 합리적일 수 있습니다.

클러스터 스토리지 시스템의 경우 스토리지 시스템에서만 hostPath를 통해 액세스하는 각 호스트에 추가 디스크를 프로비저닝하는 것을 상상할 수 있습니다. Docker나 emptyDir에서는 사용하지 않습니다.

ID와 관련하여 여기에서 제안에 문제가 없다고 봅니다. https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

이 문제는 IMO에 대한 충분한 우선 순위가 없기 때문에 주로 남아 있습니다.

Clayton의 말을 되풀이하려면(또는 그냥 똑같은 말을 하지만 더 멍청하게):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

의미는 RC(또는 무언가)가 이것이 ID 세트임을 깨닫고, identityPool에서 인덱스를 할당하고, 해당 ID를 포드 이름에 할당한 다음 내부를 들여다보고 다른 ID 중심 필드가 설정되어 있는지 확인한다는 것입니다. 이 경우 볼륨.

완전히 일반적인 것은 아니지만(임의의 필드를 풀링할 수 없음) 필요에 따라 더 많은 식별 인식 옵션을 추가할 수 있습니다.

우리가 이 부분에 대해 마음에 드는 사양을 정했다면 더 빨리 완료될 수 있을 것 같습니다.

스펙을 작성하는데도 시간이 걸립니다.

IdentityPool/VolumePool과 관련하여 우리는 이미 오래전에 여러 풀이 작동하지 않을 것이라고 결정했습니다.

1.1 코드 완성 마감일은 금요일입니다. 지금은 이 작업을 수행하지 않을 수 있습니까?

관련 항목: #170. 그것은 포드 템플릿을 분할하는 것을 제안했지만 템플릿 구성표(패치보다 강력하게 선호함)를 사용하는 경우 함께 고려해야 합니다.

나는 적어도 v1.2-candidate에 디자인을 넣었습니다.

죄송합니다. 스케치에서 명확하지 않았습니다. RC(또는 IC?)에는 다음과 같은 개념이 있습니다.
기본 풀 또는 인덱스. 포드에 IC의 인덱스가 할당되면
index는 모든 풀 중심 필드를 인덱싱하는 데 사용됩니다.

템플릿을 분할하면 RC가
템플릿을 변경합니다. 그것은 조금 더 까다 롭습니다.

이번 주에 이것에 대한 이야기는 그만해도 좋습니다. 내 안에 딱 들어왔어
받은 편지함과 나는이 아이디어를 씹고있었습니다 ...

2015년 9월 15일 화요일 오후 10:09, Brian Grant 알림 @github.com
썼다:

스펙을 작성하는데도 시간이 걸립니다.

IdentityPool/VolumePool과 관련하여 우리는 이미 오랫동안
이전에는 여러 풀이 작동하지 않습니다.

1.1 코드 완성 마감일은 금요일입니다. 지금은 이 작업을 수행하지 않을 수 있습니까?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

네, 우리 측에서 토론을 촉발시킨 일이 있었습니다.
고객 문제는 릴리스 프로세스가 없을 때까지 기다립니다.

2015년 9월 16일 수요일 오전 1시 14분, Tim Hockin [email protected]
썼다:

죄송합니다. 스케치에서 명확하지 않았습니다. RC(또는 IC?)에는 다음과 같은 개념이 있습니다.
기본 풀 또는 인덱스. 포드에 IC의 인덱스가 할당되면
index는 모든 풀 중심 필드를 인덱싱하는 데 사용됩니다.

템플릿을 분할하면 RC가
템플릿을 변경합니다. 그것은 조금 더 까다 롭습니다.

이번 주에 이것에 대한 이야기는 그만해도 좋습니다. 내 안에 딱 들어왔어
받은 편지함과 나는이 아이디어를 씹고있었습니다 ...

2015년 9월 15일 화요일 오후 10:09, Brian Grant 알림 @github.com
썼다:

스펙을 작성하는데도 시간이 걸립니다.

IdentityPool/VolumePool과 관련하여 우리는 이미 오랫동안
이전에는 여러 풀이 작동하지 않습니다.

1.1 코드 완성 마감일은 금요일입니다. 제발 이러지 말자
지금?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

논의는 모두 IP 번호와 Pod에 관한 것이지만 Mongo & Zookeeper IP에 대한 제 경험에 따르면 Pod는 관련성이 없어야 합니다(애완동물이 되지 않아야 함). 영구 _volume_은 이 볼륨이 다른 '볼륨'의 IP 번호를 기록하기 때문에 명목 번호가 필요합니다. 해당 볼륨을 마운트하는 Pod가 무엇이든 기록된 IP 번호를 어떻게든 사용할 수 있어야 합니다. 볼륨은 애완 동물 ...

볼륨에 대해 일정하고 볼륨을 탑재하는 Pod에 할당된 DNS 이름은 제 생각에 먼 길을 올 것입니다.

Mongo & ZK에서 앙상블 멤버십을 변경하려면 항상 사용자 정의 코드를 실행해야 하며 대부분의 다른 앙상블에서도 동일할 것으로 예상합니다. 따라서 복제 컨트롤러는 잘못된 이름입니다. 이 애완동물은 멤버쉽 컨트롤러가 더 필요합니다. Member Ship 컨트롤러는 초기 설정을 처리한 다음 앙상블에 대한 증분 변경을 처리할 수 있어야 하며 마지막으로 이를 제거할 수 있어야 합니다.

마운트된 볼륨을 기반으로 하는 일정한 DNS 이름과 사용자 지정 코드로 앙상블 멤버십을 처리할 수 있는 가능성은 이러한 유형의 시스템을 처리할 수 있어야 한다고 생각합니다.

예, 포드 IP는 단기 해킹에 가깝습니다.

이 제안이 진행되는 위치는 DNS와 볼륨 모두
결합을 유지하기 위해 활용할 수 있습니다. 문제는 볼륨을 정의하는 DNS 이름입니다.
이미 설정한 커플링의 반대이며,
포드 사양의 다른 부분이 더 높은 개념을 활용하도록 하고 싶습니다.
(identity)는 환경에 대한 하향 API와 같습니다. 그것이 적응을 만든다.
다른 앙상블 소프트웨어에 대한 ID를 더 쉽게
유형).

앙상블을 넘어서는 사용 사례가 없는지 확인해야 합니다.
여기에서 중복(제안된 것을 들어본 적이 없음)한 다음
최소한의 적절하다고 느끼는 구체적인 제안. 내가 생각하는 팀
가장 최근에 여기에 요약했습니다.

2015년 9월 23일 오전 11시 33분에 Peter Kriens [email protected]에서 다음과 같이 썼습니다.

토론은 모두 IP 번호와 Pod에 관한 것이지만 제 경험으로는
Mongo & Zookeeper IP Pod는 관련성이 없어야 합니다(애완동물이 되지 않아야 함).
영구 _volume_은 이 볼륨이 기록하기 때문에 명목상 숫자가 필요합니다.
다른 '볼륨'의 IP 번호입니다. 해당 볼륨을 마운트하는 Pod
기록된 IP 번호를 어떻게든 사용할 수 있어야 합니다. 볼륨은
애완 동물 ...

볼륨에 대해 일정하고 다음을 수행하는 Pod에 할당된 DNS 이름
마운트 볼륨은 내가 생각하는 먼 길을 올 것입니다.

Mongo & ZK에서 앙상블 멤버쉽을 변경하려면 항상 사용자 정의가 필요합니다.
코드를 실행할 수 있으며 대부분의 다른 앙상블에서도 동일할 것으로 예상합니다. 그래서
복제 컨트롤러의 이름이 잘못되었습니다. 이 애완동물은 구성원이 더 필요합니다.
선박 관제사. Member Ship 컨트롤러는 다음을 처리할 수 있어야 합니다.
초기 설정과 앙상블에 대한 점진적 변경, 그리고 마지막으로
죽여버려.

탑재된 볼륨 및
사용자 정의 코드로 앙상블 멤버십을 처리할 수 있어야 합니다.
내가 생각하는 이러한 유형의 시스템을 처리합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/핑

https://hub.docker.com/r/elevy/zookeeper/ 에서 기존 기능을 사용하여 Kubernetes에서 ZK 클러스터를 설정하는 예를 찾을 수 있습니다

@smarterclayton @thockin

며칠 전 자전거를 타고 사무실에 가면서 드는 생각:

나는 현재 이것을 PetSet 컨트롤러 또는 아마도 ShardSet 컨트롤러로 생각하고 있습니다. 사람들이 그렇게 생각하고 싶다면 처음에 다시 논의한 것처럼: https://github.com/kubernetes/kubernetes/issues/260# 문제의견 -57671926.

우리가 다루려고 하는 경우는 N개의 유사한 애완동물이 있지만 여전히 애완동물입니다. 대체할 수 없습니다.

나는 여전히 이것을 ReplicationController에 묶는 것이 작동하지 않는다고 생각합니다. 부분적으로 ReplicationController에는 단일 템플릿만 있기 때문입니다. PetSet/ShardSet은 Deployment 또는 DaemonSet과 같은 더 높은 수준의 추상화여야 합니다. PetSet은 잠재적으로 인스턴스당 하나의 PodTemplate 개체를 생성할 수 있습니다.

나는 우리가 Deployment API를 재사용할 수 있다고 생각하지 않습니다. 무엇보다도 현재 kubectl 및 Deployment의 롤링 업데이트 롤아웃 전략이 이 경우에는 작동하지 않습니다. 대부분의 애완동물은 재생 업데이트를 원할 것이고, 롤링 업데이트를 원하는 애완동물은 샤드 수를 초과하는 급증을 처리할 수 없으며 업데이트 순서에 특히 신경을 쓸 것입니다.

아이디어가 마음에 드는 만큼 상향식 ID 할당이 작동하지 않을 것이라고 생각합니다. 풀에 할당된 ID를 반환하는 것과 새 ID를 할당하는 것과 관련된 경쟁 조건이 너무 많습니다. @erictune 이 Job과 함께 RabbitMQ 사용을 탐색하는 동안 발생한 문제와 매우 유사합니다.

컨트롤러 및 자격 증명 풀, 컨트롤러 및 서비스와 같이 둘 이상의 위치에서 PetSet의 규모를 표현하고 싶지 않습니다.

이 경우에는 범용 템플릿이 필요하지 않다고 생각합니다. 연결된 스토리지 및 예측 가능하고 내구성 있는 네트워크 ID가 있는 포드를 제거하기만 하면 됩니다. 대략적인 등가물은 Borg에서 충분합니다. 따라서 나는 #12450 라인을 따라 무언가에 강하게 기대고 있지만 포드 자체보다는 포드 템플릿에 있습니다. 아마도 podTemplate과 함께 persistentVolumeClaimTemplate의 배열일 것입니다. 모든 클라우드 공급자별 볼륨 소스에 대한 멋진 대체를 추가하고 싶지 않습니다. 특히 어쨌든 이러한 소스를 더 이상 사용하지 않기를 원하기 때문입니다. PVC에 추가 요구 사항 및/또는 선택기를 추가하는 것으로 충분해야 합니다. 또한 어떤 시점에서 어떻게든 영구 볼륨을 프로비저닝할 수 있어야 합니다.

우리는 여전히 로컬 스토리지에 대해 뭔가를 해야 할 것이지만, 나는 그것이 분리될 수 있다고 생각합니다.

그리고 위에서 언급한 호스트 이름과 헤드리스 서비스 변경 사항은 다음과 같습니다.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

지금 제안서를 작성 중이며 곧 초안이 작성됩니다.

제안은 https://github.com/kubernetes/kubernetes/pull/18016 에

... 그럼 PetSet은 어디에 있습니까?

Kubernetes 위에 HA 데이터베이스 솔루션을 구축 중입니다. 일부, 특히 단일 마스터 데이터베이스에는 해당 포드의 이벤트를 기반으로 특정 포드에 매핑되는 엔드포인트가 있는 서비스가 필요합니다. 예를 들어:

1. 서비스 "postgres"는 라운드 로빈을 ReplicaSet의 모든 포드에 매핑하지만 서비스 "postgres-master"는 하나의 포드에만 매핑합니다.
2. 마스터 포드가 죽습니다.
3. 장애 조치가 발생합니다. 장애 조치의 일부로 새 마스터는 API를 통해 Kube-master를 업데이트하여 postgres-master 서비스를 "잡기"합니다.
4. 이렇게 하면 postgres-master에 대한 모든 이전 연결이 종료됩니다.

@jberkus PetSets 를 활성화하는 초기 알파 코드가 병합되었거나 병합 대기 중입니다. @ingvagabund 내 팀 PetSet의 메이크업 사용이 잘 작동하고 여전히 개선이 필요한 것을 볼 것을 함께 예제를 넣어 시작하는 것입니다. 조합하고 테스트하고 싶은 특정 사용 사례가 있는 경우 그에게 연락하는 것이 좋습니다.

@ncdc v1.3에서 모든 작업이 완료되었습니까? 제안이 병합되지 않았고 한동안 이것을 참조하는 다른 PR이 없었기 때문에 불명확합니다.

@bprashanth ^

우리는 e2es를 상륙하고 예제 작업을 계속하고 있습니다. 알파에 있다
지금은 제안서가 첫 번째 알파 피드백을 받을 것입니다.
병합하기 전에.

2016년 5월 19일 오전 10시 25분, Brandon Philips [email protected]
썼다:

@ncdc https://github.com/ncdc v1.3에서 모든 작업이 완료되었습니까? 그것은
제안이 병합되지 않았고 다른 PR이 없었기 때문에 불명확함
잠시 동안 이것을 참조하십시오.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

이에 대한 문서는 어디에서 찾을 수 있습니까? 데이터베이스 장애 조치 사용 사례에 대해 테스트하고 싶습니다.

아하, 포스트그레스 전문가가 필요한 것입니다 :)

예제는 https://github.com/kubernetes/contrib/pull/921 을 참조 @philips 는 etcd 예제가 좋을 것입니다). 나는 아직 문서를 작성하지 않았으며 1.3의 마지막 몇 주 동안 문서를 작성할 것입니다(금요일에 코드가 완료된 후 릴리스까지 여전히 5주).

꽤 일반적이기 때문에 postgres를 사용하여 장애 조치를 자동화하려고 할 것이라고 생각합니다. 나는 현재 그것이 내가 원하는 만큼 쉽지 않다는 것을 인정할 것입니다. 아마도 감시자가 필요할 것입니다. @jberkus 어떤 패턴이 그것을 더 쉽게 만드는지 피드백을 듣고 싶습니다.

빠른 검토를 제공하기 위해 현재 petset은 네트워크 탑재 볼륨과 일치하는 일관된 네트워크 ID(DNS, 호스트 이름) 및 주문 보장을 제공합니다. 따라서 replicas: 3 를 사용하여 애완 동물 세트를 만들면 다음을 얻을 수 있습니다.
관리 서비스: *.galear.default.svc.cluster.local
mysql-0 - 볼륨 0
mysql-1 - volume1: 0이 실행되고 준비될 때까지 시작되지 않습니다.
mysql-2 - volume2: 0, 1이 준비될 때까지 시작되지 않음

포드는 관리 서비스에 삽입된 SRV 레코드를 조회하여 서비스 검색에 DNS를 사용할 수 있습니다. 이것이 바로 이 간단한 포드가 하는 일입니다: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. 따라서 위의 예와 같이 초기화 컨테이너를 통해 피어 파인더를 사용하면 초기화 컨테이너가 DNS에서 (mysql-1, mysql-0)을 볼 때까지 mysql-1이 시작되지 않고 적절한 구성을 작성합니다.

볼륨은 동적 프로비저닝 도구(https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md)에 의해 프로비저닝되므로 볼륨이 없는 경우 클러스터에서 실행 중이지만 프로토타입을 만들고 싶다면 간단히 emptyDir을 사용할 수 있습니다. "data-gravity"(https://github.com/kubernetes/kubernetes/issues/7562) 사례는 아직 작동하지 않지만 결국 작동합니다.

현재는 초기화 컨테이너를 통해 피어 목록과 함께 "시작 시" 알림을 전달하는 것이 더 쉽다고 덧붙입니다. "변경 시" 알림도 필요하다는 것이 분명합니다. 현재 클러스터 멤버십 변경 사항을 확인하려면 사용자 지정 pid1을 사용해야 합니다. 공유 pid 네임스페이스를 사용하면 사이드카를 사용할 수 있으므로 이 작업을 더 쉽게 수행할 수 있습니다. 이 또한 제대로 작동해야 하는 것입니다.

나는 감시자가 있는데, 내가 원하는 것보다 더 복잡한 서비스 장애 조치입니다. 테스트하겠습니다, 감사합니다!

나는 또한 etcd를 지원해야 하므로 앞으로 많은 테스트가 있을 수 있습니다.

@ncdc 이에 대한 알파 코드의 상태는 무엇입니까? 테스트/구현을 시작하고 싶습니다. 여기에서 곧 카산드라 클러스터를 배포해야 합니다. 기존 코드베이스로 할 수 있지만 petset 항목을 테스트하는 것이 좋습니다.

HEAD에서 빌드하면 얻을 수 있습니다.

@bprashanth 가 기본 저장소에 병합되었습니까? 감사합니다. 할 것이다.

https://github.com/kubernetes/contrib/tree/master/pets

주석 문자열에 포함된 yaml? ooof, ouch :(. 감사합니다. 카산드라 세트를 만드는 방법을 조사하겠습니다.

그것은 json입니다. GA 개체(포드의 컨테이너 초기화)에 추가된 알파 기능입니다.
@chrislovecnm 은 Cassandra에서 작업 중이며 그를 기다리고 싶을 수도 있습니다.

@paralin은 여기에서 내가 작업하고 있는 것입니다. 지금은 문서화하고 k8 repo에 저장할 시간이 없지만 장기적 계획입니다. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra HEAD에서 로컬로 저를 위해 일하고 있습니다.

데모의 최신 C* 이미지가 잘 작동합니다.

더 많은 문서를 위해 열려 있는 문제가 있습니다. 윙크 윙크 톡톡 @bprashanth

etcd 클러스터가 있는 PetSets의 예[1].

[1] https://github.com/kubernetes/contrib/pull/1295

검토를 마친 후 제안 문서에 디자인 요청을 캡처해야 합니다.

2016년 6월 30일 오전 1시 25분에 Jan Chaloupka [email protected] 은 다음과 같이 썼습니다.

etcd 클러스터가 있는 PetSets의 예[1].

[1] kubernetes/contrib#1295
https://github.com/kubernetes/contrib/pull/1295

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658,
또는 스레드 음소거
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

petset 문서는 https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md 및 https://github.com/kubernetes/kubernetes.github입니다. io/tree/release-1.3/docs/user-guide/petset/bootstrapping , 이 문제를 닫고 아무도 반대하지 않는 한 petset을 베타로 이동하는 문제를 해결하는 새 문제를 열 ​​계획입니다.

https://github.com/kubernetes/kubernetes/issues/28718