@lavalamp 적어도 우리의 생각을 통합하고 타사 리소스에 대한 진행 상황을 추적할 수 있는 장소를 만들기 위해 이것을 만들었습니다. 안정판으로 승격하기 전에 해결해야 할 알려진 단점 목록을 만들려고 했습니다.

마음에 주인은 없지만 문제 인식이 1단계인 것 같다.

@deads2k 최근에 제3자 리소스를 배우고 있는데 도움이 되고 싶습니다.

@deads2k 최근에 제3자 리소스를 배우고 있는데 도움이 되고 싶습니다.

나는 전술적 우선순위에 따라 목록을 재정렬했습니다. 사람들은 지금 이것을 사용하려고 하고 있으며 이러한 문제는 그들을 심하게 태울 것입니다.

"여러 자원" 항목을 사용하는 것이 편하다면 좋은 시작이 될 것입니다. 별도의 문제를 만들 수 있으며 거기에서 구현에 대해 이야기할 수 있습니다.

@deads2k 첫 번째 문제를 재현하는 데 시간을 보냈습니다.

Multiple Resources, single version, different add times - Adding resource A, waiting for it to appear, then adding resource B fails. Resource B is never added.

그러나 불행으로. 다음은 내 재현 단계입니다.

1. 사용자 지정 타사 리소스를 만들고 표시될 때까지 기다립니다.

