- Información general
- Requisitos
- Recomendado: plantillas de implementación
- Manual: preparar la instalación
- Manual: preparar la instalación
- Paso 1: configurar el registro compatible con OCI para las instalaciones sin conexión
- Paso 2: configurar el almacén de objetos externo
- Paso 3: configurar High Availability Add-on
- Paso 4: configurar Microsoft SQL Server
- Paso 5: configurar el equilibrador de carga
- Paso 6: configurar el DNS
- Paso 7: configurar los discos
- Paso 8: configurar el kernel y la configuración en el nivel del sistema operativo
- Paso 9: configurar los puertos de nodo
- Paso 10: aplicar ajustes diversos
- Paso 12: Validar e instalar los paquetes RPM necesarios
- Paso 13: Generar cluster_config.json
- Configuración de certificados
- Configuración de la base de datos
- Configuración del almacén de objetos externo
- Configuración de URL prefirmada
- Configuración de registro externo compatible con OCI
- Disaster recovery: configuraciones activas/pasivas y activas/activas
- Configuración de High Availability Add-on
- Configuración específica de Orchestrator
- Configuración específica de Insights
- Process Mining-specific configuration
- Configuración específica de Document Understanding
- Automation Suite Robots-specific configuration
- Configuración de la supervisión
- Opcional: configurar el servidor proxy
- Opcional: habilitación de la resistencia a fallos de zona en un clúster multinodo de producción preparada para alta disponibilidad
- Opcional: pasar resolv.conf personalizado
- Optional: Increasing fault tolerance
- parámetros de install-uipath.sh
- Inclusión de un nodo agente dedicado compatible con GPU
- Añadir un nodo agente dedicado a Task Mining
- Conexión de la aplicación Task Mining
- Añadir un nodo agente dedicado a Automation Suite Robots
- Paso 15: configurar el registro temporal de Docker para las instalaciones sin conexión
- Paso 16: validar los requisitos previos para la instalación
- Manual: realizar la instalación
- Después de la instalación
- Administración de clústeres
- Gestionar los productos
- Primeros pasos con el Portal de administración del clúster
- Migrating objectstore from persistent volume to raw disks
- Migrar del en el clúster a High Availability Add-on externo
- Migrating data between objectstores
- Migrating in-cluster objectstore to external objectstore
- Migrar a un registro externo compatible con OCI
- Cambiar manualmente al clúster secundario en una configuración activa/pasiva
- Disaster Recovery: realizar operaciones posteriores a la instalación
- Convertir una instalación existente en una configuración en varios sitios
- Directrices sobre la actualización de una implementación activa/pasiva o activa/activa
- Directrices sobre la copia de seguridad y restauración de una implementación activa/pasiva o activa/activa
- Redireccionando el tráfico de los servicios no compatibles al clúster principal
- Supervisión y alertas
- Migración y actualización
- Paso 1: Mover los datos de la organización de identidad de independiente a Automation Suite
- Paso 2: restaurar la base de datos del producto independiente
- Paso 3: Realizar una copia de seguridad de la base de datos de la plataforma en Automation Suite
- Paso 4: Fusionar organizaciones en Automation Suite
- Paso 5: actualizar las cadenas de conexión de los productos migrados
- Paso 6: migrar el Orchestrator independiente
- Paso 7: migrar Insights independiente
- Paso 8: eliminar el tenant predeterminado
- B) Migración de tenant único
- Migrar de Automation Suite en Linux a Automation Suite en EKS / AKS
- Actualizar Automation Suite
- Descargar los paquetes de instalación y obtener todos los archivos del primer nodo del servidor
- Recuperar la última configuración aplicada del clúster
- Actualizar la configuración del clúster
- Configurar el registro compatible con OCI para las instalaciones sin conexión
- Ejecutar la actualización
- Realizar operaciones posteriores a la actualización
- Configuración específica del producto
- Uso de la herramienta de configuración de Orchestrator
- Configurar parámetros de Orchestrator
- Configuración de Orchestrator
- Configurar AppSettings
- Configurar el tamaño máximo de la solicitud
- Anular la configuración de almacenamiento a nivel de clúster
- Configurar almacenes de credenciales
- Configurar clave de cifrado por tenant
- Limpiar la base de datos de Orchestrator
- Buenas prácticas y mantenimiento
- Solución de problemas
- Cómo solucionar los problemas de los servicios durante la instalación
- Cómo desinstalar el clúster
- Cómo limpiar los artefactos sin conexión para mejorar el espacio en disco
- Cómo borrar datos de Redis
- Cómo habilitar el registro de Istio
- Cómo limpiar manualmente los registros
- Cómo limpiar los registros antiguos almacenados en el depósito sf-logs
- Cómo deshabilitar los registros de transmisión para AI Center
- Cómo depurar instalaciones de Automation Suite fallidas
- Cómo eliminar imágenes del instalador antiguo después de la actualización
- Cómo deshabilitar la descarga de la suma de comprobación TX
- Cómo actualizar desde Automation Suite 2022.10.10 y 2022.4.11 a 2023.10.2
- Cómo establecer manualmente el nivel de registro de ArgoCD en Info
- Cómo expandir el almacenamiento de AI Center
- Cómo generar el pull_secret_value codificado para registros externos
- Cómo abordar los cifrados débiles en TLS 1.2
- No se puede ejecutar una instalación sin conexión en el sistema operativo RHEL 8.4
- Error al descargar el paquete
- La instalación sin conexión falla porque falta un binario
- Problema de certificado en la instalación sin conexión
- First installation fails during Longhorn setup
- Error de validación de la cadena de conexión SQL
- Error en la comprobación de requisitos previos para el módulo iscsid de selinux
- Azure disk not marked as SSD
- Fallo tras la actualización del certificado
- El antivirus causa problemas de instalación
- Automation Suite not working after OS upgrade
- Automation Suite requiere que backlog_wait_time se establezca en 0
- El volumen no se puede montar porque no está listo para las cargas de trabajo
- Error de recopilación de registros del paquete de soporte
- Se ignora la cadena de conexión SQL de la automatización de pruebas
- La actualización de nodo único falla en la etapa de tejido
- Cluster unhealthy after automated upgrade from 2021.10
- Upgrade fails due to unhealthy Ceph
- RKE2 no se inicia debido a un problema de espacio
- El volumen no se puede montar y permanece en estado de bucle de conexión/desconexión
- La actualización falla debido a objetos clásicos en la base de datos de Orchestrator
- El clúster de Ceph se encuentra en un estado degradado tras una actualización en paralelo.
- Un componente Insights en mal estado provoca el fallo de la migración
- La actualización del servicio falla para Apps
- Tiempos de actualización in situ
- La migración del registro de Docker se atasca en la fase de eliminación de PVC
- Error de aprovisionamiento de AI Center después de actualizar a 2023.10 o posterior
- La actualización falla en entornos sin conexión
- La validación SQL falla durante la actualización
- pod de snapshot-controller-crds en estado CrashLoopBackOff después de la actualización
- Error de actualización/reinstalación del punto final de la API REST de Longhorn
- Establecer un intervalo de tiempo de espera para los portales de gestión
- La autenticación no funciona tras la migración
- kinit: no se puede encontrar la KDC para el territorio <AD Domain> mientras se obtienen las credenciales iniciales
- kinit: keytab no contiene claves adecuadas para *** mientras se obtienen las credenciales iniciales
- Error en la operación GSSAPI debido a un código de estado no válido
- Alarma recibida por un error en el trabajo de Kerberos-tgt-update
- Proveedor de SSPI: servidor no encontrado en la base de datos de Kerberos
- Error en inicio de sesión de un usuario AD debido a una cuenta deshabilitada
- ArgoCD login failed
- Actualizar las conexiones del directorio subyacente
- Fallo en la obtención de la imagen de Sandbox
- Los pods no se muestran en la interfaz de usuario de ArgoCD
- Fallo de la sonda Redis
- El servidor RKE2 no se inicia
- Secreto no encontrado en el espacio de nombres UiPath
- ArgoCD entra en estado de progreso tras la primera instalación
- Pods MongoDB en CrashLoopBackOff o pendientes de aprovisionamiento de PVC tras su eliminación
- Unhealthy services after cluster restore or rollback
- Pods atascados en Inicialización: 0 / X
- Faltan métricas de Ceph-rook en los paneles de supervisión
- Los pods no pueden comunicarse con FQDN en un entorno de proxy
- Document Understanding no se encuentra en la barra izquierda de Automation Suite
- Estado fallido al crear una sesión de etiquetado de datos
- Estado fallido al intentar implementar una habilidad ML
- El trabajo de migración falla en ArgoCD
- El reconocimiento de la escritura manual con el extractor de formularios inteligente no funciona
- Ejecutar alta disponibilidad con Process Mining
- La ingestión de Process Mining falló al iniciar sesión con Kerberos
- Después de Disaster Recovery, Dapr no funciona correctamente para Process Mining y Task Mining
- No se puede conectar a la base de datos AutomationSuite_ProcessMining_Warehouse utilizando una cadena de conexión en formato pyodbc
- La instalación de Airflow falla con sqlalchemy.exc.ArgumentError: no se pudo analizar la URL rfc1738 de la cadena ''
- Cómo añadir una regla de tabla de IP para utilizar el puerto 1433 de SQL Server
- Ejecutar la herramienta de diagnóstico
- Uso del paquete de soporte de Automation Suite
- Explorar registros
Gestionar los certificados
El proceso de instalación genera certificados autofirmados en tu nombre. Estos certificados cumplen con FIPS y caducarán en 90 días. Debes reemplazarlos por certificados firmados por una autoridad de certificación (AC) de confianza en cuanto finalice la instalación. Si no actualizas los certificados, la instalación dejará de funcionar transcurridos 90 días.
Si instalaste Automation Suite en un host habilitado para FIPS y deseas actualizar los certificados, asegúrate de que sean compatibles con FIPS.
El paquete de instalación ofrece una herramienta de gestión de clústeres que le permite actualizar los certificados después de la instalación. Para acceder a la herramienta, accede al lugar en el que tengas el paquete del instalador:
cd /opt/UiPathAutomationSuite/
cd /opt/UiPathAutomationSuite/
Para generar el CSR y la clave privada, ejecuta el siguiente comando:
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
# copy the machine openssl configuration locally
cp /etc/pki/tls/openssl.cnf ./openssl.tmp.cnf
# Replace the [AUTOMATION_SUITE_FQDN] value. For example, "automationsuite.corp.com"
AS_FQDN=[AUTOMATION_SUITE_FQDN]
cat >> ./openssl.tmp.cnf <<EOF
[SAN]
subjectAltName=DNS:$AS_FQDN,DNS:alm.$AS_FQDN,DNS:monitoring.$AS_FQDN,DNS:registry.$AS_FQDN,DNS:objectstore.$AS_FQDN,DNS:insights.$AS_FQDN
EOF
# create the certificate request
openssl req -new -sha256 -newkey rsa:2048 -nodes -keyout server.key -subj "/C=xx/ST=xx/O=xx/OU=xx/CN=$AS_FQDN" -reqexts SAN -config openssl.tmp.cnf -out ${AS_FQDN}.csr
Su equipo de TI utiliza los valores obtenidos para generar un certificado firmado. La clave privada generada sigue siendo local.
Para ver más información sobre los certificados de servidor, ejecuta el siguiente comando:
sudo ./configureUiPathAS.sh tls-cert --help
sudo ./configureUiPathAS.sh tls-cert --help
Salida:
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage cluster tls and server certificate
Usage:
configureUiPathAS.sh tls-cert [command]
configureUiPathAS.sh tls-cert [flags]
Available Commands:
update Update the tls / server certificate
get Get the tls / server certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh tls-cert
.
Instalación en línea: Cómo encontrar el certificado del servidor
istio-ingressgateway-certs
en el espacio de nombres istio-system
.
Consulta los archivos de certificado en la siguiente lista:
- El certificado TLS del servidor se almacena como
tls.crt
- La clave privada TLS del servidor como
tls.key
- El paquete de CA se almacena como
ca.crt
Puedes verificar los secretos utilizando el siguiente comando :
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
kubectl -n istio-system get secrets istio-ingressgateway-certs -o yaml
Los certificados también se almacenan en el espacio de nombres de UiPath. Esto es aplicable a todos los productos de UiPath® que necesitan información de certificados para confiar en las llamadas entrantes. Para obtener más detalles, consulta Comprender la arquitectura del contenedor relacionada con los certificados.
Instalación sin conexión: Cómo encontrar el certificado del servidor
rootCA.crt
y tls.crt
: ArgoCD y el registro de Docker. A continuación, los certificados se almacenan en los espacios de nombres de Docker y ArgoCD.
Puedes verificar los secretos utilizando el siguiente comando :
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https
# For docker registry
kubectl -n docker-registry get secrets docker-registry-tls -o yaml
# For Argocd
argocd login alm.cluster_fqnd --username argocd_username --password argocd_password
argocd cert list --cert-type https
Cómo actualizar los certificados del servidor
Para descifrar la clave del certificado, ejecuta el siguiente comando:
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
# replace /path/to/encrypted/cert/key to absolute file path of key
# replace /path/to/decrypt/cert/key to store decrypt key
# Once prompted, please entry the passphrase or password to decrypt the key
openssl rsa -in /path/to/encrypted/cert/key -out /path/to/decrypt/cert/key
configureUiPathAS.sh
para actualizar el certificado como se muestra a continuación. Necesita la ruta a cada uno de los tres archivos del certificado. Todo el archivo del certificado debe estar en formato PEM
. .
- Paquete de entidad de certificación: este paquete debe contener solo los certificados en cadena utilizados para firmar el certificado del servidor TLS. El límite de la cadena es de hasta nueve certificados.
- Certificado del servidor: certificado del servidor público
-
Clave privada: clave privada para el certificado del servidor
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
sudo ./configureUiPathAS.sh tls-cert update --ca-cert-file /path/to/cacert --tls-cert-file /path/to/tlscert --tls-key-file /path/to/tlskey
/directory/path/to/store/certificate
.
Para imprimir los archivos del certificado, ejecuta el siguiente comando y especifica el directorio donde se almacenan los certificados.
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh tls-cert get --outpath /directory/path/to/store/certificate
Usted es responsable de asegurarse de que los certificados generados sean de confianza.
Para añadir el certificado al almacén de confianza de la máquina virtual host, ejecuta los siguientes comandos en todos los nodos del clúster:
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Para ver más información sobre certificados de CA adicionales, ejecuta el siguiente comando:
./configureUiPathAS.sh additional-ca-certs --help
./configureUiPathAS.sh additional-ca-certs --help
Salida:
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
***************************************************************************************
Manage additional CA certificates, this can be used to add sql server CA
Usage:
configureUiPathAS.sh additional-ca-certs [command]
configureUiPathAS.sh additional-ca-certs [flags]
Available Commands:
update Update the additional trusted CA certificates.
get Get the additional trusted CA certificates
Flags:
-h|--help Display help
***************************************************************************************
./configureUiPathAS.sh additional-ca-certs
.
Este comando le ayuda a actualizar o sustituir los certificados de AC configurados existentes.
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
./configureUiPathAS.sh additional-ca-certs update --ca-cert-file /path/to/ca/certs
--replace
al final.
.pem
válido y puede constar de más de un certificado.
Para descargar los certificados de CA ya configurados, ejecuta el siguiente comando:
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
./configureUiPathAS.sh additional-ca-certs get --outpath /path/to/download/certs
Usted es responsable de asegurarse de que los certificados generados sean de confianza.
Para añadir el certificado al almacén de confianza de la máquina virtual host, ejecuta los siguientes comandos en todos los nodos del clúster:
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
# 1. Copy the certificate file to the /usr/share/pki/ca-trust-source/anchors/ or the /etc/pki/ca-trust/source/anchors/ directory
cp /path/to/the/ca-cert /usr/share/pki/ca-trust-source/anchors/
# 2. Update the trust store configuration
update-ca-trust
Para ver más información sobre los certificados de firma de tokens de identidad, ejecuta el siguiente comando:
sudo ./configureUiPathAS.sh identity token-cert --help
sudo ./configureUiPathAS.sh identity token-cert --help
Salida:
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
************************************************************************************
Manage Identity token signing certificate
Usage:
configureUiPathAS.sh identity token-cert [command]
configureUiPathAS.sh identity token-cert [flags]
Available Commands:
update Update secondary certificate to signing
the authentication token
rotate Switch secondary certificate as a primary
token signing certificate
get Get token signing certificate
Flags:
-h|--help Display help
************************************************************************************
./configureUiPathAS.sh identity token-cert
.
Para cargar el nuevo certificado para firmar el token, ejecuta el siguiente comando:
El siguiente comando no reemplaza el certificado de firma de token existente.
.pem
.
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
sudo ./configureUiPathAS.sh identity token-cert update --cert-file-path /path/to/cert --cert-key-file-path /path/to/certkey
Para rotar o reemplazar el certificado antiguo por el nuevo, ejecuta el siguiente comando:
sudo ./configureUiPathAS.sh identity token-cert rotate
sudo ./configureUiPathAS.sh identity token-cert rotate
El tiempo de espera entre la actualización del certificado y la rotación debe ser de 24 a 48 horas.
Este tiempo de espera es necesario para poder seguir admitiendo la autenticación de tokens en caché firmados por un certificado antiguo.
Si se rota el certificado con demasiada antelación a la expiración del token de caché, puede ocasionarse tiempo de inactividad. Y es posible que deba reiniciar todos sus robots.
Para realizar una actualización de certificados de emergencia, sigue estos pasos:
Ejecuta el siguiente comando para descargar el certificado de firma del token actual:
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
sudo ./configureUiPathAS.sh identity token-cert get --outpath /directory/path/to/store/certificate
Por defecto, los certificados RKE2 caducan en 12 meses. En los 90 días anteriores a su fecha de vencimiento, los certificados se rotan al reiniciar RKE2.
Para más detalles, consulta RKE2: opciones avanzadas: rotación de certificados.
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
if [[ -d "/var/lib/rancher/rke2/server/tls" ]]; then
dir="/var/lib/rancher/rke2/server/tls"
elif [[ -d "/var/lib/rancher/rke2/agent/tls" ]]; then
dir="/var/lib/rancher/rke2/agent/tls"
else
dir="/var/lib/rancher/rke2/agent/"
fi
# Loop through each .crt file in the directory
for file in "$dir"/*.crt; do
# Extract the expiry date from the certificate
expiry=$(openssl x509 -enddate -noout -in "$file" | cut -d= -f 2-)
# Get the file name without the path
filename=$(basename "$file")
# Print the filename and expiry date in a pretty format
printf "%-30s %s\n" "$filename:" "$expiry"
done
El resultado obtenido debería ser similar al mostrado en la siguiente imagen:
By default, RKE2 certificates expire in 12 months. In the 90 days prior to their expiration date, certificates are rotated when you restart RKE2. However, if the validity of the certificates exceeds the 90-day period, you must manually rotate the certificates by following the steps mentioned in RKE2 - Advanced Options - Certificate rotation.
If you want to customize the expiration period of RKE2 certificates to meet particular requirements, you can do so before restarting the RKE2 services for both server and agent nodes.
Para rotar los certificados RKE2, debes ejecutar primero una serie de acciones en los nodos del servidor y luego continuar con algunos pasos en los nodos del agente.
- Detén el servidor RKE2:
systemctl stop rke2-server.service
systemctl stop rke2-server.service - Borrar cualquier proceso RKE2 restante:
rke2-killall.sh
rke2-killall.sh - Elimina el archivo
dynamic-cert.json
ubicado en/var/lib/rancher/rke2/server/tls/
. -
To customize the expiration period of the RKE2 certificates, use the following command. Be aware that this example sets the validity period to 1000 days, but you can change this value based on your requirements.
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload
SERVICE_NAME="rke2-server.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Reinicia el servidor RKE2:
systemctl start rke2-server.service
systemctl start rke2-server.serviceNota: si el clúster tiene más de un nodo del servidor, los pasos 1-4 pueden no ejecutarse por completo, ya que etcd puede no poder completar la elección del líder. Si esto sucede, repite los pasos de 1-4 en otros nodos del servidor. - Elimina el secreto
rke2-serving
del espacio de nombreskube-system
:kubectl delete secret -n kube-system rke2-serving
kubectl delete secret -n kube-system rke2-servingNota:En una implementación multinodo, es posible que no puedas ejecutar los comandoskubectl
hasta que hayas completado las primeras cuatro operaciones en el número necesario de nodos del servidor. Esto es para cumplir el requisito de quórum etcd. Puedes eliminar el secretorke2-serving
inmediatamente después de que el servidor RKE2 se inicie.
kubectl get nodes
. Cuando tus nodos del servidor están listos, puedes continuar a los nodos del agente para regenerar los certificados.
Ejecuta los siguientes pasos en los nodos del agente:
- Detén el servidor RKE2:
systemctl stop rke2-agent.service
systemctl stop rke2-agent.service - Borrar cualquier proceso RKE2 restante:
rke2-killall.sh
rke2-killall.sh -
To customize the expiration period of the RKE2 certificates, use the following command. Be aware that this example sets the validity period to 1000 days, but you can change this value based on your requirements.
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload
SERVICE_NAME="rke2-agent.service" conf_file_path="/etc/systemd/system/${SERVICE_NAME}.d/cert.conf" mkdir -p /etc/systemd/system/"${SERVICE_NAME}".d/ cat > "$conf_file_path" <<EOF [Service] Environment="CATTLE_NEW_SIGNED_CERT_EXPIRATION_DAYS=1000" EOF systemctl daemon-reload - Reinicia el servidor RKE2:
systemctl start rke2-agent.service
systemctl start rke2-agent.service
- Generating a Certificate Signing Request (CSR) and a private key
- Gestionar certificados de servidor
- Actualizar el certificado del servidor
- Acceder al certificado TLS
- Adding the CA certificate to the host trust store
- Gestionar certificados de AC adicionales
- Actualizar los certificados de AC
- Acceder a los certificados de AC
- Adding the CA certificate to the host trust store
- Gestionar certificados de firma de tokens de identidad
- Actualizar el certificado
- Rotar el certificado
- Rotación de certificados en caso de emergencia
- Acceder al certificado
- Gestionar certificados RKE2
- Comprobar la fecha de vencimiento del certificado de RKE2
- Rotar el certificado de RKE2
- Gestionar el certificado de registro externo compatible con OCI