@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://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . Если это сработает, все хорошо. Если это не удается, что-то не так.

@ deads2k Привет, Дэвид, пожалуйста, взгляните на сообщение, которое я отправил в 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 (TPR должен быть удален при удалении пространства имен)

@ deads2k можешь обновить контрольный список?

@ deads2k можешь обновить контрольный список?

Все вопросы по-прежнему не решены. На самом деле это функция для отслеживания проблем в (уже) бета-реализации thirdparyresources из 1.3. Нам нужно было место, где можно было бы отслеживать наши проблемы, но мы должны были посвятить силы другим усилиям в 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

Чтобы снизить сложность TPR в коде apiserver и сделать логику TPR более явной, я бы определенно проголосовал за автономный tpr-apiserver . Но ИМО на самом деле это не блокирует какие-либо исправления.

Я добавляю несколько пунктов об обработке семантики API (получение, список, наблюдение, обновление, исправление) при работе с несколькими неконвертируемыми видами. Я думаю, что для этого, вероятно, потребуется проектный документ, поскольку семантика вряд ли будет соответствовать нормальной семантике API.

Я предприму (еще одну) попытку исправить некоторые из этих проблем ...

https://github.com/kubernetes/kubernetes/pull/40260 и https://github.com/kubernetes/kubernetes/pull/40096 приведут нас в приличную форму на стороне kubectl

Самая серьезная проблема на стороне сервера на данный момент - сборщик мусора теряет сознание из-за ownerRefs, которые указывают на TPR.

Как только мы получим это решение, мы должны решить, какой должна быть семантика API для нескольких версий данного TPR, и убедиться, что тип TPR содержит данные, которые нам нужны. Это, вероятно, повлияет на имплантацию хранилища на стороне сервера, поэтому я бы предпочел разработать дизайн, прежде чем мы будем выполнять слишком много работы на стороне сервера.

@liggitt Я посмотрю на их обзор. Спасибо

У кого-нибудь есть указатель на то, как ссылаться на TPR в правилах RBAC? У меня есть TPR с именем foo-bar.something.example.com. Как администратор кластера я могу получить список foobars в заданном пространстве имен с помощью kubectl get foobars .

Когда обычный пользователь пробует то же самое, он получает Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

Я пробовал все варианты foobar, foo-bar и т.д., которые я мог придумать в правиле RBAC, пока безуспешно.

В правиле вы ищете 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?

Нет, проблема заключалась в том, что сборщик мусора не знал, как искать ownerRefs для чего-либо, кроме скомпилированных в типах. Также существует обратная проблема, когда сборщик мусора не обращает внимания на финализаторы ни на что иное, кроме скомпилированных типов.

Обе эти проблемы со сборщиком мусора отличаются от необходимости надежной очистки объектов ThirdPartyResourceData при удалении объекта ThirdPartyResource.

@liggitt Спасибо за терпеливое объяснение, каков план TPR в 1.6?

GC теперь регистрирует только 1k раз в секунду вместо 50k раз в секунду,
так что он больше не выигрывает гонку с вращателем бревен. Но настоящее исправление будет
скоро, надеюсь.

В субботу, 4 февраля 2017 г., в 23:54 TonyAdo [email protected] написал:

@liggitt https://github.com/liggitt Спасибо за терпеливое объяснение, так что
какой план TPR в 1.6?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на 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 / дашборд-сопровождающие

Каков статус / план для TPR без пространства имен? Обсуждений не нашел, может что-то упустил?

@sttts Для начала меня заинтриговала разработка Kubernetes. И я хочу внести свой вклад в это, но Go для меня новый язык. Что вы, ребята, порекомендуете мне сделать, чтобы получить этот проект для GSoC 2017?

Чтобы добавить кое-что обо мне, я неплохо разбираюсь в C ++ и Java и имею степень бакалавра компьютерных наук. Я также начал читать документацию и прошел курс Udacity по Kubernetes.

@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, чтобы обеспечить более стабильную основу для роста.

Мы планируем продвинуться вперед с https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md в сроки 1.7. Я буду делать обновления здесь и в звонках sig-apimachinery по мере нашего продвижения.

@ deads2k Я не видел там ничего о проверке tpr. Разве вы не сочли бы это тем, что понадобится для бета-тестирования?

@frankgreco, предложение касается прочной основы для построения TPR. Такие функции, как проверка, могут быть добавлены позже, но здесь они не рассматриваются.

Я отредактировал родительский комментарий этой ветки, чтобы использовать новый шаблон и уточнить объем работ, запланированных для 1.7, насколько я понимаю. Пожалуйста, просмотрите это и исправьте / прокомментируйте.