[root<strong i="12">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/lbclaim.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancerclaim.k8s.io
description: "Allow user to claim a loadbalancer instance"
versions:
- name: v1
[root<strong i="13">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/lbclaim.yaml
thirdpartyresource "loadbalancerclaim.k8s.io" created
[root<strong i="14">@localhost</strong> kubernetes]# curl  http://localhost:8080/apis/extensions/v1beta1/thirdpartyresources/
{
  "kind": "ThirdPartyResourceList",
  "apiVersion": "extensions/v1beta1",
  "metadata": {
    "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/",
    "resourceVersion": "170"
  },
  "items": [
    {
      "metadata": {
        "name": "loadbalancerclaim.k8s.io",
        "selfLink": "/apis/extensions/v1beta1/thirdpartyresources/loadbalancerclaim.k8s.io",
        "uid": "dcb88b3a-9857-11e6-a19b-08002767e1f5",
        "resourceVersion": "146",
        "creationTimestamp": "2016-10-22T13:03:01Z"
      },
      "description": "Allow user to claim a loadbalancer instance",
      "versions": [
        {
          "name": "v1"
        }
      ]
    }
  ]
}

1. 잠시 후(10초 이상) 다른 사용자 지정 타사 리소스 생성

[root<strong i="19">@localhost</strong> kubernetes]# cat /home/tony/Desktop/debug/loadbalancer.yaml
kind: ThirdPartyResource
apiVersion: extensions/v1beta1
metadata:
  name: loadbalancer.k8s.io
description: "Allow user to curd a loadbalancer instance"
versions:
- name: v1
[root<strong i="20">@localhost</strong> kubernetes]# kc create -f /home/tony/Desktop/debug/loadbalancer.yaml
thirdpartyresource "loadbalancer.k8s.io" created

1. 두 리소스가 모두 존재하는지 확인

[root<strong i="25">@localhost</strong> kubernetes]# curl http://localhost:8080/apis/k8s.io/v1/
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "k8s.io/v1",
  "resources": [
    {
      "name": "loadbalancerclaims",
      "namespaced": true,
      "kind": "Loadbalancerclaim"
    },
    {
      "name": "loadbalancers",
      "namespaced": true,
      "kind": "Loadbalancer"
    }
  ]
}
[root<strong i="26">@localhost</strong> kubernetes]# kc get loadbalancers
No resources found.
[root<strong i="27">@localhost</strong> kubernetes]# kc get loadbalancerclaims
No resources found.

우리는 이미 여러 리소스, 단일 버전을 지원하는 것 같습니다.

그리고 TPR 관련 코드를 자세히 살펴봅니다. thirdparty_controller 는 주기적으로 동기화(10초마다)를 수행하고 모든 새 TPR을 설치하고 일부 삭제 작업도 수행합니다. ThirdPartyResourceServer 에는 설치된 모든 TPR 매핑이 포함됩니다. SyncOneResource 및 InstallThirdPartyResource 에서 볼 수 있듯이 이 그룹이 존재하더라도 새 API로 그룹을 계속 업데이트합니다.

또한 시스템에 TPR 인스턴스가 있더라도 TPR 스키마 def를 삭제할 수 있음을 발견했습니다. 나는 이것이 허용되어서는 안된다고 생각한다.

@deads2k 첫 번째 문제를 재현하는 데 시간을 보냈습니다.

이 테스트를 활성화하십시오: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . 그것이 효과가 있다면, 우리는 좋은 것입니다. 실패하면 뭔가 잘못된 것입니다.

@deads2k 안녕하세요 David, 제가 Slack으로 보낸 메시지를 봐주세요. 게다가 실패한 통합 테스트에 대한 수정 사항을 추가합니다. TPR이 삭제되면 타사 리소스 컨트롤러가 해당 경로 처리기를 제거합니다. 이는 통합 테스트에 도움이 될 것이지만 이것이 다른 문제를 일으킬지 여부는 확실하지 않습니다. .

문제 # 1의 경우 여기에서 수정되었습니다.

https://github.com/kubernetes/kubernetes/pull/28414

@brendandburns는 실제로 그렇지 않습니다. 주석 처리 통합 테스트를 실행할 수 있으며 실패합니다.

@brendandburns 더 정확하게

@AdoHe 문제를 제기 했습니까? 나는 볼 수 있습니다.

@brendandburns 여기에서 볼 수 있습니다:

https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 

이 테스트를 활성화하면 실패하는 것을 볼 수 있습니다. 나는 이것을 내 지역에서 수정하려고 시도했으며 오늘 나중에 PR을 열 것입니다.

@brendandburns 문제를 제기하지 않습니다.

또한 https://github.com/kubernetes/kubernetes/issues/32306을 참조

@deads2k 체크리스트를 업데이트할 수 있습니까?

@deads2k 체크리스트를 업데이트할 수 있습니까?

모든 문제가 아직 미해결 상태입니다. 이것은 실제로 1.3에서 (이미) 베타 thirdparyresources 구현의 문제를 추적하는 기능입니다. 우리는 우리의 문제를 추적할 장소가 필요했지만 1.5에서 다른 노력에 에너지를 바쳐야 했습니다.

@deads2k 저는 이미 Multiple Resources, single version 및 Multiple versions 작업 중이며 많은 코드를 업데이트해야 한다고 생각합니다.

@deads2k 는 여전히 1.5를 대상으로 합니까?

@idvoretskyi 나는 두렵지 않습니다 :(

@deads2k : 연합 API에 ThirdPartyResources를 추가해야 합니다.

@deads2k : 현재 ThirdPartyObjects를 쿼리할 때 필드 선택기가 작동하지 않습니다. 목록에 해당 사항이 있습니까?

@deads2k @rmohr kubectl은 여전히 ​​TPR에 대한 많은 뛰어난 기능을 가지고 있으며, 이를 추적하려면 위의 목록을 업데이트해야 합니다.

@deads2k : 현재 ThirdPartyObjects를 쿼리할 때 필드 선택기가 작동하지 않습니다. 목록에 해당 사항이 있습니까?

이는 모든 API 유형에서 일관되지 않은 필드 선택기 지원의 보다 일반적인 문제입니다.

저도 이것부터 보기 시작합니다. ThirdPartyResources는 spark 와 같은 "외부" 컨트롤러를 지원하는 데 매우 중요하며 하위 리소스와 같은 것을 추가하기 전에 이 문제를 수정해야 합니다.

필드 선택기는 일반 API 객체에서 직접 선별한 필드에서만 작동합니다. TPR의 모든 필드에서 작동할 것으로 기대하지 않습니다. apiserver는 임의 쿼리를 수행하도록 구축되지 않았습니다. 그러한 행동이 필요한 경우 TPR이 작동하지 않습니다.

TPR을 애드온 API 서버 로 옮기는 다음 단계가 여기에 있습니까?
이 항목에서 차단될 수 있는 목록의 일부 문제를 해결하기 위해 미해결 PR이 있는 것 같습니다.

/cc @liggitt @deads2k @AdoHe

apiserver 코드에서 TPR의 복잡성을 줄이고 TPR 논리를 훨씬 더 명시적으로 만들기 위해 독립 실행형 tpr-apiserver 확실히 투표할 것입니다. 그러나 IMO는 실제로 수정 사항을 차단하지 않습니다.

변환할 수 없는 여러 종류를 처리할 때 API 의미(get, list, watch, update, patch) 처리에 대한 몇 가지 항목을 추가하고 있습니다. 의미 체계가 일반적인 API 의미 체계와 일치하지 않을 가능성이 높기 때문에 아마도 설계 문서가 필요할 것이라고 생각합니다.

이 문제 중 일부를 해결하기 위해 (또 다른) 실행을 할 것입니다 ...

https://github.com/kubernetes/kubernetes/pull/40260 및 https://github.com/kubernetes/kubernetes/pull/40096 은 kubectl 측면에서 우리를 괜찮은 상태로 만들 것입니다.

현재 가장 심각한 서버 측 문제는 TPR을 가리키는 ownerRef에 대해 가비지 수집기가 정신을 잃는 것입니다.

문제가 해결되면 주어진 TPR의 여러 버전에 대한 API 의미 체계를 결정하고 TPR 유형에 필요한 데이터가 있는지 확인해야 합니다. 그것은 서버 측 스토리지 impl에 영향을 미칠 가능성이 있으므로 서버 측 작업을 너무 많이 수행하기 전에 디자인을 고정하는 것이 좋습니다.

@liggitt 리뷰를 살펴보겠습니다. 고마워

RBAC 규칙에서 TPR을 참조하는 방법에 대한 포인터가 있는 사람이 있습니까? foo-bar.something.example.com과 같은 이름의 TPR이 있습니다. 클러스터 관리자는 kubectl get foobars 를 사용하여 지정된 네임스페이스의 foobar 목록을 얻을 수 있습니다.

일반 사용자가 동일한 것을 시도하면 Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) 됩니다.

나는 지금까지 운이 없는 RBAC 규칙에서 생각할 수 있는 foobar, foo-bar 등의 모든 변형을 시도했습니다.

규칙에서 다음을 찾고 있습니다. resource=foobas apigroup=something.example.com verb=get,list,watch

@deads2k 트릭을 했습니다. 감사 해요!

@liggitt

The most severe server-side issue at the moment is the garbage collector losing its mind over ownerRefs that point to TPRs.

TPR 정리 문제와 관련된 것이 있습니까?

아니요, 가비지 수집기가 형식으로 컴파일되지 않은 다른 항목에 대해 ownerRef를 조회하는 방법을 모르는 문제였습니다. 반대 문제도 존재하는데, 가비지 수집기는 컴파일된 유형 이외의 종료자에 주의를 기울이지 않습니다.

이러한 가비지 수집기 문제는 모두 ThirdPartyResource 개체가 제거될 때 ThirdPartyResourceData 개체를 안정적으로 정리해야 하는 필요성과 다릅니다.

@liggitt 환자 설명 감사합니다. 1.6에서 TPR의 계획은 무엇입니까?

GC는 이제 초당 50,000번 대신 초당 1,000번만 기록합니다.
그래서 더 이상 로그 로테이터로 경주에서 이기지 않습니다. 그러나 진정한 해결은
곧 올 것입니다.

2017년 2월 4일 토요일 오후 11시 54분에 TonyAdo [email protected]에서 다음과 같이 썼습니다.

@liggitt https://github.com/liggitt 환자 설명에 감사드립니다.
1.6에서 TPR의 계획은 무엇입니까?

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

TPR과 관련된 몇 가지 미해결 문제. 완전하지 않습니다.

그룹/버전 문제: https://github.com/kubernetes/kubernetes/pull/24299 , https://github.com/kubernetes/kubernetes/pull/36977
보기: https://github.com/kubernetes/kubernetes/issues/25340
자체 링크: https://github.com/kubernetes/kubernetes/issues/37622
네임스페이스 삭제: https://github.com/kubernetes/kubernetes/issues/37554
GC: https://github.com/kubernetes/kubernetes/issues/39816
종료자: https://github.com/kubernetes/kubernetes/issues/40715
TPR 데이터 정리: https://github.com/kubernetes/kubernetes/issues/35949
더 강력한 메타데이터 검증: https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
단위 테스트 부족: https://github.com/kubernetes/kubernetes/pull/40956
정리: https://github.com/kubernetes/kubernetes/issues/36998

사용자가 다른 리소스에서 작동하기 때문에 버그라고 생각하는 기능:
비동기 동작: https://github.com/kubernetes/kubernetes/issues/29002
정수: https://github.com/kubernetes/kubernetes/issues/30213
YAML: https://github.com/kubernetes/kubernetes/issues/37455
괜찮은 kubectl 출력: https://github.com/kubernetes/kubernetes/issues/31343
리소스 명명 간소화: https://github.com/kubernetes/kubernetes/issues/29415
신청: https://github.com/kubernetes/kubernetes/issues/29542 , https://github.com/kubernetes/kubernetes/issues/39906
편집: https://github.com/kubernetes/kubernetes/issues/35993

/cc

대시보드에서 TPR을 처리하려고 하므로 구독합니다.

추적 문제는 https://github.com/kubernetes/dashboard/issues/1671 및 https://github.com/kubernetes/dashboard/issues/1504입니다.

@kubernetes/dashboard-maintainers

네임스페이스가 없는 TPR의 상태/계획은 무엇입니까? 나는 그것에 대한 토론을 찾지 못했습니다. 아마도 뭔가를 놓친 것입니까?

@sttts 먼저 Kubernetes의 개발에 관심이 있습니다. 그리고 나는 그것에 기여하고 싶지만 바둑은 저에게 새로운 언어입니다. GSoC 2017용으로 이 프로젝트를 수행할 수 있도록 여러분이 추천하는 작업은 무엇입니까?

나에 대해 덧붙이자면, 저는 C++와 Java에 상당히 능숙하며 컴퓨터 공학 학사를 보유하고 있습니다. 또한 문서를 읽기 시작했으며 Kubernetes와 관련된 Udacity 과정을 수강했습니다.

@grpndrs 우리는 코드에 들어가기에 좋은 출발점인 레이블이 지정된 문제 목록을 가지고 있습니다. https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -기고자. 여유롭게 저에게 연락해 주시면 그 중 몇 가지를 살펴보겠습니다.

@enisoc

Multiple Resources, single version, different add times 여전히 문제입니까? 문제 없이 여러 TPR을 만들고 삭제할 수 있습니다.

또한 Outstanding Capabilities 의 확인란에 번호를 매기면 참조하기 쉽습니까? @deads2k 다음과 같이 할 수 있다고 생각합니다.

1. - [ ] ...
2. - [ ] ...

이것의 유효성 검사 구성 요소가 어떻게 진행되는지 아는 사람이 있습니까? 저는 TPR을 많이 사용하며 이 기능은 값을 매길 수 없으며 많은 사용자 지정 코드를 절약할 수 있습니다. 이 기능에 기여하고 싶지만 이 문제를 구독하는 사람이 상태를 알고 있는지 알고 싶습니다.

이것의 유효성 검사 구성 요소가 어떻게 진행되는지 아는 사람이 있습니까?

나는 그것이 1.7에 일어날 것으로 기대하지 않는다. 현재 https://github.com/kubernetes/community/pull/524 에서 보다 안정적인 성장 기반을 제공하기 위해 몇 가지 구조적 성장통에 대해 논의하고 있습니다.

나는 그것이 1.7에 일어날 것으로 기대하지 않는다. 현재 kubernetes/community#524에서 보다 안정적인 성장 기반을 제공하기 위해 몇 가지 구조적 성장 문제에 대해 논의하고 있습니다.

1.7 기간 동안 https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md 로 진행할 계획입니다. 진행하면서 여기와 sig-apimachinery 호출에서 업데이트하겠습니다.

@deads2k tpr 유효성 검사에 대해 아무 것도 보지 못했습니다. 베타에 필요한 부분이라고 생각하지 않으세요?

@frankgreco 제안은 TPR을 구축할 수 있는 건전한 기반에 관한 것입니다. 유효성 검사와 같은 기능은 나중에 추가할 수 있지만 여기서는 범위를 벗어납니다.

새 템플릿을 사용하고 1.7에 대해 계획된 작업 범위를 명확히 하기 위해 이 스레드의 상위 주석을 편집했습니다. 보시고 수정/댓글 부탁드립니다.

@deads2k @enisoc 우리는 최근에 TPR을 사용하기 시작했으며 TPR 검증은 우리의 다가오는 프로젝트 중 일부에서 매우 중요할 것입니다. 작업할 수 있는 리소스가 있다면 커뮤니티 기여자를 받아 들일 수 있습니까?

@deads2k @enisoc 우리는 최근에 TPR을 사용하기 시작했으며 TPR 검증은 우리의 다가오는 프로젝트 중 일부에서 매우 중요할 것입니다. 작업할 수 있는 리소스가 있다면 커뮤니티 기여자를 받아 들일 수 있습니까?

전적으로. 이와 같은 경우 pull 요청을 살펴보기 전에 디자인 제안이 필요합니다. 또한 가능한 다양한 접근 방식을 고려할 때 상위 3개 정도의 아이디어를 나열하고 선택한 방법이 가장 좋은 이유에 대해 간략하게 설명하는 것이 좋습니다. 서버 측이므로 성능 및 보안 고려 사항이 매우 중요합니다.

또한 이것은 광범위한 기능이기 때문에 드라이브 바이 기여가 되지 않는 것이 중요합니다. https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md 로의 전환을 위한 적극적인 기여(리뷰, 테스트, 코드, 마이그레이션)가 도움이 될 것입니다. 관심이 있고 이야기하고 싶다면 나는 deads2k on slack입니다.

@deads2k 감사합니다! 그것은 완전히 합리적입니다. TPR 검증을 위한 몇 가지 설계 제안을 제시할 것입니다. 이를 공유하는 가장 좋은 방법은 무엇입니까? 나도 슬플거야.

@xiao-zhou 바로 이 주제에 대한 Google Summer of Code 프로젝트를 수락하게 되어 기쁩니다(방금 어제 발표됨). 이에 대해 협업하는 방법에 대해 Slack에서 채팅합시다. 당신이 이것에 관심을 가지고 있다는 것은 매우 멋진 일입니다. 그래서 우리는 이것을 앞으로 밀어붙일 상당한 힘이 있습니다!

@xiao-zhou @sttts @deads2k TPR 검증(이상적으로는 기본값 설정)에 대한 제안을 받자마자 제안 검토에서 저를 태그하시겠습니까? 감사 해요

@sdminonne sig-apimachinery에 게시됩니다. 해당 Google 그룹에 가입하면 알림을 받아야 합니다.

@sttts 감사합니다

@deads2k TPR 에 ObservedGeneration을 추가하시겠습니까?

https://github.com/kubernetes/kubernetes/issues/7328#issuecomment -287683598

@deads2k TPR 에 ObservedGeneration을 추가하시겠습니까?

나는 계획하지 않았다. 관심이 있는 클라이언트는 단순히 사양 및 상태 이름을 비교할 수 없습니까?

사양 및 상태 이름을 비교하시겠습니까?

무슨 말인지 잘 모르겠습니다. 정정합니다. 제가 틀렸지만 ObservedGeneration에 두 부분이 있다고 생각합니다. 1) API 서버는 TPR 사양에 업데이트가 있을 때마다 metadata.generation 를 업데이트해야 하고 2) TPR은 status.observedGeneration 기반으로 metadata.Generation 합니다. 나는 1) 내가 당신에게 묻는 것이고 2) TPR 작성자가 처리해야 할 일이라고 생각합니다.

