Tenga en cuenta que probablemente también deberíamos cambiar el nombre del servicio a lbservice o algo así para distinguirlos de otros tipos de servicios.

Como parte de esto, eliminaría los objetos de servicio del servidor principal y facilitaría el uso de otros equilibradores de carga, como HAProxy y nginx.

Sería bueno si la definición lógica de un servicio (la consulta y / o el nombre global) pudiera usarse / especializarse de múltiples maneras, como un simple equilibrador de carga instalado a través de la infraestructura, como un equilibrador de carga completo con más funciones como nginx o haproxy también ofrecido por la infraestructura, como un punto final consultable, un integrador podría sondear / esperar (GET / services / foo -> {endpoints: [{host, port}, ...]}), o como información disponible para los hosts para exponer equilibradores de carga locales. Obviamente, estos podrían ser múltiples casos de uso diferentes y, como tal, dividirse en sus propios recursos, pero tener cierta flexibilidad para especificar la intención (unificar en una libra) distinta del mecanismo hace que sea más fácil satisfacer una amplia gama de solicitudes.

@smarterclayton Estoy de acuerdo con separar la política y el mecanismo.

Primitivas que necesitamos:

1. La capacidad de sondear / mirar un conjunto identificado por un selector de etiquetas. No estoy seguro de si se ha presentado un problema todavía.
2. La capacidad de consultar direcciones IP de pod (# 385).

Esto sería suficiente para componer con otros mecanismos de nomenclatura / descubrimiento y / o balanceadores de carga. Luego, podríamos construir una capa de nivel superior sobre el núcleo que agrupa patrones comunes con una API simple.

Las dos primitivas descritas por @ bgrant0607 , ¿vale la pena mantener abierto este problema? ¿O hay problemas más específicos que podamos presentar?

No creo que el guardián del zoológico esté resuelto, ya que necesita el identificador único en cada contenedor. Creo que podría hacer esto con 3 controladores de replicación separados (uno por instancia) o un modo en el controlador de replicación.

Creo que el diseño del servicio merece una discusión, como señala Brian. Actualmente acopla una abstracción de infraestructura (proxy local) con un mecanismo de exposición (variables de entorno en todos los contenedores) con una consulta de etiqueta. Existe un caso de uso igualmente válido para un proxy de borde que toma hosts / rutas L7 y los equilibra con una consulta de etiqueta, así como protocolos compatibles como http (s) y sockets web. Además, los servicios tienen un límite de escala estricto en la actualidad de 60k backends, compartidos en todo el clúster (la cantidad de IP asignadas). Debería ser posible ejecutar un proxy local en un minion que solo actúe como proxy de los servicios que necesitan los contenedores en ese host, y también para evitar que los contenedores tengan que saber sobre el puerto externo. Podemos mover esta discusión al # 494 si es necesario.

Abordar el problema de los servicios singleton y los servicios que no se escalan automáticamente con replicación fija, como bases de datos replicadas maestro-esclavo, almacenes de valores clave con grupos de pares de tamaño fijo (por ejemplo, etcd, zookeeper), etc.

Los casos de replicación fija requieren un comportamiento similar a una matriz predecible. Los compañeros deben ser capaces de descubrirse y dirigirse individualmente entre sí. Estos servicios generalmente tienen sus propias bibliotecas de cliente y / o protocolos, por lo que no necesitamos resolver el problema de determinar a qué instancia debe conectarse un cliente, aparte de hacer que las instancias sean direccionables individualmente.

Propuesta: Deberíamos crear un nuevo tipo de servicio, llamado servicios Cardinal, que mapee N direcciones IP en lugar de solo una. Los servicios cardinales realizarían una asignación estable de estas direcciones IP a N instancias a las que apunta su selector de etiquetas (es decir, una N específica, no solo la cantidad de objetivos que existan). Una vez que tengamos DNS (# 1261, # 146), asignaría nombres DNS predecibles basados ​​en un prefijo proporcionado, con sufijos 0 a N-1. Las asignaciones se pueden registrar en anotaciones o etiquetas de los grupos de destino.

Esto preservaría el desacoplamiento de la asignación de roles de las identidades de los pods y los controladores de replicación, al tiempo que proporcionaría nombres y direcciones IP estables, que podrían usarse en los mecanismos de configuración de aplicaciones estándar.

Parte de la discusión sobre los diferentes tipos de equilibrio de carga ocurrió en el diseño de services v2: # 1107.

Presentaré un problema por separado para la elección general.

/ cc @smarterclayton @thockin

Las asignaciones tendrían que llevarse a cabo en los pods a través de algún mecanismo de parametrización del entorno (casi con certeza).

Para el ejemplo de etcd, crearía:

• cardinalidad del controlador de replicación 1: 1 pod, apuntando al volumen de almacenamiento estable A
• cardinalidad del controlador de replicación pod 2: 1, apuntando al volumen de almacenamiento estable B
• cardinalidad del controlador de replicación 3: 1 pod, apuntando al volumen de almacenamiento estable C
• servicio cardinal 'etcd' apuntando a las vainas

Si el módulo 2 muere, el controlador de replicación 2 crea una nueva copia y lo vuelve a adjuntar al volumen B. El servicio cardinal 'etcd' sabe que ese módulo es nuevo, pero ¿cómo sabe que debería ser cardinalidad 2 (que proviene de los datos almacenados? en el volumen B)?

En lugar de 3 controladores de replicación, ¿por qué no un controlador de fragmentación, que
mira una etiqueta como "kubernetes.io/ShardIndex" al tomar decisiones. Si
desea fragmentación de 3 vías, hace 3 pods con índices 0, 1, 2. Creo que
esto fue derribado antes, pero no puedo reconstruir el problema que causó en
mi cabeza.

Simplemente parece incorrecto imponer esa carga a los usuarios si se trata de una
escenario común.

¿Crees que importa si la IP nominal de un pod dado cambia debido a
cambios no relacionados en el conjunto? Por ejemplo:

en el tiempo 0, los pods (A, B, C) constituyen un servicio cardinal, con IP
10.0.0. {1-3} respectivamente

en el momento 1, el nodo que aloja el módulo B muere

en el momento 2, el controlador de replicación que controla B crea un nuevo módulo D

en el momento 3, el servicio cardinal cambia a (A, C, D) con la IP 10.0.0. {1-3}
respectivamente

NB: la "IP estable" del pod C cambió de 10.0.0.3 a 10.0.0.2 cuando el
membresía cambiada. Espero que esto haga cosas malas para correr.
conexiones.

Para evitar esto, necesitaríamos tener los valores ordinales especificados
fuera del servicio, o algo más inteligente. Tal vez eso esté bien, pero
parece frágil y fácil de equivocarse si la gente tiene que lidiar con ello.

El jueves 2 de octubre de 2014 a las 10:17 a. M., Clayton Coleman [email protected]
escribió:

Las asignaciones tendrían que llevarse a cabo en las vainas a través de algunos
mecanismo de parametrización del entorno (casi con certeza).

Para el ejemplo de etcd, crearía:

• cardinalidad del controlador de replicación 1: 1 pod, apuntando a estable
  volumen de almacenamiento A
• cardinalidad del controlador de replicación 2: 1 pod, apuntando a estable
  volumen de almacenamiento B
• controlador de replicación cardinalidad 3: 1 pod, apuntando a estable
  volumen de almacenamiento C
• servicio cardinal 'etcd' apuntando a las vainas

Si el módulo 2 muere, el controlador de replicación 2 crea una nueva copia y
lo vuelve a adjuntar al volumen B. El servicio cardinal 'etcd' sabe que ese módulo está
nuevo, pero ¿cómo sabe que debería ser cardinalidad 2 (que proviene de
datos almacenados en el volumen B)?

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

Creo que un controlador de fragmentación tiene sentido y probablemente sea más útil en el contexto de un servicio cardinal.

Creo que los cambios de IP basados ​​en la membresía dan miedo y puedo pensar en un montón de casos extremos degenerados. Sin embargo, si la cardinalidad se almacena con las vainas, la decisión es menos difícil.

En primer lugar, no tenía la intención de que esto se tratara de fragmentación, ese es el n. ° 1064. Llevemos las discusiones sobre fragmentación allí. Hemos visto muchos casos de intentar utilizar un mecanismo análogo para la fragmentación y llegamos a la conclusión de que no es la mejor manera de implementar la fragmentación.

En segundo lugar, mi intención es que no sea necesario ejecutar N controladores de replicación. Debería ser posible usar solo uno, aunque el número requerido depende de los detalles de implementación (canarios, múltiples pistas de lanzamiento, actualizaciones continuas, etc.).

En tercer lugar, estoy de acuerdo en que debemos considerar cómo interactuaría esto con la propuesta de datos duraderos (# 1515): @erictune .

Cuatro, estoy de acuerdo en que probablemente necesitemos reflejar la identidad en la cápsula. Según # 386, idealmente se utilizaría un mecanismo estándar para hacer que las asignaciones de nombres de IP y DNS sean visibles para el pod. ¿Cómo aparecerían normalmente los alias de IP y de host en Linux?

En quinto lugar, sugerí que aseguráramos la estabilidad de la asignación al registrar las asignaciones en los pods mediante etiquetas o anotaciones.

En sexto lugar, el problema con un "controlador de fragmentación" que reemplaza al controlador de replicación es que quiero desacoplar la asignación de roles de la gestión de imagen / entorno. Veo que el controlador de replicación proporciona lo último (consulte https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

En el caso de datos duraderos, según # 1515:

1. Para cápsulas duraderas, esta propuesta simplemente funcionaría. La asignación sería estable para la cápsula duradera.
2. Para objetos de datos separados, el servicio cardinal también necesitaría administrar la asignación de roles para los objetos de datos y diferiría la asignación de roles a los pods hasta después de que se hicieran coincidir con los datos. Creo que esto sería sencillo.

/ cc @erictune

Creo que estabas tratando de facilitar la conversación, pero no estoy seguro de que haya funcionado.

Re: fragmentación - ¿no es "un conjunto de réplicas con identidad distinta" básicamente fragmentación?

Re: 1 controlador de replicación: hoy no tenemos un controlador de replicación que asigne índices. No creo que queramos eso, ¿verdad?

Re: decirle al pod su propia identidad: el servicio es una capa limpia sobre el pod. Sería complicado informar a un servicio sobre un módulo inminente para que pueda asignar una IP antes de que exista. Creo que el ID debe ser parte del grupo, por ejemplo, una etiqueta ShardIndex o algo así. Podemos reflejar eso en el pod (de alguna manera) y el servicio puede usarlo para asignar IP. Si dejamos que el servicio Cardinal lo haga por sí mismo, entonces el módulo ya se habrá iniciado en el momento en que se asigne. Podríamos tener metadatos por pod como lo hacemos con las VM en GCE, pero esa es una propuesta más grande.

No, proporcionar identidades distintas y estables no es necesario ni suficiente para la fragmentación. Consulte el n. ° 1064 para obtener más detalles, que acabo de agregar allí.

No, no queremos que el controlador de replicación asigne índices. Propuse intencionalmente que los servicios de Cardinal hicieran eso en su lugar.

Sí, espero que los pods existan (y potencialmente hayan comenzado) antes de que se les asignen roles (índices). Eso fue deliberado. También debe ser posible revocar una asignación.

Posible enfoque de identidad: cree un alias de IP no persistente en el contenedor y proporcione una búsqueda de DNS inversa en la implementación de DNS.

Sin embargo, no creo que integrar la identidad en los contenedores de vainas sea esencial para muchos casos de uso. Si la aplicación utiliza el registro automático, probablemente ni siquiera necesite este mecanismo.

Si el administrador del servicio está dispuesto a mantener algún estado al margen de lo que
lo hace actualmente, solo podemos recordar las asignaciones que se hicieron anteriormente
y tratar de respetarlos.

El jueves 2 de octubre de 2014 a las 8:59 p.m., bgrant0607 [email protected] escribió:

Posible enfoque de identidad: cree un alias de IP no persistente en el
contenedor y proporcionar búsqueda de DNS inversa en la implementación de DNS.

Sin embargo, no creo que introducir la identidad en los contenedores de vainas sea
esencial para muchos casos de uso. Si la aplicación está usando
autorregistro, probablemente ni siquiera necesite este mecanismo.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

Re. recordando las asignaciones, estoy de acuerdo; consulte https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

Sin embargo, no sé qué importancia tiene eso para el comentario al que respondiste.

GitHub y el correo electrónico no se mezclan. Lo siento

El jueves 2 de octubre de 2014 a las 9:39 p.m., bgrant0607 [email protected] escribió:

Re. recordando las asignaciones, estoy de acuerdo - vea el n. ° 260 (comentario)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

Sin embargo, no sé qué importancia tiene eso para el comentario al que respondiste.

Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Tim sugirió "nominal", que estoy de acuerdo es mejor.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

También me gusta nominal. Odiaré explicárselo a los usuarios, pero muy a menudo aparecerá en uso para cosas creadas por la configuración (es decir, un conjunto de réplicas de mongodb nominal será un controlador de réplica, un servicio nominal, volúmenes, por lo que ya es algo complejo).

----- Mensaje original -----

Tim sugirió "nominal", que estoy de acuerdo es mejor.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

Dos problemas que veo:

1. La asignación de roles implica establecer al menos variables de entorno o configuraciones de volumen por pod (es decir, el primer pod necesita obtener el volumen a, y si se elimina, su reemplazo necesita el mismo volumen)
2. Si los pods para un servicio nominal provienen de un solo controlador de réplica, la plantilla debe modificarse después de la creación, pero antes de que se vincule el pod.

Esto parece implicar que la asignación de roles es un controlador que se encuentra entre el apiserver y el programador como un paso del flujo de trabajo. También implica alguna forma de transformación o anulación de la plantilla, de modo que la plantilla sin la asignación de roles no necesariamente tiene sentido.

El controlador de fragmentos parece una variante de este problema, solo para una asignación de roles más complicada.

Ejemplo de ejecución de zookeeper con un servicio por instancia: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

Entonces sé que este es un hilo antiguo, pero toca un tema cercano y querido para mí ;-)

Siempre que el sistema pueda avanzar + retroceder registros para "servicios nominales" no nativos para paracaidistas y usar nombres como la inyección de ENV en los pods que usan ese servicio, ¿existen otras limitaciones?

Puede parecer un poco extraño en el caso de ZK, donde cada elemento del quórum usaría los otros elementos, por ejemplo:
zk1 utiliza: zk2, zk3
zk2 utiliza: zk1, zk3
zk3 utiliza: zk1, zk2

pero en teoría debería funcionar, ¿verdad? Siempre que podamos agregar los registros inversos para los servicios nominales.

@ bgrant0607 ¿Me estoy perdiendo algo?

Se vuelve un poco más extraño cuando otras aplicaciones desean utilizar el servicio general que proporciona. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc Lo que propones funcionaría si zk1, zk2 y zk3 fueran servicios, al menos una vez que se admitan los servicios multipuerto.

Sí, hay algo feo aquí.

Un módulo de ejecución no sabe qué servicios lo "encabezan". Ej. Dado un servicio
de una instancia de backend, el VIP utilizado para acceder al servicio no es conocido por
el backend (a menos que busque esa información conociendo el servicio
nombre). En un servicio nominal (N), tendría N backends y N VIP (y
presumiblemente N nombres DNS o un nombre de dirección N), pero los backends aún
no conocen a sus propios VIP. Pueden observar el conjunto de nombres DNS, pero
no sé (sin sondear) cuál es uno mismo. Esto haría que tu ZK
caso difícil de usar los VIP (también los VIP se pueden observar en este momento).

Alternativas:

1) configure 1 servicio (N) y haga que cada instancia analice todos los VIP por sí mismo

2) configure instancias de N service (1) y use etiquetas y marcas de cmdline para
Asignar índices manualmente, hacer que cada backend ZK conozca (a priori) el nombre DNS
unos de otros ZK backend

3) Hacer DNS para los selectores de etiquetas, asignar un nombre DNS al conjunto de réplicas ZK,
espero que los clientes usen DNS correctamente

