¿Puedo crear mis propios controladores de admisión?

Sí, consulte la documentación de Kubernetes y Red Hat OpenShift para obtener más información.

Tal como se indica en la documentación de Kubernetes, puede utilizar controladores de admisión para operaciones que si no gestionaría el plano de control. Por tanto, tenga mucho cuidado al configurar un controlador de admisión personalizado. Usted es el responsable de los cambios que se produzcan en el clúster debido a un controlador de admisión personalizado.

¿Cuáles son las mejores prácticas para utilizar webhooks?

Evita utilizar webhooks siempre que sea posible. Utilice y MutatingAdmissionPolicyValidatingAdmissionPolicy (cuando estén habilitados de forma predeterminada) como alternativas.

Si debe utilizar webhooks, tenga en cuenta las siguientes prácticas recomendadas y consideraciones al configurar un webhook.

• No utilice webhooks mutantes para mutar recursos propiedad de otro controlador u operador. Hacerlo podría causar un bucle de reconciliación infinito entre el propietario del recurso y el webhook. Los webhooks pueden determinar la propiedad del recurso comprobando si metadata.ownerReferences está establecido en los datos del recurso. Por ejemplo, un recurso Kubernetes replicaset es propiedad de un recurso Kubernetes deployment y nunca debe ser mutado por un webhook.

• Cree pods de réplica para el webhook de modo que, si un pod falla, el webhook puede procesar las solicitudes de los recursos. Distribuya los pods de réplica entre zonas, si es posible.

• Establezca una opción de failurePolicy adecuada, como por ejemplo si el webhook falla o ignora los errores de conexión o los tiempos de espera excedidos. Puede establecer failurePolicy en Ignore si desea que el webhook ignore los errores de conexión y los tiempos de espera excedidos. Tenga en cuenta que esto no cambia el comportamiento de apiserver si el webhook rechaza una solicitud.

• Revise el intervalo timeoutSeconds. Los webhooks más antiguos que utilizan la API de v1beta1.admissionregistration.k8s.io tienen un tiempo de espera predeterminado de 30 segundos. La API de v1 utiliza un valor predeterminado de 10 segundos. Si la política de anomalía de webhook es Ignorar y el timeoutSeconds actual es 30, considere la posibilidad de reducir el tiempo de espera a 10 segundos. Para los clústeres de OpenShift, los componentes del plano de control a menudo tienen su propio tiempo de espera de 13 segundos.

  Evite permitir que varios webhooks mutantes operen sobre los mismos recursos. Los webhooks mutantes se ejecutan secuencialmente. Un único webhook mutante puede funcionar según lo esperado desde el punto de vista de la política de tiempo de espera y fallos, pero cuando se combina con otros webhooks mutantes que operan sobre el mismo recurso, los webhooks mutantes pueden exceder el tiempo de espera total del contexto asignado para ejecutar todos los webhooks.

• Defina las solicitudes de recursos y los límites de CPU y de memoria adecuados para el webhook.

• Añade sondas de actividad y disponibilidad para asegurarte de que tu contenedor de webhooks está en funcionamiento y listo para atender solicitudes.

• Defina reglas de planificación de antiafinidad de pod para que los pods de webhook se ejecuten preferentemente en distintos nodos trabajadores y zonas cuando sea posible. En su lugar, puede utilizar la topología de pod. Sin embargo, evita las «taints» o las afinidades forzadas que puedan restringir los lugares en los que se pueden programar los pods de webhook.

• Establezca la prioridad de pod en system-cluster-critical para los pods de webhook para que otros pods no puedan ocupar recursos de los pods de webhook.

• Limite el webhook al proyecto adecuado. Evita los webhooks que procesen recursos que se ejecuten en proyectos críticos para el sistema configurados de forma predeterminada en tu clúster, como los proyectos kube-system, ibm-system, ibm-operators, calico-apiserver, calico-system, tigera-operator y openshift-*.

• Revise la opción namespaceSelector. Puede añadir etiquetas a determinados espacios de nombres críticos, como por ejemplo kube-system, para que no se llame al webhook para estos casos. Esta configuración se denomina configuración de estilo "opt-out". O bien, puede configurar la opción namespaceSelector para que solo se llame al webhook para los espacios de nombres que tienen una etiqueta específica. Esta configuración se denomina configuración "opt in". En función de la finalidad del webhook, puede ser importante que se llame al webhook para todos los espacios de nombres. Revise las opciones de configuración de namespaceSelector en la documentación deKubernetes y ajuste la configuración de webhook.

• Asegúrate de que los nodos de trabajo de tu clúster tengan el tamaño adecuado para ejecutar tus aplicaciones de webhook. Por ejemplo, si los pods solicitan más CPU o memoria de la que puede proporcionar el nodo trabajador, los pods no se planifican.

¿Qué otros tipos de aplicaciones utilizan controladores de admisión?

Muchos complementos de clúster, plugins y otras extensiones de terceros utilizan controladores de admisión. Algunos de los más comunes son los siguientes:

• Portieris

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   service:
      name: admission-webhook
      namespace: default
      path: /validate
      port: 443

clientConfig:
   caBundle: #CA_BUNDLE_BASE64#
   url: https://#WEBHOOK_URL#:443/validate

Necesito ayuda con un webhook roto. ¿Qué puedo hacer?

Para obtener ayuda para la resolución de problemas de webhooks, consulte Depuración de webhooks o El clúster no se puede actualizar debido a un webhook roto.