무슨 말인지 잘 모르겠습니다. 내가 틀렸지만 ObservedGeneration에 두 부분이 있다고 생각하는 경우 수정하십시오. 1) API 서버는 TPR 사양에 업데이트가 있을 때마다 metadata.generation을 업데이트해야 하고 2) TPR 업데이트 상태를 담당하는 컨트롤러 .observedGeneration은 metadata.Generation을 기반으로 합니다. 나는 1) 내가 당신에게 묻는 것이고 2) TPR 작성자가 처리해야 할 일이라고 생각합니다.

아, 무슨 질문을 하시는지 제가 잘못 이해했습니다. CustomResourceDefinition이 아닌 CustomResource에 대해observedGeneration을 원합니다. 나는 관찰된 생성이 조치가 필요한 사양 변경에 대해서만 충돌했다고 생각했습니다. 메타데이터에 대한 업데이트가 이를 트리거하지 않았으며 일부 사양 필드에 대한 업데이트도 충돌을 피할 수 있음을 의미합니다.

위에 링크된 내 의견에서 나는 TPR 자체가 아니라 TPR 인스턴스에 대한 Generation 지원을 요청했습니다.

예를 들어 Kind: TPR; name: foo.example.com 및 해당 TPR Kind: Foo; name: foo123 인스턴스가 있는 경우 foo123 대한 Generation/ObservedGeneration에 관심이 있으므로 Foo 컨트롤러가 Foo 소비자가 처리했는지 알 수 있도록 합니다. foo123 인스턴스에 대한 업데이트. 말이 되나요? k8 서버 측에서 적절한 지원 없이 이것이 어떻게 달성될 수 있는지 모르겠습니다.