@ deads2k @enisoc Мы недавно начали использовать TPR, и проверка TPR будет очень важной для некоторых из наших будущих проектов. Если у нас есть ресурсы для работы, не могли бы вы принять участие в программе сообщества, чтобы это произошло?

@ deads2k @enisoc Мы недавно начали использовать TPR, и проверка TPR будет очень важной для некоторых из наших будущих проектов. Если у нас есть ресурсы для работы, не могли бы вы принять участие в программе сообщества, чтобы это произошло?

Абсолютно. Для чего-то вроде этого нам нужно предложение по дизайну, прежде чем мы начнем рассматривать запросы на вытягивание. Кроме того, учитывая, сколько различных подходов возможно, я бы посоветовал вам перечислить три или около того идей и дать краткое объяснение, почему тот, который вы выберете, является лучшим. Со стороны сервера очень важны соображения производительности и безопасности.

Кроме того, поскольку это далеко идущая функция, важно, чтобы она не превратилась в дополнительный вклад. Помогли бы активные взносы (обзоры, тесты, код, миграция) для перехода на https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md . Я deads2k на Slack, если вам интересно и вы хотите поговорить.

Спасибо @ deads2k! Это совершенно разумно. Мы подготовим несколько предложений по дизайну для проверки TPR, как лучше всего ими поделиться? Я тоже расслаблюсь

@ xiao-zhou, мы рады, что приняли проект Google Summer of Code по этой самой теме (о котором было объявлено только вчера). Давайте поговорим в Slack о том, как совместно работать над этим. Очень здорово, что вы тоже заинтересованы в этом, так что у нас есть достаточно сил, чтобы продвигать это вперед!

@ xiao- zhou @sttts @ deads2k, как только у вас появится предложение о проверке TPR (и, в идеале, по умолчанию), помните, отметьте меня в обзоре предложения? Спасибо

@sdminonne он будет размещен в sig-apimachinery. Если вы подпишетесь на эту группу Google, вы должны получить уведомление.

@sttts спасибо

@ deads2k , собираетесь ли вы добавить ObservedGeneration для TPR?

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

@ deads2k , собираетесь ли вы добавить ObservedGeneration для TPR?

Я не планировал. Не может ли заинтересованный клиент просто сравнить имена спецификаций и статусов?

сравнить имена спецификаций и статусов?

Не уверен, что вы здесь имеете в виду. Поправьте меня Если я ошибаюсь, но я думаю, что ObservedGeneration состоит из двух частей: 1) сервер API должен обновлять metadata.generation каждый раз, когда есть обновление в спецификации TPR и 2) контроллер, ответственный за TPR обновляет status.observedGeneration на основе metadata.Generation . Я думаю, 1) это то, о чем я вас спрашиваю, и 2) что-то, о чем должны позаботиться авторы TPR?

Не уверен, что вы здесь имеете в виду. Исправьте меня Если я ошибаюсь, но я думаю, что есть две части, относящиеся к ObservedGeneration: 1) сервер API должен обновлять metadata.generation каждый раз, когда есть обновление в спецификации TPR и 2) контроллер, ответственный за статус обновлений TPR .observedGeneration на основе метаданных. Я думаю, 1) это то, о чем я вас спрашиваю, и 2) что-то, о чем должны позаботиться авторы TPR?

О, я неправильно понял, о чем вы спрашивали. Вы хотите наблюдать генерацию для CustomResource, а не CustomResourceDefinition. Я думал, что наблюдение за генерацией было затронуто только из-за изменений в спецификации, требующих действий. Это означает, что обновление метаданных не запускало его, а обновление некоторых полей спецификации также могло избежать его столкновения.

В моем комментарии, приведенном выше, я просил о поддержке генерации экземпляров TPR, а не самих TPR (хотя это тоже было бы неплохо. Есть ли причины не добавлять его ко всем объектам?).

Например, если у меня есть Kind: TPR; name: foo.example.com и экземпляр этого TPR Kind: Foo; name: foo123 , меня интересует Generation / ObservedGeneration для foo123 чтобы контроллер Foo мог сообщить потребителям Foo, обработал ли он обновление экземпляра foo123 . Имеет ли это смысл? Я не понимаю, как этого можно достичь без надлежащей поддержки на стороне сервера k8s.

Да, генерация / наблюдаемое поколение имеет смысл для пользовательской схемы TPR, а не для фактического ресурса TPR по мере его развития.

