Hace poco me paso un caso interesante con los cluster RKE on premise de la empresa, resulta que inesperadamente me llegaban las notificaciones de Grafana por uso intensivo de CPU y RAM, ingresando a ver el estado del cluster me doy con la sorpresa que 3 de los 4 worker nodos estaban caídos (NotReady).

La razón de que los 3 nodos estaban no disponibles fue que en algún momento se “eliminaron” los kubelets y kube-proxys de dichos nodos. Desesperado vi la forma de solucionar este problema pero desafortunadamente no encontré ninguna respuesta, así que me puse a averiguar sobre la funcionalidad del binario RKE (que se usa para instalar el cluster).

Resulta que RKE tiene la opción de actualizar un cluster (agregar o quitar worker nodes sin la necesidad de hacer algún cambio en los nodos masters) para ello se le tiene que pasar la opción — update-only en el comando para instalar el cluster:

Para ello primero saque los nodos dañados del descriptor cluster.yml y ejecuté el comando anterior, esto a fin de que los nodos se desligaran del cluster. Luego agregue los nodos en el descriptor cluster.yml y volví a ejecutar el mismo comando.

El resultado de esa acción fue que dichos nodos fueron considerados como nodos nuevos por lo que el instalador volvió a instalar las imágenes correspondientes (Kubelet, proxy, etc.) Volviendo así el cluster a su normalidad.

Troubleshoting in RKE: Nodos en estado NotReady was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.

En este post veremos como instalar un cluster de 1 master y 1 worker (obviamente por los recursos limitados de mí pc), para ello necesario algunos requisitos:

• Conexión SSH desde el host que instalará el cluster a los nodos master y worker, esta conexión debe permitir que el host puede conectarse sin la necesidad de ingresar algún password.
• Tener instalado docker en cada nodo, aquí se debe tener cuidado en la versión que se debe instalar. Aquí te dejo un enlace de scripts hechos por el team de Rancher de los instaladores de Docker .
• Reglas de entrada y salida del firewall.

Una vez que tengamos los requerimientos anteriores, el siguiente paso es descargar el ejecutable de RKE desde Github y configurarlo en modo ejecución:

Luego creamos un archivo descriptor del cluster que deseemos configurar, este archivo es un yaml:

En esta configuración especificamos que queremos 1 Worker y 1 Master y que además agregue un nginx como controlador del Ingress

Terminado de realizar la configuración de nuestro cluster solo es necesario ejecutar el siguiente comando:

Si tienes Vagrant instalado puedes descargar y ejecutar los archivos desde mí github.

Solo bastara con hacer un vagrant up

Rancher Kubernetes Engine (RKE) was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Requisitos:

1. Tener un cluster k8s instalado (Aquí tengo una publicación de como instalarlo onPremise).
2. Una maquina que será usado como servidor NFS.

Configuración del Servidor NFS:

Instalamos las herramientas necesarias para NFS y luego habilitamos los servicios

Ahora creamos un directorio el cual queremos compartir en nuestro caso será /home/vagrant/nfs_data y además dar ciertos permisos

Luego debemos de realizar la configuración en el archivo exports

vi /etc/exports

Es en este archivo donde describimos que clientes van a tener acceso a la carpeta compartida, en mi caso tengo 2 workers con ip 192.168.2.X por lo tanto la configuración será:

/home/vagrant/nfs_data 192.168.2.90(rw,sync,no_root_squash,no_subtree_check)

/home/vagrant/nfs_data 192.168.2.91(rw,sync,no_root_squash,no_subtree_check)

Una vez hecho la configuración ejecutamos el siguiente comando:

exports -a

Configuración Clientes NFS

En el lado del cliente que son los worker de k8s solo debemos instalar las herramientas necesarias:

yum -y install nfs-utils

Ahora es momento de probar dicha configuración en kubernetes para lo cual creamos un PersistentVolumen en el cual especificaremos la ip y ruta de nuestro servidor NFS