예, generation/observedGeneration은 진화한 실제 TPR 리소스가 아니라 TPR의 사용자 스키마에 대해 의미가 있습니다.

@kargakis 규칙은 상태가 아닌 사양 업데이트 시에만 개체 생성을 증가시키는 것입니다. 맞죠? 그렇다면 먼저 TPR 인스턴스에서 사양/상태 분할을 공식적으로 지원해야 합니다. 1.8을 목표로 TPR 상태에 대한 제안서를 작성할 계획이었습니다. 제안서에 증가하는 개체 생성을 포함할 수 있습니다.

규칙은 상태가 아니라 사양 업데이트 시에만 개체 생성을 증가시키는 것입니다. 맞습니까?

옳은.

그렇다면 먼저 TPR 인스턴스에서 사양/상태 분할을 공식적으로 지원해야 합니다.

예, 기존 문제의 일부로 해당 분할을 찾을 것으로 예상했지만 거기에 도달하기 전에 더 많은 작업이 필요한 것 같습니다.

@kargakis 1.7의 범위를 벗어났지만 이러한 항목을 언급하기 위해 최상위 주석을 편집했습니다.

/cc

@deads2k CustomResourceDefinition의

CustomResourceDefinition 에 대한 짧은 이름 CRD를 추가했습니다 .