4) Ejecute puentes kube2zk junto a cada ZK que sincroniza los puntos finales de kubernetes ->
Configuración de ZK

5) Diseñe una forma alternativa de asignar VIP o índices que sea más
centrado en el controlador de replicación que en el servicio. Brendan y yo
Hice una lluvia de ideas aquí hace un tiempo, pero no he tenido tiempo para seguir
en eso.

En cuanto al DNS inverso, ¿no estoy seguro de ver su función? Yo no estoy en contra
apoyarlo (es decir, pedirle a @bketelsen que lo apoye :) pero no lo creo
se aplica aquí. El tráfico nunca proviene "de" una IP de servicio.

Tim

El sábado 7 de marzo de 2015 a las 8:56 p.m., Brian Grant [email protected]
escribió:

@timothysc https://github.com/timothysc Lo que propones funcionaría si
zk1, zk2 y zk3 eran servicios, al menos una vez que los servicios multipuerto son
soportado.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) suena como esta propuesta.

Soy un gran admirador de 5: los pods saben que su función es el paso uno, los pods tienen una identificación de DNS única o usan puntos finales para obtener la IP de otros y reaccionar ante ellos son dos. Ser capaz de buscar la IP del pod en los puntos finales mediante un ID de rol estable sería el tercero.

El 8 de marzo de 2015, a las 11:06 a. M., Tim Hockin [email protected] escribió:

Sí, hay algo feo aquí.

Un módulo de ejecución no sabe qué servicios lo "encabezan". Ej. Dado un servicio
de una instancia de backend, el VIP utilizado para acceder al servicio no es conocido por
el backend (a menos que busque esa información conociendo el servicio
nombre). En un servicio nominal (N), tendría N backends y N VIP (y
presumiblemente N nombres DNS o un nombre de dirección N), pero los backends aún
no conocen a sus propios VIP. Pueden observar el conjunto de nombres DNS, pero
no sé (sin sondear) cuál es uno mismo. Esto haría que tu ZK
caso difícil de usar los VIP (también los VIP se pueden observar en este momento).

Alternativas:

1) configure 1 servicio (N) y haga que cada instancia analice todos los VIP por sí mismo

2) configure instancias de N service (1) y use etiquetas y marcas de cmdline para
Asignar índices manualmente, hacer que cada backend ZK conozca (a priori) el nombre DNS
unos de otros ZK backend

3) Hacer DNS para los selectores de etiquetas, asignar un nombre DNS al conjunto de réplicas ZK,
espero que los clientes usen DNS correctamente

4) Ejecute puentes kube2zk junto a cada ZK que sincroniza los puntos finales de kubernetes ->
Configuración de ZK

5) Diseñe una forma alternativa de asignar VIP o índices que sea más
centrado en el controlador de replicación que en el servicio. Brendan y yo
Hice una lluvia de ideas aquí hace un tiempo, pero no he tenido tiempo para seguir
en eso.

En cuanto al DNS inverso, ¿no estoy seguro de ver su función? Yo no estoy en contra
apoyarlo (es decir, pedirle a @bketelsen que lo apoye :) pero no lo creo
se aplica aquí. El tráfico nunca proviene "de" una IP de servicio.

Tim

El sábado 7 de marzo de 2015 a las 8:56 p.m., Brian Grant [email protected]
escribió:

@timothysc https://github.com/timothysc Lo que propones funcionaría si
zk1, zk2 y zk3 eran servicios, al menos una vez que los servicios multipuerto son
soportado.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Entonces tendré que tomarme un tiempo para escribir un poco más esta idea.

El domingo, 8 de marzo de 2015 a las 10:25 a. M., Clayton Coleman [email protected]
escribió:

Soy un gran admirador de 5: las cápsulas saben que su papel es el primer paso, las cápsulas
Tener una identificación de DNS única o usar puntos finales para obtener la IP de otros y
reaccionando a ella son dos. Ser capaz de buscar la ip del pod en puntos finales mediante un
La identificación del rol estable sería la tercera.

El 8 de marzo de 2015, a las 11:06 a. M., Tim Hockin [email protected]
escribió:

Sí, hay algo feo aquí.

Un módulo de ejecución no sabe qué servicios lo "encabezan". Por ejemplo, dado un
Servicio
de una instancia de backend, se desconoce la VIP utilizada para acceder al servicio
por
el backend (a menos que busque esa información conociendo el servicio
nombre). En un servicio nominal (N), tendría N backends y N VIP
(y
presumiblemente N nombres de DNS o un nombre de N-dirección), pero los backends
aún
no conocen a sus propios VIP. Pueden observar el conjunto de nombres DNS, pero
no sé (sin sondear) cuál es uno mismo. Esto haría que tu ZK
caso difícil de usar los VIP (también los VIP se pueden observar en este momento).

Alternativas:

1) configure 1 servicio (N) y haga que cada instancia analice todos los VIP por sí mismo

2) configure instancias de N service (1) y use etiquetas y marcas de cmdline para
Asignar índices manualmente, hacer que cada backend ZK conozca (a priori) el DNS
nombre
unos de otros ZK backend

3) Hacer DNS para los selectores de etiquetas, asignar un nombre DNS al conjunto de réplicas ZK,
espero que los clientes usen DNS correctamente

4) Ejecute puentes kube2zk junto con cada ZK que sincroniza los puntos finales de Kubernetes
->
Configuración de ZK

5) Diseñe una forma alternativa de asignar VIP o índices que sea más
centrado en el controlador de replicación que en el servicio. Brendan y yo
Hice una lluvia de ideas aquí hace un tiempo, pero no he tenido tiempo de
seguir
en eso.

En cuanto al DNS inverso, ¿no estoy seguro de ver su función? Yo no estoy en contra
apoyarlo (es decir, pedirle a @bketelsen que lo apoye :) pero no lo creo
se aplica aquí. El tráfico nunca proviene "de" una IP de servicio.

Tim

El sábado 7 de marzo de 2015 a las 8:56 p.m., Brian Grant [email protected]
escribió:

@timothysc https://github.com/timothysc Lo que propongas funcionaría
Si
zk1, zk2 y zk3 eran servicios, al menos una vez que los servicios multipuerto son
soportado.

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

-
Responda a este correo electrónico directamente o véalo en GitHub.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: reverse DNS, simplemente

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

