@lavalamp He creado esto para tratar de tener un lugar donde al menos podamos consolidar nuestros pensamientos y seguir el progreso de los recursos de terceros. Intenté crear una lista de deficiencias conocidas para resolver antes de la promoción a estable.

No tengo un propietario en mente, pero el reconocimiento del problema parece el paso 1.

@ deads2k Estoy aprendiendo sobre recursos de terceros recientemente, también deseo ayudar con algo.

@ deads2k Estoy aprendiendo sobre recursos de terceros recientemente, también deseo ayudar con algo.

He reordenado la lista en términos de lo que veo como prioridad táctica. La gente está tratando de usar esto ahora y estos problemas los quemarán mucho.

Si se siente cómodo tomando el ítem "recursos múltiples", sería un gran comienzo. Puede crear un problema separado y podemos hablar sobre la implementación allí.

@ deads2k Pasé algún tiempo tratando de reproducir el primer problema:

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.

pero con mala suerte. A continuación se muestran mis pasos de reproducción:

1. cree un recurso de terceros personalizado y espere a que aparezca

[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. después de un momento (más de 10 segundos), cree otro recurso de terceros personalizado

[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. verificar que ambos recursos existan

[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.

Parece que ya admitimos múltiples recursos, versión única.

Y echo un vistazo profundo al código relacionado con TPR. El thirdparty_controller se sincronizará periódicamente (cada 10 segundos), instalará cada nuevo TPR y también realizará un trabajo de eliminación. El ThirdPartyResourceServer contiene todas las asignaciones TPR instaladas. Como podemos ver en SyncOneResource y InstallThirdPartyResource , incluso si este grupo existe, seguirá actualizando el grupo con la nueva API.

También descubrí que puedo eliminar una definición de esquema TPR incluso si hay instancias de TPR en el sistema. Creo que esto no debería permitirse.

@ deads2k Pasé algún tiempo tratando de reproducir el primer problema:

Intente habilitar esta prueba: https://github.com/kubernetes/kubernetes/blob/master/test/integration/thirdparty/thirdparty_test.go#L137 . Si funciona, estamos bien. Si falla, algo anda mal.

@ deads2k Hola David, por favor mira el mensaje que envié en Slack. Además, agrego una solución a la prueba de integración fallida, el controlador de recursos de terceros eliminará el controlador de rutas correspondiente cuando se elimine un TPR, esto ayudará con la prueba de integración, pero no estoy seguro de si esto traerá otros problemas .

Para el problema n. ° 1, se solucionó aquí:

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

@brendandburns en realidad no, puede ejecutar la prueba de integración de comentarios y fallará.

@brendandburns Más correctamente,

@AdoHe presentaste un problema? Puedo echar un vistazo.

@brendandburns puedes ver aquí:

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

habilite esta prueba y verá que fallará. Intenté arreglar esto en mi local y abriré un PR más tarde hoy.

@brendandburns Me temo que no

También consulte https://github.com/kubernetes/kubernetes/issues/32306 (TPR debe eliminarse cuando se elimina el espacio de nombres)

@ deads2k ¿puedes actualizar la lista de verificación?

@ deads2k ¿puedes actualizar la lista de verificación?

Todos los problemas siguen pendientes. Esta es en realidad una función para rastrear los problemas en la implementación (ya) beta thirdparyresources de 1.3. Necesitábamos un lugar para realizar un seguimiento de nuestros problemas, pero tuvimos que dedicar energía a otros esfuerzos en 1.5.

@ deads2k Ya estoy trabajando en Multiple Resources, single version y Multiple versions , creo que es necesario actualizar una gran cantidad de código.

¿@ deads2k todavía presenta el objetivo 1.5?

@idvoretskyi Me temo que no :(

@ deads2k : ThirdPartyResources debe agregarse a las API federadas.

@ deads2k : Actualmente, los selectores de campo no funcionan al consultar ThirdPartyObjects, ¿es algo para su lista?

@ deads2k @rmohr kubectl todavía tiene muchas capacidades sobresalientes contra TPR, la lista anterior debe actualizarse para rastrearlas.

@ deads2k : Actualmente, los selectores de campo no funcionan al consultar ThirdPartyObjects, ¿es algo para su lista?

Ese es un problema más general de compatibilidad con el selector de campo inconsistente en todos los tipos de API.

Estoy empezando a ver esto también. ThirdPartyResources es muy importante para admitir controladores "externos" como Spark , y antes de que podamos agregar cosas como sub-recursos, deberíamos arreglar esto.

Los selectores de campo solo funcionan en campos seleccionados a mano en los objetos API normales. No esperaría que funcionen para ningún campo en los TPR; apiserver no está diseñado para realizar consultas arbitrarias. Si necesita ese comportamiento, TPR no funcionará para usted.

¿El siguiente paso es mover los TPR a un servidor API adicional ?
Parece que hay algunos RP pendientes para solucionar algunos de los problemas de la lista aquí que pueden estar bloqueados en este elemento.

/ cc @liggitt @ deads2k @AdoHe

Para reducir la complejidad de los TPR en el código de apiserver y hacer que la lógica de TPR sea mucho más explícita, definitivamente votaría por un tpr-apiserver independiente. Pero en mi opinión, esto realmente no bloquea ninguna de las correcciones.

Estoy agregando algunos elementos sobre el manejo de la semántica de la API (obtener, listar, observar, actualizar, parchear) cuando se trata de varios tipos no convertibles. Creo que probablemente necesite un documento de diseño, ya que es poco probable que la semántica coincida con la semántica normal de la API.

Tomaré (otra más) carrera para solucionar algunos de estos problemas ...

https://github.com/kubernetes/kubernetes/pull/40260 y https://github.com/kubernetes/kubernetes/pull/40096 nos pondrán en buena forma en el lado de kubectl

El problema más grave del lado del servidor en este momento es que el recolector de basura se está volviendo loco por ownerRefs que apuntan a los TPR.

Una vez que resolvamos eso, debemos decidir cuál debe ser la semántica de la API en torno a múltiples versiones de un TPR dado, y asegurarnos de que el tipo de TPR tenga los datos que necesitamos. Es probable que eso afecte a la implicación de almacenamiento del lado del servidor, por lo que prefiero concretar el diseño antes de hacer demasiado trabajo del lado del servidor.

@liggitt Echaré un vistazo a revisarlos. Gracias

¿Alguien tiene una idea de cómo hacer referencia a los TPR en las reglas de RBAC? Tengo un TPR llamado foo-bar.something.example.com. Como administrador de clúster, puedo obtener una lista de foobars en un espacio de nombres dado con kubectl get foobars .

Cuando un usuario habitual intenta lo mismo, obtiene Error from server (Forbidden): the server does not allow access to the requested resource (get foobars.something.example.com) .

He probado todas las variaciones de foobar, foo-bar, etc. que se me ocurren en una regla RBAC sin suerte hasta ahora.

En la regla, estás buscando resource = foobars apigroup = something.example.com verb = get, list, watch

@ deads2k Eso funcionó. ¡Gracias!

@liggitt

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

¿Algo relacionado con el problema de la limpieza de TPR?

No, fue un problema con el recolector de basura que no sabía cómo buscar ownerRefs para cualquier otra cosa que no fuera compilada en tipos. El problema inverso también existe, ya que el recolector de basura no presta atención a los finalizadores en nada más que en los tipos compilados.

Ambos problemas del recolector de basura son distintos de la necesidad de limpiar los objetos ThirdPartyResourceData de manera confiable cuando se elimina el objeto ThirdPartyResource.

@liggitt Gracias por la paciente explicación, ¿cuál es el plan de TPR en 1.6?

El GC ahora solo registra 1000 veces por segundo en lugar de 50000 veces por segundo,
por lo que ya no gana la carrera con el rotador de troncos. Pero una verdadera solución será
próximamente, con suerte.

El sábado 4 de febrero de 2017 a las 11:54 p.m., TonyAdo [email protected] escribió:

@liggitt https://github.com/liggitt Gracias por la paciente explicación.
¿Cuál es el plan de TPR en 1.6?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/kubernetes/features/issues/95#issuecomment-277503470 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AAnglmGf00K6W7SsJ1aSqWOI_M-A7Hf2ks5rZYBPgaJpZM4KLBmK
.

Algunas de las cuestiones pendientes relacionadas con la TPR. No exhaustivo.

Problemas de grupo / versión: https://github.com/kubernetes/kubernetes/pull/24299 , https://github.com/kubernetes/kubernetes/pull/36977
Ver: https://github.com/kubernetes/kubernetes/issues/25340
Autoenlace: https://github.com/kubernetes/kubernetes/issues/37622
Eliminación del espacio de nombres: https://github.com/kubernetes/kubernetes/issues/37554
GC: https://github.com/kubernetes/kubernetes/issues/39816
Finalizadores: https://github.com/kubernetes/kubernetes/issues/40715
Limpieza de datos de TPR: https://github.com/kubernetes/kubernetes/issues/35949
Validación más sólida de metadatos: https://github.com/kubernetes/kubernetes/issues/22768#issuecomment -215940468
Falta de pruebas unitarias: https://github.com/kubernetes/kubernetes/pull/40956
Limpieza: https://github.com/kubernetes/kubernetes/issues/36998

Funciones que los usuarios piensan que son errores porque funcionan para otros recursos:
Comportamiento asincrónico: https://github.com/kubernetes/kubernetes/issues/29002
Enteros: https://github.com/kubernetes/kubernetes/issues/30213
YAML: https://github.com/kubernetes/kubernetes/issues/37455
Salida decente de kubectl: https://github.com/kubernetes/kubernetes/issues/31343
Simplifique la denominación de recursos: https://github.com/kubernetes/kubernetes/issues/29415
Aplicar: https://github.com/kubernetes/kubernetes/issues/29542 , https://github.com/kubernetes/kubernetes/issues/39906
Editar: https://github.com/kubernetes/kubernetes/issues/35993

/ cc

Suscripción mientras intentamos gestionar los TPR en Dashboard.

Los problemas de seguimiento son https://github.com/kubernetes/dashboard/issues/1671 y https://github.com/kubernetes/dashboard/issues/1504.

@ kubernetes / mantenedores de paneles

¿Cuál es el estado / plan de TPR sin espacios de nombres? No encontré discusiones al respecto, ¿tal vez me perdí algo?

@sttts Para empezar, me intriga el desarrollo de Kubernetes. Y quiero contribuir a ello, pero Go es un idioma nuevo para mí. ¿Qué me recomiendan hacer para poder obtener este proyecto para GSoC 2017?

Para agregar algo sobre mí, soy bastante bueno en C ++ y Java y tengo una licenciatura en Ciencias de la Computación. También comencé a leer la documentación y tomé el curso de Udacity que involucra a Kubernetes.

@grpndrs tenemos una lista de problemas etiquetados que son un buen punto de partida para entrar en el código: https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Afor-new -contribuidores. No dude en ponerse en contacto conmigo en holgura y podemos revisar algunos de ellos.

@enisoc

¿Sigue siendo Multiple Resources, single version, different add times un problema? Puedo crear y eliminar varios TPR sin ningún problema.

Además, ¿podemos numerar las casillas de verificación en Outstanding Capabilities para que sea más fácil de consultar? @ deads2k creo que puedes hacerlo así:

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

¿Alguien sabe cómo va el componente de validación de esto? Trabajo mucho con TPR y esta característica no tendría precio y ahorraría MUCHO código personalizado. Me encantaría contribuir a esta función, pero me gustaría saber si alguien suscrito a este problema conoce su estado.

¿Alguien sabe cómo va el componente de validación de esto?

No espero que suceda en 1.7. Por el momento, estamos discutiendo algunos problemas de crecimiento estructural aquí https://github.com/kubernetes/community/pull/524 para proporcionar una base más estable sobre la cual crecer.

No espero que suceda en 1.7. Por el momento, estamos discutiendo algunos problemas de crecimiento estructural aquí kubernetes / community # 524 para proporcionar una base más estable sobre la cual crecer.

Planeamos seguir adelante con https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md en el plazo de 1.7. Haré actualizaciones aquí y en las llamadas sig-apimachinery a medida que avancemos.

@ deads2k No vi nada allí sobre la validación de tpr. ¿No consideraría que es algo que se necesitaría para la versión beta?

@frankgreco, la propuesta trata sobre una base sólida sobre la que construir los

He editado el comentario principal de este hilo para usar la nueva plantilla y para aclarar el alcance del trabajo planeado para 1.7, según tengo entendido. Por favor, revíselo y corrija / comente.

@ deads2k @enisoc Recientemente comenzamos a usar TPR, y la validación de TPR será bastante crítica para algunos de nuestros próximos proyectos. Si tenemos los recursos para trabajar en ello, ¿consideraría aceptar colaboradores de la comunidad para que esto suceda?

@ deads2k @enisoc Recientemente comenzamos a usar TPR, y la validación de TPR será bastante crítica para algunos de nuestros próximos proyectos. Si tenemos los recursos para trabajar en ello, ¿consideraría aceptar colaboradores de la comunidad para que esto suceda?

Absolutamente. Para algo como esto, querríamos una propuesta de diseño antes de comenzar a buscar solicitudes de extracción. Además, dada la cantidad de enfoques diferentes posibles, le sugiero que enumere las tres ideas principales y dé una breve explicación de por qué el que elija es el mejor. Desde el lado del servidor, las consideraciones de rendimiento y seguridad son muy importantes.

Además, dado que se trata de una función de gran alcance, es importante que no se convierta en una contribución automática. Las contribuciones activas (revisiones, pruebas, código, migración) para la transición a https://github.com/kubernetes/community/blob/master/contributors/design-proposals/thirdpartyresources.md ayudarían. Estoy deads2k en holgura si estás interesado y quieres hablar.

¡Gracias @ deads2k! Eso es totalmente razonable. Propondremos algunas propuestas de diseño para la validación de TPR, ¿cuál es la mejor manera de compartirlo? Yo también llegaré a holgazanear

@ xiao-zhou estamos felices de tener un proyecto Google Summer of Code aceptado en torno a este mismo tema (se anunció ayer). Charlemos en Slack sobre cómo colaborar en esto. Es genial que también estés interesado en esto, ¡así que tenemos bastante fuerza para impulsar esto!

@ xiao-zhou @sttts @ deads2k tan pronto tenga una propuesta para la validación de TPR (e idealmente por defecto), ¿me etiquetará en la revisión de la propuesta? Gracias

@sdminonne se publicará en sig-apimachinery. Si se suscribe a ese grupo de Google, debería recibir una notificación.

@sttts gracias

@ deads2k , ¿va a agregar ObservedGeneration para los TPR?

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

@ deads2k , ¿va a agregar ObservedGeneration para los TPR?

No estaba planeando hacerlo. ¿No podría un cliente que se preocupa simplemente comparar los nombres de especificaciones y estados?

comparar los nombres de especificaciones y estados?

No estoy seguro de a qué te refieres aquí. Corríjame si me equivoco, pero creo que hay dos partes en la generación observada: 1) el servidor de API necesita actualizar metadata.generation cada vez que hay una actualización en las especificaciones del TPR y 2) el controlador responsable de la TPR actualiza status.observedGeneration basado en metadata.Generation . Supongo que 1) es lo que le estoy preguntando y 2) ¿es algo de lo que los autores de TPR deben ocuparse?