CustomResources 검증을 위한 디자인 제안: https://github.com/kubernetes/community/pull/708 :smile:

@deads2k @enisoc @lavalamp
사용자가 CRD 개체에 대해 k8s 컨트롤러 AND(OR) CURD 메서드를 구성할 수 있는지 궁금합니다.

내 특정 사용 사례에서는 networks.stable.example.com CRD를 만들고 이를 사용하여 네트워크 개체 net1을 만듭니다.

서브넷 범위가 겹치는 네트워크 CRD 개체가 이미 있는 경우 새 네트워크 CRD 개체를 만들 수 없도록 해야 합니다.

그러한 메커니즘이 존재하지 않는다면, 나는 기꺼이 디자인 문서에 몇 가지 생각을 조합할 것입니다.

1.7 릴리스 노트 및 문서에서 언급했듯이 TPR은 이제 더 이상 사용되지 않으며 1.8에서 제거할 계획입니다. 사용자는 1.7 기간 동안 CRD로 전환해야 합니다.

질문이나 우려 사항이 있는 경우 제거를 위한 추적 문제에 대해 의견을 말하십시오.

1.8 업데이트/계획:

• CustomResources에 대한 JSON 스키마 기반 유효성 검사 및 기본값 설정 지원( 제안 )
• CR에 대한 하위 리소스(예: 상태 및 규모) 추가(~곧 나올 제안 ~

@nikhita 감사합니다. 1.8 계획을 반영하도록 상단 댓글을 편집했습니다.

검색은 CR에 대한 올바른 정보를 반환하지만 REST 매퍼는 이를 사용하지 않습니다 - https://github.com/kubernetes/kubernetes/issues/49948

CustomResources용 SubResources 제안: https://github.com/kubernetes/community/pull/913 :tada:

내 잘못된 게시물을 용서해 주세요. 그러나 나는 kubernetes가 단지 제3자 컨테이너 자원을 관리하기 위한 것 이상으로 마이크로 서비스 프레임워크를 포함한다고 생각하는 다른 kubernetes 페이지에서 이 페이지에 왔습니다.

Redhat은 OpenShift kubernetes를 마이크로 서비스 플랫폼으로 마케팅하지만 아직 이 기능을 찾지 못하는 것 같습니다. 내 자신의 매우 가벼운 독립 애플리케이션 마이크로 서비스 제품군을 호스팅할 애플리케이션 서버를 찾고 있습니다.

그런 것이 존재합니까, 아니면 우리는 springboot에서 뚱뚱한 자바 전쟁 앱을 만들고 관리하기 어렵고 배포하기 어려운 kuberenetes 관리 컨테이너 내부에 있는 tomcat 서버에 배포하도록 강등되었습니다. 관리자 1명이 수백 개의 마이크로 서비스를 관리하고 운영할 수 있는 마이크로 서비스 플랫폼이 필요합니다.

이 질문이 의미가 있습니까?

@hectoralicea 이 저장소는 Kubernetes 개발자가 작업한 기능을 계획하는 데 사용됩니다.

이와 같은 일반적인 질문은 Kubernetes 사용자 그룹에 게시하십시오. 그들은 일반적으로 이런 종류의 높은 수준의 토론에 훨씬 더 도움이 됩니다. :)