RC que aplicó una etiqueta única (miembros = #) a cada pod que crea e intenta crear una secuencia de hasta N réplicas, y luego un servicio sin cabeza que creó un nombre A y CNAME para cada valor de la etiqueta "miembro" (# .service.namespace.local), donde la raíz sirvió a todos esos service.namespace.local -> round robin -> 1.service.namespace.local, 2.service.namespace.local parece local.

_Podríamos_ utilizar IPs de pod estrictas para esas etiquetas de DNS individuales. Crear direcciones IP falsas para cada una es costoso y el contenedor no podrá enviar su propia IP a alguien.

----- Mensaje original -----

@thockin re: DNS inverso, simplemente
requisito.

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: DNS inverso: ¿qué es DNS inverso? La IP de origen de
conexiones? Nada de eso funciona en kube. Las conexiones a través de servicios son
proxy, por lo que source-ip no funciona en primer lugar (podría arreglarse).

No lo sé, ZK, ¿puedes explicar qué están tratando de conseguir al revés?
DNS? Parece una suposición muy frágil.

El lunes 9 de marzo de 2015 a las 9:05 a. M., Timothy St. Clair [email protected]
escribió:

@thockin https://github.com/thockin re: DNS inverso, solo saludemos
nuestras manos y lo consideramos un requisito.

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

Creo que mi experiencia (y tal vez la de Tim) es que la mayoría del software agrupado de hoy espera lo siguiente:

• cada nodo tiene una identidad estable
• esa identidad es un nombre DNS
• la IP de la identidad subyacente no tiene que ser estable
• el nodo espera identificarse con otros nodos ya sea por su identidad estable (DNS) o su IP pública
• algunos de los software agrupados esperan que la IP del nodo al que accede un cliente coincida con una IP que puede anunciarse a otros en el clúster y que esa IP sea accesible.

----- Mensaje original -----

@timothysc re: DNS inverso: ¿qué es DNS inverso? La IP de origen de
conexiones? Nada de eso funciona en kube. Las conexiones a través de servicios son
proxy, por lo que source-ip no funciona en primer lugar (podría arreglarse).

No lo sé, ZK, ¿puedes explicar qué están tratando de conseguir al revés?
DNS? Parece una suposición muy frágil.

El lunes 9 de marzo de 2015 a las 9:05 a. M., Timothy St. Clair [email protected]
escribió:

@thockin https://github.com/thockin re: DNS inverso, solo saludemos
nuestras manos y lo consideramos un requisito.

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

El lunes 9 de marzo de 2015 a las 12:49 p. M., Clayton Coleman
[email protected] escribió:

RC que aplicó una etiqueta única (miembros = #) a cada pod que crea e intenta crear una secuencia hasta
N réplicas y luego un servicio sin cabeza que creó un nombre A y CNAME para cada valor de "miembro"
etiqueta (# .service.namespace.local), donde la raíz sirvió a todos esos service.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local parece local.

La idea de que Brendan y yo estábamos rebotando era básicamente una piscina
de tokens, tal vez parte de RC, tal vez no, que cada elemento de un RC
sería asignado. Dado ese token, se podrían asignar otras cosas

• VIP, PD, índices genéricos, etc. Lo bueno es que cuando un grupo
  muere, el token se devuelve al grupo, y cuando se reemplaza ese pod
  ese token se reutiliza.

El problema viene con averiguar cómo convertir un "token arbitrario" en
algo significativo.

_Podríamos_ utilizar IPs de pod estrictas para esas etiquetas de DNS individuales. Crear direcciones IP falsas para cada una es costoso y el contenedor no podrá enviar su propia IP a alguien.

No lo he intentado, pero apuesto a que podríamos hacer que los servicios nominales funcionen completamente en SNAT.
y DNAT ya que son 1: 1. Esta sería una forma de estabilizarse
IP por pod sin IP migrables.

----- Mensaje original -----

@thockin re: DNS inverso, simplemente
requisito.

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

-
Responda a este correo electrónico directamente o véalo en GitHub.

Lejos de mí nadar contra la corriente, si suficientes aplicaciones realmente esperan que el DNS
funciona de esta manera, podemos hacer que funcione de esta manera.

Bosquejo:

Al crear un controlador de replicación, R crea un nombre DNS "$ R.rc", que es el
grupo de IP de pod que están "debajo" de ese RC. Cada pod P recibe un nombre DNS
"$ P. $ R.rc". Pero, ¿qué es P? Podrían ser índices simples, pero eso tiene
nos mordió duro internamente. Pueden ser cadenas aleatorias como GenerateName,
pero tienen que sobrevivir a la muerte / reinicio del pod (y tal vez los nombres de host del pod deberían
¿coincidir?).

El martes 10 de marzo de 2015 a las 7:59 a. M., Clayton Coleman [email protected]
escribió:

Creo que mi experiencia (y tal vez la de Tim) es que la mayoría de las
El software actual espera lo siguiente:

• cada nodo tiene una identidad estable
• esa identidad es un nombre DNS
• la IP de la identidad subyacente no tiene que ser estable
• el nodo espera identificarse con otros nodos ya sea por su estabilidad
  identidad (DNS) o su IP pública
• parte del software agrupado espera que la IP del nodo sea un cliente
  lo alcanza para que coincida con una IP que puede anunciar a otros en el
  clúster y que esa IP sea accesible.

----- Mensaje original -----

@timothysc re: DNS inverso: ¿qué es DNS inverso? La IP de origen de
conexiones? Nada de eso funciona en kube. Las conexiones a través de servicios son
proxy, por lo que source-ip no funciona en primer lugar (podría arreglarse).

No lo sé, ZK, ¿puedes explicar qué están tratando de conseguir al revés?
DNS? Parece una suposición muy frágil.

El lunes, 9 de marzo de 2015 a las 9:05 a. M., Timothy St. Clair <
[email protected]>
escribió:

@thockin https://github.com/thockin re: DNS inverso, solo saludemos
nuestras manos y lo consideramos un requisito.

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Responda a este correo electrónico directamente o véalo en GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

Me gusta que el DNS esté adjunto a servicios nominales en lugar de RC.

¿Cuál fue el punto de dolor con índices simples internamente? P> 5000?

----- Mensaje original -----

Lejos de mí nadar contra la corriente, si suficientes aplicaciones realmente esperan que el DNS
funciona de esta manera, podemos hacer que funcione de esta manera.

Bosquejo:

Al crear un controlador de replicación, R crea un nombre DNS "$ R.rc", que es el
grupo de IP de pod que están "debajo" de ese RC. Cada pod P recibe un nombre DNS
"$ P. $ R.rc". Pero, ¿qué es P? Podrían ser índices simples, pero eso tiene
nos mordió duro internamente. Pueden ser cadenas aleatorias como GenerateName,
pero tienen que sobrevivir a la muerte / reinicio del pod (y tal vez los nombres de host del pod deberían
¿coincidir?).

El martes 10 de marzo de 2015 a las 7:59 a. M., Clayton Coleman [email protected]
escribió:

Creo que mi experiencia (y tal vez la de Tim) es que la mayoría de las
El software actual espera lo siguiente:

• cada nodo tiene una identidad estable
• esa identidad es un nombre DNS
• la IP de la identidad subyacente no tiene que ser estable
• el nodo espera identificarse con otros nodos ya sea por su estabilidad
  identidad (DNS) o su IP pública
• parte del software agrupado espera que la IP del nodo sea un cliente
  lo alcanza para que coincida con una IP que puede anunciar a otros en el
  clúster y que esa IP sea accesible.

----- Mensaje original -----

@timothysc re: DNS inverso: ¿qué es DNS inverso? La IP de origen de
conexiones? Nada de eso funciona en kube. Las conexiones a través de servicios son
proxy, por lo que source-ip no funciona en primer lugar (podría arreglarse).

No lo sé, ZK, ¿puedes explicar qué están tratando de conseguir al revés?
DNS? Parece una suposición muy frágil.

El lunes, 9 de marzo de 2015 a las 9:05 a. M., Timothy St. Clair <
[email protected]>
escribió:

@thockin https://github.com/thockin re: DNS inverso, solo saludemos
nuestras manos y lo consideramos un requisito.

ZK se romperá sin él, al igual que muchos otros sistemas distribuidos.

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Responda a este correo electrónico directamente o véalo en GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 a VIP 1: 1 en carcasa especial. Creo que será un caso común.

Todavía me preocupa cambiar las asignaciones de DNS de forma dinámica. Preferiría un enfoque que no requiriera eso.

Algo a tener en cuenta al evaluar alternativas es que estoy 100% seguro de que eventualmente vamos a necesitar 2 pods con el mismo rol para coexistir al mismo tiempo, el viejo y el nuevo. Por lo tanto, la función no se puede vincular al nombre del objeto ni a otra cosa que debe ser única y debe estar grabada en piedra en el momento de la creación de la vaina.

Si vinculamos el mecanismo de asignación de roles al controlador de replicación, eso prácticamente descarta las actualizaciones continuas, los canarios, etc. Me gustaría evitar eso si es posible.

@smarterclayton Los índices simples no son problemáticos debido a la escala. Es por el modelo. Vea mis comentarios de hace unos minutos. Los índices simples son el camino a seguir si se pueden asignar dinámicamente independientemente de la identidad del pod y del RC.

Dado que uno de los problemas son las suposiciones orientadas al sistema, ¿hay algo que Linux pueda hacer por nosotros aquí? Por ejemplo, ¿podríamos crear un alias de IP o algo así en el contenedor para el servicio VIP?

Hola chicos,

Estoy fuera toda esta semana. Esta es una conversación muy divertida, pero requiere
más tiempo del que tengo a mano. Estaría feliz de sentarme y discutir en real
tiempo la semana que viene.

El martes 10 de marzo de 2015 a las 3:56 p.m., Brian Grant [email protected]
escribió:

Dado que uno de los problemas son los supuestos orientados al sistema, ¿hay
¿Algo que Linux podría hacer por nosotros aquí? Por ejemplo, ¿podríamos crear una IP
alias o algo así en el contenedor del servicio VIP?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

Estoy fuera de mi bolsillo los próximos dos días, la semana que viene.

El 10 de marzo de 2015, a las 11:33 p.m., Tim Hockin [email protected] escribió:

Hola chicos,

Estoy fuera toda esta semana. Esta es una conversación muy divertida, pero requiere
más tiempo del que tengo a mano. Estaría feliz de sentarme y discutir en real
tiempo la semana que viene.

El martes 10 de marzo de 2015 a las 3:56 p.m., Brian Grant [email protected]
escribió:

Dado que uno de los problemas son los supuestos orientados al sistema, ¿hay
¿Algo que Linux podría hacer por nosotros aquí? Por ejemplo, ¿podríamos crear una IP
alias o algo así en el contenedor del servicio VIP?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

-
Responda a este correo electrónico directamente o véalo en GitHub.

+1 para la próxima semana, tal vez un hangout.

Repetir este hilo debido a que aparecen temas relacionados (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, # 6393).

1. ¿Cómo asignamos identidades de red (nombres DNS y / o direcciones IP) a pods individuales, que pueden ser singleton o parte de un conjunto nominal?
2. ¿Cómo transmitimos la identidad a los contenedores dentro de una vaina?

¿Debemos programar un hangout o usar un hangout semanal de la comunidad?

También https://github.com/openshift/mongodb/pull/14, que estamos empezando a hacer un prototipo de lo que sería un patrón genérico para la inicialización del conjunto de miembros (algo que podemos poner en un contenedor, biblioteca o ...)

@danmcp @mfojtik

----- Mensaje original -----

Empujar este hilo nuevamente debido a temas relacionados que aparecen
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393).

1. ¿Cómo asignamos identidades de red (nombres DNS y / o direcciones IP) a
   vainas individuales, que pueden ser singleton o parte de un conjunto nominal?
2. ¿Cómo transmitimos la identidad a los contenedores dentro de una vaina?

¿Debemos programar un hangout o usar un hangout semanal de la comunidad?

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, una pieza de ese rompecabezas es la elección maestra n. ° 1542.

Sí, lo discutimos. Para la mayoría de los clústeres que pueden realizar sus propias elecciones, la membresía es lo más importante (detectar la membresía de los puntos finales de Kube, aplicar al clúster), pero siempre hay diferentes formas de abordarlo. Por ejemplo, Cassandra básicamente usa Kube como la fuente externa de verdad para los miembros, por lo que es SEP y eso facilita la elección de líderes. Aunque creo que, dependiendo del retraso de los miembros, podría terminar con una partición si la membresía flamea.

Para mongo, desea ponerse en contacto con cada uno de los miembros y hacer que se unan a un clúster existente o formen un nuevo clúster. Si existen varios clústeres, no querrá empeorarlos.

Tenga en cuenta que el problema de comunicar una IP de servicio a un contenedor es similar a comunicar una IP externa a una VM: https://cloud.google.com/compute/docs/networking. GCE traduce las direcciones externas hacia / desde direcciones internas, y las direcciones externas se comunican a través del servidor de metadatos: http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS es similar: http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton Actualicé el prototipo de mongo PR: https://github.com/openshift/mongodb/pull/17

ahora está usando One Shot Pod que inicializa el replicaSet

Re. vincular este mecanismo a la replicación / controlador de fragmentos:

Probar nombres DNS en controladores de replicación y / o nombres de objetos de pod obliga a un modelo de actualización in situ. Se necesitaría implementar un tipo completamente diferente de actualización continua "en el lugar", mientras que de alguna manera se admiten múltiples plantillas simultáneamente con un solo controlador. También significaría que para realizar algunos tipos de actualizaciones (incluido el traslado a nuevos hosts), los pods deberían eliminarse y luego volver a crearse con los mismos nombres, lo que aumentaría el tiempo de inactividad en comparación con el enfoque en el que agregamos un nuevo vaina antes de llevarse una vieja.

La idea del grupo de fichas suena genial. Solo creo que debe desacoplarse de los RC.

Esto podría acoplarse a un controlador de nivel superior, si tuviéramos que agregar uno. Comentará más sobre el n. ° 1743 y / o el n. ° 503.

Esto realmente no debería estar acoplado al DeploymentController propuesto en # 1743. No funcionaría para el escenario de múltiples pistas de lanzamiento independientes, ni en el caso en el que alguien quisiera controlar sus lanzamientos con un mecanismo diferente, como la actualización continua de intercambio de nombres propuesta. Por razones similares, no vincularía los nombres DNS a los nombres de los objetos pod / RC / DC.

Así que volvemos a un tipo de servicio, o un controlador completamente separado. ¿Quizás el controlador de puntos finales podría asignar índices a los puntos finales de servicio? ¿Es Endpoints en sí mismo un lugar lo suficientemente confiable para registrar estos datos? Si se perdiera, todos los pods se volverían a indexar.

Para facilitar la comunicación de la identidad hasta los contenedores en el pod (como a través de la sustitución de la var. Env. Discutida en # 2316), sería útil establecer un campo en el pod cuando el rol se asignó / desasignó, a través de un subrecurso. Eso también podría abordar el problema de la durabilidad.

Deberíamos reservar espacio en el esquema DNS para instancias nominales - # 6666.

Podría creer que podríamos intentar usar IP de pod y simplemente reasignar DNS para instancias nominales, según https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406.

Además, eliminé esto del hito 1.0 en febrero (aunque no roadmap.md), pero la discusión en # 6393 sugiere que se puede agregar nuevamente.

Sugerido por @thockin : la búsqueda inversa usando DNS (registros PTR) parece una forma razonable de pasar de IP de pod a nombres DNS nominales:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Sí, haría muy fácil "quién soy yo" a través de herramientas de nombres estándar.

El 10 de abril de 2015, a las 8:11 p.m., Brian Grant [email protected] escribió:

Sugerido por @thockin : la búsqueda inversa usando DNS (registros PTR) parece una forma razonable de pasar de IP de pod a nombres DNS nominales:
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

-
Responda a este correo electrónico directamente o véalo en GitHub.

/suscribir

Ya no estoy seguro de entender los requisitos aquí.

Existe una relación N-to-M inherente entre los servicios y los pods, por
diseño del sistema. Cosas como el DNS inverso generalmente esperan obtener una
respuesta única: dada la IP de un pod, obtén un nombre canónico. Cada documento escrito
about DNS dice "no devuelva varios registros inversos". Dado que una vaina puede ser
en N servicios, esta única respuesta no puede estar realmente relacionada con el servicio. Nosotros
podría hacer una búsqueda inversa a un nombre canónico y luego una búsqueda TXT en ese
nombre de "bajo qué servicios estás", pero es difícil de mantener y es
esencialmente un protocolo personalizado de todos modos.

La razón por la que pensé en adjuntar algo nominal a los RC es que es un
relación más concreta. Pero ni siquiera está. Una vaina puede ser creada por
un RC, huérfano, adoptado por otro RC y destruido por éste. O
destruido manualmente

Así que no estoy seguro de qué queremos hacer con esto, salvo limitar el número
de los servicios que una vaina puede tener "por debajo", lo que suena horrible.

¿Cuáles son los requisitos de comportamiento? Qué queremos lograr. Nosotros
puede proporcionar una semántica de conjuntos simple con DNS y servicios sin cabeza. Es eso
¿suficiente? Si no es así, ¿por qué?

Podríamos ir a los extremos y configurar las reglas de iptables para los pods SNAT / DNAT en un
servicio para que todos se vean en VIP. Por ejemplo, dado un conjunto de vainas
(P1, P2, P3) obtendrían VIP (V1, V2, V3). El tráfico de P1 a V2
parece provenir de V1, etc. Los clientes accederían a V {1,2,3}. Pero que
problema, ¿eso resuelve, de verdad? Proporciona IP estables, pero ¿no es esto un
¿Problema general para los servicios sin cabeza por todas partes?

El martes 21 de abril de 2015 a las 2:17 p.m., David Oppenheimer < [email protected]

escribió:

/suscribir

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

El objetivo era muy concreto. Los sistemas agrupados reales tienen miembros que tienen una "identidad" que se espera que sea continua en presencia de fallas en los nodos. Esa identidad puede estar adjunta a un disco persistente o un "nombre", pero el nombre que identifica a otros sistemas no puede cambiar.

Por ejemplo, el guardián del zoológico tiene una identidad por nodo. Esa identidad debe permanecer estable en la membresía del clúster: _podría_ haber dos pods que piensan que son host1, pero si host1 desaparece, host435 no puede reemplazarlo. Puede haber un disco persistente reutilizado para ese pod que se mueve de un lugar a otro, pero cuando lo hace, el pod tiene que poder definir esa identidad. Pero necesitamos una forma de asignar ese #.

Sospecho que la forma en que pienso sobre los servicios nominales siempre se trata de habilitar el software existente con una membresía pequeña (3/5/7), no el caso de uso totalmente flexible de varios cientos. Quizás deberíamos separar ese caso de uso de esta discusión.

El 22 de abril de 2015, a la 1:59 a. M., Tim Hockin [email protected] escribió:

Ya no estoy seguro de entender los requisitos aquí.

Existe una relación N-to-M inherente entre los servicios y los pods, por
diseño del sistema. Cosas como el DNS inverso generalmente esperan obtener una
respuesta única: dada la IP de un pod, obtén un nombre canónico. Cada documento escrito
about DNS dice "no devuelva varios registros inversos". Dado que una vaina puede ser
en N servicios, esta única respuesta no puede estar realmente relacionada con el servicio. Nosotros
podría hacer una búsqueda inversa a un nombre canónico y luego una búsqueda TXT en ese
nombre de "bajo qué servicios estás", pero es difícil de mantener y es
esencialmente un protocolo personalizado de todos modos.

La razón por la que pensé en adjuntar algo nominal a los RC es que es un
relación más concreta. Pero ni siquiera está. Una vaina puede ser creada por
un RC, huérfano, adoptado por otro RC y destruido por éste. O
destruido manualmente

Así que no estoy seguro de qué queremos hacer con esto, salvo limitar el número
de los servicios que una vaina puede tener "por debajo", lo que suena horrible.

¿Cuáles son los requisitos de comportamiento? Qué queremos lograr. Nosotros
puede proporcionar una semántica de conjuntos simple con DNS y servicios sin cabeza. Es eso
¿suficiente? Si no es así, ¿por qué?

Podríamos ir a los extremos y configurar las reglas de iptables para los pods SNAT / DNAT en un
servicio para que todos se vean en VIP. Por ejemplo, dado un conjunto de vainas
(P1, P2, P3) obtendrían VIP (V1, V2, V3). El tráfico de P1 a V2
parece provenir de V1, etc. Los clientes accederían a V {1,2,3}. Pero que
problema, ¿eso resuelve, de verdad? Proporciona IP estables, pero ¿no es esto un
¿Problema general para los servicios sin cabeza por todas partes?

El martes 21 de abril de 2015 a las 2:17 p.m., David Oppenheimer < [email protected]

escribió:

/suscribir

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

-
Responda a este correo electrónico directamente o véalo en GitHub.

Algún tipo de controlador podría activar o desactivar dinámicamente algunos campos en los pods. Simplemente no se puede combinar con la identidad de pod o RC. Vincular la identidad de la red a las identidades de pod o RC está totalmente roto.

No trataría de hacer que la búsqueda de DNS inversa funcione para servicios ordinarios o sin cabeza, y no creo que sea irrazonable imponer un máximo de un servicio nominal por pod, lo que no tiene por qué limitar otros tipos de servicios en absoluto. .

Hay una serie de limitaciones de DNS que queremos impulsar a largo plazo (invalidación de caché, compatibilidad con sondeos prolongados, etc.). Múltiples registros PTR es quizás solo otro elemento agregado a esa lista.

La otra alternativa es que podemos darle una IP de servicio a cada pod del servicio nominal y luego solucionar los problemas que crea.

----- Mensaje original -----

Algún tipo de controlador podría activar o desactivar dinámicamente algunos campos en los pods. Eso
simplemente no se puede combinar con la identidad de pod o RC. Vincular la identidad de la red
a las identidades de pod o RC está totalmente roto.

No trataría de hacer que la búsqueda de DNS inversa funcione para personas normales o sin cabeza.
servicios, y no creo que sea irrazonable imponer un máximo de un valor nominal
servicio por pod, que no tiene por qué limitar otros tipos de servicios en
todo.

Hay una serie de limitaciones de DNS que queremos impulsar a largo plazo.
(invalidación de caché, soporte para sondeos largos, etc.). Múltiples registros PTR
es quizás solo otro elemento agregado a esa lista.

La otra alternativa es que podemos dar una IP de servicio a cada pod del
servicio nominal y luego solucionar los problemas que crea.

Muchos de estos servicios esperan que la IP que tienen (su nombre) se resuelva en la IP a la que se conectan, por lo que si se conectan a X en 172.1.1.1, X piensa que es 172.1.1.1. Eso no es todo software, pero parte de él. Sin embargo, generalmente es un nombre DNS, lo que significa que la IP puede cambiar debajo.

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

Me temo que todo esto es todavía un poco abstracto para mí.

Los sistemas agrupados reales tienen miembros que tienen una "identidad" que es
Se espera que sea continuo en presencia de fallas en los nodos. Esa identidad
puede estar adjunto a un disco persistente o un "nombre", pero el nombre del
Identificar a otros sistemas no puede cambiar.

Esto no es un requisito. Es tan vago que no se puede implementar.

Por ejemplo, el guardián del zoológico tiene una identidad por nodo. Esa identidad debe permanecer
estable en la membresía del clúster

¿Qué es una identidad? ¿Una dirección IP? ¿Se pasó una bandera de cadena al software?
y env var? ¿Cómo aprende un proceso zk cuál es su propia identidad?

Algún tipo de controlador podría activar o desactivar dinámicamente algunos campos en los pods

Lo que activará el reinicio de esos pods y aún no responde al
pregunta de qué campos, qué valores y qué lógica decirle al grupo.

Pude ver algo como expandir anotaciones en banderas de línea de comando
(como estamos discutiendo con env vars) o simplemente en env vars. P.ej
el controlador escribe anotaciones ["zookeeper.com/index"] = 9, convertimos
$ .metatdata ["zookeeper.com/index"] en ZK_INDEX env. Pero estoy haciendo esto
arriba, no he visto demandas concretas que digan qué es exactamente el cuidador del zoológico (o
lo que sea) necesidad.

No creo que sea irrazonable imponer un máximo de un servicio nominal
por vaina

Creo que será difícil implementar tales restricciones. El sistema es tan
vagamente acoplado y asincrónico que imponer estos límites podría ser peor que
simplemente resolviendo los problemas.

podemos dar una IP de servicio a cada pod del servicio nominal

Aquí es donde empezamos, pero ...

Muchos de estos servicios esperan que la IP que tienen (su nombre)
se resuelve en la IP a la que se conectan, por lo que si se conectan a X en 172.1.1.1,
entonces X piensa que es 172.1.1.

Las IP de servicio no satisfacen esto, a menos que hagamos algo más en profundidad como
Lo mencioné con SNAT / DNAT. E incluso eso tiene deficiencias reales.

No estoy tratando de ser un dolor de cabeza, es solo que tenemos muy poco
tiempo en el período previo a 1.0, y no hay nada aquí que sea lo suficientemente claro como para
incluso prueba de concepto, y mucho menos implementar correctamente.

Estoy tratando de precisar exactamente lo que queremos experimentar para poder ver
lo que podemos implementar. Dadas las repetidas referencias a DNS, tengo
fuera de la reelaboración de DNS hasta que sepa qué está pasando aquí.

El miércoles 22 de abril de 2015 a las 10:12 a. M., Clayton Coleman [email protected]
escribió:

----- Mensaje original -----

Algún tipo de controlador podría activar / desactivar dinámicamente algunos campos en
vainas. Eso
simplemente no se puede combinar con la identidad de pod o RC. Atar la red
identidad
a las identidades de pod o RC está totalmente roto.

No trataría de hacer que la búsqueda de DNS inversa funcione para personas normales o sin cabeza.
servicios, y no creo que sea irrazonable imponer un máximo de uno
nominal
servicio por pod, que no tiene por qué limitar otros tipos de servicios en
todo.

Hay una serie de limitaciones de DNS que queremos impulsar a largo plazo.
correr
(invalidación de caché, soporte para sondeos largos, etc.). RPP múltiple
registros
es quizás solo otro elemento agregado a esa lista.

La otra alternativa es que podemos dar una IP de servicio a cada pod del
servicio nominal y luego solucionar los problemas que crea.

Muchos de estos servicios esperan que la IP que tienen (su nombre) resuelva
a la IP a la que se conectan, por lo que si se conectan a X en 172.1.1.1, entonces X
piensa que es 172.1.1.1. Eso no es todo software, pero parte de él. Por lo general es
Sin embargo, un nombre DNS, lo que significa que la IP puede cambiar debajo.

---

Responda a este correo electrónico directamente o véalo en GitHub:

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

La mayoría de los ejemplos de puertos múltiples son sistemas agrupados. Por ejemplo:
ZK : nombre de host o dirección IP que se puede resolver en un archivo de configuración, más un "id" (es decir, un índice: 1, 2, 3, ...) en un archivo

También deberíamos mirar a través de algunas bases de datos.

Hagamos lo que hagamos no funcionará para todo. Solo tenemos que encontrar el punto óptimo.

----- Mensaje original -----

Me temo que todo esto es todavía un poco abstracto para mí.

Los sistemas agrupados reales tienen miembros que tienen una "identidad" que es
Se espera que sea continuo en presencia de fallas en los nodos. Esa identidad
puede estar adjunto a un disco persistente o un "nombre", pero el nombre del
Identificar a otros sistemas no puede cambiar.

Esto no es un requisito. Es tan vago que no se puede implementar.

Por ejemplo, el guardián del zoológico tiene una identidad por nodo. Esa identidad debe permanecer
estable en la membresía del clúster

¿Qué es una identidad? ¿Una dirección IP? ¿Se pasó una bandera de cadena al software?
y env var? ¿Cómo aprende un proceso zk cuál es su propia identidad?

Algún tipo de controlador podría activar o desactivar dinámicamente algunos campos en los pods

Lo que activará el reinicio de esos pods y aún no responde al
pregunta de qué campos, qué valores y qué lógica decirle al grupo.

Pude ver algo como expandir anotaciones en banderas de línea de comando
(como estamos discutiendo con env vars) o simplemente en env vars. P.ej
el controlador escribe anotaciones ["zookeeper.com/index"] = 9, convertimos
$ .metatdata ["zookeeper.com/index"] en ZK_INDEX env. Pero estoy haciendo esto
arriba, no he visto demandas concretas que digan qué es exactamente el cuidador del zoológico (o
lo que sea) necesidad.

No creo que sea irrazonable imponer un máximo de un servicio nominal
por vaina

Creo que será difícil implementar tales restricciones. El sistema es tan
vagamente acoplado y asincrónico que imponer estos límites podría ser peor que
simplemente resolviendo los problemas.

podemos dar una IP de servicio a cada pod del servicio nominal

Aquí es donde empezamos, pero ...

Muchos de estos servicios esperan que la IP que tienen (su nombre)
se resuelve en la IP a la que se conectan, por lo que si se conectan a X en 172.1.1.1,
entonces X piensa que es 172.1.1.

Las IP de servicio no satisfacen esto, a menos que hagamos algo más en profundidad como
Lo mencioné con SNAT / DNAT. E incluso eso tiene deficiencias reales.

No estoy tratando de ser un dolor de cabeza, es solo que tenemos muy poco
tiempo en el período previo a 1.0, y no hay nada aquí que sea lo suficientemente claro como para
incluso prueba de concepto, y mucho menos implementar correctamente.

Estoy tratando de precisar exactamente lo que queremos experimentar para poder ver
lo que podemos implementar. Dadas las repetidas referencias a DNS, tengo
fuera de la reelaboración de DNS hasta que sepa qué está pasando aquí.

Creo que es prudente, deberíamos dedicar tiempo específicamente a resolver un conjunto de ejemplos conocidos. Tenemos 3 de nuestro lado que podemos aprovechar para ejemplos concretos (conjunto de réplicas de MongoDB, Zookeeper, Mysql Master / Slave), así como los ejemplos existentes en kube / examples. Quizás una sesión de trabajo para analizar los elementos, establecer límites a los problemas sin solución, identificar lo que queda.

Sugiera cambiar el nombre de esta función, ya que también podría usarse para trabajos por lotes para asignar un número de ID de fragmento.

Los trabajos por lotes tienen requisitos algo diferentes, por lo que me gustaría mantenerlos separados.

Ejemplo de cuidador del zoológico: https://github.com/openshift/origin/pull/1965

Ejemplo de necesidades nominales de ish de servicio https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

Estoy un poco confundido por qué la dirección todavía no está clara aquí, particularmente de parte de los empleados de Google. Google ha estado ejecutando servicios con estado bajo Borg durante muchos años, y está bastante claro qué se requiere para este tipo de carga de trabajo:

• Un identificador estable para el cual uno del conjunto de "fragmentos" (réplicas no idénticas) representa el pod actual (en borg, este es el "número de tarea", un entero simple). Este identificador debe permanecer constante durante las reprogramaciones / reinicios del módulo.
• Una forma de enumerar y contactar todos los fragmentos "pares", probablemente usando sus identificadores estables de alguna manera (en borg, este es un prefijo gordito junto con el número de tarea)

.. y terminamos.

Nota: Si la exclusión de recursos es crítica para cada fragmento, las aplicaciones deberán realizar su propio bloqueo distribuido, ya que siempre existe la posibilidad de que la vida útil del módulo se superponga durante fallas / reinicios (tal vez utilizando un bloqueo etcd basado en el identificador del fragmento). Una posible extensión de características exóticas es permitir más de una réplica idéntica dentro de cada fragmento, para redundancia / carga.

Esto se puede falsificar ahora mismo creando un servicio / puerto único para cada fragmento y ejecutando un controlador de replicación con réplicas: 1 pero es un poco torpe administrar una gran cantidad de fragmentos "a mano" como este.

Una forma natural de implementar esto en kubernetes podría ser:

• Los pods obtienen variables de entorno adicionales que dan su propio índice de fragmentos (entero) y el número total de fragmentos (¿o quizás lo comunican a través de la API descendente?).
• ReplicationControllers obtiene un recuento de "fragmentos" (predeterminado: 1) y "réplicas" se reinterpreta para significar "réplicas dentro de cada fragmento" (predeterminado: 1). Al reducir el conjunto de réplicas, deben eliminarse desde el final (para mantener contiguos los índices de fragmentos). Tenga en cuenta que el cambio de "fragmentos" requerirá un reinicio continuo de los pods controlados para actualizar su var env de "fragmentos totales" (bueno, no quiere que suceda instantáneamente).
• Los servicios obtienen un recuento de "fragmentos" similar que asigna un rango contiguo de puertos al selector normal más un selector de "índice de fragmentos" implícito.
• Los pods pueden encontrar otros fragmentos mediante SERVICE_PORT (¿o alguna nueva var env?) + Desplazamiento del índice del fragmento.

Tenga en cuenta que lo anterior se degrada graciosamente al comportamiento actual cuando los fragmentos = 1.

Generalmente estoy de acuerdo con esto (y como usted dice, ha cumplido la prueba del tiempo en Borg), aunque desaconsejaría ir con la "extensión de características exóticas" de múltiples réplicas por fragmento (aunque probablemente necesitemos algo así en el coberturas para migración).

Como mencioné anteriormente, esto está estrechamente relacionado con lo que debemos hacer para admitir trabajos por lotes con asignación de trabajo estático (lo que yo llamaba "tipo 1" aquí: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142)

Las otras características que debemos alinear si cambiamos RC (o agregamos algo nuevo) es cómo encaja la implementación, específicamente:

¿Cómo hago una actualización continua para:

1. Un RC regular
2. Un PerNodeController
3. Un RC fragmentado
4. ¿Un trabajo por lotes?

Es posible que deseemos mantener la implementación de implementación hasta que tengamos un hombre de paja para cada uno de ellos, porque creo que una implementación que solo funciona contra un RC simple tiene algunos problemas.

----- Mensaje original -----

En general estoy de acuerdo con esto (y como usted dice, ha cumplido la prueba del tiempo
en Borg), aunque desaconsejaría utilizar la "función exótica
extensión "de varias réplicas por fragmento (aunque probablemente necesitemos algo
así bajo las sábanas para la migración).

Como mencioné anteriormente, esto está estrechamente relacionado con lo que debemos hacer para
admitir trabajos por lotes con asignación de trabajo estático (lo que yo llamaba "tipo 1"
aquí:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

Hemos optado por no priorizar esto (y generamos automáticamente reclamaciones de volumen persistente) para 1.0 porque existen múltiples soluciones, como crear un servicio, RC y reclamación de volumen persistente por instancia.

Si bien los índices de tareas densamente asignados estáticamente en Borg se utilizan ampliamente, hemos aprendido que tienen una serie de deficiencias y hemos pasado algún tiempo durante los últimos años desarrollando alternativas. Muchos de los problemas surgen del hecho de que los índices están acoplados al ciclo de vida y la identidad de las tareas en sí. Esto dificulta la implementación de una serie de estrategias de implementación, migración, administración dinámica de tareas y muchos otros escenarios. Otra complejidad proviene de la generación estática de la configuración por índice para cada tarea previa al despliegue; esto equivale a generar un RC por valor de índice. Eso sería sencillo para alguien si realmente quisiera. Las etiquetas aún podrían usarse para derribar todo el conjunto.

Controlador por nodo / demonio: Buen punto. Los índices densamente asignados son un mal modelo para ese caso. ¿Qué haces cuando un nodo desaparece permanentemente, por ejemplo? Los índices se vuelven escasos. Recomiendo que no lo apoyemos.

Trabajos por lotes: como se discutió en el n. ° 1624, nos gustaría asignar índices basados ​​en finalizaciones, no en pods que se estén ejecutando actualmente.

Como se mencionó anteriormente, la asignación de índices debe tener en cuenta el almacenamiento asociado, como las reclamaciones de volumen persistente: la identidad se deriva de la identidad de la red (nombre DNS y / o dirección IP) y el almacenamiento.

La asignación no puede ser impulsada por un solo controlador de replicación. Esto simplemente no funciona. Los controladores de replicación no son entidades duraderas y esperamos que haya varios RC por servicio, para canarios, actualizaciones continuas, múltiples pistas de lanzamiento, múltiples clústeres, etc. Incluso el objeto de implementación propuesto (# 1743) no tiene el alcance correcto .

Hay 3 alternativas de asignación:

1. Asignar asignación con un tipo especial de servicio. El servicio tiene exactamente el alcance correcto. (También eventualmente necesitaremos servicios regionales). Esto sería una especie de híbrido entre los servicios regulares y los servicios autónomos. Es lo que imaginé cuando propuse originalmente este mecanismo. La asignación se registraría en Endpoints. Los puntos finales y / o DNS sin cabeza serían las formas obvias de enumerar a todos los pares.
2. Cree un nuevo tipo de objeto que sea similar a Service, pero solo para servicios nominales. Es probable que también necesitemos un nuevo objeto para registrar la asignación. Esto expandiría nuestra superficie API innecesariamente, en mi opinión.
3. "Tirar" en lugar de "empujar". Los pods están programados para hosts sin un controlador explícito, incluso con restricciones de nodo (selector) o uno de los mecanismos de antiafinidad propuestos (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). Esto también es similar a la asignación de servicio VIP. Podríamos hacer algo similar para los servicios nominales. Un pod (o plantilla de pod) especificaría el grupo de índices del que deseaba asignar un índice. A diferencia de los servicios generales, no esperamos que a los pods se les deba asignar varios índices de diferentes grupos. La asignación se registraría en la especificación de la cápsula.
4. Ventajas: más simple para los usuarios. No requiere otro objeto. Permite la asignación por parte de los usuarios.
5. Contras: Diferente de otros tipos de servicios.

La asignación de PVC idealmente usaría el mismo modelo.

También vale la pena considerar cómo se orquestaría la migración de pod # 3949. La cápsula de reemplazo DEBE crearse antes de eliminar la cápsula que se está reemplazando para transferir el estado del contenedor. Esto puede hacer que el modelo pull sea un poco problemático. Independientemente, el mecanismo de asignación debería tener en cuenta la migración.

Otras Consideraciones:

1. Cómo comunicar el índice / identidad a los compañeros. DNS es la respuesta obvia.
2. Cómo comunicar el índice / identidad a los contenedores en el pod. Variables de entorno, DNS inverso, ... El índice asignado no va a cambiar dinámicamente, aunque el enlace de DNS puede cambiarse mientras el pod todavía existe. Me gustaría elegir un mecanismo que las aplicaciones ya esperan que funcione en otros entornos, y al igual que con la discusión de API descendente más amplia (# 386), no quiero acoplar aplicaciones a variables de entorno específicas de Kubernetes, pero el nuevo EnvVarSource y la sustitución de env var (# 7936) ayudaría a evitar eso.

No estoy de acuerdo con algo de lo que dijo, pero esperemos para continuar esta discusión hasta después de 1.0.

Reviviendo este viejo hilo para hacer una pregunta. ¿Existe algún interés en una política de nomenclatura del controlador de replicación? Nombres específicamente nominales como se discutió anteriormente, donde todos los Pods controlados por este controlador de replicación tendrían sufijos numerados, algo así como 0001, 0002 ...

Un caso de uso de ejemplo es un balanceador de carga nginx que apunta a este conjunto de pods por nombres de dominio. Entonces, a medida que los pods van y vienen, se espera que los nombres de dominio siempre se corrijan de xxx-0001 a xxx-000N.

@ravigadde Lea mi último comentario sobre este problema: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

Me encontré con este problema al intentar configurar un contenedor RabbitMQ. La persistencia de Rabbit depende del nombre de host, por lo que tener nombres de host variables significa que perderá la base de datos de Mnesia al reiniciar el contenedor.

Intenté solucionarlo con la configuración de la imagen (nombre de host directamente y Rabbit), variables ENV y la API descendente. No pude obtener ninguno para resolver el problema: Rabbit aún toma el nombre del Pod generado. Resolviendo temporalmente al cambiar de usar un controlador de replicación según la sugerencia de

Si lo entiendo correctamente, el módulo rabbitmq (creado con un controlador de replicación) en el ejemplo de celerey-rabbit perderá datos en caso de falla del

RabbitMQ nombra el directorio de la base de datos utilizando el nombre de host actual del sistema. Si el nombre de host cambia, se crea una nueva base de datos vacía. Para evitar la pérdida de datos, es fundamental configurar un nombre de host fijo y que se pueda resolver.

No hay una buena solución para esto ahora, pero podría crear un pod (no vinculado a un rc) con un disco persistente migrable, con la advertencia de que el pod deberá reprogramarse manualmente en ciertos casos de fallas. Esa es la única forma que se me ocurre de mantener el nombre de host estático.

O en el inicio, enlace simbólico el directorio del nombre de host a una ubicación estable

El 11 de julio de 2015, a las 5:26 p.m., Mike Danese [email protected] escribió:

Si entiendo correctamente, el módulo rabbitmq (creado con una réplica
controlador) en el clerey-conejo
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
ejemplo perderá datos en caso de falla del pod incluso si los datos se almacenan en un
disco persistente. Desde rabbitmq doc:

RabbitMQ nombra el directorio de la base de datos utilizando el nombre de host actual del
sistema. Si el nombre de host cambia, se crea una nueva base de datos vacía. Para evitar
La pérdida de datos es crucial para configurar un nombre de host fijo y resoluble.

No hay una buena solución para esto ahora, pero podría crear un pod (no
enlazado a un rc) con un disco persistente migrable, la advertencia es el pod
deberá reprogramarse manualmente en ciertos casos de fallas. Eso es
única forma en que puedo pensar para mantener el nombre de host estático.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

Ese es un ejemplo de por qué el nombre de host no debe derivarse del nombre del pod - # 4825

Para darle una ligera patada a esto:

Hay varios problemas fundamentales que deben resolverse:

1. Algunos componentes deben tener una identidad única por pod que esté vinculada a su almacenamiento en disco.
   
   
   
   1. Como problema adicional, algunos de ellos (el cuidador del zoológico en algunos casos) necesitan que el nombre de host se pueda resolver y que coincida
   
   
2. Algunos componentes que se escalan horizontalmente deben tener un almacenamiento persistente que sea diferente por pod (los pods apuntan a PVC que difieren por pod, vinculados a la identidad)
   
   
   
   1. A veces, esos volúmenes deben crearse a pedido a escala.
   
   
   2. A veces, esos volúmenes deben reutilizarse de un grupo y no recrearse
   
   
3. Algunos componentes pueden escalar horizontalmente a decenas de miles de instancias, donde el seguimiento de identidades asignadas individuales se vuelve poco práctico
   
   
   
   1. La mayoría de los usos de nominal probablemente serán entre 2 y 7 instancias de un pod (la mayoría de las bases de datos escalables actuales, la mayoría de las configuraciones multimaestro fragmentadas)
   
   
4. A algunos componentes les gustaría no tener que implementar su propia elección maestra, pero dejar que la plataforma lo gestione haciendo que una de las identidades sea arbitraria (la identidad 1 se convierte en la maestra)
5. Cuando resolvamos estos problemas, los usuarios aún deberán implementar cambios en los pods (a través de implementaciones) y asegurarse de que cualquier identidad se conserve o se reasigne.

No es necesario que todos se resuelvan en la misma solución. Por ejemplo, creo que hay una diferencia significativa entre la identidad de clúster de tamaño pequeño (2-7) y la identidad de clúster de gran escala (> 7). Por ejemplo, en el caso grande, ese software está menos preocupado por las brechas o tiene un protocolo de consenso / membresía existente. En el caso pequeño, el software necesita más ayuda para establecer la identidad. Los separaría en software nativo de la nube (> 7) y en clúster existente (2-7).

Estoy de acuerdo con 1a, 1b y 2a. 2b suena como un problema diferente, aunque quizás la solución pueda reutilizar el mismo patrón.

Creo que la escala (3) sugiere principalmente que nuestra solución alternativa de un servicio y RC por instancia no es adecuada, aunque estoy de acuerdo con la distinción entre nativos de la nube y no.

La elección maestra (4) se puede abordar por separado.

También de acuerdo con (5).

Creo que la mayoría de los requisitos de diseño están claros en este momento.

Preguntas de diseño restantes:

I. ¿Asignar VIP o permitir cambios de IP? Estrechamente relacionado con esto está si los contenedores deben poder descubrir sus propias IP a través de Linux o no, ya que los VIP actualmente no se pueden descubrir a través del sistema. Supongo que necesitan poder descubrir sus IP, pero podrían usar la API descendente, como con la IP del pod (# 12595). Permitir que las IP cambien (debido al uso de IPs de pod) implica un límite en la tasa de cambio de la IP, debido a los TTL de DNS y los "errores" de almacenamiento en caché. Sin embargo, en algún momento, también pretendemos hacer que las IP de los pods sean migrables (# 3949), por lo que cambiar las IP no sería para siempre.

II. Empujar (a las cápsulas) frente a tirar (de las cápsulas). Los servicios y los RC se acoplan intencionalmente de forma flexible a los pods y, por lo tanto, ambos utilizan el modelo "push". Los servicios nominales estarían más intrínsecamente ligados a la identidad de los pods (aunque no de forma permanente, los pods deben ser reemplazables). En consecuencia, veo menos motivación para el modelo push. Otros casos de asignación, como programación y esp. enlace exclusivo, como reclamos de volumen persistente a volúmenes persistentes, usa un modelo de solicitud / ack, también conocido como "pull". Ese es actualmente el modelo que prefiero para los servicios nominales.

¿Alguien tiene opiniones sobre (yo)?

La elección maestra es el n. ° 1542 y se está discutiendo como parte de la implementación de HA (por ejemplo, n. ° 12884).

No sé a qué te refieres con empujar y tirar.

He vuelto a leer la mayor parte de este número y estoy convencido de que no hay un solo
solución. Necesitaremos una familia de funciones para construir un puente hacia
este tipo de aplicaciones.

Empiezo con el axioma de que una vez que se está ejecutando una cápsula no se puede
cambiar una cápsula para correr. Hay algunas excepciones a esto (por ejemplo, virtual
contenidos del sistema de archivos) pero las cosas que parecen importar (env vars, IP,
hostname) te quedas atascado con lo que sea que comiences.

También estoy comenzando con la afirmación de que el acoplamiento flexible entre
El servicio y la cápsula se mantienen, lo que hace que esto de lo que estamos hablando no sea realmente un
Servicio. Los pods realmente no saben qué servicios tienen frente a ellos. Si cambiamos
eso, ya no es un Servicio.

Solo voy a hacer una corriente de conciencia y ver qué no apesta.

Idea 1: ThingPools y parches.

Defina un nuevo objeto API o algo que le permita definir un grupo de
cosas. ¿Qué es una cosa? Una cosa es una cadena (o tal vez un blob JSON) que
tiene un tipo enumerado. Puede crear un grupo de Cosas y esas Cosas
son tuyos para usar. Los tipos de cosas incluyen VUID (nombres de host), cadenas, VIP.

Defina una nueva construcción de API que se pueda pasar para crear operaciones: una
parche. Un parche son instrucciones sobre cómo parchear el objeto que se está
creado. Una de las opciones de parche es "asignar desde un ThingPool".

Para poner estos juntos:

Defina un ThingPool {meatadata.name: my-quorum-hostnames, type: VUID,
autogenerate: 5,} // crea un grupo de 5 VUID válidos

Definir un RC {réplicas: 5 ...}

En la creación de RC (POST) también envíe un parche: {qué:
"podTemplate.spec.containers [*]. metadata.VUID", grupo: "my-quorum-hostnames"
}

La operación POST aplicaría el parche al RC - asignando un VUID
por contenedor de ThingPool. Cada vez que se mata y se recrea una vaina,
el VUID se devuelve al grupo y el siguiente pod que se inicia lo obtendrá.

Puede usar esto para generar un grupo de cadenas ("0" a "99") y pegar
ésos en una var env. Puede usar esto para asignar un grupo de VIP y
luego asigne esos VIP a los pods (sería una nueva característica: pod duradero
IP: no estoy seguro de cómo se escalará :) Podría generar un grupo de
PersistentVolumeClaim nombra y parchea el volumen de reclamos que usa cada pod.

Esta idea es imperfecta en muchos sentidos, pero creo que capta mejor la
idea de un conjunto de vainas sin definir directamente un conjunto de vainas.

Idea 2: Defina un conjunto de vainas. No finjas que es un servicio. Esta mas cerca
a un trabajo Borg. Es como un RC pero asigna ordinalidad a las vainas que
controles: números de fragmentos. Controla el grupo de VUID (pero no queremos
nombre de host para que sea algo que los usuarios puedan configurar, hmmm ...).

Pensé que tenía más ideas, pero no las tengo. Estoy luchando con abstracciones
e implementaciones: no tiene sentido definir una abstracción que no podemos
implementar. VIP para nominales suena muy bien, pero creo que empujará el
límites de iptables. Proporcionar un conjunto de nombres de host estables para un conjunto de pods
parece ser lo más importante, con un conjunto de almacenamiento para un conjunto de
vainas calientes en su cola.

El martes 18 de agosto de 2015 a las 7:28 p.m., Brian Grant [email protected]
escribió:

Estoy de acuerdo con 1a, 1b y 2a. 2b suena como un problema diferente, aunque
quizás la solución pueda reutilizar el mismo patrón.

Creo que la escala (3) sugiere principalmente que nuestra solución de un servicio y
RC por instancia no es adecuado, aunque estoy de acuerdo con la distinción entre
nativo de la nube frente a no.

La elección maestra (4) se puede abordar por separado.

También de acuerdo con (5).

Creo que la mayoría de los requisitos de diseño están claros en este momento.

Preguntas de diseño restantes:

I. ¿Asignar VIP o permitir cambios de IP? Estrechamente ligado a esto está si
los contenedores deben poder descubrir sus propias IP a través de Linux o no,
dado que los VIP actualmente no son detectables a través del sistema. Supongo que lo hacen
necesitan poder descubrir sus IP, pero podrían usar la API descendente, ya que
con IP de pod (# 12595 https://github.com/kubernetes/kubernetes/pull/12595).
Permitir que las direcciones IP cambien (debido al uso de direcciones IP de pod) implica un límite en la tasa
de cambio de la IP, debido a DNS TTL y "errores" de almacenamiento en caché. En algún momento, nosotros
también tiene la intención de hacer que las IP de los pods sean migrables, aunque (# 3949
https://github.com/kubernetes/kubernetes/issues/3949), cambiando IPs
no sería para siempre.

II. Empujar (a las cápsulas) frente a tirar (de las cápsulas). Los servicios y los RC son
intencionalmente acoplado libremente a las vainas y, por lo tanto, ambos usan el "empujar"
modelo. Los servicios nominales estarían más intrínsecamente vinculados a la identidad del grupo.
(aunque no de forma permanente, las cápsulas deben ser reemplazables). En consecuencia, veo
menos motivación para el modelo push. Otros casos de asignación, como
programación, y esp. vinculación exclusiva, como reclamos de volumen persistente a
volúmenes persistentes, use un modelo de solicitud / ack, también conocido como "pull". Que es actualmente
el modelo que prefiero para los servicios nominales.

¿Alguien tiene opiniones sobre (yo)?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

Probablemente no me refería realmente a la elección maestra como lo piensas, más que
al crear una funcionalidad en la que es necesario inicializar un conjunto de instancias
(sin coordinar explícitamente) teniendo solo la instancia que piensa que es
Hablar "1" con otros pods suele ser suficiente para iniciar un clúster. Un
ejemplo es mongodb, donde debe iniciar el conjunto de réplicas, si los pods
que piensan que son "2" o "3" iniciados, puede obtenerlos en los casos en que
iniciar una división. Pero "1" puede iniciarse de forma segura cada vez, y luego
intente agregar los otros miembros (que tienen un estado persistente que pueden usar para
determinar si ya forman parte de un clúster). Dependiendo de
garantías proporcionadas por el servicio de identidad, es posible que no obtenga una
clúster exitoso, pero no tiene que crear un grupo externo separado para
inicialice su servicio (aunque eso tampoco es terrible).

El martes 18 de agosto de 2015 a las 11:59 p.m., Brian Grant [email protected]
escribió:

La elección maestra es la n. ° 1542
https://github.com/kubernetes/kubernetes/issues/1542 , y está siendo
discutido como parte de la implementación de HA (por ejemplo, # 12884
https://github.com/kubernetes/kubernetes/pull/12884).

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

Clayton Coleman | Ingeniero jefe, OpenShift

@smarterclayton Es un aparte del problema de los servicios nominales, pero no es seguro arrancar como está describiendo. Si "1" se reinicia en una nueva máquina y resulta que no puede alcanzar los nodos existentes, entonces se reiniciará y ahora tiene dos mongodb que afirman ser autorizados. Debe cambiar la definición del trabajo para eliminar la capacidad de bootstrap después de que se complete el bootstrap.

Como podría estar aludiendo @thockin , creo que estamos combinando innecesariamente varias características similares pero diferentes aquí, y estamos incluyendo más de lo estrictamente necesario en el nivel k8s.

Veo dos casos de uso bastante diferentes descritos anteriormente, que difieren según la fuente de la verdad:

_Prescriptive: _ "Quiero N fragmentos en ejecución, y si hay más o menos que eso, haga cambios para devolverlos a N."
_Descriptivo: _ "Solo quiero descubrir automáticamente todos los fragmentos disponibles y dejarme averiguar de alguna manera a medida que aparecen y desaparecen".

Creo que estos son diferentes y deberían describirse de manera diferente (aunque pueden presentar metadatos similares a los pods en ejecución reales).

La discusión también ha incorporado cercas de recursos y garantías de acceso único. Afaics, el _único_ caso en el que esto debe hacerse dentro de k8s es montar volúmenes persistentes remotos (porque el montaje de fs debe realizarse fuera del contenedor), y esto es bastante fácil de hacer a través de bloqueos etcd si el servicio de volumen remoto subyacente no lo hace ' t ya proporciona vallas internamente. Todos los demás casos pueden ser manejados por los propios trabajos del usuario, utilizando un servicio de bloqueo distribuido (o accediendo a servicios que proporcionan bloqueo internamente). Pedirle a los trabajos que hagan su propio bloqueo abre todo tipo de patrones (asignación fija, asignación oportunista, "repuestos en caliente", etc.) y estrategias de inaccesibilidad / recuperación (falla completa, continuar con el último conocido, etc.).

Sugiero sacar la solicitud de función de cercado de recursos general de este error (e implementamos el cercado simplemente proporcionando una receta para ejecutar varios servicios de bloqueo distribuidos en k8s sin que el k8s participe más).

Solo un recordatorio: hay un _ lote_ de puertos detrás de un solo VIP. Estoy de acuerdo en que no queremos migrar direcciones IP, ya que eso suena difícil en la red subyacente a gran escala y es incómodo para la red lidiar con duplicados temporales durante casos de falla / recuperación en el borde. Sin embargo, creo que _es_ bastante factible asignar un puerto de servicio único a cada miembro del fragmento y datos de proxy a cada instancia de pod, incluso para trabajos muy grandes. (Esta sugerencia supone que los proxies siguen siendo la dirección en la que queremos ir con k8s; no me he mantenido al día con ninguna discusión reciente sobre esta área)

Por push, me refería a otro recurso, como un Servicio o controlador, que supervisaría conjuntos de pods mediante un selector de etiquetas y les otorgaría "cosas" (nombres DNS resolubles, VIP, PVC).

Por pull, quise decir que el pod solicitaría explícitamente la asignación de una "cosa", que luego estaría vinculada a ella a través de algo como / binding.

Con respecto al cambio de pods en ejecución: cambiar un pod después de la creación es diferente a cambiar un pod con contenedores en ejecución. El planificador se realiza de forma asincrónica. inicialización, por ejemplo. PodIP también se asigna tarde. Discutido de manera más general en el n. ° 3585.

En cuanto a si esto es realmente un "servicio" o no:

• Las cosas deben asignarse a los conjuntos de grupos
• La cosa (p. Ej., Nombres DNS) no debe estar intrínsecamente vinculada al nombre de recurso de un pod
• Una cosa debe ser transferible de una vaina a otra.
• El pod necesita "saber" (o ser capaz de averiguar a través de API descendente) qué cosa (especialmente el nombre DNS y VIP) se le asignó.
• Una cosa que debemos admitir es DNS resoluble
• Si necesitamos VIPs era mi única pregunta pendiente. Estoy bien con no usar VIP.
• No es ideal, pero el usuario podría crear un segundo servicio sin cabeza dirigido a todo el conjunto para el descubrimiento de pares a través de DNS y / o puntos finales.

Idea (1), ThingPools + Patches es una idea interesante. Lo describiría como un enfoque de "tracción". ThingPool no es malo, pero me preocupa que los parches sean difíciles de usar y no quisiera aplicar ingeniería inversa a la información semántica de los parches dentro del sistema para proporcionar un comportamiento aceptable en torno al ciclo de vida del almacenamiento, etc. Preferiría algo más específico del dominio. Además, los ThingPools independientes para nombres DNS y PVC no funcionarían, ya que deben ser asignados conjuntamente.

Describiría la idea (2) como un enfoque de "empuje". No quiero duplicar el trabajo en RC e implementaciones, por lo que no deberíamos introducir otro controlador de pod. Un asignador estaría bien, pero está más débilmente acoplado de lo necesario y no coincide con el precedente de cómo manejamos la asignación.

Re. relleno de información en env vars: esto también ha surgido para Job. Quiero incluir la información en una anotación y extender la API descendente para poder solicitar anotaciones específicas. Quiero seguir permitiendo que los usuarios soliciten solo la información que necesitan y elijan nombres de var env.

Re. Asignar diferentes puertos a cada instancia: eso no funcionaría para muchas aplicaciones heredadas y tampoco es compatible con el diseño de nuestro sistema.

Re. prescriptivo: Mantener N en ejecución es lo que hace ReplicationController.

Re. descriptivo: Eso es servicios sin cabeza, que ya existen.

Re. bloqueo: Sí, esa es la API de arrendamiento que está en marcha.

El aprovisionamiento de almacenamiento se analiza en # 6773 (push) y # 12450 (pull).

Ahora es demasiado tarde, pero de alguna manera intentaré hacer una propuesta después de dormir un poco.

Observación rápida: los servicios sin cabeza no asignan VIP

Podríamos desvincular la asignación / asignación de la publicación de DNS. Ignorando cómo ocurre la asignación / asignación por el momento, podríamos tener un sabor especial de servicio sin cabeza que toma nombres de algún campo en los pods que representan el nombre de host.

Y los problemas de almacenamiento local duradero son relevantes: # 7562, # 1515, # 598

Actualizaciones más rápidas como hago principalmente con otras revisiones de relaciones públicas:

Una ventaja de usar un servicio es que no necesitaríamos garantizar que los nombres de host solicitados para los pods fueran únicos a nivel mundial, ya que el servicio abarcaría los nombres publicados en DNS.

Re. Asignación / asignación: quiero evitar agregar más tipos de plantillas a ReplicationController, Deployment, Daemon, etc., y quiero que el almacenamiento y los nombres puedan migrar entre controladores tan fácilmente como entre pods (si eso es lo que quiere el usuario).

El 19 de agosto de 2015, a la 1:04 a. M., Angus Lees [email protected] escribió:

@smarterclayton https://github.com/smarterclayton Es un aparte del
problema de servicios nominales, pero no es seguro arrancar ya que está
describiendo. Si se reinicia "1" en una máquina nueva y resulta que no
para llegar a los nodos existentes, luego se reiniciará y ahora tiene dos
mongodb afirma ser autoritario. Necesitas cambiar de trabajo
definición para eliminar la capacidad de bootstrap después de que el bootstrap sea
completo.

Es muy posible que se superponga en ese caso, pero en la mayoría
casos, estamos hablando de almacenamiento persistente con bloqueos para bloquear
de todos modos hasta que gce / AWS soltó su valla y pudo adjuntar. Entonces
sacrifica la disponibilidad en el arranque, pero no necesariamente en el tiempo de ejecución
(a menos que esté en un almacenamiento sin valla, en cuyo caso acepto que esto no sería
a salvo)

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

El 19 de agosto de 2015, a la 1:35 a. M., Angus Lees [email protected] escribió:

Como @thockin https://github.com/thockin podría estar aludiendo, creo
estamos combinando innecesariamente varias características similares pero diferentes aquí

• e incluimos más de lo estrictamente necesario en el nivel k8s.

Veo dos casos de uso bastante diferentes descritos anteriormente, que difieren según la fuente
de verdad:

_Prescriptive: _ "Quiero N fragmentos en ejecución, y si hay más o menos
que eso, luego haga cambios para devolverlo a N. "
_Descriptivo: _ "Solo quiero descubrir automáticamente todos los fragmentos disponibles y
déjame averiguarlo de alguna manera a medida que van y vienen ".

Creo que estos son diferentes y deberían describirse de manera diferente (aunque

podrían presentar metadatos similares a los pods en ejecución reales).

La discusión también ha incorporado cercas de recursos y acceso único.
Garantías. Afaics, el _único_ caso en el que esto debe hacerse dentro de k8s
(afaics) está montando volúmenes remotos, porque es necesario realizar el montaje fs
fuera del contenedor. Todos los demás casos pueden ser manejados por los trabajos del usuario.
ellos mismos, utilizando un servicio de bloqueo distribuido (o accediendo a servicios que
proporcionar bloqueo internamente). Pedir a los trabajos que hagan su propio bloqueo abre
todo tipo de patrones (asignación fija, asignación oportunista, "hot
repuestos ", etc.) y estrategias de inaccesibilidad / recuperación (falla dura,
continuar con el último conocido, etc.).

Sugiero mover la solicitud de función de cercado de recursos general fuera de este
error (e implementamos cercas simplemente proporcionando una receta para ejecutar
varios servicios de bloqueo distribuido en k8s sin más participación de
k8s en sí).

No creo que podamos desvincular el objetivo de ejecutar ciertos tipos de
software fuera: el diseño dice servicios nominales, pero los casos de uso que estamos
describir es reutilizar la identidad y el disco. Estoy de acuerdo, la cerca es propiedad de
volúmenes, pero vinculando la adquisición de un volumen a una determinada propiedad de
la instancia de pod no lo es.

Solo un recordatorio: hay un _ lote_ de puertos detrás de un solo VIP. Estoy de acuerdo que
no quiero migrar direcciones IP ya que eso suena difícil en la red subyacente
a escala, y es incómodo para la red lidiar con duplicados temporales
durante casos extremos de falla / recuperación. Sin embargo, creo que es bastante factible
para asignar un puerto de servicio único a cada miembro del fragmento y datos de proxy a cada
instancia de pod, incluso para trabajos muy grandes. (Esta sugerencia asume la
los proxies siguen siendo la dirección en la que queremos ir con k8s; no he seguido el ritmo
con cualquier discusión reciente sobre esta área)

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

Ligero giro a la idea de ThingPool + Patches de @thockin:

Plantilla: lista de recursos + parámetros y sustitución. Consulte https://github.com/openshift/origin/blob/master/pkg/template/api/types.go para obtener inspiración. Ref # 503, # 1743, # 4210, # 6487.

TemplatePool. Básicamente ThingPool. Genera instancias de plantilla densamente indexadas a pedido en lugar de por recuento de réplicas.

Por diversión / coherencia: v2 ReplicationController podría replicar plantillas arbitrarias en lugar de solo pods. ref # 170 (más o menos). Quizás no sea necesario si toda la asignación se basa en la replicación de pod.

La principal alternativa sería algo más específico del dominio, centrado en el nombre de host y los grupos de PVC, pero los grupos separados para cada uno no funcionarían. Un único grupo debería poder asignar tuplas de nombres de host y PVC (potencialmente múltiples). Una ventaja de TemplatePool es que alguien podría usarlo para asignar un servicio (quizás externo) por réplica, automatizando la solución actual de Zookeeper. No sé si podría haber otros recursos que alguien quisiera replicar de manera similar 1 a 1 con pods, pero dada la velocidad a la que crece nuestra API, no apuesto a que no los habrá.

@smarterclayton Para su información, cuando responde por correo electrónico con comentarios en línea, sus respuestas son ilegibles, tanto en gmail como en github. En gmail, no hay saltos de línea y en github no hay prefijos de comillas, por lo que su respuesta es difícil de distinguir aparte del texto que se cita.

Sí, hay algo mal con gmail + github + iPhones.

El jueves 20 de agosto de 2015 a las 2:24 p.m., Brian Grant [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton FYI cuando responda
por correo electrónico con comentarios en línea, sus respuestas son ilegibles, tanto en
gmail y en github. En gmail, no hay saltos de línea y en github hay
no hay prefijos entre comillas, por lo que su respuesta es difícil de distinguir aparte de los
texto que se cita.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Ingeniero jefe, OpenShift

Hoy tuvimos una charla rápida, algunos aspectos destacados:

Hablé de las tres clases de aplicaciones:

• Aplicaciones que son aplicaciones web sin estado (solo funciona con RC)
• Aplicaciones de escala gigante que utilizan maestros externos y tienen coherencia existente
  protocolos (Cassandra, Infiniband) para manejar el consenso
• Software con estado agrupado pequeño como Mongodb, rethinkdb, volt, etcd,
  zookeeper, riak, redis clusters, que necesitan algunos patrones para funcionar bien
  
  
  
  • Identidad única (generalmente)
  
  
  • Volumen persistente único por instancia que se reutiliza (generalmente)
  
  
  • Dirección IP estable o nombre DNS (comúnmente): el nombre DNS suele ser un
    
    en lugar de una dirección IP estable
  
  
  • Nombre de host estable (rara vez)
  
  

Hoy en día, puede resolver una identidad única y un volumen persistente al tener N
controladores de replicación, dirección IP estable con N servicios. Nos gustaria
para no requerir N RC y servicios para algunos de esos casos de uso.

Hablamos sobre las sugerencias de Tim y Brian, sin ningún orden en particular:

• TemplatePool es problemático porque el replicador necesita tener el
  autoridad para crear objetos en todo el clúster, y debe saber
  donde está cada punto final de la API.
  
  
  
  • Podría tener un punto final de plantilla de instancia, pero aún necesita
    
    resolver el problema de delegación de autoridad (¿con cuentas de servicio?)
  
  
  • Ubicar objetos y restringir el permiso son cosas a más largo plazo
  
  
• La "identidad de la cápsula", también conocida como campo vuid, del que hablamos: el argumento se hizo
  y, en general, estamos de acuerdo con que no es necesario que sea único a nivel mundial, solo
  único dentro del dominio que el pod espera usarlo.
  
  
  
  • Un asignador de índice hipotético (escaso o denso) podría establecer ese valor
    
    post creación, y el kubelet podía esperar para iniciar los pods hasta que tuvieran un
    
    identidad (es posible que deba indicar que están esperando una)
  
  
  • Los índices densos son generalmente útiles para cosas simples, pero debido a que esto
    
    es posterior a la creación y desacoplado del kubelet, podría tener diferentes
    
    tipos de algoritmos de asignación (numérico denso, anillo hash consistente,
    
    aleatorio, etc.)
  
  
• La creación de plantillas simples en pods parece un buen punto de partida, pero necesitamos
  para que sea coherente con nuestra cadena de herramientas existente de una manera que no
  romperlo totalmente
  
  
  
  • Utilice el campo de identidad para crear plantillas en otros campos
  
  
• Agregue un campo de nombre de host en la especificación del pod que los usuarios puedan configurar ellos mismos y
  parametrizar con la identidad
• Permitir que un servicio sin cabeza responda a consultas de dns para endpoints por su
  identidad (haga que el controlador de puntos finales materialice la identidad de un pod
  en puntos finales) que garantiza cierta estabilidad
• De alguna manera permitir que las reclamaciones de volumen persistentes se parametricen o modifiquen para
  extraer de una piscina (o tener un controlador de piscina para asegurarse de que haya un volumen por
  identidad, o hacer que el controlador de identidad extraiga de grupos), es necesario pensar
• Necesita herramientas que faciliten convertir el entorno / api descendente en
  archivos de configuración (ortogonales, pero debería ser más fácil)
• Todavía algunas preocupaciones sobre el patrón

El jueves 20 de agosto de 2015 a las 3:34 p.m., Clayton Coleman [email protected]
escribió:

Sí, hay algo mal con gmail + github + iPhones.

El jueves 20 de agosto de 2015 a las 2:24 p.m., Brian Grant [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton FYI cuando responda
por correo electrónico con comentarios en línea, sus respuestas son ilegibles, tanto en
gmail y en github. En gmail, no hay saltos de línea y en github hay
no hay prefijos entre comillas, por lo que su respuesta es difícil de distinguir aparte de los
texto que se cita.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Ingeniero jefe, OpenShift

Clayton Coleman | Ingeniero jefe, OpenShift

Un problema más: certificados TLS para miembros de servicios nominales

Los certificados TLS para servicios en general también serían algo bueno (firmado
por la CA del clúster automáticamente a pedido).

El jueves 20 de agosto de 2015 a las 5:19 p.m., Brian Grant [email protected] escribió:

Un problema más: certificados TLS para miembros de servicios nominales

-
Responda a este correo electrónico directamente o véalo en GitHub.

Clayton Coleman | Ingeniero jefe, OpenShift

Sí: # 11725

Re:

• Agregue un campo de nombre de host en la especificación del pod que los usuarios puedan configurar ellos mismos y
  parametrizar con la identidad
• Permitir que un servicio sin cabeza responda a consultas de dns para endpoints por su
  identidad (haga que el controlador de puntos finales materialice la identidad de un pod
  en puntos finales) que garantiza cierta estabilidad

Creo que acordamos que el dns debería ser compatible con los nombres de host establecidos en las especificaciones del pod (que podrían ser parametrizados por sus identidades una vez que agreguemos esa funcionalidad), de modo que los nombres de host vistos por los contenedores se puedan resolver con otros contenedores.

Para configurar el subdominio, tendríamos que decirle al pod qué servicio lo apuntó, explícita o implícitamente. La desventaja de explícito es que requiere más pegado de configuración / plantillas. La desventaja de implícito es que sería propenso a los desafíos que tenemos con el acoplamiento flojo en el sistema: carreras de orden de creación e inconsistencia, dificultades de cumplimiento 1 a 1, etc. Me inclino por lo explícito. Deberíamos trabajar para mejorar el alcance de las referencias cruzadas.

Algo como:

Hostname string
Subdomain string

por encima de HostNetwork en PodSpec.

Solo entregaríamos el DNS basado en el nombre de host si el subdominio coincidiera con eso para un servicio del tipo correcto. También podríamos unir los dos en un solo campo.

Creo que deberíamos reutilizar el número 4825 para eso y conseguir que alguien trabaje en él. Es mucho más concreto y menos laborioso que el resto.

De alguna manera permitir que las reclamaciones de volumen persistentes se parametricen o modifiquen para
extraer de una piscina (o tener un controlador de piscina para asegurarse de que haya un volumen por
identidad, o hacer que el controlador de identidad extraiga de grupos), es necesario pensar

Hay dos cosas sobre las afirmaciones que creo que pueden ayudar aquí:

1. Cambiar encuadernación de 1: 1 a 1: N
   
   
   
   1. pvc.Spec.VolumeName a pvc.Spec.VolumeNames [] como referencia de enlace
   
   
2. pvc.Spec.Singelton booleano que indica si un reclamo debe vincularse exactamente una vez para compartir o permitir que el reclamo esté vinculado muchas veces.

Un RC puede unirse a nuevos volúmenes según sea necesario. Descubriría cómo manejar esto en la carpeta.

Aún sería importante hacer coincidir el volumen correcto con el pod correcto.

Tendría que tener un mapa de identidades para nombres de volumen.

El viernes 21 de agosto de 2015 a las 3:17 p.m., Mark Turansky [email protected]
escribió:

De alguna manera permitir que las reclamaciones de volumen persistentes se parametricen o modifiquen para
extraer de una piscina (o tener un controlador de piscina para asegurarse de que haya un volumen por
identidad, o hacer que el controlador de identidad extraiga de grupos), es necesario pensar

Hay dos cosas sobre las afirmaciones que creo que pueden ayudar aquí:

1. Cambiar encuadernación de 1: 1 a 1: N
   
   
   
   1. pvc.Spec.VolumeName a pvc.Spec.VolumeNames [] como enlace
      
      referencia
   
   
2. pvc.Spec.Singelton booleano que indica si un reclamo debe estar vinculado
   exactamente una vez para compartir o permitir que el reclamo esté vinculado muchas veces.

Un RC puede unirse a nuevos volúmenes según sea necesario. Descubriría cómo manejar esto
en la carpeta.

Aún sería importante hacer coincidir el volumen correcto con el pod correcto.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

Clayton Coleman | Ingeniero jefe, OpenShift

El viernes 21 de agosto de 2015 a las 12:56 a. M., Brian Grant [email protected] escribió:

Para configurar el subdominio, tendríamos que decirle al pod qué servicio lo apuntó,
explícita o implícitamente. La desventaja de lo explícito es que requiere más
configuración de pegamento / plantilla. La desventaja de implícito es que sería
propensos a los desafíos que tenemos con el acoplamiento flexible en el sistema: creación-
orden de carreras e inconsistencia, dificultades de cumplimiento 1 a 1, etc. Me inclino
hacia lo explícito. Deberíamos trabajar para mejorar el alcance de las referencias cruzadas.

Seamos claros: si NO configuramos el subdominio, no podemos permitir que los usuarios proporcionen
sus propios nombres de host. Si establecemos el subdominio, tenemos que hacerlo en un
manera que sea lo suficientemente única (en el espacio DNS, que actualmente significa a través de
el espacio de nombres). Hacer que el subdominio sea el nombre de un Servicio es
lo suficientemente único.

Dadas algunas de las limitaciones de nuestro DNS (un solo TLD), este
de manera realista significa que le damos a los usuarios dos campos DNS_LABEL: nombre de host
y nominal-set. Para un ejemplo concreto:

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

Esto daría como resultado que la vaina vea:

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

y DNS que atienden registros A y PTR por foo.bar.my-app.nom.cluster.local

Este es un nivel más profundo que nuestra estructura de DNS actual, pero creo que
nuestros ndots = 5 actuales cubren esto. Alternativamente, podríamos decir que un
el espacio de nombres ES el apellido, y se lo devuelve a los usuarios para que asignen un nombre único.
nombres de host en un espacio de nombres. El resultado de DNS sería
foo.my-app.pod.cluster.local que refleja los servicios. Incluso podríamos
hágalos más parecidos agregando un campo de nombre de host opcional a Services.

Solo entregaríamos el DNS basado en el nombre de host si el subdominio coincide con eso para
un servicio del tipo adecuado. También podríamos unir los dos en un solo campo.

La parte que menos me gusta de esto es que el pod dice "Soy parte
de Servicio 'barra' "(en el ejemplo anterior). Al frente. A priori.

La pendiente resbaladiza es ¿por qué no permitir esto en general? Sería
simplificar un montón de cosas que no se pueden hacer suposiciones en la actualidad (porque
de acoplamiento flojo) aunque en la práctica rara vez vemos un solo Pod
detrás de más de un servicio. Si todos los pods estuvieran por debajo de cero o uno
Servicio, ¿se simplifica el sistema?

Creo que deberíamos reutilizar el número 4825 para eso y conseguir que alguien trabaje en él. Es mucho más concreto y menos laborioso que el resto.

Ciertamente es algo que podría comenzar de inmediato, pero (para aquellos
siguiendo en casa) es solo el mecanismo para implementar pod
identidad, no la política de gestionar conjuntos de identidades.

El viernes 21 de agosto de 2015 a las 3:17 p.m., Mark Turansky [email protected] escribió:

Hay dos cosas sobre las afirmaciones que creo que pueden ayudar aquí:

1. Cambiar encuadernación de 1: 1 a 1: N

Aquí es donde comencé, pero ...

El viernes 21 de agosto de 2015 a las 12:38 p. M., Clayton Coleman
[email protected] escribió:

Tendría que tener un mapa de identidades para nombres de volumen.

Sí. Esto realmente se está convirtiendo en un problema de creación de plantillas.
Si piensa en el problema como una "plantilla de grupo" en la que algunos
los campos tienen marcadores de posición que se rellenan con una "tupla de sustitución"
extraído de un grupo en tiempo de ejecución o lo piensa como un módulo completamente reificado
especificación que está "parcheada" con una "tupla de sustitución" extraída de un grupo
en tiempo de ejecución, son isomórficos e igualmente desagradables.

Y, sin embargo, creo que este es uno de los problemas más importantes que debemos resolver.
¿Deberíamos empezar a elaborar propuestas de hombre de paja para estos?

Tenemos varios ejemplos de grupos que tienen dos o tres servicios, uno para
propagación, uno para la exposición y otro para probar la exposición.

Con respecto a la identidad, cada pod creado por un controlador daemon debe tener asignada una identidad que se derive de la identidad del nodo y la identidad del controlador. Este puede ser un caso en el que la identidad es obvia (pod x en el host y tiene una identidad f (y)) y parte de la responsabilidad de los demonios.

@smarterclayton, por lo que una

El controlador de demonio _sólo_ tiene identidad en el contexto del nodo en el que se encuentra el pod
ejecutarse en. Los controladores y servicios de replicación son diferentes. Demonio
el controlador dice "debería haber uno de estos ejecutándose en cada nodo". Ahí
no hay otra identidad que el pod pueda tener excepto su nodo.

El viernes 11 de septiembre de 2015 a las 1:13 a. M., Angus Lees [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton así que un común (pero no
universal) aquí es mantener una lista ordenada y estable de grupos
miembros. Creo que eso implica que la identidad _no_ debería estar ligada a la
nodo en el que está programado el pod.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

Clayton Coleman | Ingeniero jefe, OpenShift

@smarterclayton ah, este problema claramente se ha transformado en algo más que la solicitud de función original: estoy perdido en lo que estaba tratando de construir aquí, así que retrocederé en lugar de continuar agregando ruido ...

Lo siento, no quise insinuar que el punto no fuera relevante. El desafío es que necesitamos definir conjuntos y propagarlos al grupo. Necesitamos que el pod sea reactivo a la membresía en el conjunto (monte el volumen X que coincida con la identidad del pod en el conjunto). Hay una pregunta abierta: ¿podría un grupo ser miembro de dos conjuntos simultáneamente y tener una identidad única en cualquiera de ellos?

Puede darse el caso de que los pods ejecutados por un controlador daemon tengan una identidad que sea "obvia" (el controlador daemon opera en un conjunto de nodos, el RC opera en un conjunto de pods).

Un requisito de la identidad es que sea única en el conjunto. ¿Podríamos aprovechar los nombres de pod y la generación de nombres de pod para garantizar esa singularidad? Por ejemplo, los RC generan nombres aleatorios. ¿Podría un RC generar nombres para las vainas de forma determinista en función del conjunto de vainas que selecciona?

Considere un RC que selecciona vainas con la etiqueta a = b. Para calcular el siguiente grupo que se va a crear, debe buscar los grupos y reducirlos a un recuento. ¿Qué pasa si lo reducimos a un conjunto de nombres único y luego el RC intenta seguir un patrón de generación de nombres dentro de ese conjunto? Dos RC que no se superponen, pero que crearon pods en una etiqueta de servicio, no podrían generar nombres únicos (pueden luchar por un nombre, pero eso está implícito). Los nombres se pueden reutilizar después de que se eliminen

Luego, los volúmenes persistentes en el pod podrían usar PVC según el nombre del pod. Un agrupador de pvc podría garantizar que haya suficientes reclamos para un grupo observado de RC. El controlador daemon puede elegir nombres deterministas para un nombre de nodo. También podemos conectar nombres DNS a nombres de pod en un servicio según algún patrón.

Esto se siente más parsimonioso que agregar un campo de identidad distinto en el pod. Significa que las vainas todavía no son mascotas, pero sus nombres pueden serlo (lo cual no es una afirmación irrazonable). No podemos evitar que dos instancias del mismo proceso de pod se ejecuten en el clúster al mismo tiempo, pero podemos hacer una garantía firme (y lo hacemos) de que el nombre solo se usa en un lugar hoy.

Significa "grupo observado de nombres" arriba. El DNS de punto final sería hashpodname.ept.service.namespace.svc.cluster.local. Ya tenemos el nombre del pod en el punto final, por lo que ni siquiera tenemos que agregar nada.

relacionado con https://github.com/kubernetes/contrib/tree/master/service-loadbalancer que propone la resolución de este problema como una posible próxima iteración

¿Por qué estamos hablando de DaemonSet aquí? Eso fue resuelto por # 12893, IMO.

@smarterclayton No usemos RC para asignar la identidad. Los problemas con esos enfoques se discutieron aquí: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

Una posibilidad sería tener una opción RC que le permita generar nombres de la manera que @smarterclayton describió si lo desea, y distintos conjuntos de funciones disponibles para usted dependiendo de cómo configure la opción. Por lo tanto, las cosas que son difíciles de implementar con un enfoque de "índice de tareas" no estarán disponibles si habilita la opción, pero la función que se describe aquí sí lo estaría. Y a la inversa, el comportamiento predeterminado (opción desactivada) le proporcionaría esas otras características, pero no la que se describe aquí.

Parece que la utilidad de algo como la abstracción del índice de tareas Borg sigue apareciendo _ para ciertos casos de uso_ y no me queda claro por qué no podemos ofrecerlo como una opción.

DaemonSet No creo que resuelva el caso de almacenamiento del sistema de archivos distribuido
(Gluster) donde cada anfitrión necesita tener una identidad consistente para volver a unirse
el racimo. Cavaré más, pero creo que aún puede necesitar algo más
las necesidades del n. ° 260: no sé si el nombre de host es suficiente si vuelve a adjuntar
un disco host en una nueva instancia. Tal vez no entendí lo que DaemonSet
proporcionado y # 12893 entregado, pero no creo que ese sea el problema para un
host del sistema que desea reutilizar el disco.

El miércoles 16 de septiembre de 2015 a las 12:22 a. M., Brian Grant [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton No volvamos a visitar
derivar la identidad de los nombres de los pod, ni utilizar RC para asignar la identidad.
Los problemas con esos enfoques se discutieron aquí: # 260 (comentario)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Ingeniero jefe, OpenShift

Como ejemplo concreto, imagine un clúster etcd. Tiene 7 instancias y 7
volúmenes. Quiero (por el bien del argumento), los nombres y volúmenes, etcd-1
a través de etcd-7 y de etcd-pvc-1 a través de etc-pvc-7.

Una implementación continua tiene MaxUnavailable 90% (o equivalente), MaxSurge 0%. Eso
escala el antiguo RC y escala el nuevo RC. El viejo RC con gracia
elimina etcd-5. Instantáneamente sale del conjunto RC efectivo. El nuevo
RC intenta crear etcd-5 (mediante la observación del espacio establecido). Recibe un
"AlreadyExistsException". Trata eso como retroceso y colas. Una vez
etcd-5 realmente se ha ido, puede continuar. Una vez que etcd-5 esté listo, el DC
pasa al siguiente paso.

Para la alternativa, la identidad establecida en el pod, el antiguo RC se reduce. A
Se crea un nuevo pod instantáneamente con un nuevo nombre. No se puede iniciar el nuevo pod
porque necesita un conjunto de identidades para averiguar qué PVC montar para su
volumen. Entra en un bucle de espera en el Kubelet. El controlador de identidad
observa un conjunto de selectores de etiquetas y observa la identidad, etc.d-5 no es
asignado. Establece la identidad etcd-5 en el nuevo pod. El kubelet observa
ese cambio y luego puede averiguar qué PVC montar, inicia el pod
(asumiendo que el volumen se ha separado del otro nodo).

Estructuralmente, estos son muy similares. Este último permite iniciar la superposición.
Ambos requieren mapear el PVC.

El miércoles 16 de septiembre de 2015 a las 12:39 a. M. , Clayton Coleman
escribió:

DaemonSet No creo que resuelva el caso de almacenamiento del sistema de archivos distribuido
(Gluster) donde cada anfitrión necesita tener una identidad consistente para volver a unirse
el racimo. Cavaré más, pero creo que aún puede necesitar algo más
las necesidades del n. ° 260: no sé si el nombre de host es suficiente si vuelve a adjuntar
un disco host en una nueva instancia. Tal vez no entendí lo que DaemonSet
proporcionado y # 12893 entregado, pero no creo que ese sea el problema para un
host del sistema que desea reutilizar el disco.

El miércoles 16 de septiembre de 2015 a las 12:22 a. M., Brian Grant [email protected]
escribió:

@smarterclayton https://github.com/smarterclayton No volvamos a visitar
derivar la identidad de los nombres de los pod, ni utilizar RC para asignar la identidad.
Los problemas con esos enfoques se discutieron aquí: # 260 (comentario)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Ingeniero jefe, OpenShift

Clayton Coleman | Ingeniero jefe, OpenShift

Lo que dificulta este problema, para mí, no es generar un grupo único estable de nombres o utilizar un grupo de PD. El problema es hacer AMBOS al mismo tiempo. Y si amplía eso, ¿por qué no se puede agrupar de esta manera casi cualquier identificador en la especificación?

Por mucho que sé (en su mayoría de segunda mano) los problemas con índices empaquetados, creo que podrían ser vivibles (especialmente si hacemos lo que sugiere David y los hacemos mutuamente excluyentes con otras características). Pero también, cuanto más me cocino, menos odio la idea de Patch que algún idiota publicó en el hilo.

Este problema ha persistido y persistido y me temo que tenemos parálisis de análisis.

Ojalá tuviéramos más ejemplos de otros casos de uso de agrupaciones. Pensé Gluster
sería diferente, pero es solo otra variante de la
cassandra / etcd / mongo / zookeeper "quiero reutilizar un volumen y necesito
recuerda quién dije que era antes ". Realmente no hemos tenido un rol basado (yo
quiero hacer los primeros coordinadores de N pods y los próximos M trabajadores) ejemplo
apalancar.

El miércoles 16 de septiembre de 2015 a las 12:46 a. M., Tim Hockin [email protected]
escribió:

Lo que dificulta este problema, para mí, no es generar un
grupo único de nombres o usando un grupo de PD. El problema es hacer AMBOS en
al mismo tiempo. Y si extiende eso, ¿por qué no puede
¿El identificador en la especificación se agrupará de esta manera?

Por lo que sé (en su mayoría de segunda mano) los problemas con índices empaquetados,
creemos que pueden ser habitables (especialmente si hacemos lo que sugiere David y hacemos
mutuamente excluyentes con otras características). Pero también, cuanto más me cocino
Eso, menos odio la idea de Patch que algún idiota publicó en el hilo.

Este problema se ha prolongado y persistido y me temo que tenemos un análisis
parálisis.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

Clayton Coleman | Ingeniero jefe, OpenShift

DaemonSet:

12893 establece el nombre de host del pod en el nombre de host del nodo cuando se usa la red de host, lo cual es totalmente razonable de usar para DaemonSet, ya que de otro modo usarían hostPort, de todos modos.

Además, la intención es integrar DaemonSet con el controlador de nodo para proporcionar un perdón indefinido implícito # 1574 y habilitar la "programación" antes de que la programación se habilite para los nodos en general. La priorización implícita también puede ser razonable.

Para un sistema de almacenamiento en clúster, podría imaginar la provisión de discos adicionales en cada host a los que se accede a través de hostPath solo por el sistema de almacenamiento; no serían utilizados por Docker ni por emptyDir.

Con respecto a la identidad, no veo ningún problema con la propuesta aquí: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Este problema ha persistido principalmente debido a la falta de suficiente prioridad, en mi opinión.

Para hablar de Clayton (o tal vez solo para decir las mismas cosas pero más tontas):

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

La implicación es que el RC (o algo) se da cuenta de que se trata de un conjunto de identidades, asigna un índice desde el conjunto de identidades, asigna esa identidad al nombre del pod y luego echa un vistazo al interior para ver si se ha establecido algún otro campo centrado en la identidad: la identidad volumen en este caso.

No es totalmente genérico (no se puede agrupar ningún campo aleatorio) pero podemos agregar más opciones de identificación según sea necesario

Tengo la sensación de que si definimos una especificación que nos gustó, podría terminar más temprano que tarde.

Incluso escribir una especificación lleva tiempo.

Con respecto a IdentityPool / VolumePool, ya decidimos hace mucho tiempo que varios grupos no funcionarán.

La fecha límite para completar el código 1.1 es el viernes. ¿Podríamos no hacer esto ahora?

También relacionado: # 170. Eso propuso simplemente dividir la plantilla de pod, pero si optamos por un esquema de plantillas (que prefiero mucho al parche), entonces deberíamos considerarlos juntos.

Puse al menos el diseño en el candidato v1.2.

Lo siento, no fui claro en mi boceto: el RC (¿o IC?) Tiene un concepto de
grupo o índice primario. Una vez que a un pod se le asigna un índice en el IC,
index se utiliza para indexar en todos los campos centrados en el grupo.

Si dividimos la plantilla, supongo que la suposición es que el RC no puede
mutar la plantilla. Eso es un poco más complicado.

Estoy bien para dejar de hablar de esto esta semana. Simplemente apareció en mi
bandeja de entrada y había estado masticando esta idea ...

El martes 15 de septiembre de 2015 a las 10:09 p.m., Brian Grant [email protected]
escribió:

Incluso escribir una especificación lleva tiempo.

Con respecto a IdentityPool / VolumePool, ya decidimos hace mucho tiempo
hace que varios grupos no funcionarán.

La fecha límite para completar el código 1.1 es el viernes. ¿Podríamos no hacer esto ahora?

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

Sí, solo hubo cosas que provocaron discusiones por nuestra parte.
Los problemas del cliente esperan que no haya ningún proceso de liberación.

El miércoles 16 de septiembre de 2015 a la 1:14 a. M., Tim Hockin [email protected]
escribió:

Lo siento, no fui claro en mi boceto: el RC (¿o IC?) Tiene un concepto de
grupo o índice primario. Una vez que a un pod se le asigna un índice en el IC,
index se utiliza para indexar en todos los campos centrados en el grupo.

Si dividimos la plantilla, supongo que la suposición es que el RC no puede
mutar la plantilla. Eso es un poco más complicado.

Estoy bien para dejar de hablar de esto esta semana. Simplemente apareció en mi
bandeja de entrada y había estado masticando esta idea ...

El martes 15 de septiembre de 2015 a las 10:09 p.m., Brian Grant [email protected]
escribió:

Incluso escribir una especificación lleva tiempo.

Con respecto a IdentityPool / VolumePool, ya decidimos hace mucho tiempo
hace que varios grupos no funcionarán.

La fecha límite para completar el código 1.1 es el viernes. ¿Podríamos por favor no hacer esto?
¿ahora?

-
Responda a este correo electrónico directamente o véalo en GitHub
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

Clayton Coleman | Ingeniero jefe, OpenShift

La discusión es sobre números de IP y Pods, pero en mi experiencia con Mongo & Zookeeper, la IP de los Pods debería permanecer irrelevante (no convertirse en mascotas). El _volumen_ persistente necesita un número nominal ya que este volumen registra el número de IP de los otros 'volúmenes'. Cualquiera que sea el Pod que monte ese volumen debería poder usar ese número de IP registrado de alguna manera. El volumen es la mascota ...

Creo que un nombre DNS que es constante en el tiempo para un volumen y asignado a un Pod que monta el volumen sería muy útil.

El cambio de pertenencia al conjunto en Mongo & ZK siempre requerirá un código personalizado para ejecutarse y espero que sea el mismo para la mayoría de los demás conjuntos. Entonces, el controlador de replicación es el nombre incorrecto, estas mascotas necesitan más un controlador de barco miembro. Un controlador de Barco Miembro debería poder manejar la configuración inicial y luego los cambios incrementales en los conjuntos, y finalmente eliminarlos.

Dado un nombre DNS constante basado en el volumen montado y la posibilidad de manejar la membresía del conjunto con un código personalizado, creo que debería hacer posible manejar este tipo de sistemas.

Sí, pod IP es más un truco a corto plazo.

Hacia dónde se dirige esta propuesta es algo por encima del DNS y el volumen que tanto
puede aprovechar para permanecer acoplado. La preocupación es que el volumen que define el nombre DNS
es el reverso del acoplamiento que ya hemos establecido, y también
quieren permitir que otras partes de la especificación del módulo aprovechen ese concepto superior
(identidad) como la API descendente sobre el medio ambiente. Que hace que se adapte
identidad a software de conjunto diferente más fácil (reduce el código personalizado por
escribe).

Necesitamos asegurarnos de que no haya un caso de uso más allá de los conjuntos que
se superpone aquí (no he escuchado una sugerencia) y luego intente llegar a un
propuesta concreta que se siente mínima y apropiada. Tim creo que tiene
resumió eso más recientemente aquí.

El 23 de septiembre de 2015, a las 11:33 a. M., Peter Kriens [email protected] escribió:

La discusión tiene que ver con los números de IP y los pods, pero en mi experiencia con
Mongo & Zookeeper la IP de los Pods debería permanecer irrelevante (no convertirse en mascotas).
El _volumen_ persistente necesita un número nominal ya que este volumen registra
el número de IP de los otros 'volúmenes'. Cualquiera que sea el Pod que monte ese volumen
debería poder usar ese número de IP registrado de alguna manera. El volumen es el
mascota ...

Un nombre DNS que es constante en el tiempo para un volumen y asignado a un Pod que
Si aumenta el volumen, creo que llegaría muy lejos.

El cambio de membresía de conjunto en Mongo & ZK siempre requerirá personalización
código para ejecutar y espero que sea el mismo para la mayoría de los otros conjuntos. Entonces
El controlador de replicación es el nombre incorrecto, estas mascotas necesitan más un miembro
Controlador de buques. Un controlador de Barco Miembro debería poder manejar
configuración inicial y luego cambios incrementales en los conjuntos, y finalmente
mátalo.

Dado un nombre DNS constante basado en el volumen montado y la posibilidad de
manejar la pertenencia al conjunto con un código personalizado debería hacer posible
manejar este tipo de sistemas, creo.

-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/silbido

Puede encontrar un ejemplo de cómo configurar un clúster ZK en Kubernetes utilizando las capacidades existentes en https://hub.docker.com/r/elevy/zookeeper/. El requisito principal son direcciones IP estables y nombres de host para los miembros del conjunto. Esto se logra utilizando servicios individuales para cada miembro del clúster. El único inconveniente es que, de forma predeterminada, ZK intentará vincularse a la IP a la que se resuelve su nombre de host, pero esto se puede evitar mediante un parámetro de configuración.

@smarterclayton @thockin

Pensamientos mientras iba en bicicleta a la oficina hace unos días:

Actualmente estoy pensando en esto como un controlador PetSet, o tal vez un controlador ShardSet, si la gente quiere pensarlo de esa manera, como se discutió al principio: https://github.com/kubernetes/kubernetes/issues/260# comentario de emisión -57671926.

El caso que estamos tratando de abordar es donde hay N mascotas similares, pero siguen siendo mascotas, no son fungibles.

Sigo pensando que vincular esto a ReplicationController no puede funcionar, en parte porque ReplicationController solo tiene una plantilla. PetSet / ShardSet debe ser una abstracción de nivel superior, más como Implementación o DaemonSet. PetSet podría generar potencialmente un objeto PodTemplate por instancia.

No creo que podamos simplemente reutilizar la API de implementación. Entre otras cosas, la estrategia de implementación de la actualización continua ahora en kubectl y la implementación no funcionará en este caso. La mayoría de las mascotas probablemente querrían las actualizaciones de Recrear, y cualquiera que quisiera actualizaciones continuas no podría manejar ningún aumento por encima de su recuento de fragmentos y sería particular sobre el orden de actualización.

Por mucho que me guste la idea, no creo que la asignación de identidad de abajo hacia arriba vaya a funcionar. Demasiadas condiciones de carrera con la devolución de identidades asignadas al grupo frente a la asignación de nuevas. Al igual que los problemas con los que @erictune se encontró mientras exploraba el uso de RabbitMQ con Job.

No quiero representar la escala del PetSet en más de un lugar, como en un controlador y en un grupo de identidades, o en un controlador y en un servicio, ya que eso haría que el escalado fuera complicado / incómodo.

No creo que necesitemos plantillas de uso general para este caso. Solo necesitamos eliminar los pods con almacenamiento asociado e identidades de red predecibles y duraderas. El equivalente aproximado ha sido suficiente en Borg. Por lo tanto, me estoy inclinando fuertemente hacia algo parecido al # 12450, pero en la plantilla de la cápsula en lugar de en las propias cápsulas. Quizás una matriz de persistentVolumeClaimTemplates además de un podTemplate. No quiero agregar una sustitución elegante para todas las fuentes de volumen específicas del proveedor de la nube, especialmente porque queremos desaprobarlas de todos modos. Debería ser suficiente agregar requisitos y / o selectores adicionales a los PVC. También necesitaremos poder aprovisionar volúmenes persistentes de alguna manera en algún momento.

Aún tendremos que hacer algo sobre el almacenamiento local eventualmente, pero creo que eso es separable.

Y luego, el nombre de host y los cambios del servicio sin cabeza mencionados anteriormente, aquí:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Trabajando en una propuesta ahora, pronto tendremos un borrador.

La propuesta está en https://github.com/kubernetes/kubernetes/pull/18016

... entonces, ¿dónde estamos con PetSet?

Estoy construyendo soluciones de base de datos HA sobre Kubernetes. Algunas, en particular las bases de datos de un solo maestro, requieren servicios con puntos finales que se asignan a pods particulares en función de los eventos de esos pods. Por ejemplo:

1. el servicio "postgres" asigna el round robin a todos los pods en ReplicaSet, pero el servicio "postgres-master" se asigna a un solo pod.
2. la vaina maestra muere.
3. ocurre la conmutación por error. Como parte de la conmutación por error, el nuevo maestro actualiza Kube-master a través de la API para "tomar" el servicio postgres-master.
4. Cuando hace esto, se terminan todas las conexiones anteriores a postgres-master.

@jberkus, el código alfa inicial para habilitar PetSets se ha fusionado o está pendiente de fusión. @ingvagabund de mi equipo va a comenzar a recopilar ejemplos que utilizan PetSet para ver qué funciona bien y qué necesita mejorar. Le recomiendo que se comunique con él si tiene algunos casos de uso específicos que desea armar y probar.

@ncdc ¿Está todo hecho para esto en la v1.3? No está claro ya que la propuesta no se fusionó y no ha habido otros RP haciendo referencia a esto por un tiempo.

@bprashanth ^

Estamos aterrizando e2es y continuamos trabajando en ejemplos. Esta en alfa
ahora, pero la propuesta tomará la primera ronda de comentarios alfa
antes de fusionarse.

El 19 de mayo de 2016, a las 10:25 a. M., Brandon Philips [email protected]
escribió:

@ncdc https://github.com/ncdc ¿Está todo hecho para esto en la v1.3? Está
poco claro ya que la propuesta no se fusionó y no ha habido otros RP
haciendo referencia a esto por un tiempo.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

¿Dónde puedo encontrar documentos para esto? Me gustaría probarlo para un caso de uso de conmutación por error de base de datos.

Ah, ja, justo lo que necesitamos un experto en postgres :)

consulte https://github.com/kubernetes/contrib/pull/921 para ver ejemplos, puedo responder cualquier pregunta sobre la creación de prototipos [db of choice] como petset. Tenemos un montón de bocetos bajo la etiqueta "apps / stateful" (por ejemplo: https://github.com/kubernetes/kubernetes/issues/23790, @philips , un ejemplo de etcd sería genial). Todavía no he escrito documentos, lo haré hacia las últimas semanas de 1.3 (aún quedan 5 semanas para publicar después de que el código se complete el viernes).

Supongo que intentará automatizar la conmutación por error con postgres, ya que es bastante común. Admito que actualmente eso no es tan fácil como me gustaría, probablemente necesites un perro guardián. @jberkus Me gustaría escuchar comentarios sobre qué patrones lo hacen más fácil.

Para brindarle una revisión rápida, el conjunto de mascotas de hoy le brinda una identidad de red consistente (DNS, nombre de host) que coincide con un volumen montado en la red y garantías de pedido. Entonces, si crea un conjunto de mascotas con replicas: 3 , obtendrá:
servicio de gobierno: * .galear.default.svc.cluster.local
mysql-0 - volumen0
mysql-1 - volume1: no se inicia hasta que 0 se está ejecutando y está listo
mysql-2 - volume2: no se inicia hasta 0, 1 se está ejecutando listo

Los pods pueden usar DNS para el descubrimiento de servicios al buscar registros SRV insertados en el servicio de gobierno. Eso es lo que hace este módulo simple: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. Entonces, si usa el buscador de pares a través de un contenedor de inicio como en los ejemplos anteriores, mysql-1 no se iniciará hasta que el contenedor de inicio vea (mysql-1, mysql-0) en DNS y escriba la configuración apropiada.

Los volúmenes son aprovisionados por un aprovisionador dinámico (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md), por lo que si no tiene uno ejecutándose en su clúster pero solo desea crear un prototipo, simplemente puede usar emptyDir. El caso de "data-gravity" (https://github.com/kubernetes/kubernetes/issues/7562) aún no funciona, pero eventualmente lo hará.

Agregaré que actualmente es más fácil entregar una notificación de "inicio" con una lista de pares, a través de contenedores de inicio. Está claro que también requerimos notificaciones de "cambio". Actualmente, para notar cambios en la membresía del clúster, debe usar un pid1 personalizado. Los espacios de nombres pid compartidos pueden hacer esto más fácil, ya que luego puede usar un sidecar, esto también es algo que simplemente debe funcionar.

Tengo un perro guardián, es el servicio de conmutación por error lo que es más complicado de lo que me gustaría. Probaré, gracias!

También necesito ser compatible con etcd, por lo que puede haber muchas pruebas en el futuro.

@ncdc ¿Cuál es el estado del código alfabético para esto? Me gustaría comenzar a probar / implementar. Necesitamos implementar un clúster de Cassandra muy pronto aquí. Puedo hacerlo con el código base existente, pero sería bueno probar las cosas de petset.

Puedes conseguirlo si construyes desde HEAD

¿@bprashanth se fusionó con el repositorio principal? muchas gracias. servirá.

https://github.com/kubernetes/contrib/tree/master/pets

yaml incrustado en cadenas de anotaciones? oof, ouch :(. gracias, sin embargo, investigaremos la creación de un conjunto de cassandra.

eso es json. Es una función alfa agregada a un objeto GA (contenedores de inicio en pods).
@chrislovecnm está trabajando en Cassandra, quizás solo quiera esperarlo.

@paralin aquí es en lo que estoy trabajando. No hay tiempo para documentarlo y ponerlo en el repositorio de k8s ahora, pero ese es un plan a largo plazo. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra Me está trabajando localmente, en HEAD.

La última imagen C * de la demostración funciona bien.

Tenemos un problema abierto para obtener más documentación. Guiño guiño, puñetazo @bprashanth

Ejemplo de PetSets con etcd cluster [1].

[1] https://github.com/kubernetes/contrib/pull/1295

Asegúrese de capturar las solicitudes de diseño en el documento de la propuesta después de terminar la revisión

El 30 de junio de 2016, a la 1:25 a. M., Jan Chaloupka [email protected] escribió:

Ejemplo de PetSets con etcd cluster [1].

[1] kubernetes / contrib # 1295
https://github.com/kubernetes/contrib/pull/1295

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

los documentos de petset son https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md y https://github.com/kubernetes/kubernetes.github. io / tree / release-1.3 / docs / user-guide / petset / bootstrapping , planeo cerrar este problema y abrir uno nuevo que aborde el cambio de petset a beta a menos que alguien se oponga

https://github.com/kubernetes/kubernetes/issues/28718