Si todo salio bien entonces ya podríamos crear nuestro PVC y por lo tanto asignarlos a algún POD

Ahora usaremos el PVC en un Nginx;

Ahora ya podemos crear subir archivos a nuestra carpeta compartida y este se mapeara en la ruta /usr/share/nginx/html de cada contenedor que se ejecute.

Kubernetes - NFS Server was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.

De lo mencionado en el párrafo anterior debemos notar que los objetos que tienen esa versión de api son:daemonsets, deployments y replicasets. Por lo que crear estos objetos de la forma en que se solía hacer (apiVersion: apps/v1beta1) nos saldrá el siguiente error:

no matches for kind “Deployment” in version “extensions/v1beta1”

Para solucionar este inconveniente solo basta con modificar el apiVersion a apps/v1.

En caso de que tengamos nuestros objetos kubernetes en archivos yaml con la versión anterior también podemos convertirlos a la versión 1.16.0 con el siguiente comando

kubectl convert -f k8s-object.yml > new_object.yml

Estos nos creara el descriptor del objeto para la nueva versión.

Para mayor información:

https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.16.md#deprecations-and-removals

Kubernetes 1.16.0 was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Requerimientos:

1. Maquinas o VM con IP estáticas.
2. Mínimo 2GB de RAM y 2 CPU por cada maquina.
3. El usuario root o usuario con los mismos privilegios.

Instalación inicial

En esta etapa se harán las instalaciones y configuraciones para todas las maquinas, sean estas workers o master.

sudo vi /etc/hosts

Configuramos las IP de cada nodo.

192.168.1.105 master
192.168.1.106 worker1

Configuramos el hostname

sudo hostnamectl set-hostname master (para el master)

sudo hostnamectl set-hostname worker1 (para el worker)

Deshabilitamos el SELIINUX

sudo setenforce 0

luego modificamos el archivo /etc/sysconfig/selinux a disabled

sudo sed -i --follow-symlinks 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/sysconfig/selinux

Hasta este paso es bueno reiniciar la maquina para que tome en cuenta el cambio que se hizo en el paso anterior.

Luego necesitamos habilitar el modulo br_netfilter del kernel

sudo modprobe br_netfilter
sudo echo '1' > /proc/sys/net/bridge/bridge-nf-call-iptables

luego des habilitamos la configuración del swap, esto por que kubernetes no permite la instalación si esta opción esta habilitada.

sudo swapoff -a

Instalamos Docker:

En este caso es recomendable instalar la version 18.04 de docker, ya que kubernetes siguiere esa version (yo instale la ultima version 19.03 y la instalación me salio normal, eso si con un WARNING de la version de docker).

sudo yum install -y yum-utils device-mapper-persistent-data lvm2

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

sudo yum install -y docker-ce

sudo systemctl enable docker.service
sudo systemctl start docker.service

Instalación de Kubernetes:

Después de instalar debemos de instalar kubernetes.

Creamos el repositorio:

sudo vi /etc/yum.repos.d/kubernetes.repo

Agregamos el siguiente contenido en el repositorio que creamos en el paso anterior:

[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg

Instalamos Kubernetes con el siguiente comando:

sudo yum install -y kubelet kubeadm kubectl

Finalmente, habilitamos el servicio de Kubelet

sudo systemctl enable kubelet.service

Configuración en el Nodo Maestro

Esta parte es para la configuración del nodo maestro:

sudo kubeadm init  --pod-network-cidr=192.168.0.0/16 --apiserver-advertise-address=<IP_MASTER>

Después de ejecutar el comando anterior nos debería de mandar un mensaje como el siguiente:

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

kubeadm join 192.168.1.105:6443 --token fwldpz.bgejrgr1cqviuoeo --discovery-token-ca-cert-hash sha256:b11fbe1063550e822c54033729d45ca28e1fdb05deed3fbd103f27cf2926b2e7

En la ultima parte del mensaje podemos ver un comando, copia ese comando en un lugar seguro ya que usaremos este comando para conectar los nodos workers con el master.

Luego ejecutamos los siguientes comando para la configuración del kubectl

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Una vez terminado, podríamos ejecutar el comando para obtener los nodos disponibles

kubectl get nodes

Deberías de ver una salida como la siguiente

NAME          STATUS     ROLES    AGE   VERSION
master         NotReady   master   14m   v1.13.2

En la salida del mensaje anterior nos muestra que el nodo master se encuentra en el estado NotReady, esto es por que nos falta instalar un CNI (Container Networking Interface)

En este caso instalaremos Calico como nuestro gestor de red, para ello primero debemos instalar un etcd para calico:

kubectl apply -f \
https://docs.projectcalico.org/v3.4/getting-started/kubernetes/installation/hosted/etcd.yaml

Luego instalar Calico:

kubectl apply -f \
https://docs.projectcalico.org/v3.4/getting-started/kubernetes/installation/hosted/calico.yaml

Deberías de ver el siguiente mensaje

configmap/calico-config created
secret/calico-etcd-secrets created
daemonset.extensions/calico-node created
serviceaccount/calico-node created
deployment.extensions/calico-kube-controllers created
serviceaccount/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created

Esperemos un momento hasta que se desplieguen los pods de calico, para lo cual ejecutamos el siguiente comando y esperamos hasta que todos los pods tengan un estado RUNNING

kubectl get pods --all-namespaces

Una vez que todos los pods tengan el estado RUNNING ejecutamos el siguiente comando:

kubectl get nodes

Deberíamos de ver algo así:

NAME          STATUS     ROLES    AGE     VERSION
master         Ready    master   6m44s   v1.13.2

Configuración en los nodos Workers

En el lado de los workers solo debemos de ejecutar el siguiente comando pero eso si cambiando los valores del token y el hash del certificado (Aquí debemos copiar el comando que nos mostró al momento de instalar en el nodo maestro):

kubeadm join 192.168.1.105:6443 --token fwldpz.bgejrgr1cqviuoeo --discovery-token-ca-cert-hash sha256:b11fbe1063550e822c54033729d45ca28e1fdb05deed3fbd103f27cf2926b2e7

Cuando la ejecución sea exitosa se mostrara el siguiente resultado:

[discovery] Trying to connect to API Server "192.168.1.105:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://192.168.1.105:6443"
[discovery] Requesting info from "https://192.168.1.105:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "192.168.1.105:6443"
[discovery] Successfully established connection with API Server "192.168.1.105:6443"
[join] Reading configuration from the cluster...
[join] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet] Downloading configuration for the kubelet from the "kubelet-config-1.13" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[tlsbootstrap] Waiting for the kubelet to perform the TLS Bootstrap...
[patchnode] Uploading the CRI Socket information "/var/run/dockershim.sock" to the Node API object "worker-node" as an annotation

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the master to see this node join the cluster.

Ahora volvamos al nodo maestro y ejecutemos el siguiente comando:

kubectl get nodes

Salida:

NAME          STATUS   ROLES    AGE     VERSION
master         Ready    master   21m     v1.13.2
worker1        Ready    <none>   5m29s   v1.13.2

Probando el cluster

Probamos ejecutando un NGINX:

kubectl create deployment nginx --image=nginx

Salida:

deployment.apps/nginx created

Creamos un service para poder ver desde nuestro navegador red:

kubectl create service nodeport nginx --tcp=80:80

Now, list out all the services by running the following command:

kubectl get svc

Deberíamos ver el puerto en el que se expone nuestro nginx:

NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
nginx       NodePort    10.102.166.47   <none>        80:30784/TCP   31s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP        25m

Finalmente, solo habré la siguiente url http://192.168.1.106:30784 (IP del nodo worker). Deberías de ver la siguiente imagen:

Instalación de Kubernetes OnPremise was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hasta este punto todo funciona normal ya que no se “modifica” nada, el problema pasa cuando en vez de retornar una instancia de la clase User nosotros creamos una clase que implemente dicha interfaz. Personalmente creí que con el simple hecho de implementar esa interfaz la cosa iba a funcionar de maravillas. Terrible error!!!.

Esta configuración trajo sus consecuencias, por ejemplo: no podía obtener un nuevo access_token usando el refresh_token que proporciona spring security oauth2.

La causa:

El problema de esta configuración fue que no me percate de algo muy importante (Me costó 2 días en descubrirlo), al momento de persistir la data spring espera que los objetos a guardar este debidamente serializados. Uno podría simplemente implementar la interfaz Serializable (tal como lo hice yo), pero NO, spring usa su propio valor de serialización que generalmente corresponde con la versión en el que este se encuentre.

Así que si alguna vez desean personalizar la clase de retorno en vez del que spring maneja por defecto, solo deben de implementar la interfaz UserDetails y Serializable y poner con valor en el campo serialVersionUID de la siguiente manera:

public class MyCustomUser implements UserDetails, Serializable{

private static final long serialVersionUID = SpringSecurityCoreVersion.SERIAL_VERSION_UID;

…

}

¿Qué es el “SERIAL_VERSION_UID” de Spring Security? was originally published in Spring in Action on Medium, where people are continuing the conversation by highlighting and responding to this story.

new SqlParameter("PV_COD_SCG", Types.ARRAY, CHAR_ARRAY)

Fue ahi que me puse a investigar un poquito el tema y vi que se tenia que hacer algunas configuraciones las cuales detallo:

Al momento de declarar los parámetros a recibir, en caso de que sea un ARRAY se tiene que especificar el nombre de ese Array a nivel de la base de datos en mi caso esos array los llame CHAR_ARRAY y NUM_ARRAY

SimpleJdbcCall simpleJdbcCall = new SimpleJdbcCall(concurrenciaDataSource)
        .withSchemaName(ConstanteUtil.ESQUEMA_ONTPAC)
        .withCatalogName(ConstanteUtil.PAQUETE_SOLBEN_AC)
        .withProcedureName(PROCEDURE)
        .withoutProcedureColumnMetaDataAccess()
        .declareParameters(
          new SqlParameter("PV_NOMB_VALID", Types.ARRAY,CHAR_ARRAY),
          new SqlParameter("PN_TOT_PRESUP", Types.ARRAY,NUM_ARRAY));

Luego se tiene que hacer la carga de la data a enviar, para ese caso se tiene utilizar la interfaz SqlTypeValue el cual debemos de implementar su metodo de la siguiente manera:

SqlTypeValue pvCodScg = new AbstractSqlTypeValue() {
    protected Object createTypeValue(Connection conn, int sqlType, String typeName) throws SQLException {
        ArrayDescriptor arrayDescriptor = new ArrayDescriptor(typeName, conn);
        return new ARRAY(arrayDescriptor, conn, strings);
    }
};

una vez implementado dicha interfaz debemos de asignar ese valor:

MapSqlParameterSource in = new MapSqlParameterSource();
in.addValue("PV_COD_SCG",pvCodScg);

y finalmente ejecutamos:

out = simpleJdbcCall.execute(in);

Ahora en el caso que nuestro SP tambien nos retorne un ARRAY debemos manejar la salida de la siguiente manera:

(ARRAY)(out.get("PV_COD_CG_SOLBEN"))

donde ARRAY proviene de la librería oracle.sql.ARRAY;

El código completo lo puede ver en el siguiente gist .

Para mayor información:

https://docs.spring.io/spring-data/jdbc/old-docs/2.0.0.BUILD-SNAPSHOT/reference/html/orcl.datatypes.html

Spring JDBC- SP con parametro Array was originally published in Spring in Action on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ante esa problemática en kubernetes existen los volumenes, estos volumenes pueden ser de diferentes tipos:

• awsElasticBlockStore
• azureDisk
• azureFile
• cephfs
• cinder
• configMap
• csi
• downwardAPI
• emptyDir
• fc (fibre channel)
• flexVolume
• flocker
• gcePersistentDisk
• gitRepo (deprecated)
• glusterfs
• hostPath
• iscsi
• local
• nfs
• persistentVolumeClaim
• projected
• portworxVolume
• quobyte
• rbd
• scaleIO
• secret
• storageos
• vsphereVolume

De estos tipos de volumenes es importante notar que soportan volumenes de los 3 principales proveedores cloud publicos gcePersistentDisk (GCP), awsElasticBlockStore (AWS ) y azureDisk (AZURE).

Del listado mencionado veremos los siguientes tipo de volumenes: hostPath y persistentVolumeClaim

hostPath: Este tipo de volumen permite crear el volumen en el directorio del nodo en el que se ejecuta el pod.

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data
      # this field is optional
      type: Directory

PersistentVolume (PV): Es espacio de almacenamiento que se provisiona, en ella se describe la capacidad de almacenamiento y el modo de acceso (ReadWriteOnce,ReadWriteMany y ReadOnlyMany)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

persistentVolumeClaim(PVC): Es un tipo de peticion para almacenamiento realizada por el usuario hacia los persistentVolume(PV) existentes y configurada por defecto para optimizar el almacenamiento, esto quiere decir si tenemos 2 persistent volumes con 100Mb y 500Mb, y creamos un persistent volumeClaim de 80Mb la peticion tomara al primer persitent volume.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

Una vez configurado el persistentVolume y el persistentVolumeClaim, procedemos a usar esos volumenes en nuestro pod de la siguiente manera:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Referencias:

https://kubernetes.io/docs/concepts/storage/persistent-volumes/

Volumenes was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.

Para sacarme de dudas use una imagen busybox y realize un ping a la IP de mi maquina host y resulta que efectivamente habia conexion.

Por lo que averiguando pude notar que la configuración por defecto de mysql permite solo conexiones locales (127.0.0.1), ya que los contenedores son asignados en otro rango de red (el mio esta en el rango de 172.17.0.0)esta conexion no se podia realizar

La solución fue habilitar la conexión externa en mysql cambiando la propiedad bind-address (archivo /etc/mysql/mysql.conf.d)

bind-address = 0.0.0.0

Además de eso fue necesario crear un usuario de mysql con los permisos necesarios y que pueda conectarse desde cualquier dominio o red

CREATE USER ‘newuser’@’%’ IDENTIFIED BY ‘user_password’;

Una vez hecha esa configuracion el contenedor pudo establecer conexion con la base de datos mysql del host.

Accediendo mysql (host) desde un contenedor was originally published in Docker Everywhere on Medium, where people are continuing the conversation by highlighting and responding to this story.

En ese sentido el poder tener una cierta regla que permita que el pod este disponible bajo ciertas pruebas nos permitira ofrecer aplicaciones menos tolerantes a fallos de cara a los cliente.

De la misma manera es importante conocer el estado de nuestra aplicacion dentro del Pod, ya que en caso de que nuestra aplicacion se haya colgado deberiamos reiniciarla.

Como solución a esas necesidades existen las pruebas de Liveness y readiness que nos permiten justamente validar el estado de nuestra aplicacion, en caso de no cumplir con los requisitos que pongamos, el pod sera reiniciado.

Estas validaciones pueden ser a nivel de http, tcp ,etc. tambien es posible especificar el delay y los periodos para hacer las pruebas.

A continuacion un ejemplo de su uso:

apiVersion: v1
kind: Pod
metadata:
name: kubia-liveness
spec:
containers:
-image: luksa/kubia-unhealthy
name: kubia
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 15
periodSeconds: 10

readinessProbe:

httpGet:

path: /readiness

port: 8888

initialDelaySeconds: 300

periodSeconds: 3

Mas información:

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

Liveness y Readiness was originally published in Kubernetes on Medium, where people are continuing the conversation by highlighting and responding to this story.