@lavalamp私はこれを作成して、少なくとも私たちの考えを統合し、サードパーティのリソースの進捗状況を追跡できる場所を

私は所有者を念頭に置いていませんが、問題の認識はステップ1のようです。

@ deads2k私は最近サードパーティのリソースを学んでいますが、何かを手伝いたいと思っています。

@ deads2k私は最近サードパーティのリソースを学んでいますが、何かを手伝いたいと思っています。

戦術的な優先順位としてリストを並べ替えました。 人々は今これを使おうとしています、そしてこれらの問題は彼らをひどく燃やすでしょう。

「複数のリソース」の項目を快適に利用できるのであれば、それは素晴らしいスタートです。 別の問題を作成して、そこでの実装について話し合うことができます。

@ 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スキーマ定義を削除できることがわかりました。 これは許されるべきではないと思います。

@ deads2k私は最初の問題を再現しようとしてしばらく時間を費やしました：

このテストを有効にしてみてください： https ：

@ 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 ：ThirdPartyResourcesをフェデレーションAPIに追加する必要があります。

@ 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を指すownerRefsを気にしないことです。

それが解決されたら、特定のTPRの複数のバージョンに関するAPIセマンティクスを決定し、TPRタイプに必要なデータが含まれていることを確認する必要があります。 これはサーバー側のストレージ実装に影響を与える可能性が高いため、サーバー側の作業をやりすぎる前に、設計を明確にしたいと思います。

@liggittそれらのレビューを見てみましょう。 THX

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 = foobars 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は、1秒あたり5万回ではなく、1秒あたり1k回しかログに記録しないようになりました。
そのため、ログローテーションでレースに勝つことはなくなりました。 しかし、実際の修正は
うまくいけば、すぐに来る。

23:54時土、2017年2月4日には、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/36977
視聴： https ：
セルフリンク： https ：
名前空間の削除： https ：
GC： https ：
ファイナライザー： https ：
TPRデータのクリーンアップ： https ：
メタデータのより強力な検証： https ：
ユニットテストの欠如： https ：
クリーンアップ： https ：

他のリソースで機能するため、ユーザーがバグと考える機能は次のとおりです。
非同期動作： https ：
整数： https ：
YAML： https ：
まともなkubectl出力： https ：
リソースの命名を簡素化する： https ：
適用： https ： //github.com/kubernetes/kubernetes/issues/39906
編集： https ：

/ cc

ダッシュボードでTPRを処理しようとしているときにサブスクライブします。

追跡の問題はhttps://github.com/kubernetes/dashboard/issues/1671とhttps://github.com/kubernetes/dashboard/issues/1504です。

@ kubernetes / dashboard-maintainers

名前空間のないTPRのステータス/計画は何ですか？ 私はそれについての議論を見つけられませんでした、多分何かを逃しましたか？

@stttsまず、Kubernetesでの開発に興味を持っています。 そして私はそれに貢献したいのですが、Goは私にとって新しい言語です。 GSoC 2017でこのプロジェクトを取得できるようにするために、皆さんが私に勧めていることは何ですか？

私について何かを追加すると、私はC ++とJavaがかなり得意で、コンピューターサイエンスの学士号を取得しています。 また、ドキュメントを読み始め、Kubernetesを含むUdacityコースを受講しました。

@grpndrsには、コードに入るのに適した開始点となるラベル付きの問題のリストがあります： https ： 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の呼び出しで、作業を進めながら更新します。

@ deads2ktpr検証については何も表示されませんでした。 それはベータ版に必要なものだと思いませんか？

@frankgrecoの提案は、TPRを構築するための健全な基盤に関するものです。 検証などの機能は後で追加できますが、ここでは範囲外です。

このスレッドの親コメントを編集して、新しいテンプレートを使用し、1.7で計画されている作業の範囲を明確にしました。 それを見て、修正/コメントしてください。

@ deads2k @enisoc最近TPRの使用を開始しており、TPRの検証は今後のプロジェクトのいくつかにとって非常に重要になるでしょう。 それに取り組むためのリソースがある場合、それを実現するためにコミュニティの貢献者を受け入れることを検討しますか？