No estoy seguro de a qué te refieres aquí. Corríjame si me equivoco, pero creo que hay dos partes con respecto a ObservedGeneration: 1) el servidor de API necesita actualizar metadata.generation cada vez que hay una actualización en las especificaciones del TPR y 2) el controlador responsable del estado de actualizaciones de TPR .observedGeneration basado en metadata.Generation. Supongo que 1) es lo que le estoy preguntando y 2) ¿es algo de lo que los autores de TPR deben ocuparse?

Oh, entendí mal sobre qué preguntabas. Desea observadoGeneration para CustomResource, no CustomResourceDefinition. Pensé que la generación observada solo se vio afectada por cambios en las especificaciones que requerían acción. Lo que significa que una actualización de los metadatos no lo activó y una actualización de algunos campos de especificaciones también podría evitar chocarlo.

En mi comentario vinculado anteriormente, estaba solicitando soporte de Generación para instancias de TPR, no para los TPR en sí mismos (aunque eso también sería bueno. ¿Alguna razón para no agregarlo a todos los objetos?).

Por ejemplo, si tengo Kind: TPR; name: foo.example.com y una instancia de ese TPR Kind: Foo; name: foo123 , estoy interesado en Generation / ObservedGeneration por foo123 para que el controlador de Foo pueda informar a los consumidores de Foo si se ha procesado una actualización de la instancia foo123 . ¿Tiene sentido? No veo cómo se puede lograr esto sin el soporte adecuado en el lado del servidor k8s.

