OpenShift - Amministrazione
In questo capitolo, tratteremo argomenti come come gestire un nodo, configurare un account di servizio, ecc.
Configurazione master e nodi
In OpenShift, dobbiamo usare il comando start insieme a OC per avviare un nuovo server. Durante l'avvio di un nuovo master, dobbiamo utilizzare il master insieme al comando di avvio, mentre durante l'avvio del nuovo nodo dobbiamo utilizzare il nodo insieme al comando di avvio. Per fare ciò, dobbiamo creare file di configurazione per il master così come per i nodi. Possiamo creare un file di configurazione di base per il master e il nodo utilizzando il seguente comando.
Per il file di configurazione principale
$ openshift start master --write-config = /openshift.local.config/master
Per il file di configurazione del nodo
$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>
Una volta eseguiti i seguenti comandi, otterremo i file di configurazione di base che possono essere utilizzati come punto di partenza per la configurazione. Successivamente, possiamo avere lo stesso file per avviare i nuovi server.
apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
logoutURL: ""
masterPublicURL: https://172.10.12.1:7449
publicURL: https://172.10.2.2:7449/console/
servingInfo:
bindAddress: 0.0.0.0:7449
certFile: master.server.crt
clientCA: ""
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
bindAddress: 0.0.0.0:53
etcdClientInfo:
ca: ca.crt
certFile: master.etcd-client.crt
keyFile: master.etcd-client.key
urls:
- https://10.0.2.15:4001
etcdConfig:
address: 10.0.2.15:4001
peerAddress: 10.0.2.15:7001
peerServingInfo:
bindAddress: 0.0.0.0:7001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
servingInfo:
bindAddress: 0.0.0.0:4001
certFile: etcd.server.crt
clientCA: ca.crt
keyFile: etcd.server.key
storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
kubernetesStoragePrefix: kubernetes.io
kubernetesStorageVersion: v1
openShiftStoragePrefix: openshift.io
openShiftStorageVersion: v1
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: MasterConfig
kubeletClientInfo:
ca: ca.crt
certFile: master.kubelet-client.crt
keyFile: master.kubelet-client.key
port: 10250
kubernetesMasterConfig:
apiLevels:
- v1beta3
- v1
apiServerArguments: null
controllerArguments: null
masterCount: 1
masterIP: 10.0.2.15
podEvictionTimeout: 5m
schedulerConfigFile: ""
servicesNodePortRange: 30000-32767
servicesSubnet: 172.30.0.0/16
staticNodeNames: []
masterClients:
externalKubernetesKubeConfig: ""
openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
clusterNetworkCIDR: 10.1.0.0/16
hostSubnetLength: 8
networkPluginName: ""
serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
assetPublicURL: https://172.10.2.2:7449/console/
grantConfig:
method: auto
identityProviders:
- challenge: true
login: true
name: anypassword
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
masterPublicURL: https://172.10.2.2:7449/
masterURL: https://172.10.2.2:7449/
sessionConfig:
sessionMaxAgeSeconds: 300
sessionName: ssn
sessionSecretsFile: ""
tokenConfig:
accessTokenMaxAgeSeconds: 86400
authorizeTokenMaxAgeSeconds: 300
policyConfig:
bootstrapPolicyFile: policy.json
openshiftInfrastructureNamespace: openshift-infra
openshiftSharedResourcesNamespace: openshift
projectConfig:
defaultNodeSelector: ""
projectRequestMessage: ""
projectRequestTemplate: ""
securityAllocator:
mcsAllocatorRange: s0:/2
mcsLabelsPerProject: 5
uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
subdomain: router.default.svc.cluster.local
serviceAccountConfig:
managedNames:
- default
- builder
- deployer
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
servingInfo:
bindAddress: 0.0.0.0:8443
certFile: master.server.crt
clientCA: ca.crt
keyFile: master.server.key
maxRequestsInFlight: 0
requestTimeoutSeconds: 3600
File di configurazione del nodo
allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
execHandlerName: native
imageConfig:
format: openshift/origin-${component}:${version}
latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
mtu: 1450
networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com
podManifestConfig:
path: "/path/to/pod-manifest-file"
fileCheckIntervalSeconds: 30
servingInfo:
bindAddress: 0.0.0.0:10250
certFile: server.crt
clientCA: node-client-ca.crt
keyFile: server.key
volumeDirectory: /root/openshift.local.volumes
Ecco come appaiono i file di configurazione del nodo. Una volta che abbiamo questi file di configurazione in posizione, possiamo eseguire il seguente comando per creare server master e nodo.
$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml
Gestione dei nodi
In OpenShift, abbiamo l'utilità della riga di comando OC che viene utilizzata principalmente per eseguire tutte le operazioni in OpenShift. Possiamo usare i seguenti comandi per gestire i nodi.
Per elencare un nodo
$ oc get nodes
NAME LABELS
node1.example.com kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com kubernetes.io/hostname = vklnld1447.int.example.com
Descrivere i dettagli su un nodo
$ oc describe node <node name>
Eliminazione di un nodo
$ oc delete node <node name>
Elenco dei pod su un nodo
$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]
Valutazione dei pod su un nodo
$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]
Autenticazione della configurazione
In OpenShift master, è presente un server OAuth integrato, che può essere utilizzato per la gestione dell'autenticazione. Tutti gli utenti OpenShift ottengono il token da questo server, che li aiuta a comunicare con OpenShift API.
Esistono diversi tipi di livelli di autenticazione in OpenShift, che possono essere configurati insieme al file di configurazione principale.
- Permettere tutto
- Nega tutto
- HTPasswd
- LDAP
- Autenticazione di base
- Richiedi intestazione
Durante la definizione della configurazione principale, possiamo definire la politica di identificazione in cui possiamo definire il tipo di politica che desideriamo utilizzare.
Permettere tutto
Permettere tutto
oauthConfig:
...
identityProviders:
- name: Allow_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: AllowAllPasswordIdentityProvider
Nega tutto
Ciò negherà l'accesso a tutti i nomi utente e le password.
oauthConfig:
...
identityProviders:
- name: deny_Authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: DenyAllPasswordIdentityProvider
HTPasswd
HTPasswd viene utilizzato per convalidare il nome utente e la password rispetto a una password di file crittografata.
Per generare un file crittografato, di seguito è riportato il comando.
$ htpasswd </path/to/users.htpasswd> <user_name>
Utilizzando il file crittografato.
oauthConfig:
...
identityProviders:
- name: htpasswd_authontication
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /path/to/users.htpasswd
Provider di identità LDAP
Viene utilizzato per l'autenticazione LDAP in cui il server LDAP svolge un ruolo chiave nell'autenticazione.
oauthConfig:
...
identityProviders:
- name: "ldap_authontication"
challenge: true
login: true
provider:
apiVersion: v1
kind: LDAPPasswordIdentityProvider
attributes:
id:
- dn
email:
- mail
name:
- cn
preferredUsername:
- uid
bindDN: ""
bindPassword: ""
ca: my-ldap-ca-bundle.crt
insecure: false
url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"
Autenticazione di base
Viene utilizzato quando la convalida del nome utente e della password viene eseguita rispetto a un'autenticazione da server a server. L'autenticazione è protetta nell'URL di base e viene presentata in formato JSON.
oauthConfig:
...
identityProviders:
- name: my_remote_basic_auth_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: BasicAuthPasswordIdentityProvider
url: https://www.vklnld908.int.example.com/remote-idp
ca: /path/to/ca.file
certFile: /path/to/client.crt
keyFile: /path/to/client.key
Configurazione di un account di servizio
Gli account di servizio forniscono un modo flessibile per accedere all'API OpenShift esponendo il nome utente e la password per l'autenticazione.
Abilitazione di un account di servizio
L'account di servizio utilizza una coppia di chiavi di chiavi pubbliche e private per l'autenticazione. L'autenticazione all'API viene eseguita utilizzando una chiave privata e convalidandola rispetto a una chiave pubblica.
ServiceAccountConfig:
...
masterCA: ca.crt
privateKeyFile: serviceaccounts.private.key
publicKeyFiles:
- serviceaccounts.public.key
- ...
Creazione di un account di servizio
Usa il seguente comando per creare un account di servizio
$ Openshift cli create service account <name of server account>
Lavorare con il proxy HTTP
Nella maggior parte degli ambienti di produzione, l'accesso diretto a Internet è limitato. Non sono esposti a Internet o sono esposti tramite un proxy HTTP o HTTPS. In un ambiente OpenShift, questa definizione di macchina proxy è impostata come variabile di ambiente.
Questo può essere fatto aggiungendo una definizione proxy sui file master e nodo che si trovano sotto /etc/sysconfig. Questo è simile a quello che facciamo per qualsiasi altra applicazione.
Master Machine
/ etc / sysconfig / openshift-master
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com
Node Machine
/ etc / sysconfig / openshift-node
HTTP_PROXY=http://USERNAME:[email protected]:8080/
HTTPS_PROXY=https://USERNAME:[email protected]:8080/
NO_PROXY=master.vklnld908.int.example.com
Una volta terminato, è necessario riavviare le macchine master e nodo.
Per Docker Pull
/ etc / sysconfig / docker
HTTP_PROXY = http://USERNAME:[email protected]:8080/
HTTPS_PROXY = https://USERNAME:[email protected]:8080/
NO_PROXY = master.vklnld1446.int.example.com
Per eseguire un pod in un ambiente proxy, è possibile farlo utilizzando:
containers:
- env:
- name: "HTTP_PROXY"
value: "http://USER:PASSWORD@:10.0.1.1:8080"
Il comando OC environment può essere utilizzato per aggiornare il file env esistente.
Archiviazione OpenShift con NFS
In OpenShift, il concetto di volume persistente e richieste di volume persistenti forma l'archiviazione persistente. Questo è uno dei concetti chiave in cui viene creato il primo volume persistente e successivamente viene rivendicato lo stesso volume. Per questo, è necessario disporre di capacità e spazio su disco sufficienti sull'hardware sottostante.
apiVersion: v1
kind: PersistentVolume
metadata:
name: storage-unit1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
nfs:
path: /opt
server: 10.12.2.2
persistentVolumeReclaimPolicy: Recycle
Successivamente, utilizzando il comando di creazione OC creare il volume persistente.
$ oc create -f storage-unit1.yaml
persistentvolume " storage-unit1 " created
Rivendicazione del volume creato.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: Storage-clame1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
Crea il reclamo.
$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created
Gestione utenti e ruoli
L'amministrazione degli utenti e dei ruoli viene utilizzata per gestire gli utenti, il loro accesso e i controlli su diversi progetti.
Creazione di un utente
I modelli predefiniti possono essere utilizzati per creare nuovi utenti in OpenShift.
kind: "Template"
apiVersion: "v1"
parameters:
- name: vipin
required: true
objects:
- kind: "User"
apiVersion: "v1"
metadata:
name: "${email}"
- kind: "Identity"
apiVersion: "v1"
metadata:
name: "vipin:${email}"
providerName: "SAML"
providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
name: "vipin:${email}"
user:
name: "${email}"
Utilizzare oc create –f <nome file> per creare utenti.
$ oc create –f vipin.yaml
Usa il seguente comando per eliminare un utente in OpenShift.
$ oc delete user <user name>
Limitazione dell'accesso degli utenti
ResourceQuotas e LimitRanges vengono utilizzati per limitare i livelli di accesso dell'utente. Vengono utilizzati per limitare i pod e i contenitori nel cluster.
apiVersion: v1
kind: ResourceQuota
metadata:
name: resources-utilization
spec:
hard:
pods: "10"
Creazione del preventivo utilizzando la configurazione di cui sopra
$ oc create -f resource-quota.yaml –n –Openshift-sample
Descrivere la citazione della risorsa
$ oc describe quota resource-quota -n Openshift-sample
Name: resource-quota
Namespace: Openshift-sample
Resource Used Hard
-------- ---- ----
pods 3 10
La definizione dei limiti del contenitore può essere utilizzata per limitare le risorse che verranno utilizzate dai contenitori distribuiti. Sono utilizzati per definire i limiti massimi e minimi di determinati oggetti.
Limitazioni del progetto utente
Questo è fondamentalmente utilizzato per il numero di progetti che un utente può avere in qualsiasi momento. Fondamentalmente vengono eseguiti definendo i livelli utente in categorie di bronzo, argento e oro.
Dobbiamo prima definire un oggetto che abbia il valore di quanti progetti può avere una categoria di bronzo, argento e oro. Questi devono essere eseguiti nel file master-confif.yaml.
admissionConfig:
pluginConfig:
ProjectRequestLimit:
configuration:
apiVersion: v1
kind: ProjectRequestLimitConfig
limits:
- selector:
level: platinum
- selector:
level: gold
maxProjects: 15
- selector:
level: silver
maxProjects: 10
- selector:
level: bronze
maxProjects: 5
Riavvia il server principale.
Assegnazione di un utente a un livello particolare.
$ oc label user vipin level = gold
Spostare l'utente fuori dall'etichetta, se necessario.
$ oc label user <user_name> level-
Aggiunta di ruoli a un utente.
$ oadm policy add-role-to-user
<user_name>
Rimozione del ruolo da un utente.
$ oadm policy remove-role-from-user
<user_name>
Aggiunta di un ruolo del cluster a un utente.
$ oadm policy add-cluster-role-to-user
<user_name>
Rimozione di un ruolo del cluster da un utente.
$ oadm policy remove-cluster-role-from-user
<user_name>
Aggiunta di un ruolo a un gruppo.
$ oadm policy add-role-to-user
<user_name>
Rimozione di un ruolo da un gruppo.
$ oadm policy remove-cluster-role-from-user
<user_name>
Aggiunta di un ruolo del cluster a un gruppo.
$ oadm policy add-cluster-role-to-group
<groupname>
Rimozione di un ruolo del cluster da un gruppo.
$ oadm policy remove-cluster-role-from-group <role> <groupname>
Utente per l'amministrazione del cluster
Questo è uno dei ruoli più potenti in cui l'utente ha la capacità di gestire un cluster completo a partire dalla creazione fino all'eliminazione di un cluster.
$ oadm policy add-role-to-user admin <user_name> -n <project_name>
Utente con la massima potenza
$ oadm policy add-cluster-role-to-user cluster-admin <user_name>