Skip to content

Commit 0abc481

Browse files
raelgaraelga
committed
clean: remove 3rd party links
Signed-off-by: Rael Garcia <[email protected]>
1 parent 30c47c9 commit 0abc481

File tree

1 file changed

+32
-43
lines changed

1 file changed

+32
-43
lines changed

‎content/es/docs/concepts/workloads/controllers/daemonset.md

Lines changed: 32 additions & 43 deletions
Original file line numberDiff line numberDiff line change
@@ -12,23 +12,14 @@ Al eliminar un DaemonSet se limpian todos los Pods que han sido creados.
1212

1313
Algunos casos de uso típicos de un DaemonSet son:
1414

15-
- ejecutar un proceso de almacenamiento en el clúster, como `glusterd`, `ceph`, en cada nodo.
16-
- ejecutar un proceso de recolección de logs en cada nodo, como `fluentd` o `logstash`.
17-
- ejecutar un proceso de monitorización de nodos en cada nodo, como [Prometheus Node Exporter](
18-
https://github.com/prometheus/node_exporter), [Sysdig Agent] (https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`,
19-
[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/),
20-
[AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes),
21-
[Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/),
22-
[New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration),
23-
Ganglia `gmond` o un agente de Instana.
15+
- Ejecutar un proceso de almacenamiento en el clúster.
16+
- Ejecutar un proceso de recolección de logs en cada nodo.
17+
- Ejecutar un proceso de monitorización de nodos en cada nodo.
2418

2519
De forma básica, se debería usar un DaemonSet, cubriendo todos los nodos, por cada tipo de proceso.
26-
En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso,
20+
En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso,
2721
pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria según el tipo de hardware.
2822

29-
30-
31-
3223
<!-- body -->
3324

3425
## Escribir una especificación de DaemonSet
@@ -46,7 +37,7 @@ kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
4637

4738
### Campos requeridos
4839

49-
Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`.
40+
Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`.
5041
Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos [desplegar aplicaciones](/docs/user-guide/deploying-applications/),
5142
[configurar contenedores](/docs/tasks/), y [gestión de objetos usando kubectl](/docs/concepts/overview/object-management-kubectl/overview/).
5243

@@ -56,18 +47,18 @@ Un DaemonSet también necesita un sección [`.spec`](https://git.k8s.io/communit
5647

5748
El campo `.spec.template` es uno de los campos obligatorios de la sección `.spec`.
5849

59-
El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/),
50+
El campo `.spec.template` es una [plantilla Pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates). Tiene exactamente el mismo esquema que un [Pod](/docs/concepts/workloads/pods/pod/),
6051
excepto por el hecho de que está anidado y no tiene los campos `apiVersion` o `kind`.
6152

62-
Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar
53+
Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar
6354
las etiquetas apropiadas (ver [selector de pod](#pod-selector)).
6455

6556
Una plantilla Pod para un DaemonSet debe tener una [`RestartPolicy`](/docs/user-guide/pod-states)
6657
igual a `Always`, o no indicarse, lo cual asume por defecto el valor `Always`.
6758

6859
### Selector de Pod
6960

70-
El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector`
61+
El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector`
7162
de un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
7263

7364
A partir de Kubernetes 1.8, se debe configurar un selector de pod que coincida con las
@@ -86,15 +77,15 @@ Cuando se configura ambos campos, el resultado es conjuntivo (AND).
8677

8778
Si se especifica el campo `.spec.selector`, entonces debe coincidir con el campo `.spec.template.metadata.labels`. Aquellas configuraciones que no coinciden, son rechazadas por la API.
8879

89-
Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro
80+
Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro
9081
DaemonSet, o via otro controlador como un ReplicaSet. De ser así, el controlador del DaemonSet
91-
pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta
82+
pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta
9283
operación. Un caso donde puede que necesites hacer esto es cuando quieres crear manualmente un Pod con un valor diferente en un nodo para pruebas.
9384

9485
### Ejecutar Pods sólo en algunos Nodos
9586

9687
Si se configura un `.spec.template.spec.nodeSelector`, entonces el controlador del DaemonSet
97-
creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado.
88+
creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado.
9889
De forma similar, si se configura una `.spec.template.spec.affinity`,
9990
entonces el controlador del DaemonSet creará los Pods en aquellos nodos que coincidan con la [afinidad de nodo](/docs/concepts/configuration/assign-pod-node/) indicada.
10091
Si no se configura ninguno de los dos, entonces el controlador del DaemonSet creará los Pods en todos los nodos.
@@ -115,13 +106,13 @@ se indica el campo `.spec.nodeName`, y por ello el planificador los ignora). Por
115106

116107
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
117108

118-
Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod.
109+
Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod.
119110
Normalmente, es el planificador de Kubernetes quien determina el nodo donde se ejecuta un Pod. Sin embargo,
120111
los pods del DaemonSet son creados y planificados por el mismo controlador del DaemonSet.
121112
Esto introduce los siguientes inconvenientes:
122113

123114
* Comportamiento inconsistente de los Pods: Los Pods normales que están esperando
124-
a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`.
115+
a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`.
125116
Esto confunde a los usuarios.
126117
* La [prioridad y el comportamiento de apropiación de Pods](/docs/concepts/configuration/pod-priority-preemption/)
127118
se maneja por el planificador por defecto. Cuando se habilita la contaminación, el controlador del DaemonSet
@@ -130,7 +121,7 @@ Esto introduce los siguientes inconvenientes:
130121
`ScheduleDaemonSetPods` permite planificar DaemonSets usando el planificador por defecto
131122
en vez del controlador del DaemonSet, añadiendo la condición `NodeAffinity`
132123
a los pods del DaemonSet, en vez de la condición `.spec.nodeName`. El planificador por defecto
133-
se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del
124+
se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del
134125
pod del DaemonSet ya existe, se sustituye. El controlador del DaemonSet sólo realiza
135126
estas operaciones cuando crea o modifica los pods del DaemonSet, y no se realizan cambios
136127
al `spec.template` del DaemonSet.
@@ -146,7 +137,7 @@ nodeAffinity:
146137
- target-host-name
147138
```
148139
149-
Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule`
140+
Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule`
150141
a los Pods del DaemonSet. Así, el planificador por defecto ignora los nodos
151142
`unschedulable` cuando planifica los Pods del DaemonSet.
152143

@@ -158,23 +149,23 @@ A pesar de que los Pods de proceso respetan las
158149
la siguientes tolerancias son añadidas a los Pods del DaemonSet de forma automática
159150
según las siguientes características:
160151

161-
| Clave de tolerancia | Efecto | Versión | Descripción |
162-
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
163-
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. |
164-
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. |
165-
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. |
166-
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. |
167-
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. |
168-
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. |
152+
| Clave de tolerancia | Efecto | Versión | Descripción |
153+
| ---------------------------------------- | ---------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------- |
154+
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. |
155+
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. |
156+
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. |
157+
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. |
158+
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. |
159+
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. |
169160

170161

171162
## Comunicarse con los Pods de los DaemonSets
172163

173164
Algunos patrones posibles para la comunicación con los Pods de un DaemonSet son:
174165

175-
- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio,
166+
- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio,
176167
como una base de datos de estadísticas. No tienen clientes.
177-
- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo,
168+
- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo,
178169
y conocen el puerto acordado.
179170
- **DNS**: Se crea un [servicio headless](/docs/concepts/services-networking/service/#headless-services) con el mismo selector de pod,
180171
y entonces se descubre a los DaemonSets usando los recursos `endpoints` o mediante múltiples registros de tipo A en el DNS.
@@ -185,10 +176,10 @@ y conocen el puerto acordado.
185176
Si se cambian las etiquetas de nodo, el DaemonSet comenzará de forma inmediata a añadir Pods a los nuevos nodos que coincidan y a eliminar
186177
los Pods de aquellos nuevos nodos donde no coincidan.
187178

188-
Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods.
179+
Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods.
189180
Además, el controlador del DaemonSet utilizará la plantilla original la próxima vez que se cree un nodo (incluso con el mismo nombre).
190181

191-
Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`,
182+
Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`,
192183
entonces los Pods continuarán ejecutándose en los nodos. Así, puedes crear entonces un nuevo DaemonSet con una plantilla diferente.
193184
El nuevo DaemonSet con la plantilla diferente reconocerá a todos los Pods existentes que tengan etiquetas coincidentes y
194185
no modificará o eliminará ningún Pod aunque la plantilla no coincida con los Pods desplegados.
@@ -198,14 +189,14 @@ A partir de las versión 1.6 de Kubernetes, puedes [llevar a cabo una actualizac
198189

199190
## Alternativas al DaemonSet
200191

201-
### Secuencias de comandos de inicialización
192+
### Secuencias de comandos de inicialización
202193

203194
Aunque es perfectamente posible ejecutar procesos arrancándolos directamente en un nodo (ej. usando
204195
`init`, `upstartd`, o `systemd`), existen numerosas ventajas si se realiza via un DaemonSet:
205196

206197
- Capacidad de monitorizar y gestionar los logs de los procesos del mismo modo que para las aplicaciones.
207198
- Mismo lenguaje y herramientas de configuración (ej. plantillas de Pod, `kubectl`) tanto para los procesos como para las aplicaciones.
208-
- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones.
199+
- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones.
209200
Sin embargo, esto también se podría conseguir ejecutando los procesos en un contenedor en vez de un Pod
210201
(ej. arrancarlos directamente via Docker).
211202

@@ -231,8 +222,6 @@ ambos crean Pods, y que dichos Pods tienen procesos que no se espera que termine
231222
servidores de almacenamiento).
232223

233224
Utiliza un Deployment para definir servicios sin estado, como las interfaces de usuario, donde el escalado vertical y horizontal
234-
del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod.
235-
Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos,
236-
y cuando se necesite que arranque antes que el resto de Pods.
237-
238-
225+
del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod.
226+
Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos,
227+
y cuando se necesite que arranque antes que el resto de Pods.

0 commit comments

Comments
 (0)