https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ 또는 스택 오버플로를 참조 하세요 .

@colemickens @deads2k @nikhita @enisoc 1.9에 대한 섹션을 추가했습니다.

@sttts v1.9에서 개선된 베타 버전 맞죠?

@luxas 버그수정 물론입니다. 하지만 여기에 나열할 필요는 없다고 생각합니다.

@sttts 저는 CRD 검증에 대해 생각하고 있었습니다... 이 기능 문제에서 다루어지고 v1.9에서 베타로 전환됩니까?

@luxas 초기 게시물의

Scope of work planned for v1.9

    CRD validation to beta kubernetes/kubernetes#22768 kubernetes/kubernetes#53829
    CRD sub-resources as alpha kubernetes/community#913

오, 감사합니다 @kargakis , 거기를 보지 않았습니다 :facepalm: :smile:

@deads2k , @enisoc 1.9에서 "안정적인" 계획이 없습니까?

@idvoretskyi 맞습니다.

@deads2k :wave: 문서 PR을 열고 추적 스프레드시트에 대한 링크를 추가하세요. 미리 감사드립니다!

@deads2k 문서 PR을 열고 추적 스프레드시트에 대한 링크를 추가하십시오. 미리 감사드립니다!

@zacharysarah 스프레드시트 링크를 잘못 배치한 것 같습니다. CRD 유효성 검사 문서는 여기 https://github.com/kubernetes/website/pull/6066

