Tareas de Día 2 #
En este último artículo de la serie ‘Instalación de OpenShift’, abordaremos algunas de las tareas que se realizan el día 2, o lo que es lo mismo, después de instalar el clúster.
Etiquetado y taints de nodos #
Se van a etiquetar y organizar los nodos para que, según el rol o etiquetas, se ejecuten unas tareas u otras en ellos.
Los nodos infra serán los encargados de ejecutar toda la parte que tiene que ver con OpenShift o la infraestructura en sí, como puede ser, por ejemplo, el ingress-controller:
oc label node ocpinfra1.arpovea.com node-role.kubernetes.io/infra=
oc label node ocpinfra1.arpovea.com node-role.kubernetes.io=infra
oc label node ocpinfra1.arpovea.com router=default
oc adm taint nodes ocpinfra1.arpovea.com infra=reserved:NoSchedule
oc label node ocpinfra2.arpovea.com node-role.kubernetes.io/infra=
oc label node ocpinfra2.arpovea.com node-role.kubernetes.io=infra
oc label node ocpinfra2.arpovea.com router=default
oc adm taint nodes ocpinfra2.arpovea.com infra=reserved:NoSchedule
oc label node ocpinfra3.arpovea.com node-role.kubernetes.io/infra=
oc label node ocpinfra3.arpovea.com node-role.kubernetes.io=infra
oc label node ocpinfra3.arpovea.com router=default
oc adm taint nodes ocpinfra3.arpovea.com infra=reserved:NoSchedule
Luego tenemos los nodos worker o de cómputo, que serán los que ejecuten las cargas de trabajo:
oc label node ocpworker1.arpovea.com node-role.kubernetes.io/compute=
oc label node ocpworker2.arpovea.com node-role.kubernetes.io/compute=
oc label node ocpworker3.arpovea.com node-role.kubernetes.io/compute=
Configuración de router o openshift-ingress #
Como comentamos en artículos anteriores, configuraremos el ingress controller de la plataforma de OpenShift para que esté alojado en los nodos infra. Para ello:
#anclar a nodos etiquetados con router default
oc patch ingresscontroller/default -n openshift-ingress-operator --type=merge \
-p '{"spec":{"nodePlacement": {"nodeSelector": {"matchLabels": {"router":
"default"}}}}}'
#anclar a nodos etiquetados con infra
oc patch ingresscontroller/default -n openshift-ingress-operator --type=merge -p '{"spec":{"nodePlacement": {"nodeSelector": {"matchLabels": {"node-role.kubernetes.io/infra": ""}}}}}'
Además, se configura con 3 réplicas, al igual que los nodos:
oc patch -n openshift-ingress-operator ingresscontroller/default --patch \
'{"spec":{"replicas": 3}}' --type=merge
Creacion de MachineConfigPool #
Se crean los grupos de nodos mediante MachineConfigPool, lo que permite agrupar los nodos para realizar acciones sobre ellos, ya sean de configuración, actualizaciones, rendimiento, etc.
Compute #
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
name: compute
labels:
node-role: compute
spec:
machineConfigSelector:
matchExpressions:
- values:
- worker
- compute
operator: In
key: machineconfiguration.openshift.io/role
nodeSelector:
matchLabels:
node-role.kubernetes.io/compute: ""
Infra #
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
name: infra
labels:
node-role: infra
spec:
machineConfigSelector:
matchExpressions:
- values:
- worker
- infra
operator: In
key: machineconfiguration.openshift.io/role
nodeSelector:
matchLabels:
node-role.kubernetes.io/infra: ""
Creacion de usuarios (IDP) #
La gestión de usuarios la podemos llevar a cabo mediante un IDP, como LDAP. Para este laboratorio, vamos a utilizar htpasswd. Para ello, podemos seguir directamente la guía de la documentación oficial:
Una vez creados los usuarios, tenemos que asegurarnos de conceder permisos de administrador a un usuario, ya que en los próximos pasos vamos a eliminar a kubeadmin, lo cual es una buena práctica.
Con este YAML podemos dar el permiso:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: <usuario>-cluster-admin
subjects:
- kind: User
apiGroup: rbac.authorization.k8s.io
name: <nombre-usuario-admin>
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
Eliminación de Kubeadmin #
Como hemos mencionado, asegúrate de configurar el apartado de IDP y otorgar a un usuario el rol de cluster-admin, luego:
Elimina el siguiente secreto:
oc delete secrets kubeadmin -n kube-system
Si tienes dudas al respecto, puedes seguir la documentación oficial:
https://docs.openshift.com/container-platform/4.14/authentication/remove-kubeadmin.html
Almacenamiento: #
En cuanto al tema del provisionador de almacenamiento, en mi caso, como ya tengo un NFS, he utilizado:
https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/tree/master
Es bastante sencillo de utilizar, y para el escenario que tenemos es más que suficiente, ya que montar una solución como ODF o Ceph consume bastantes recursos.
GitOps con Openshift-Gitops (ARGOCD) #
Por último, realizamos la instalación del operador de OpenShift-GitOps. Podemos realizar la instalación directamente desde la interfaz de OpenShift en la parte del catálogo o también podemos instalarlo mediante el Subscription. En mi caso, en el momento de la instalación, es:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
labels:
operators.coreos.com/openshift-gitops-operator.openshift-operators: ""
name: openshift-gitops-operator
namespace: openshift-operators
spec:
channel: gitops-1.10
installPlanApproval: Manual
name: openshift-gitops-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
startingCSV: openshift-gitops-operator.v1.10.1
Una vez aprobado el correspondiente installPlan y terminada la instalación, procedemos a otorgar permisos a la serviceAccount que utiliza esta instancia para permitir que pueda administrar y realizar cambios a nivel de la plataforma OpenShift. Esto lo realizamos con el siguiente ClusterRoleBinding:
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: gitops-cluster-admin
subjects:
- kind: ServiceAccount
name: openshift-gitops-argocd-application-controller
namespace: openshift-gitops
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
Se utilizará ArgoCD para tener controlada, mediante Git, toda la configuración posible y componentes de la plataforma OpenShift.
Estas tareas que he mostrado son solo algunas de las que he realizado en el día dos. Podéis encontrar más tareas y configuraciones recomendadas posteriores a la instalación de OpenShift en el siguiente enlace:
Fin de la serie “Instalación de OpenShift” #
Si has llegado hasta aquí, lo primero, ¡gracias! Y lo segundo, ¡enhorabuena! Ya tienes un clúster de OpenShift listo y funcionando.
A lo largo de esta serie, hemos sentado las bases para el despliegue de la plataforma de Openshift lo que te permitira construir y administrar aplicaciones de manera más eficiente. En futuros artículos, profundizaremos en el mundo de GitOps, una metodología que está revolucionando la forma en que desplegamos y gestionamos aplicaciones en los distintos entornos.
Próximamente, tendrás un artículo dedicado a GitOps y ArgoCD, donde detallaré áreas específicas como:
- Applications en ArgoCD: Cómo gestionar tus aplicaciones de forma declarativa y automatizada.
- Projects en ArgoCD: Aprende a organizar tus aplicaciones y aplicar políticas de acceso.
- Recorrido por la interfaz de ArgoCD: Un recorrido guiado por la interfaz de usuario de ArgoCD para maximizar su utilidad desde el principio.
- Conexión con repositorios Git: Configura tus repositorios Git para un despliegue continuo con ArgoCD.
- Buenas prácticas en GitOps: Consejos y estrategias para implementar GitOps de manera efectiva y segura.
¡Gracias por acompañarme en esta serie!