@ deads2k @enisoc最近TPRの使用を開始しており、TPRの検証は今後のプロジェクトのいくつかにとって非常に重要になるでしょう。 それに取り組むためのリソースがある場合、それを実現するためにコミュニティの貢献者を受け入れることを検討しますか？

絶対。 このような場合は、プルリクエストを検討する前に設計提案が必要です。 また、さまざまなアプローチが可能であることを考えると、上位3つほどのアイデアをリストし、選択したアイデアが最適である理由を簡単に説明することをお勧めします。 サーバー側なので、パフォーマンスとセキュリティの考慮事項は非常に重要です。

また、これは広範囲にわたる機能であるため、ドライブバイの貢献にならないことが重要です。 https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.mdへの移行のための積極的な貢献（レビュー、テスト、コード、移行）が役立ちます。 あなたが興味を持って話をしたいのなら、私はたるみでdeads2kです。

ありがとう@ deads2k！ それは完全に合理的です。 TPR検証のためのいくつかの設計提案を考え出しますが、それを共有する最良の方法は何ですか？ 私もたるみます

@ xiao-zhouこのトピックに関するGoogleSummer of Codeプロジェクトが承認されたことをうれしく思います（昨日発表されました）。 これに協力する方法についてSlackでチャットしましょう。 あなたもこれに興味を持っているのはとてもクールなので、私たちはこれを前進させるためにかなりの力を持っています！

@ xiao-zhou @sttts @ deads2k TPR検証の提案（そして理想的にはデフォルト）ができたらすぐに、提案レビューで私にタグを付けますか？ ありがとう

@sdminonneそれはsig-apimachineryに投稿されます。 あなたがそのグーグルグループを購読するならば、あなたは通知を受けるべきです。

@stttsありがとう

@ deads2k TPRにObservedGenerationを追加しますか？

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

@ deads2k TPRにObservedGenerationを追加しますか？

私はそうするつもりはなかった。 スペック名とステータス名を単純に比較することを気にするクライアントはできませんか？

スペック名とステータス名を比較しますか？

ここで何を意味するのかわかりません。 私が間違っているが、ObservedGenerationには2つの部分があると思う場合は、1）TPRの仕様が更新されるたびにAPIサーバーがmetadata.generationを更新する必要があり、2） TPRは更新status.observedGenerationに基づいてmetadata.Generation 。 1）私があなたに尋ねていることであり、2）TPRの作者が世話をする必要があることだと思いますか？

ここで何を意味するのかわかりません。 私が間違っているが、ObservedGenerationには2つの部分があると思う場合：1）APIサーバーはTPRの仕様に更新があるたびにmetadata.generationを更新する必要があり、2）TPR更新ステータスを担当するコントローラーメタデータに基づく.observedGeneration.Generation。 1）私があなたに尋ねていることであり、2）TPRの作者が世話をする必要があることだと思いますか？

ああ、私はあなたが何を求めているのか誤解しました。 CustomResourceDefinitionではなく、CustomResourceのobservedGenerationが必要です。 私は、observedGenerationは、アクションを必要とする仕様の変更に対してのみぶつかったと思いました。 つまり、メタデータを更新してもメタデータはトリガーされず、一部のスペックフィールドを更新しても、メタデータがぶつかるのを防ぐことができます。

上にリンクされた私のコメントでは、TPR自体ではなく、TPRインスタンスの生成サポートを求めていました（それもいいでしょうが、すべてのオブジェクトに追加しない理由はありますか？）。

たとえば、 Kind: TPR; name: foo.example.comとそのTPR Kind: Foo; name: foo123インスタンスがある場合、FooコントローラーがFooコンシューマーに処理したかどうかを通知できるように、 foo123 Generation / ObservedGenerationに関心があります。 foo123インスタンスへの更新。 それは意味がありますか？ k8sサーバー側で適切なサポートがないと、これをどのように実現できるかわかりません。

ええ、generation / observedGenerationは、TPRのユーザースキーマには意味があり、進化した実際のTPRリソースには意味がありません。