Sí, la generación / generación observada tiene sentido para el esquema de usuario del TPR y no para el recurso TPR real a medida que ha evolucionado.

@kargakis La regla es solo incrementar la generación de objetos en la actualización de especificaciones, no en el estado, ¿verdad? Si es así, significa que primero debemos admitir oficialmente la división Spec / Status en la instancia TPR. Estaba planeando escribir una propuesta para el estado de TPR, con el objetivo de 1.8. Puedo asegurarme de incluir el incremento de la generación de objetos en la propuesta.

La regla es solo incrementar la generación de objetos en la actualización de las especificaciones, no en el estado, ¿verdad?

Correcto.

Si es así, significa que primero debemos admitir oficialmente la división Spec / Status en la instancia TPR.

Sí, esperaba encontrar esa división como parte del problema existente, pero parece que hay más trabajo por hacer antes de que lleguemos allí ...

@kargakis He editado el comentario de nivel superior para mencionar estos elementos, aunque están fuera del alcance de 1.7.

/ cc

@ deads2k ¿Deberíamos agregar un nombre corto para CustomResourceDefinition?

Se agregó CRD de nombre corto para CustomResourceDefinition .

Una propuesta de diseño para la validación de CustomResources: https://github.com/kubernetes/community/pull/708 : smile:

@ deads2k @enisoc @lavalamp
me preguntaba si el usuario puede configurar el controlador k8s Y (O) los métodos CURD para los objetos CRD

En mi caso de uso particular, creo un networks.stable.example.com CRD y lo uso para crear el objeto de red net1:

Necesito asegurarme de que no se permita la creación de un nuevo objeto CRD de red si ya existe un objeto CRD de red con un rango de subred superpuesto

Si tal mecanismo no existe, estaré encantado de poner algunas ideas juntas en un documento de diseño.

Como se menciona en las notas y documentos de la versión 1.7, TPR ahora está obsoleto y planeamos eliminarlo en 1.8. Los usuarios deben cambiar a CRD durante el período de 1.7.

Comente sobre el problema de seguimiento para su eliminación si tiene alguna pregunta o inquietud.

Actualizaciones / Planes para 1.8:

• Admite la validación basada en el esquema JSON y la configuración predeterminada para CustomResources ( propuesta )
• Agregue sub-recursos (como el estado y la escala) para los CR (~ propuesta que saldrá pronto ~ propuesta )

Gracias @nikhita. He editado el comentario superior para reflejar los planes 1.8.

Discovery devuelve información correcta para los CR, pero el asignador REST no la usa: https://github.com/kubernetes/kubernetes/issues/49948