참고로 CRD 버전 문제는 https://github.com/kubernetes/features/issues/544에 있습니다.

GA로 이동하는 CRD의 작업 목록: https://github.com/kubernetes/kubernetes/issues/58682

@nikhita 전체 CRD 기능이 GA로 이동한다는 것을 의미합니까?

전체 CRD 기능이 GA로 이동한다는 의미입니까?

API는 GA, 즉 v1으로 이동하며 일부 베타/알파 하위 기능이 있을 수 있습니다. 이것이 언제 일어날지, 즉 1.10이 실행 가능한지 여부는 종료되지 않습니다.

@sttts @nikhita 기능 로드맵을 더 정확하게 정의할 수 있습니까?

기능 로드맵을 더 정확하게 정의할 수 있습니까?

1.10의 경우:

• https://github.com/kubernetes/kubernetes/issues/58682에 나열된 사용자 지정 리소스 및 버그 수정에 대한 하위 리소스(최소한 줄이 그어진 것)

다음 릴리스에 대해 계획된 _정확한_ 결과물 세트는 없지만 연말까지 GA로 전환할 계획입니다(https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

https://github.com/kubernetes/kubernetes/issues/58682에 표시되지 않은 모든 문제가 완료되면 GA로 이동합니다.

CRD API가 GA로 전환되면 여기에 기능이 있을 수 있습니다(예: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg/features/kube_features.go#L35) 알파/베타 버전일 수 있습니다.

@sttts @nikhita @ deads2k
1.11에서 이에 대한 계획이 있습니까?

그렇다면 해당 기능이 최신 상태인지 확인할 수 있습니까?

• 설명
• 중요한 단계
• 양수인
• 라벨:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

1.11에서 이에 대한 계획이 있습니까?

나는 PR 본문을 편집할 권한이 없습니다(누군가가 그렇게 할 수 있다면 좋을 것입니다!). 그러나 계획은 다음과 같습니다.

• CRD 버전 관리를 구현합니다. 여기에는 또 다른 기능 문제가 있습니다: https://github.com/kubernetes/features/issues/544. 디자인 제안: https://github.com/kubernetes/community/pull/2026.
• 사용자 지정 리소스에 대한 정리 및 기본값 설정을 추가합니다.
• CRD 유효성 검사 스키마에서 맵을 지원합니다. https://github.com/kubernetes/kubernetes/issues/59485
• 사용자 지정 리소스에 대한 할당량 지원 구현(이것도 버그 수정으로 간주될 수 있음) https://github.com/kubernetes/kubernetes/issues/53777

그렇다면 해당 기능이 최신 상태인지 확인할 수 있습니까?
설명

"CRD에 대한 유효성 검사, 기본값 설정, 하위 리소스 및 버전 관리 추가"를 포함하도록 한 줄 설명을 업데이트해야 합니다.

설명에 언급된 설계 제안에는 다음이 포함되어야 합니다.

• https://github.com/kubernetes/community/pull/2026
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-validation.md
• https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/customresources-subresources.md

누군가 이것을 PR 본문에도 추가할 수 있습니까?

라벨:

/종류 기능

/ 참조 @mbohlool

누군가 이것을 PR 본문에도 추가할 수 있습니까?

완료

@nikhita @sttts @mbohlool -- 명확히

@nikhita @sttts @mbohlool -- 이것에 다시 핑...
1.11 베타를 목표로 하고 있습니까? 기능 정지가 오늘인지 확인하고 싶습니다.

@justaugustus CRD는 이미 베타 버전입니다. GA는 1.11에서 계획되지 않습니다.

나열된 모든 기능/확장(가지치기, 기본값 설정, 버전 관리)은 아마도 알파로 시작될 것입니다.

@sttts 흠, 이 경우 해당 기능/확장 및 해당 단계를 독립적으로 추적하기 위해 별도의 문제가 있어야 합니까?

기록하려면 - @nikhita 가 하위 기능에 대한 문제를 만들었습니다. https://github.com/kubernetes/features/issues/571

@sttts @justaugustus

기본값 설정 및 정리 하위 기능 문제: https://github.com/kubernetes/features/issues/575

@justaugustus @idvoretskyi 1.12 추적 목적: 추가 및 버그 수정이 있을 수 있지만 이것은 1.12용 베타 버전으로 유지됩니다(따라서 기능 관점에서 변경 사항 없음).

알파로 계획된 새로운 하위 기능이 있지만 별도의 문제로 생성됩니다: https://github.com/kubernetes/features/issues/575.

안녕하세요
이 개선 사항은 이전에 추적되었으므로 Kubernetes 1.13의 졸업 단계에 대한 계획이 있는지 확인하고 확인하고 싶습니다. 이 릴리스는 보다 '안정적인' 것을 목표로 하며 공격적인 일정을 갖습니다. 다음 마감일을 충족할 것이라고 확신하는 경우에만 이 개선 사항을 포함하십시오.

• 문서(열린 자리 표시자 PR): 11/8
• 코드 슬러시: 11/9
• 코드 동결 시작: 11/15
• 문서 작성 및 검토: 11/27

나중에 추적할 수 있도록 원본 게시물의 이정표를 업데이트하고 1.13 개선 사항 추적 시트에 포함해야 하는 경우 @kacole2로 핑하십시오.

감사 해요!

이 개선 사항은 이전에 추적되었으므로 Kubernetes 1.13의 졸업 단계에 대한 계획이 있는지 확인하고 확인하고 싶습니다.

아니요, 1.13에서 이것을 졸업할 계획이 없습니다. CRD API는 베타 버전으로 유지됩니다.

90일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

지금 이 문제를 닫는 것이 안전하다면 /close 로 닫으십시오.

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

@deads2k 안녕하세요 - 저는 1.14에 대한 개선 사항의 리더이며 1.14 릴리스에 대해 어떤 작업(있는 경우)이 계획되고 있는지 확인하기 위해 이 문제를 확인하고 있습니다. 개선 사항 동결은 1월 29일이며 모든 개선 사항에는 KEP가 있어야 함을 상기시키고 싶습니다.

@claurence CRD API는 1.14에서도 베타 버전으로 유지됩니다.

안녕하세요 @nikhita @deads2k , 저는 1.15의 Enhancement Lead입니다. 이 기능은 1.15에서 알파/베타/안정 단계를 졸업할 예정입니까? 제대로 추적하고 스프레드시트에 추가할 수 있도록 알려주십시오. 1.15 포함을 위해서는 KEP도 병합되어야 합니다. 감사 해요!

코딩이 시작되면 이 호의 모든 관련 k/k PR을 나열하여 올바르게 추적할 수 있도록 하십시오.

이것은 베타 단계로 유지됩니다. 유효성 검사, 변환 및 OpenAPI 게시 작업이 1.15에서 진행 중입니다.

1.15에 대한 관련 KEP에 대한 링크가 있는 업데이트된 설명

안녕하세요, @liggitt @deads2k @jpbetz @sttts 저는 v1.15 문서 릴리스 섀도우입니다.

이 개선 사항(또는 v1.15에 대해 계획된 작업)에 새로운 문서(또는 수정 사항)가 필요합니까?

5월 30일 목요일까지 k/website (branch dev-1.15)에 대한 PR을 찾고 있다는 친근한 알림입니다. 전체 문서의 시작이라면 좋겠지만 자리 표시자 PR도 허용됩니다. 질문이 있으면 알려주세요! 😄

@deads2k @jpbetz @sttts @liggitt

5월 30일 목요일까지 k/website (branch dev-1.15)에 대한 PR을 찾고 있다는 친근한 알림입니다. 전체 문서의 시작이라면 좋겠지만 자리 표시자 PR도 허용됩니다. 질문이 있으면 알려주세요! 😄

1.15용 문서 PR: https://github.com/kubernetes/website/pull/14583

@deads2k 문제 설명을 업데이트할 수 있습니까?

/마일스톤 v1.16
/스테이지 안정

안녕하세요, @liggitt @jpbetz @sttts 저는 v1.16 문서 릴리스 리더입니다.

이 개선 사항(또는 v1.16에 대해 계획된 작업)에 새로운 문서(또는 수정 사항)가 필요합니까?

8월 23일 금요일까지 k/website (branch dev-1.16)에 대한 PR을 찾고 있음을 알려드립니다. 질문이 있으면 알려주세요!

@simonswine 자리 표시자 PR https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts 목요일은 코드 동결입니다. 이것이 Stable로 전환되는 것을 방해하는 미해결 k/k PR이 있습니까? 계획된 1.15* 작업에 대한 원본 게시물의 모든 내용이 병합된 것으로 보입니다.

저는 뛰어난 PR이 기능 게이트 버전 범프(https://github.com/kubernetes/kubernetes/pull/81965)와 이번 주에 진행되어야 하는 두 가지 뛰어난 버그 수정이라고 믿습니다: https://github.com/kubernetes /kubernetes/pull/81436 , https://github.com/kubernetes/kubernetes/issues/78707

https://github.com/kubernetes/website/pull/15982 에서 검토할 문서 준비

v1.16.0에서 안정 버전으로 출시

https://github.com/orgs/kubernetes/projects/28 에서 추적된 GA 이후 작업

/닫다

@liggitt : 이 문제를 종료합니다.