@kargakisルールは、ステータスではなく、仕様の更新時にのみオブジェクトの生成をインクリメントすることですよね？ もしそうなら、それは最初にTPRインスタンスでSpec / Status分割を公式にサポートする必要があることを意味します。 1.8をターゲットにしたTPRステータスの提案を書くことを計画していました。 提案には、オブジェクト生成の増分を含めることができます。

ルールは、ステータスではなく、仕様の更新時にのみオブジェクトの生成を増やすことですよね？

正しい。

もしそうなら、それは最初にTPRインスタンスでSpec / Status分割を公式にサポートする必要があることを意味します。

ええ、私は既存の問題の一部としてその分割を見つけることを期待していましたが、そこに到達する前に行う必要のある作業がまだあるようです。

@kargakisこれらの項目について言及するためにトップレベルのコメントを編集しましたが、1.7の範囲外です。

/ cc

@ deads2k CustomResourceDefinitionの

CustomResourceDefinitionの短縮名CRDを追加しました。

CustomResourcesの検証のための設計提案： https ：

@ 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のサブリソースの提案： https ：

誤った投稿はご容赦ください。他のkubernetesページからこのページにアクセスしたのは、kubernetesにはサードパーティのコンテナリソースを管理するだけでなく、マイクロサービスフレームワークが含まれていると考えたためです。

RedhatはOpenShiftkubernetesをマイクロサービスプラットフォームとして販売していますが、それでもこの機能を見つけることができないようです。 非常に軽量な独立したアプリケーションマイクロサービスの独自のスイートをホストするための、アプリケーションサーバーのようなものを探しています。

そのようなことが存在するのでしょうか、それとも、springbootでファットJava Warアプリを作成し、それらをkuberenetesマネージドコンテナー内にあるTomcatサーバーにデプロイすることに追いやられているのでしょうか。これは、管理が難しく、デプロイが困難です。 1人の管理者が数百のマイクロサービスを管理および運用できるマイクロサービスプラットフォームが必要です。

この質問は理にかなっていますか？

@hectoraliceaこのリポジトリは、Kubernetes開発者が取り組んでいる機能を計画するために使用されます。

このような一般的な質問については、Kubernetesユーザーグループに投稿してください。 彼らは通常、この種の高レベルの議論にはるかに役立ちます:)

https://groups.google.com/forum/#!forum/kubernetes -users、 http ： //slack.k8s.io/、またはStackOverflowを参照して

@colemickens @ deads2k @nikhita @enisoc I 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に感謝し

@ deads2k、1.9で"安定"のための計画はない、右@enisoc？

@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 ：

@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でます。

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 ： https ：
• カスタムリソースのプルーニングとデフォルト設定を追加します。
• CRD検証スキーマでマップをサポートします。 https://github.com/kubernetes/kubernetes/issues/59485
• カスタムリソースのクォータサポートを実装します（これもバグ修正と見なすことができます） https://github.com/kubernetes/kubernetes/issues/53777

もしそうなら、あなたはその機能が適切なもので最新であることを確認してください：
説明

1行の説明を更新して、「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本体にもこれらを追加してくれませんか？

ラベル：

/種類の機能

/ cc @mbohlool

誰かがPR本体にもこれらを追加してくれませんか？

終わり

@nikhita @sttts @ mbohlool-明確にするために、1.11サイクルのベータ版をターゲットにしていますか？

@nikhita @ sttts @ mbohlool-これについてもう一度pingを実行します...
1.11のベータ版をターゲットにしていますか？ 機能のフリーズが今日であることを確認したいだけです。

@justaugustusCRDはすでにベータ版です。 GAは1.11では計画されていません。

リストされているすべての機能/拡張機能（プルーニング、デフォルト、バージョン管理）は、おそらくアルファ版として開始されます。

@stttsうーん、その場合、それらの機能/拡張機能とそれらのステージを個別に追跡するために、個別の問題が必要ですか？

記録するには- @ nikhitaがサブ機能https://github.com/kubernetes/features/issues/571の問題を作成しました

@sttts @justaugustus

デフォルト設定とプルーニングのサブ機能の問題： https ：