Propuesta de subrecursos para CustomResources: https://github.com/kubernetes/community/pull/913 : tada:

Por favor, perdone mi publicación errónea, pero llegué a esta página desde otra página de kubernetes pensando que kubernetes incluía un marco de microservicios, más allá de solo para administrar recursos de contenedores de terceros.

Redhat comercializa OpenShift kubernetes como una plataforma de microservicios, pero aún así, parece que no puedo encontrar esta función. Estoy buscando un servidor de aplicaciones para alojar mi propio conjunto de microservicios de aplicaciones independientes muy ligeros.

¿Existe tal cosa, o estamos relegados a crear aplicaciones fat java war en springboot e implementarlas en un servidor tomcat que se encuentra dentro de un contenedor administrado por kuberenetes, que es difícil de administrar y difícil de implementar? Necesito una plataforma de microservicios donde un administrador pueda gestionar y operar cientos de microservicios.

¿Esta pregunta tiene sentido?

@hectoralicea este repositorio se utiliza para planificar funciones en las que trabajaron los desarrolladores de Kubernetes.

Para preguntas generales como esta, publíquelas en los grupos de usuarios de Kubernetes. Por lo general, son mucho más útiles para este tipo de discusión de alto nivel :)

Consulte https://groups.google.com/forum/#!forum/kubernetes -users, http://slack.k8s.io/ o Stack Overflow.

@colemickens @ deads2k @nikhita @enisoc He agregado una sección para 1.9.

@sttts Versión beta mejorada en v1.9, ¿verdad?

Corrección de errores de

@sttts Estaba pensando en la validación de CRD ... ¿está cubierto en este problema de características y pasará a beta en v1.9 o?

@luxas del post inicial

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

Oh, gracias @kargakis , no

@ deads2k , @enisoc no hay planes para "estable" en 1.9, ¿verdad?

@idvoretskyi Correcto.

@ deads2k : wave: abra un PR de documentación y agregue un enlace a la hoja de cálculo de seguimiento. ¡Gracias por adelantado!

@ deads2k Abra un PR de documentación y agregue un enlace a la hoja de cálculo de seguimiento. ¡Gracias por adelantado!

@zacharysarah Parece que he https://github.com/kubernetes/website/pull/6066

