Kubernetes Prow Robot
GitHub
commit
d9c3c04087
|
|
@ -41,13 +41,13 @@ L'utilizzo di questi campi varia a seconda del provider cloud o della configuraz
|
|||
|
||||
### Condition
|
||||
|
||||
l campo `conditions` descrive lo stato di tutti i nodi` Running`.
|
||||
l campo `conditions` descrive lo stato di tutti i nodi `Running`.
|
||||
|
||||
|
||||
| Condizione del nodo | Descrizione |
|
||||
| ---------------- | ------------- |
|
||||
| `OutOfDisk` | `True` se lo spazio disponibile sul nodo non è sufficiente per aggiungere nuovi pod, altrimenti` False` |
|
||||
| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod,` False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
|
||||
| `Pronto` | `True` se il nodo è integro e pronto ad accettare i pod, `False` se il nodo non è integro e non accetta i pod e `Sconosciuto` se il controller del nodo non è stato ascoltato dal nodo nell'ultimo` nodo-monitor -grace-periodo` (il valore predefinito è 40 secondi) |
|
||||
| `MemoryPressure` | `Vero` se la pressione esiste sulla memoria del nodo, ovvero se la memoria del nodo è bassa; altrimenti `False` |
|
||||
| `PIDPressure` | `True` se la pressione esiste sui processi, ovvero se ci sono troppi processi sul nodo; altrimenti `False` |
|
||||
| `DiskPressure` | `True` se esiste una pressione sulla dimensione del disco, ovvero se la capacità del disco è bassa; altrimenti `False` |
|
||||
|
|
@ -64,12 +64,12 @@ La condizione del nodo è rappresentata come un oggetto JSON. Ad esempio, la seg
|
|||
]
|
||||
```
|
||||
|
||||
Se lo stato della condizione Ready rimane `Unknown` o` False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
|
||||
Se lo stato della condizione Ready rimane `Unknown` o `False` per un tempo superiore a `pod-eviction-timeout`, viene passato un argomento al [gestore-kube-controller](/docs/admin/kube-controller-manager/) e tutti i pod sul nodo sono programmati per la cancellazione dal controller del nodo. La durata predefinita del timeout di sfratto è di ** cinque minuti **. In alcuni casi, quando il nodo non è raggiungibile, l'apiserver non è in grado di comunicare con kubelet sul nodo. La decisione di eliminare i pod non può essere comunicata al kubelet fino a quando non viene ristabilita la comunicazione con l'apiserver. Nel frattempo, i pod che sono programmati per la cancellazione possono continuare a funzionare sul nodo partizionato.
|
||||
|
||||
Nelle versioni di Kubernetes precedenti alla 1.5, il controllore del nodo [forzerebbe la cancellazione](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods)
|
||||
questi pod non raggiungibili dall'apiserver. Tuttavia, in 1.5 e versioni successive, il controller del nodo non impone l'eliminazione dei pod finché non lo è
|
||||
confermato che hanno smesso di funzionare nel cluster. Puoi vedere i pod che potrebbero essere in esecuzione su un nodo irraggiungibile
|
||||
lo stato `Terminating` o` Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
|
||||
lo stato `Terminating` o `Unknown`. Nei casi in cui Kubernetes non può dedurre dall'infrastruttura sottostante se ha un nodo
|
||||
lasciato permanentemente un cluster, potrebbe essere necessario che l'amministratore del cluster elimini manualmente l'oggetto nodo. Cancellare l'oggetto nodo da
|
||||
Kubernetes fa sì che tutti gli oggetti Pod in esecuzione sul nodo vengano eliminati dal server apis e libera i loro nomi.
|
||||
|
||||
|
|
@ -227,7 +227,7 @@ Per l'autoregistrazione, il kubelet viene avviato con le seguenti opzioni:
|
|||
- `--kubeconfig` - Percorso delle credenziali per autenticarsi sull'apiserver.
|
||||
- `--cloud-provider` - Come parlare con un provider cloud per leggere i metadati su se stesso.
|
||||
- `--register-node` - Si registra automaticamente con il server API.
|
||||
- `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola` <chiave> = <valore>: <effetto> `). No-op se `register-node` è falso.
|
||||
- `--register-with-taints` - Registra il nodo con la lista data di taints (separati da virgola `<chiave> = <valore>: <effetto>`). No-op se `register-node` è falso.
|
||||
- `--node-ip` - Indirizzo IP del nodo.
|
||||
- `--node-labels` - Etichette da aggiungere quando si registra il nodo nel cluster (vedere le restrizioni dell'etichetta applicate dal [plugin di accesso NodeRestriction](/docs/reference/access-authn-authz/admission-controller/#noderestriction) in 1.13+).
|
||||
- `--node-status-update-frequency` - Specifica la frequenza con cui kubelet invia lo stato del nodo al master
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ weight: 20
|
|||
<!-- overview -->
|
||||
|
||||
Quando si utilizza l'autenticazione del certificato client, è possibile generare certificati
|
||||
manualmente tramite `easyrsa`,` openssl` o `cfssl`.
|
||||
manualmente tramite `easyrsa`, `openssl` o `cfssl`.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ controllerManager:
|
|||
mountPath: "/etc/kubernetes/cloud.conf"
|
||||
```
|
||||
|
||||
I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
|
||||
I provider cloud in-tree in genere richiedono sia `--cloud-provider` e `--cloud-config` specificati nelle righe di
|
||||
comando per [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
|
||||
e il [Kubelet](/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider
|
||||
è documentato di seguito.
|
||||
|
|
@ -91,8 +91,8 @@ spec:
|
|||
* `service.beta.kubernetes.io / aws-load-balancer-access-log-enabled`: utilizzato sul servizio per abilitare o disabilitare i log di accesso.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-name`: usato per specificare il nome del bucket di log degli accessi s3.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-prefix`: utilizzato per specificare il prefisso del bucket del registro di accesso s3.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: "Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2" `.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o` https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o` tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e` aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: `"Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2"`.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o `https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o `tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e `aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-ssl-cert`: utilizzato nel servizio per richiedere un listener sicuro. Il valore è un certificato ARN valido. Per ulteriori informazioni, vedere [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN è un ARN certificato IAM o CM, ad es. `ARN: AWS: ACM: US-est-1: 123456789012: certificato / 12345678-1234-1234-1234-123456789012`.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-enabled`: utilizzato sul servizio per abilitare o disabilitare il drenaggio della connessione.
|
||||
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-timeout`: utilizzato sul servizio per specificare un timeout di drenaggio della connessione.
|
||||
|
|
@ -125,7 +125,7 @@ corrispondere al nome VM di CloudStack.
|
|||
Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
|
||||
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il primo segmento del nome del nodo
|
||||
Kubernetes deve corrispondere al nome dell'istanza GCE (ad esempio, un nodo denominato `kubernetes-node-2.c.my-proj.internal`
|
||||
deve corrispondere a un'istanza denominata` kubernetes-node-2`) .
|
||||
deve corrispondere a un'istanza denominata `kubernetes-node-2`) .
|
||||
|
||||
## OpenStack
|
||||
Questa sezione descrive tutte le possibili configurazioni che possono
|
||||
|
|
@ -243,7 +243,7 @@ file:
|
|||
il bilanciamento del carico.
|
||||
* `lb-method` (Opzionale): utilizzato per specificare l'algoritmo in base al quale verrà caricato il carico
|
||||
distribuito tra i membri del pool di bilanciamento del carico. Il valore può essere
|
||||
`ROUND_ROBIN`,` LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
|
||||
`ROUND_ROBIN`, `LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
|
||||
nessuno è specificato è `ROUND_ROBIN`.
|
||||
* `lb-provider` (Opzionale): utilizzato per specificare il provider del servizio di bilanciamento del carico.
|
||||
Se non specificato, sarà il servizio provider predefinito configurato in neutron
|
||||
|
|
@ -272,7 +272,7 @@ Queste opzioni di configurazione per il provider OpenStack riguardano lo storage
|
|||
e dovrebbe apparire nella sezione `[BlockStorage]` del file `cloud.conf`:
|
||||
|
||||
* `bs-version` (Opzionale): usato per sovrascrivere il rilevamento automatico delle versioni. Valido
|
||||
i valori sono `v1`,` v2`, `v3` e` auto`. Quando `auto` è specificato automatico
|
||||
i valori sono `v1`, `v2`, `v3` e `auto`. Quando `auto` è specificato automatico
|
||||
il rilevamento selezionerà la versione supportata più alta esposta dal sottostante
|
||||
Cloud OpenStack. Il valore predefinito se nessuno è fornito è `auto`.
|
||||
* `trust-device-path` (Opzionale): Nella maggior parte degli scenari i nomi dei dispositivi a blocchi
|
||||
|
|
|
|||
|
|
@ -162,9 +162,9 @@ In secondo luogo, decidi quanti cluster dovrebbero essere disponibili allo stess
|
|||
il numero che può essere non disponibile `U`. Se non sei sicuro, allora 1 è una buona scelta.
|
||||
|
||||
Se è possibile bilanciare il carico per indirizzare il traffico verso qualsiasi regione in caso di guasto di un cluster, allora
|
||||
avete bisogno almeno dei grossi `R` o` U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
|
||||
avete bisogno almeno dei grossi `R` o `U + 1`. Se non lo è (ad esempio, vuoi garantire una bassa latenza per tutti
|
||||
utenti in caso di guasto di un cluster), quindi è necessario disporre di cluster `R * (U + 1)`
|
||||
(`U + 1` in ciascuna delle regioni` R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
|
||||
(`U + 1` in ciascuna delle regioni `R`). In ogni caso, prova a mettere ciascun cluster in una zona diversa.
|
||||
|
||||
Infine, se uno qualsiasi dei tuoi cluster richiederebbe più del numero massimo consigliato di nodi per un cluster Kubernetes, allora
|
||||
potresti aver bisogno di più cluster. Kubernetes v1.3 supporta cluster di dimensioni fino a 1000 nodi. Supporta Kubernetes v1.8
|
||||
|
|
|
|||
|
|
@ -23,12 +23,12 @@ Kubernetes gestisce il ciclo di vita di tutte le immagini tramite imageManager,
|
|||
di consulente.
|
||||
|
||||
La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
|
||||
`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
|
||||
soglia è stata soddisfatta.
|
||||
|
||||
La politica per la raccolta dei rifiuti delle immagini prende in considerazione due fattori:
|
||||
`HighThresholdPercent` e` LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
`HighThresholdPercent` e `LowThresholdPercent`. Utilizzo del disco al di sopra della soglia alta
|
||||
attiverà la garbage collection. La garbage collection cancellerà le immagini utilizzate meno di recente fino al minimo
|
||||
soglia è stata soddisfatta.
|
||||
|
||||
|
|
@ -44,8 +44,8 @@ Kubelet agirà su contenitori non identificati, cancellati o al di fuori dei lim
|
|||
precedentemente menzionate. I contenitori più vecchi saranno generalmente rimossi per primi. `MaxPerPodContainer`
|
||||
e `MaxContainer` possono potenzialmente entrare in conflitto l'uno con l'altro in situazioni in cui il mantenimento del
|
||||
numero massimo di contenitori per pod (`MaxPerPodContainer`) non rientra nell'intervallo consentito di contenitori morti
|
||||
globali (` MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
|
||||
quello di eseguire il downgrade di` MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
|
||||
globali (`MaxContainers`). `MaxPerPodContainer` verrebbe regolato in questa situazione: uno scenario peggiore sarebbe
|
||||
quello di eseguire il downgrade di `MaxPerPodContainer` su 1 e rimuovere i contenitori più vecchi. Inoltre, i
|
||||
contenitori di proprietà dei pod che sono stati cancellati vengono rimossi una volta che sono più vecchi di "MinAge".
|
||||
|
||||
I contenitori che non sono gestiti da Kubelet non sono soggetti alla garbage collection del contenitore.
|
||||
|
|
@ -83,12 +83,12 @@ Compreso:
|
|||
|
||||
| Bandiera esistente | Nuova bandiera | Motivazione
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` o` --eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` o `--eviction-soft` | i segnali di sfratto esistenti possono innescare la garbage collection delle immagini |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | i reclami di sfratto ottengono lo stesso comportamento |
|
||||
| `--maximum-dead-containers` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
|
||||
| `--maximum-dead-containers-per-container` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
|
||||
| `--minimum-container-ttl-duration` | | deprecato una volta che i vecchi log sono memorizzati al di fuori del contesto del contenitore |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` o` eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` o `eviction-soft` | lo sfratto generalizza le soglie del disco ad altre risorse |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | lo sfratto generalizza la transizione della pressione del disco verso altre risorse |
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -47,7 +47,7 @@ $ kubectl logs counter
|
|||
...
|
||||
```
|
||||
|
||||
You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag` --previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
You can use `kubectl logs` to retrieve logsPuoi usare `kubectl logs` per recuperare i log da una precedente istanziazione di un contenitore con il flag `--previous`, nel caso in cui il contenitore si sia arrestato in modo anomalo. Se il pod ha più contenitori, è necessario specificare i registri del contenitore a cui si desidera accedere aggiungendo un nome contenitore al comando. Vedi la documentazione [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) per maggiori dettagli. from a previous instantiation of a container with `--previous` flag, in case the container has crashed. If your pod has multiple containers, you should specify which container's logs you want to access by appending a container name to the command. See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
|
||||
|
||||
## Logging at the node level
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ bypassando il meccanismo di registrazione predefinito. Usano il [klog] [klog]
|
|||
biblioteca di registrazione. È possibile trovare le convenzioni per la gravità della registrazione per quelli
|
||||
componenti nel [documento di sviluppo sulla registrazione](https://git.k8s.io/community/contributors/devel/logging.md).
|
||||
|
||||
Analogamente ai log del contenitore, i log dei componenti di sistema sono in /var/log`
|
||||
Analogamente ai log del contenitore, i log dei componenti di sistema sono in `/var/log`
|
||||
la directory dovrebbe essere ruotata. Nei cluster di Kubernetes allevati da
|
||||
lo script `kube-up.sh`, quei log sono configurati per essere ruotati da
|
||||
lo strumento `logrotate` al giorno o una volta che la dimensione supera i 100 MB.
|
||||
|
|
@ -143,7 +143,7 @@ Puoi utilizzare un contenitore sidecar in uno dei seguenti modi:
|
|||
|
||||
|
||||
|
||||
Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e` stderr`
|
||||
Facendo scorrere i propri contenitori sidecar sul proprio `stdout` e `stderr`
|
||||
flussi, è possibile sfruttare il kubelet e l'agente di registrazione che
|
||||
già eseguito su ciascun nodo. I contenitori del sidecar leggono i log da un file, un socket,
|
||||
o il diario. Ogni singolo contenitore sidecar stampa il log nel proprio `stdout`
|
||||
|
|
@ -151,16 +151,16 @@ o flusso `stderr`.
|
|||
|
||||
Questo approccio consente di separare diversi flussi di log da diversi
|
||||
parti della tua applicazione, alcune delle quali possono mancare di supporto
|
||||
per scrivere su `stdout` o` stderr`. La logica dietro il reindirizzamento dei registri
|
||||
per scrivere su `stdout` o `stderr`. La logica dietro il reindirizzamento dei registri
|
||||
è minimo, quindi non è un sovraccarico significativo. Inoltre, perché
|
||||
`stdout` e` stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati
|
||||
`stdout` e `stderr` sono gestiti da kubelet, puoi usare gli strumenti integrati
|
||||
come `log di kubectl`.
|
||||
|
||||
Considera il seguente esempio. Un pod esegue un singolo contenitore e il contenitore
|
||||
scrive su due file di registro diversi, utilizzando due formati diversi. Ecco un
|
||||
file di configurazione per il pod:
|
||||
|
||||
{{<codenew file = "admin/logging/two-files-counter-pod.yaml">}}
|
||||
{{< codenew file="admin/logging/two-files-counter-pod.yaml" >}}
|
||||
|
||||
Sarebbe un disastro avere voci di registro di diversi formati nello stesso registro
|
||||
stream, anche se si è riusciti a reindirizzare entrambi i componenti al flusso `stdout` di
|
||||
|
|
@ -170,7 +170,7 @@ i registri al proprio flusso `stdout`.
|
|||
|
||||
Ecco un file di configurazione per un pod con due contenitori sidecar:
|
||||
|
||||
{{<codenew file = "admin/logging/two-files-counter-pod-streaming-sidecar.yaml">}}
|
||||
{{< codenew file="admin/logging/two-files-counter-pod-streaming-sidecar.yaml" >}}
|
||||
|
||||
Ora quando si esegue questo pod, è possibile accedere separatamente a ciascun flusso di log
|
||||
eseguendo i seguenti comandi:
|
||||
|
|
@ -205,7 +205,7 @@ approccio contenitore.
|
|||
I contenitori del sidecar possono anche essere usati per ruotare i file di log che non possono essere
|
||||
ruotato dall'applicazione stessa. [Un esempio](https://github.com/samsung-cnct/logrotate)
|
||||
di questo approccio è un piccolo contenitore che esegue periodicamente logrotate.
|
||||
Tuttavia, si raccomanda di usare `stdout` e` stderr` direttamente e lasciare la rotazione
|
||||
Tuttavia, si raccomanda di usare `stdout` e `stderr` direttamente e lasciare la rotazione
|
||||
e politiche di conservazione al kubelet.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ my-nginx-svc LoadBalancer 10.0.0.208 <pending> 80/TCP 0s
|
|||
```
|
||||
|
||||
Con i suddetti comandi, prima creiamo le risorse sotto `examples/application/nginx/` e stampiamo le risorse create con il formato di output `-o name`
|
||||
(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con` kubectl get`.
|
||||
(stampa ogni risorsa come risorsa / nome). Quindi `grep` solo il" servizio ", e poi lo stampiamo con `kubectl get`.
|
||||
|
||||
Se si organizzano le risorse su più sottodirectory all'interno di una particolare directory, è possibile eseguire ricorsivamente anche le operazioni nelle sottodirectory, specificando `--recursive` o` -R` accanto al flag `--filename, -f`.
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ $ kubectl create -f project/k8s/development
|
|||
error: you must provide one or more resources by argument or filename (.json|.yaml|.yml|stdin)
|
||||
```
|
||||
|
||||
Invece, specifica il flag `--recursive` o` -R` con il flag `--filename, -f` come tale:
|
||||
Invece, specifica il flag `--recursive` o `-R` con il flag `--filename, -f` come tale:
|
||||
|
||||
```shell
|
||||
$ kubectl create -f project/k8s/development --recursive
|
||||
|
|
@ -121,7 +121,7 @@ deployment.apps/my-deployment created
|
|||
persistentvolumeclaim/my-pvc created
|
||||
```
|
||||
|
||||
Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag` --filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
|
||||
Il flag `--recursive` funziona con qualsiasi operazione che accetta il flag `--filename, -f` come: `kubectl {crea, ottieni, cancella, descrivi, implementa} ecc .`
|
||||
|
||||
Il flag `--recursive` funziona anche quando sono forniti più argomenti` -f`:
|
||||
|
||||
|
|
@ -195,7 +195,7 @@ modo che la nuova versione possa ricevere il traffico di produzione in tempo rea
|
|||
|
||||
Ad esempio, puoi usare un'etichetta `track` per differenziare le diverse versioni.
|
||||
|
||||
La versione stabile e primaria avrebbe un'etichetta `track` con valore come` stable`:
|
||||
La versione stabile e primaria avrebbe un'etichetta `track` con valore come `stable`:
|
||||
|
||||
```yaml
|
||||
name: frontend
|
||||
|
|
@ -210,7 +210,7 @@ La versione stabile e primaria avrebbe un'etichetta `track` con valore come` sta
|
|||
```
|
||||
|
||||
e quindi puoi creare una nuova versione del frontend del guestbook che porta l'etichetta `track` con un valore diverso
|
||||
(ad esempio` canary`), in modo che due gruppi di pod non si sovrappongano:
|
||||
(ad esempio `canary`), in modo che due gruppi di pod non si sovrappongano:
|
||||
|
||||
```yaml
|
||||
name: frontend-canary
|
||||
|
|
@ -266,7 +266,7 @@ my-nginx-2035384211-u3t6x 1/1 Running 0 23m fe
|
|||
```
|
||||
|
||||
questo produce tutti i pod "app = nginx", con un'ulteriore colonna di etichette del livello dei pod (specificata
|
||||
con `-L` o` --label-columns`).
|
||||
con `-L` o `--label-columns`).
|
||||
|
||||
Per ulteriori informazioni, consultare [labels](/docs/concepts/overview/working-with-objects/labels/) e
|
||||
[kubectl label](/docs/reference/generated/kubectl/kubectl-commands/#label).
|
||||
|
|
@ -353,7 +353,7 @@ non è in grado di rilevare l'eliminazione delle proprietà impostate al momento
|
|||
motivo, non li rimuoverà.
|
||||
|
||||
Tutte le chiamate successive a `kubectl apply`, e altri comandi che modificano la configurazione, come `kubectl replace`
|
||||
e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a` kubectl apply` per rilevare ed
|
||||
e `kubectl edit`, aggiorneranno l'annotazione, consentendo le successive chiamate a `kubectl apply` per rilevare ed
|
||||
eseguire cancellazioni usando un tre via diff.
|
||||
|
||||
{{< note >}}
|
||||
|
|
@ -368,7 +368,7 @@ In alternativa, puoi anche aggiornare le risorse con `kubectl edit`:
|
|||
$ kubectl edit deployment/my-nginx
|
||||
```
|
||||
|
||||
Questo equivale a prima "get` la risorsa, modificarla nell'editor di testo e quindi" applicare "la risorsa con la
|
||||
Questo equivale a prima `get` la risorsa, modificarla nell'editor di testo e quindi `apply` la risorsa con la
|
||||
versione aggiornata:
|
||||
|
||||
```shell
|
||||
|
|
@ -381,7 +381,7 @@ $ rm /tmp/nginx.yaml
|
|||
```
|
||||
|
||||
Questo ti permette di fare più cambiamenti significativi più facilmente. Nota che puoi specificare l'editor con le
|
||||
variabili di ambiente `EDITOR` o` KUBE_EDITOR`.
|
||||
variabili di ambiente `EDITOR` o `KUBE_EDITOR`.
|
||||
|
||||
Per ulteriori informazioni, consultare il documento [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands/#edit).
|
||||
|
||||
|
|
|
|||
|
|
@ -59,7 +59,7 @@ parla con altre macchine virtuali nel tuo progetto. Questo è lo stesso modello
|
|||
|
||||
Gli indirizzi IP di Kubernetes esistono nello scope `Pod` - contenitori all'interno di un 'Pod`
|
||||
condividere i loro spazi dei nomi di rete, compreso il loro indirizzo IP. Ciò significa che
|
||||
i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su` localhost`. Questo
|
||||
i contenitori all'interno di un `Pod` possono raggiungere tutti gli altri porti su `localhost`. Questo
|
||||
significa anche che i contenitori all'interno di un 'Pod` devono coordinare l'utilizzo della porta, ma questo
|
||||
non è diverso dai processi in una VM. Questo è chiamato il modello "IP-per-pod".
|
||||
|
||||
|
|
@ -195,10 +195,10 @@ Docker è avviato con:
|
|||
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
||||
```
|
||||
|
||||
Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al `Nodo` .spec.podCIDR`.
|
||||
Questo bridge è creato da Kubelet (controllato da `--network-plugin = kubenet` flag) in base al Nodo `.spec.podCIDR`.
|
||||
|
||||
Docker ora assegna gli IP dal blocco `cbr-cidr`. I contenitori possono raggiungere l'un l'altro e `Nodi` sul
|
||||
ponte` cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
|
||||
ponte `cbr0`. Questi IP sono tutti instradabili all'interno della rete del progetto GCE.
|
||||
|
||||
GCE non sa nulla di questi IP, quindi non lo farà loro per il traffico internet in uscita. Per ottenere ciò viene
|
||||
utilizzata una regola iptables masquerade (aka SNAT - per far sembrare che i pacchetti provengano dal `Node` stesso)
|
||||
|
|
|
|||
Loading…
Reference in New Issue