@justaugustus @idvoretskyi 1.12追跡目的：追加とおそらくバグ修正がありますが、これは1.12のベータ版のままです（したがって、機能の観点からの変更はありません）。

アルファ版として計画されている新しいサブ機能がありますが、別の問題として作成されています： //github.com/kubernetes/features/issues/575。

やあ
この拡張機能は以前に追跡されているため、チェックインして、Kubernetes1.13のステージを卒業する計画があるかどうかを確認したいと思います。 このリリースは、より「安定」することを目的としており、積極的なタイムラインがあります。 次の期限に間に合うと確信できる場合にのみ、この拡張機能を含めてください。

• ドキュメント（オープンプレースホルダーPR）：11/8
• コードスラッシュ：11/9
• コードフリーズの開始：11/15
• ドキュメントの完成とレビュー：11/27

1.13拡張トラッキングシートに含める必要がある場合は、今後の追跡とping @ kacole2のために、元の投稿のマイルストーンを更新してください。

ありがとう！

この拡張機能は以前に追跡されているため、チェックインして、Kubernetes1.13のステージを卒業する計画があるかどうかを確認したいと思います。

いいえ、1.13でこれを卒業する予定はありません。 CRDAPIはベータ版のままです。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecyclestale

@ deads2kこんにちは-私は1.14の拡張機能のリーダーであり、この問題をチェックして、1.14リリースで計画されている作業（ある場合）を確認しています。 拡張機能のフリーズは1月29日であり、すべての拡張機能にはKEPが必要であることを思い出してください。

@claurence CRD APIは、1.14でもベータ版のままです。

こんにちは@ nikhita @ deads2k 、私は1.15のエンハンスメントリードです。 この機能は1.15でアルファ/ベータ/安定段階を卒業する予定ですか？ 適切に追跡してスプレッドシートに追加できるように、お知らせください。 KEPは、1.15を含めるためにもマージする必要があります。 ありがとう！

コーディングを開始したら、適切に追跡できるように、この号に関連するすべてのk / kPRをリストしてください。

これはベータ段階のままになります。 検証、変換、およびOpenAPI公開に関する作業は1.15で行われています

1.15の関連するKEPへのリンクを含む更新された説明

ねえ、@liggitt @ deads2k @jpbetz @sttts私はV1.15ドキュメントのリリース影です。

この拡張機能（またはv1.15で計画されている作業）には、新しいドキュメント（または変更）が必要ですか？

5月30日木曜日までに予定されているk / website（ブランチdev-1.15）に対するPRを探しています。 それが完全なドキュメントの始まりであるならばそれは素晴らしいでしょう、しかしプレースホルダーPRでさえ受け入れられます。 ご不明な点がございましたらお知らせください。 😄

@ deads2k @jpbetz @sttts @liggitt

5月30日木曜日までに予定されているk / website（ブランチdev-1.15）に対するPRを探しています。 それが完全なドキュメントの始まりであるならばそれは素晴らしいでしょう、しかしプレースホルダーPRでさえ受け入れられます。 ご不明な点がございましたらお知らせください。 😄

1.15のドキュメントPR： https ：

@ deads2k問題の説明を更新できますか？

/マイルストーンv1.16
/ステージ安定

ねえ、 @ liggitt @ jpbetz @ sttts私はv1.16ドキュメントのリリースリードです。

この拡張機能（またはv1.16で計画されている作業）には、新しいドキュメント（または変更）が必要ですか？

8月23日金曜日までに予定されているk / website（ブランチdev-1.16）に対するPRを探しています。 ご不明な点がございましたらお知らせください。

@simonswineプレースホルダー：//github.com/kubernetes/website/pull/15982

@liggitt @ jpbetz @ sttts木曜日はコードフリーズです。 これがStableに移行するのを妨げる未解決のk / k PRはありますか？ 計画された1.15 *の作業の元の投稿のすべてがマージされているように見えます。

未解決のPRは、機能ゲートバージョンのバンプ（https://github.com/kubernetes/kubernetes/pull/81965）と、今週行われる2つの未解決のバグ修正（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 ：この問題を解決します。