OpenShift - Administración

En este capítulo, cubriremos temas como cómo administrar un nodo, configurar una cuenta de servicio, etc.

Configuración de maestro y nodo

En OpenShift, necesitamos usar el comando de inicio junto con OC para iniciar un nuevo servidor. Al lanzar un nuevo maestro, necesitamos usar el maestro junto con el comando de inicio, mientras que al iniciar el nuevo nodo, necesitamos usar el nodo junto con el comando de inicio. Para hacer esto, necesitamos crear archivos de configuración para el maestro y para los nodos. Podemos crear un archivo de configuración básica para el maestro y el nodo usando el siguiente comando.

Para archivo de configuración maestro

$ openshift start master --write-config = /openshift.local.config/master

Para el archivo de configuración del nodo

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

Una vez que ejecutemos los siguientes comandos, obtendremos los archivos de configuración base que se pueden usar como punto de partida para la configuración. Posteriormente, podemos tener el mismo archivo para arrancar los nuevos servidores.

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

Archivos de configuración de 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

Así es como se ven los archivos de configuración del nodo. Una vez que tengamos estos archivos de configuración en su lugar, podemos ejecutar el siguiente comando para crear un servidor maestro y nodo.

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

Gestión de nodos

En OpenShift, tenemos la utilidad de línea de comandos OC que se usa principalmente para realizar todas las operaciones en OpenShift. Podemos usar los siguientes comandos para administrar los nodos.

Para listar 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

Describir detalles sobre un nodo

$ oc describe node <node name>

Eliminar un nodo

$ oc delete node <node name>

Listado de pods en un nodo

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

Evaluar pods en un nodo

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

Autenticación de configuración

En OpenShift master, hay un servidor OAuth integrado, que se puede utilizar para administrar la autenticación. Todos los usuarios de OpenShift obtienen el token de este servidor, lo que les ayuda a comunicarse con la API de OpenShift.

Hay diferentes tipos de niveles de autenticación en OpenShift, que se pueden configurar junto con el archivo de configuración principal.

• Permitir todo
• Negar todo
• HTPasswd
• LDAP
• Autenticación básica
• Encabezado de solicitud

Mientras definimos la configuración maestra, podemos definir la política de identificación donde podemos definir el tipo de política que deseamos utilizar.

Permitir todo

Permitir todo

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

Negar todo

Esto negará el acceso a todos los nombres de usuario y contraseñas.

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd se utiliza para validar el nombre de usuario y la contraseña frente a una contraseña de archivo cifrada.

Para generar un archivo cifrado, el siguiente es el comando.

$ htpasswd </path/to/users.htpasswd> <user_name>

Usando el archivo cifrado.

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

Proveedor de identidad LDAP

Se utiliza para la autenticación LDAP, en la que el servidor LDAP desempeña un papel clave en la autenticación.

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"

Autenticación básica

Se utiliza cuando la validación del nombre de usuario y la contraseña se realiza frente a una autenticación de servidor a servidor. La autenticación está protegida en la URL base y se presenta en 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

Configurar una cuenta de servicio

Las cuentas de servicio proporcionan una forma flexible de acceder a la API de OpenShift exponiendo el nombre de usuario y la contraseña para la autenticación.

Habilitación de una cuenta de servicio

La cuenta de servicio utiliza un par de claves públicas y privadas para la autenticación. La autenticación a la API se realiza mediante una clave privada y la valida con una clave pública.

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

Crear una cuenta de servicio

Use el siguiente comando para crear una cuenta de servicio

$ Openshift cli create service account <name of server account>

Trabajar con proxy HTTP

En la mayor parte del entorno de producción, el acceso directo a Internet está restringido. No están expuestos a Internet o están expuestos a través de un proxy HTTP o HTTPS. En un entorno OpenShift, esta definición de máquina proxy se establece como una variable de entorno.

Esto se puede hacer agregando una definición de proxy en los archivos maestro y de nodo ubicados en /etc/sysconfig. Esto es similar a lo que hacemos con cualquier otra aplicación.

Máquina maestra

/ 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

Máquina de nodo

/ 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 vez hecho esto, necesitamos reiniciar las máquinas maestra y nodo.

Para 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

Para hacer que un pod se ejecute en un entorno proxy, se puede hacer usando:

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

El comando de entorno OC se puede utilizar para actualizar el entorno env existente.

Almacenamiento OpenShift con NFS

En OpenShift, el concepto de volumen persistente y reclamos de volumen persistente forma almacenamiento persistente. Este es uno de los conceptos clave en los que se crea el primer volumen persistente y luego se reclama ese mismo volumen. Para esto, necesitamos tener suficiente capacidad y espacio en disco en el hardware subyacente.

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

A continuación, utilizando el comando OC create, cree un volumen persistente.

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

Reclamando el volumen creado.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

Crea el reclamo.

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

Gestión de usuarios y roles

La administración de usuarios y roles se utiliza para administrar usuarios, su acceso y controles en diferentes proyectos.

Crear un usuario

Se pueden utilizar plantillas predefinidas para crear nuevos usuarios en 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}"

Utilice oc create –f <nombre de archivo> para crear usuarios.

$ oc create –f vipin.yaml

Utilice el siguiente comando para eliminar un usuario en OpenShift.

$ oc delete user <user name>

Limitar el acceso de los usuarios

ResourceQuotas y LimitRanges se utilizan para limitar los niveles de acceso de los usuarios. Se utilizan para limitar las vainas y contenedores en el clúster.

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

Creando la cotización usando la configuración anterior

$ oc create -f resource-quota.yaml –n –Openshift-sample

Describiendo la cotización del recurso

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

La definición de los límites de contenedores se puede utilizar para limitar los recursos que van a utilizar los contenedores desplegados. Se utilizan para definir las limitaciones máximas y mínimas de determinados objetos.

Limitaciones del proyecto de usuario

Esto se usa básicamente para la cantidad de proyectos que un usuario puede tener en cualquier momento. Básicamente, se realizan definiendo los niveles de usuario en categorías de bronce, plata y oro.

Primero debemos definir un objeto que tenga el valor de cuántos proyectos puede tener una categoría de bronce, plata y oro. Estos deben realizarse en el archivo 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

Reinicie el servidor maestro.

Asignar un usuario a un nivel particular.

$ oc label user vipin level = gold

Sacar al usuario de la etiqueta, si es necesario.

$ oc label user <user_name> level-

Agregar roles a un usuario.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Eliminar el rol de un usuario.

$ oadm policy remove-role-from-user 
      
        <user_name> 
      

Agregar una función de clúster a un usuario.

$ oadm policy add-cluster-role-to-user 
      
        <user_name> 
      

Eliminar una función de clúster de un usuario.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Agregar un rol a un grupo.

$ oadm policy add-role-to-user 
      
        <user_name> 
      

Eliminar un rol de un grupo.

$ oadm policy remove-cluster-role-from-user 
      
        <user_name> 
      

Agregar una función de clúster a un grupo.

$ oadm policy add-cluster-role-to-group 
      
        <groupname> 
      

Eliminar una función de clúster de un grupo.

$ oadm policy remove-cluster-role-from-group <role> <groupname>

Usuario para la administración de clústeres

Este es uno de los roles más poderosos donde el usuario tiene la capacidad de administrar un clúster completo desde la creación hasta la eliminación de un clúster.

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

Usuario con la máxima potencia

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>