@kargakis Правило состоит в том, чтобы увеличивать генерацию объекта только при обновлении спецификации, а не статуса, верно? Если это так, это означает, что нам сначала нужно официально поддержать разделение Spec / Status на экземпляре TPR. Я планировал написать предложение по статусу TPR с таргетингом на 1.8. Я могу обязательно включить в предложение увеличивающуюся генерацию объектов.

Правило состоит в том, чтобы увеличивать генерацию объекта только при обновлении спецификации, а не статуса, верно?

Верный.

Если это так, это означает, что нам сначала нужно официально поддержать разделение Spec / Status на экземпляре TPR.

Да, я ожидал найти этот раскол как часть существующей проблемы, но, похоже, нужно еще поработать, прежде чем мы доберемся до нее ...

@kargakis Я отредактировал комментарий верхнего уровня, чтобы упомянуть эти элементы, хотя они выходят за рамки 1.7.

/ cc

@ deads2k Должны ли мы добавить короткое имя для CustomResourceDefinition?

Добавлено короткое имя CRD для CustomResourceDefinition .

Проектное предложение для проверки CustomResources: https://github.com/kubernetes/community/pull/708 : smile:

@ deads2k @enisoc @lavalamp
было интересно, может ли пользователь настроить контроллер k8s И (ИЛИ) методы CURD для объектов CRD

В моем конкретном случае использования я создаю networks.stable.example.com CRD и использую его для создания сетевого объекта net1:

Мне нужно убедиться, что новый объект Network CRD не может быть создан, если объект Network CRD с перекрывающимся диапазоном подсети уже существует.

Если такого механизма не существует, я буду счастлив объединить некоторые мысли в дизайн-документ.

Как упоминалось в примечаниях к выпуску 1.7 и документации, TPR устарел, и мы планируем удалить его в 1.8. Пользователи должны перейти на CRD в течение периода 1.7.

Прокомментируйте проблему отслеживания для удаления, если у вас есть какие-либо вопросы или проблемы.

Обновления / планы для 1.8:

• Поддержка проверки на основе схемы JSON и значений по умолчанию для CustomResources ( предложение )
• Добавьте подресурсы (например, статус и масштаб) для CR (~ предложение скоро будет опубликовано ~ предложение )

Спасибо @nikhita. Я отредактировал верхний комментарий, чтобы отразить планы 1.8.

Discovery возвращает правильную информацию для CR, но REST mapper ее не использует - https://github.com/kubernetes/kubernetes/issues/49948

Предложение для субресурсов для CustomResources: https://github.com/kubernetes/community/pull/913 : tada:

Прошу простить мою ошибку, но я пришел на эту страницу с какой-то другой страницы кубернетов, думая, что кубернеты включают фреймворк микросервисов, помимо управления ресурсами сторонних контейнеров.

Redhat продвигает OpenShift kubernetes как платформу для микросервисов, но пока я не могу найти эту функцию. Я ищу сервер приложений, чтобы разместить мой собственный набор очень легких независимых микросервисов приложений.

Существует ли такая вещь, или мы вынуждены создавать толстые военные Java-приложения в springboot и развертывать их на сервере tomcat, который находится внутри управляемого контейнера kuberenetes, которым сложно управлять и сложно развертывать. Мне нужна платформа микросервисов, где один администратор может управлять сотнями микросервисов и управлять ими.

Имеет ли смысл этот вопрос?

@hectoralicea это репо используется для планирования функций, над которыми работают разработчики Kubernetes.

По общим вопросам, подобным этому, отправляйте сообщения в группы пользователей Kubernetes. Обычно они намного более полезны для такого рода обсуждений на высоком уровне :)

См. Https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ или Stack Overflow.

@colemickens @ deads2k @nikhita @enisoc Я добавил раздел для 1.9.

@sttts Улучшенная бета-версия в v1.9, верно?

Конечно, @luxas исправляет

@sttts Я думал о проверке CRD ... это охвачено этой проблемой функций и перейдет в бета-версию в версии 1.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 планов на "стабильную"

@idvoretskyi Верно.

@ deads2k : wave: Откройте PR документации и добавьте ссылку на таблицу отслеживания. Заранее спасибо!

@ deads2k Откройте PR документации и добавьте ссылку на таблицу отслеживания. Заранее спасибо!

@zacharysarah Кажется, я потерял ссылку на электронную таблицу. Документы для проверки CRD здесь https://github.com/kubernetes/website/pull/6066

Для записи, проблема с версией CRD существует здесь: https://github.com/kubernetes/features/issues/544.

Список задач для CRD, переходящих в GA: 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).

Мы перейдем в GA, как только будут решены все вопросы, не перечеркнутые в https://github.com/kubernetes/kubernetes/issues/58682 .

