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>