Para el registro, el problema de control de versiones de CRD existe aquí: https://github.com/kubernetes/features/issues/544.

Lista de tareas para los CRD que se trasladan a GA: https://github.com/kubernetes/kubernetes/issues/58682

@nikhita, ¿significa que toda la función CRD se está moviendo a GA?

¿Significa que toda la función CRD se está moviendo a GA?

La API se moverá a GA, es decir, a v1, aunque posiblemente con algunas subcaracterísticas beta / alpha. Sin embargo, no se termina cuando esto sucederá, es decir, si 1.10 es factible.

@sttts @nikhita ¿ Puede definir la hoja de ruta de funciones con mayor precisión?

¿Puede definir la hoja de ruta de funciones con mayor precisión?

Para 1.10:

• subrecursos para recursos personalizados y correcciones de errores (al menos los que no están tachados) enumerados en https://github.com/kubernetes/kubernetes/issues/58682.

No hay un conjunto _exact_ de entregables planificados para los próximos lanzamientos, pero el plan es pasar a GA antes de fin de año (https://groups.google.com/forum/#!topic/kubernetes-sig-api-machinery/ 07JKqCzQKsc).

Iremos a GA una vez que se completen todos los problemas que no están tachados en https://github.com/kubernetes/kubernetes/issues/58682 .

Cuando la API de CRD pasa a GA, puede haber características en ella (ejemplo: CustomResourceValidation https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiextensions-apiserver/ pkg / features / kube_features.go # L35) que podría estar en alfa / beta.

@sttts @nikhita @ deads2k
¿Algún plan para esto en 1.11?

Si es así, ¿puede asegurarse de que la función esté actualizada con lo siguiente?

• Descripción
• Hito
• Cesionario (s)
• Etiquetas:
  
  
  
  • stage/{alpha,beta,stable}
  
  
  • sig/*
  
  
  • kind/feature
  
  

cc @idvoretskyi

¿Algún plan para esto en 1.11?

No tengo permisos para editar el cuerpo de relaciones públicas (si alguien puede hacer eso, ¡sería genial!). Pero el plan es:

• Implementar el control de versiones de CRD. Esto tiene otro problema de características: https://github.com/kubernetes/features/issues/544. Propuesta de diseño: https://github.com/kubernetes/community/pull/2026.
• Agregue la poda y el valor predeterminado para los recursos personalizados.
• Soporta mapas en el esquema de validación CRD. https://github.com/kubernetes/kubernetes/issues/59485
• Implementar soporte de cuotas para recursos personalizados (esto también se puede considerar como una corrección de errores) https://github.com/kubernetes/kubernetes/issues/53777

Si es así, ¿puede asegurarse de que la función esté actualizada con lo siguiente?
Descripción

La descripción de una línea debe actualizarse para incluir "Agregar validación, valores predeterminados, subrecursos y control de

Las propuestas de diseño mencionadas en la descripción deben incluir:

• 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

¿Alguien puede agregar estos también en el cuerpo de relaciones públicas?

Etiquetas:

/ tipo de característica

/ cc @mbohlool

¿Alguien puede agregar estos también en el cuerpo de relaciones públicas?

hecho

@nikhita @sttts @mbohlool : solo para aclarar, ¿estamos apuntando a la versión beta para el ciclo 1.11?

@nikhita @sttts @mbohlool -
¿Estamos apuntando a la versión beta de la versión 1.11? Solo quiero asegurarme de que la congelación de funciones sea hoy.

@justaugustus Los CRD ya son beta. GA no está prevista para el 1.11.

Todas las funciones / extensiones enumeradas (poda, predeterminación, control de versiones) probablemente comenzarán como alfa.

@sttts Hmmm, en ese caso, ¿deberíamos tener problemas separados para rastrear esas características / extensiones y sus etapas de forma independiente?

Para grabar: @nikhita ha creado un problema para la subfunción https://github.com/kubernetes/features/issues/571

@sttts @justaugustus

Problema de subcaracterística predeterminada y poda: https://github.com/kubernetes/features/issues/575

@justaugustus @idvoretskyi para fines de seguimiento de 1.12: habrá adiciones y tal vez correcciones de errores, pero esto permanecerá en beta durante 1.12 (por lo que no habrá cambios desde la perspectiva de las características).

Hay una nueva subfunción que está planificada como alfa, pero se crea como un problema separado: https://github.com/kubernetes/features/issues/575.

Hola
Se ha realizado un seguimiento de esta mejora antes, por lo que nos gustaría verificar y ver si hay algún plan para que esto gradúe las etapas en Kubernetes 1.13. Esta versión está destinada a ser más "estable" y tendrá una línea de tiempo agresiva. Incluya esta mejora solo si existe un alto nivel de confianza en que cumplirá con los siguientes plazos:

• Documentos (RRPP de marcador de posición abierto): 8/11
• Código Slush: 11/9
• Comienza la congelación de código: 15/11
• Documentos completos y revisados: 27/11

Tómese un momento para actualizar los hitos en su publicación original para un seguimiento futuro y haga ping a hoja de seguimiento de mejoras 1.13

¡Gracias!

Se ha realizado un seguimiento de esta mejora antes, por lo que nos gustaría verificar y ver si hay algún plan para que esto gradúe las etapas en Kubernetes 1.13.

No, no hay planes para graduar esto en 1.13. La API de CRD permanecerá en versión beta.

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

/ remove-lifecycle stale

@ deads2k Hola: Soy el líder de la mejora para la versión 1.14 y estoy revisando este problema para ver qué trabajo (si corresponde) se está planificando para la versión 1.14. La congelación de las mejoras es el 29 de enero y quiero recordar que todas las mejoras deben tener un KEP

@claurence La API de CRD también permanecerá en versión beta durante la versión 1.14.

Hola @nikhita @ deads2k , soy el líder de mejora de 1.15. ¿Esta función va a graduar las etapas alfa / beta / estable en 1.15? Por favor, avíseme para que se pueda rastrear correctamente y agregar a la hoja de cálculo. También será necesario fusionar un KEP para su inclusión en 1,15. ¡Gracias!

Una vez que comience la codificación, enumere todos los RP k / k relevantes en este número para que se puedan rastrear correctamente.

esto permanecerá en fase beta. el trabajo sobre validación, conversión y publicación de OpenAPI se está llevando a cabo en 1.15

descripción actualizada con enlaces a KEP relevantes para 1.15

Hola, @liggitt @ deads2k @jpbetz @sttts Soy la sombra de publicación de documentos v1.15.

¿Esta mejora (o el trabajo planificado para la versión 1.15) requiere algún documento nuevo (o modificaciones)?

Solo un recordatorio amistoso que estamos buscando un PR contra k / website (branch dev-1.15) que vence el jueves 30 de mayo. Sería genial si es el comienzo de la documentación completa, pero incluso un PR de marcador de posición es aceptable. ¡Hazme saber si tienes alguna pregunta! 😄

@ deads2k @jpbetz @sttts @liggitt

Solo un recordatorio amistoso que estamos buscando un PR contra k / website (branch dev-1.15) que vence el jueves 30 de mayo. Sería genial si es el comienzo de la documentación completa, pero incluso un PR de marcador de posición es aceptable. ¡Hazme saber si tienes alguna pregunta! 😄

Docs PR para 1.15: https://github.com/kubernetes/website/pull/14583

@ deads2k ¿puedes actualizar la descripción del problema?

/ hito v1.16
/ escenario estable

Hola, @liggitt @jpbetz @sttts Soy el líder de lanzamiento de documentos v1.16.

¿Esta mejora (o el trabajo planificado para v1.16) requiere algún documento nuevo (o modificaciones)?

Solo un recordatorio amistoso que estamos buscando un PR contra k / sitio web (sucursal dev-1.16) para el viernes 23 de agosto. ¡Hazme saber si tienes alguna pregunta!

@simonswine el marcador de posición PR https://github.com/kubernetes/website/pull/15982

@liggitt @jpbetz @sttts El jueves se congela el código. ¿Hay algún RP k / k sobresaliente que evite que esto se gradúe a Estable? Todo en la publicación original para el trabajo planificado 1.15 * parece estar fusionado.

Creo que las relaciones públicas sobresalientes son solo el aumento de la versión de la puerta de funciones (https://github.com/kubernetes/kubernetes/pull/81965) y dos correcciones de errores sobresalientes que deberían ir en esta semana: https://github.com/kubernetes / kubernetes / pull / 81436 , https://github.com/kubernetes/kubernetes/issues/78707

documentos listos para su revisión en https://github.com/kubernetes/website/pull/15982

Publicado como estable en v1.16.0

Seguimiento del trabajo posterior a GA en https://github.com/orgs/kubernetes/projects/28

/cerrar

@liggitt : Cerrando este problema.