Когда API CRD переходит на 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?

Ярлыки:

/ kind feature

/ cc @mbohlool

Может ли кто-нибудь добавить их и в PR?

сделано

@nikhita @sttts @mbohlool - просто чтобы уточнить, ориентируемся ли мы на бета-версию цикла 1.11?

@nikhita @sttts @mbohlool - снова пингуюсь по этому поводу ...
Мы ориентируемся на бета-версию 1.11? Просто хочу убедиться, что сегодня замораживание функций.

CRD @justaugustus уже находятся в стадии бета-тестирования. 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 с открытыми заполнителями): 8/11
• Кодекс Slush: 11/9
• Начало замораживания кода: 15/11
• Документы заполнены и проверены: 27 ноября

Уделите время, чтобы обновить вехи в исходном сообщении для будущего отслеживания, и ping лист отслеживания улучшений 1.13.

Спасибо!

Это улучшение отслеживалось и раньше, поэтому мы хотели бы проверить и посмотреть, есть ли какие-либо планы по переходу этапов в Kubernetes 1.13.

Нет, выпускать это в 1.13 не планируется. CRD API останется в стадии бета-тестирования.

Проблемы устаревают после 90 дней бездействия.
Отметьте проблему как новую с помощью /remove-lifecycle stale .
Устаревшие выпуски гниют после дополнительных 30 дней бездействия и в конечном итоге закрываются.

Если сейчас можно безопасно закрыть эту проблему, сделайте это с помощью /close .

Отправьте отзыв в sig-testing, kubernetes / test-infra и / или fejta .
/ жизненный цикл устаревший

/ remove-жизненный цикл устаревший

@ deads2k Здравствуйте! Я руководитель усовершенствования версии 1.14, и я проверяю эту проблему, чтобы узнать, какие работы (если таковые имеются) планируются для выпуска 1.14. Заморозка улучшений 29 января, и я хочу напомнить, что все улучшения должны иметь KEP

@claurence CRD API останется в бета-версии и для версии 1.14.

Привет @nikhita @ deads2k , я руководитель отдела улучшения 1.15. Будет ли эта функция переходить на стадии альфа / бета / стабильная версия в 1.15? Пожалуйста, дайте мне знать, чтобы его можно было правильно отследить и добавить в электронную таблицу. KEP также необходимо будет объединить для включения 1.15. Спасибо!

Как только начнется кодирование, перечислите все соответствующие PR в этом выпуске, чтобы их можно было правильно отслеживать.

это останется в стадии бета-тестирования. работа над проверкой, преобразованием и публикацией OpenAPI ведется в версии 1.15.

обновленное описание со ссылками на соответствующие KEP для 1.15

Привет, @liggitt @ deads2k @jpbetz @sttts Я тень выпуска документации v1.15.

Требуются ли для этого улучшения (или работы, запланированной в версии 1.15) какие-либо новые документы (или модификации)?

Напоминаем, что нам нужен PR-адрес k / website (ветка dev-1.15) до четверга, 30 мая. Было бы здорово, если бы это начало полной документации, но приемлем даже PR-заполнитель. Дайте знать, если у вас появятся вопросы! 😄

@ deads2k @jpbetz @sttts @liggitt

Напоминаем, что нам нужен PR-адрес k / website (ветка dev-1.15) до четверга, 30 мая. Было бы здорово, если бы это начало полной документации, но приемлем даже PR-заполнитель. Дайте знать, если у вас появятся вопросы! 😄

Документы PR для 1.15: https://github.com/kubernetes/website/pull/14583

@ deads2k можешь обновить описание проблемы?

/ веха v1.16
/ сценическая конюшня

Привет, @liggitt @jpbetz @sttts Я руководитель выпуска документации

Требуются ли для этого улучшения (или работы, запланированной в версии 1.16) какие-либо новые документы (или модификации)?

Напоминаем, что мы ждем PR против k / website (ветка dev-1.16) до пятницы, 23 августа. Дайте знать, если у вас появятся вопросы!

@simonswine PR местозаполнителя https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts Четверг - замораживание кода. Существуют ли какие-либо невыполненные K / K PR, которые не позволят ему перейти в стабильный? Все в исходном сообщении о запланированной работе 1.15 *, похоже, будет объединено.

Я считаю, что выдающиеся PR - это просто удар версии функции Gate (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

Выпущен как стабильный в версии 1.16.0

Работа после GA отслеживается в https://github.com/orgs/kubernetes/projects/28

/близко

@liggitt : закрытие этого вопроса.