One place for hosting & domains

      Cómo monitorear los anuncios y las rutas de BGP utilizando BGPalerter en Ubuntu 18.04


      El autor seleccionó el COVID-19 Relief Fund para que reciba una donación como parte del programa Write for DOnations.

      Introducción

      BGP (Protocolo de puerta de enlace de borde) es uno de los protocolos principales responsable de redirigir paquetes a través de Internet; por lo tanto, si presenta errores, se pueden producir interrupciones importantes. Por ejemplo, en 2019, un pequeño proveedor de servicios de Internet hizo una mala configuración de BGP que, lamentablemente, se propagó de manera ascendente y dejó importantes partes de Cloudflare y AWS sin conexión durante más de una hora.  Además, hace un año, se realizó un ataque a BGP para interceptar el tráfico a un proveedor de monederos de criptomonedas y robar los fondos de clientes desprevenidos.

      BGPalerter es una herramienta de monitoreo de la red de BGP de código abierto que puede proporcionar alertas en tiempo real sobre la actividad de BGP, incluso la visibilidad de rutas y los anuncios de nuevas rutas, así como actividades potencialmente nefastas, como intercepciones o fugas en las rutas. BGPalerter ingiere automáticamente la información de redireccionamiento de la red disponible públicamente, lo que significa que no necesita tener ningún nivel de acceso con privilegios ni integración en las redes que quiere controlar.

      Nota: BGPalerter ingiere automáticamente la información de redireccionamiento de la red disponible públicamente, lo que significa que no necesita tener ningún nivel de acceso con privilegios ni integración en las redes que quiere controlar. Todo el monitoreo cumple plenamente con la Ley de Uso Indebido de Computadoras (Computer Misuse Act), la Ley de Fraude y Abuso de Computadoras (Computer Fraud and Abuse Act), y otras leyes similares.  Sin embargo, se recomienda revelar de forma responsable cualquier hallazgo relevante al operador de la red afectado.

      En este tutorial, instalará y configurará BGPalerter para monitorear sus redes importantes, a fin de detectar actividades potencialmente sospechosas.

      Requisitos previos

      Para completar este tutorial, necesitará lo siguiente:

      Para cada dispositivo o red, necesitará identificar la dirección IP individual, el intervalo de la dirección IP o el número de sistema autónomo del que es parte. Esto se abarca en el paso 1.

      Una vez que tenga todo esto listo, inicie sesión en su servidor como non-root user.

      Paso 1: Identificar las redes que se quieren monitorear

      En este paso, identificará los detalles pertinentes de las redes que quiere monitorear.

      BGPalerter puede monitorear sobre la base de direcciones IP individuales o prefijos de red. También puede monitorear redes enteras sobre la base de su número de sistema autónomo (AS), que es un identificador global único de una red propiedad de una entidad administrativa en particular.

      Para encontrar esta información, puede utilizar el servicio de búsqueda IP-to-ASN de WHOIS, proporcionado por el servicio de inteligencia de amenazas Team Cymru. Se trata de un servidor de WHOIS personalizado diseñado para buscar información de dirección IP y enrutamiento de red.

      Si no tiene whois instalado, puede instalarlo usando el siguiente comando:

      • sudo apt update
      • sudo apt install whois

      Una vez que haya confirmado que whois está instalado, comience por realizar una búsqueda de la dirección IP de su propio servidor, utilizando el argumento -h para especificar un servidor personalizado:

      • whois -h whois.cymru.com your-ip-address

      Esto generará un resultado similar al siguiente, que muestra el nombre y el número de AS del que su servidor es parte. Normalmente, será el AS de su proveedor de alojamiento del servidor, por ejemplo, DigitalOcean.

      Output

      AS | IP | AS Name 14061 | your-ip-address | DIGITALOCEAN-ASN, US

      A continuación, puede realizar una búsqueda para identificar el prefijo de la red o el intervalo del que su servidor es parte. Para hacerlo, agregue el argumento -p a su solicitud:

      • whois -h whois.cymru.com " -p your-ip-address"

      El resultado será muy similar al comando anterior, pero, ahora, mostrará el prefijo de dirección IP al que pertenece la dirección IP de su servidor:

      Output

      AS | IP | BGP Prefix | AS Name 14061 | your-ip-address | 157.230.80.0/20 | DIGITALOCEAN-ASN, US

      Por último, puede buscar más detalles del AS del que forma parte su servidor, incluyendo la región geográfica y la fecha de asignación.

      Sustituya el número de AS que identificó usando los comandos anteriores. Utiliza el argumento -v para habilitar el resultado detallado, lo que garantiza que se muestren todos los detalles relevantes:

      • whois -h whois.cymru.com " -v as14061"

      El resultado mostrará más información sobre el AS:

      Output

      AS | CC | Registry | Allocated | AS Name 14061 | US | arin | 2012-09-25 | DIGITALOCEAN-ASN, US

      identificó detalles clave sobre las redes que quiere monitorear. Tome nota de estos detalles en algún lugar, ya que los necesitará más adelante. A continuación, comenzará a configurar BGPalerter.

      Paso 2: Crear un usuario sin privilegios para BGPalerter

      En este paso, creará una nueva cuenta de usuario sin privilegios para BGPalerter, dado que el programa no necesita ejecutarse con privilegios sudo/root.

      Primero, cree un usuario nuevo con contraseña deshabilitada:

      • sudo adduser --disabled-password bgpalerter

      No necesita configurar una contraseña o una clave de SSH, dado que solo utilizará este usuario como una cuenta de servicio para ejecutar/mantener BGPalerter.

      Inicie sesión con el usuario nuevo utilizando su:

      Ahora, está conectado con su usuario nuevo:

      bgpalerter@droplet:/home/user$
      

      Utilice el comando cd para dirigirse al directorio de inicio de su usuario nuevo:

      bgpalerter@droplet:/home/user$ cd
      bgpalerter@droplet:~$
      

      Creó un usuario sin privilegios nuevo para BGPalerter. A continuación, instalará y configurará BGPalerter en su sistema.

      Paso 3: Instalar y configurar BGPalerter

      En este paso, instalará y configurará BGPalerter. Asegúrese de seguir conectado con su usuario sin privilegios nuevo.

      Primero, debe identificar la última versión de BGPalerter, a fin de asegurarse de descargar la más reciente. Diríjase a la página de Lanzamientos de BGPalerter y copie el enlace de descarga de la versión de Linux x64 más reciente.

      Ahora, puede descargar una copia de BGPalerter usando wget, asegurándose de sustituir el enlace de descarga correcto:

      • wget https://github.com/nttgin/BGPalerter/releases/download/v1.24.0/bgpalerter-linux-x64

      Una vez que el archivo haya terminado de descargarse, márquelo como ejecutable:

      • chmod +x bgpalerter-linux-x64

      A continuación, compruebe que BGPalerter se haya descargado e instalado correctamente comprobando el número de la versión:

      • ./bgpalerter-linux-x64 --version

      Esto dará como resultado el número de la versión actual:

      Output

      1.24.0

      Para poder ejecutar BGPalerter adecuadamente, deberá definir las redes que desea monitorear en un archivo de configuración. Cree y abra el archivo prefixes.yml en su editor de texto favorito:

      En este archivo de configuración, especificará cada una de las direcciones IP individuales, los intervalos de dirección IP y los números de AS que quiere monitorear.

      Añada el siguiente ejemplo y ajuste los valores de configuración según sea necesario usando la información de la red que identificó en el paso 1:

      ~/prefixes.yml

      your-ip-address/32:
        description: My Server
        asn:
          - 14061
        ignoreMorespecifics: false
      
      157.230.80.0/20:
        description: IP range for my Server
        asn:
          - 14061
        ignoreMorespecifics: false
      
      options:
        monitorASns:
          '14061':
            group: default
      

      Puede monitorear todos los intervalos de dirección IP o números de AS que quiera. Para monitorear direcciones IP individuales, represéntelas utilizando /32 para IPv4 y /128 para IPv6.

      El valor ignoreMorespecifics se utiliza para determinar si BGPalerter debe ignorar la actividad de las rutas más específicas (pequeñas) que la que está monitoreando. Por ejemplo, si está monitoreando /20 y se detecta un cambio de enrutamiento para /24 en su interior, se considera que es más específica. En la mayoría de los casos, no es recomendable ignorarlas si está monitoreando una red grande con varios prefijos de cliente delegados, sin embargo, puede ayudar a reducir interferencias de fondo.

      Ahora, puede ejecutar BGPalerter por primera vez para comenzar a monitorear sus redes:

      Si BGPalerter se inicia correctamente, verá un resultado similar al siguiente. Tenga en cuenta que, a veces, el monitoreo puede tardar unos minutos en iniciarse:

      Output

      Impossible to load config.yml. A default configuration file has been generated. BGPalerter, version: 1.24.0 environment: production Loaded config: /home/bgpalerter/config.yml Monitoring 157.230.80.0/20 Monitoring your-ip-address/32 Monitoring AS 14061

      BGPalerter se seguirá ejecutando hasta que lo detenga usando Ctrl+C.

      En el siguiente paso, interpretará algunas de las alertas que BGPalerter puede generar.

      Paso 4: Interpretar alertas de BGPalerter

      En este paso, revisará algunas alertas de BGPalerter de ejemplo. BGPalerter emitirá alertas en la fuente de salida principal, y también, de forma opcional, en cualquier otro extremo de información que pueda configurarse dentro de config.yml, como se describe en la documentación de BGPalerter.

      De manera predeterminada, BGPalerter monitorea y alerta sobre lo siguiente:

      • Intercepciones de ruta: se produce cuando un AS anuncia un prefijo que no está permitido, lo que provoca que el tráfico se enrute de forma errónea. Puede ser un ataque deliberado o un error de configuración accidental.

      • Pérdida de visibilidad de la ruta: una ruta se considera visible cuando la mayoría de los enrutadores de BGP de Internet pueden redirigir de forma fiable hacia ella. La pérdida de visibilidad significa que su red no está disponible, por ejemplo, si su emparejamiento de BGP ha dejado de funcionar.

      • Nuevos anuncios de subprefijos: sucede cuando un AS comienza a anunciar un prefijo que es más pequeño de lo que se espera. Esto puede indicar un cambio de configuración previsto, un error de configuración accidental o, en algunos casos, un ataque.

      • Actividad en su AS: normalmente, se refiere a anuncios de rutas nuevas. Una ruta se considera “nueva” si BGPalerter todavía no la conoce.

      A continuación, se presentan algunas alertas de ejemplo, junto con una descripción breve de su significado:

      Alert #1

      The prefix 203.0.113.0/24 is announced by AS64496 instead of AS65540
      

      Esta alerta muestra pruebas de una intercepción de la ruta, donde AS64496 anunció 203.0.113.0/24 cuando se esperaba que se anuncie AS65540. Esto es un claro indicio de un error de configuración que conduce a una fuga de la ruta o a una intercepción deliberada de un atacante.

      Alert #2

      The prefix 203.0.113.0/24 has been withdrawn. It is no longer visible from 6 peers
      

      Esta alerta indica que la red 203.0.113.0/24 ya no está visible. Esto puede deberse a un problema de enrutamiento previo o a un fallo de energía en un enrutador.

      Alert #3

      A new prefix 203.0.113.0/25 is announced by AS64496. It should be instead 203.0.113.0/24 announced by AS64496
      

      Esta alerta indica que se anunció un prefijo más específico en un caso en el que no estaba previsto, por ejemplo, si se anunció /25 cuando se esperaba /24. Es muy probable que esto sea un error de configuración, sin embargo, en algunos casos, puede indicar la intercepción de la ruta.

      Alert #4

      AS64496 is announcing 192.0.2.0/24 but this prefix is not in the configured list of announced prefixes
      

      Por último, esta alerta indica que AS64496 anunció un prefijo que BGPalerter todavía no conoce. Esto podría deberse a que usted está anunciando legítimamente un nuevo prefijo o podría ser un indicio de un error de configuración que haya provocado que anunciara accidentalmente un prefijo propiedad de otra persona.

      En este paso, revisó algunas alertas de BGPalerter de ejemplo. A continuación, configurará BGPalerter para que se ejecute de forma automática en el arranque.

      Paso 5: Iniciar BGPalerter en el arranque

      En este último paso, configurará BGPalerter para que se ejecute en el arranque.

      Asegúrese de seguir conectado con su usuario sin privilegios nuevo y, luego, abra el editor de crontab:

      Luego, añada la siguiente línea a la parte inferior del archivo de crontab:

      crontab

      @reboot sleep 10; screen -dmS bgpalerter "./bgpalerter-linux-x64"
      

      Cada vez que su sistema se arranque, esto creará una sesión screen separada denominada ‘bgpalerter’ en la que se iniciará BGPalerter.

      Guarde y salga del editor de crontab. Ahora, es conveniente que reinicie su sistema para asegurarse de que BGPalerter se inicie correctamente en el arranque.

      Primero, cierre la sesión de su usuario de BGPalerter:

      Luego, proceda con un reinicio normal del sistema:

      Una vez que su sistema se haya reiniciado, vuelva a iniciar sesión en su servidor y utilice su para volver a acceder a su usuario de BGPalerter:

      Luego, puede unirse a la sesión en cualquier momento para ver el resultado de BGPalerter:

      En este último paso, configuró BGPalerter para que se ejecute en el arranque.

      Conclusión

      En este artículo, configuró BGPalerter y lo utilizó para monitorear cambios de enrutamiento de BGP en las redes.

      Si quiere hacer que BGPalerter sea más fácil de usar, puede configurarlo para que envíe alertas a un canal de slack a través de un webhook:

      Si quiere obtener más información sobre BGP, pero no tiene acceso a un entorno de producción de BGP, puede utilizar DN42 para realizar pruebas con BGP en un entorno seguro y aislado:



      Source link

      Cómo optimizar las consultas de MySql con almacenamiento en caché de ProxySQL en Ubuntu 16.04


      El autor seleccionó la Free Software Foundation para recibir una donación como parte del programa Write for DOnations.

      Introducción

      ProxySQL es un servidor proxy con reconocimiento de SQL que puede posicionarse entre su aplicación y su base de datos. Ofrece muchas funciones, como el equilibrio de carga entre varios servidores MySQL y además sirve como capa de almacenamiento en caché para las consultas. Este tutorial se centrará en la función de almacenamiento en caché de ProxySQL, y en la forma en que puede optimizar las consultas de su base de datos MySQL.

      El almacenamiento en caché de MySQL se produce cuando el resultado de una consulta se almacena de modo que, cuando se repite la consulta, el resultado pueda mostrarse sin necesidad de realizar búsquedas en la base de datos. Esto puede aumentar considerablemente la velocidad de las consultas comunes. Sin embargo, en muchos métodos de almacenamiento en caché, los desarrolladores deben modificar el código de su aplicación, lo que podría introducir un error en la base de código. Para evitar esta práctica propensa a errores, ProxySQL le permite configurar un método de almacenamiento en caché transparente.

      En el almacenamiento en caché transparente, los administradores de la base de datos solo necesitan cambiar la configuración de ProxySQL para permitir el almacenamiento en caché de las consultas más comunes, y estos cambios pueden realizarse a través de la interfaz de administración de ProxySQL. Lo único que el desarrollador debe hacer es establecer conexión con el proxy que reconoce el protocolo. El proxy decidirá si la consulta puede presentarse desde la memoria caché sin alcanzar al servidor de backend.

      En este tutorial, usará ProxySQL para configurar un almacenamiento en caché transparente para un servidor MySQL en Ubuntu 16.04. A continuación, probará su rendimiento usando mysqlslap con y sin almacenamiento en caché para demostrar el efecto del almacenamiento en caché y la cantidad de tiempo que puede ahorrarse con él al ejecutar muchas consultas similares.

      Requisitos previos

      Para completar esta guía, necesitará lo siguiente:

      Paso 1: Instalar y configurar el servidor de MySQL

      Primero, instalará el servidor de MySQL y lo configurará para que lo use ProxySQL como servidor de backend para presentar consultas de clientes.

      En Ubuntu 16.04, puede instalar mysql-server usando este comando:

      • sudo apt-get install mysql-server

      Pulse Y para confirmar la instalación.

      Se solicitará su contraseña de usuario** root** de MySQL. Introduzca una contraseña segura y guárdela para su uso posterior.

      Ahora que tiene su servidor MySQL listo, lo configurará para que ProxySQL funcione correctamente. Debe añadir un usuario monitor para que ProxySQL monitorice el servidor de MySQL, ya que ProxySQL escucha al servidor de backend a través del protocolo SQL en vez de usar una conexión TCP o solicitudes HTTP GET para garantizar que el backend está en ejecución. El *usuario monitor *usará una conexión SQL ficticia para determinar si el servidor está activo o no.

      Primero, inicie sesión en el shell de MySQL:

      -uroot inicia sesión por usted usando el usuario root de MySQL y -p solicita la contraseña del usuario root. Este usuario root es diferente del usuario root de su servidor y la contraseña es la que introdujo cuando instaló el paquete mysql-server.

      Introduzca la contraseña root y pulse ENTER.

      Ahora, creará dos usuarios, uno llamado** monitor** para ProxySQL y otro que usará para ejecutar las consultas de los clientes y otorgarles los privilegios adecuados. En este tutorial, se asignará el nombre sammy a este usuario.

      Cree el usuario monitor:

      • CREATE USER 'monitor'@'%' IDENTIFIED BY 'monitor_password';

      La consulta CREATE USER se utiliza para crear un nuevo usuario que pueda conectarse desde IP específicas. Usar % denota que el usuario puede conectarse desde cualquier dirección IP. IDENTIFIED BY establece la contraseña para el nuevo usuario; introduzca la contraseña que desee, pero asegúrese de recordarla para usarla más adelante.

      Una vez creado el usuario monitor, cree el usuario sammy:

      • CREATE USER 'sammy'@'%' IDENTIFIED BY 'sammy_password';

      A continuación, conceda privilegios a sus nuevos usuarios. Ejecute el siguiente comando para configurar el usuario monitor:

      • GRANT SELECT ON sys.* TO 'monitor'@'%';

      La consulta GRANT se utiliza para dar privilegios a los usuarios. Aquí solo concedió SELECT en todas las tablas de la base de datos sys al usuario monitor; solo necesita este privilegio para escuchar al servidor de backend.

      Ahora, conceda todos los privilegios para todas las bases de datos al usuario sammy:

      • GRANT ALL PRIVILEGES on *.* TO 'sammy'@'%';

      Esto permitirá que sammy realice las consultas necesarias para probar su base de datos más tarde.

      Aplique los cambios de privilegios ejecutando lo siguiente:

      Finalmente, salga del shell mysql:

      Con esto, habrá instalado mysql-server y creado un usuario que ProxySQL utilizará para monitorizar su servidor de MySQL, y otro para ejecutar las consultas de clientes. A continuación, instalará y configurará ProxySQL.

      Paso 2: Instalar y configurar el servidor de ProxySQL

      Ahora podrá instalar el servidor de ProxySQL, que se utilizará como una capa de almacenamiento en caché para sus consultas. Una capa de almacenamiento en caché existe como punto de detención entre los servidores de su aplicación y los servidores de backend de la base de datos; se utiliza para conectar con la base de datos y para guardar los resultados de algunas consultas en su memoria para acceder a ellas más rápidamente.

      En la página de Github para versiones de ProxySQL se ofrecen archivos de instalación para distribuciones comunes de Linux. A los efectos de este tutorial, usará wget para descargar el archivo de instalación de Debian para la versión de ProxySQl 2.0.4:

      • wget https://github.com/sysown/proxysql/releases/download/v2.0.4/proxysql_2.0.4-ubuntu16_amd64.deb

      A continuación, instale el paquete usando dpkg:

      • sudo dpkg -i proxysql_2.0.4-ubuntu16_amd64.deb

      Una vez que lo haga, inicie ProxySQL con este comando:

      • sudo systemctl start proxysql

      Puede comprobar si ProxySQL se inició correctamente con este comando:

      • sudo systemctl status proxysql

      Verá un resultado similar a este:

      Output

      root@ubuntu-s-1vcpu-2gb-sgp1-01:~# systemctl status proxysql ● proxysql.service - LSB: High Performance Advanced Proxy for MySQL Loaded: loaded (/etc/init.d/proxysql; bad; vendor preset: enabled) Active: active (exited) since Wed 2019-06-12 21:32:50 UTC; 6 months 7 days ago Docs: man:systemd-sysv-generator(8) Tasks: 0 Memory: 0B CPU: 0

      Ahora es el momento de conectar su servidor de ProxySQL con el servidor de MySQL. Para esto, utilice la interfaz de administración SQL de ProxySQl, que por defecto escucha el puerto 6032 en localhost y tiene admin como nombre de usuario y contraseña.

      Establezca conexión con la interfaz ejecutando lo siguiente:

      • mysql -uadmin -p -h 127.0.0.1 -P6032

      Introduzca admin cuando se le solicite la contraseña.

      -uadmin establece admin como nombre de usuario, y el indicador -h especifica que localhost es el host. El puerto es el 6032, especificado usando el indicador -P.

      Aquí, tuvo que especificar el host y el puerto de forma explícita porque, por defecto, el cliente MySQL se conecta usando un archivo de sockets local y el puerto 3306.

      Ahora que inició sesión en el shell de mysql como admin, configure el usuario monitor de modo que ProxySQL pueda usarlo. Primero, utilice consultas SQL estándares para establecer los valores de dos variables globales:

      • UPDATE global_variables SET variable_value='monitor' WHERE variable_name='mysql-monitor_username';
      • UPDATE global_variables SET variable_value='monitor_password' WHERE variable_name='mysql-monitor_password';

      La variable mysql-monitor_username especifica el nombre de usuario de MySQL que se utilizará para comprobar si el servidor de backend está activo o no. La variable mysql-monitor_password apunta a la contraseña que se usará cuando establece conexión con el servidor de backend. Utilice la contraseña que creó para el nombre de usuario monitor.

      Cada vez que realice un cambio en la interfaz de administración de ProxySQL, deberá usar el comando LOAD adecuado para aplicar los cambios a la instancia de ProxySQL en ejecución. Cambió las variables globales de MySQL. Por ello, cárguelas en RUNTIME para aplicar los cambios:

      • LOAD MYSQL VARIABLES TO RUNTIME;

      A continuación, aplique SAVE los cambios a la base de datos en el disco para que los cambios persistan entre reinicios. ProxySQL utiliza su propia base de datos local SQLite para guardar sus tablas y variables:

      • SAVE MYSQL VARIABLES TO DISK;

      Ahora, transmitirá información a ProxySQL sobre el servidor de backend. La tabla mysql_servers contiene información sobre cada servidor de backend en los cuales ProxySQL puede establecer conexión y ejecutar consultas. Por lo tanto, debe añadir un nuevo registro usando una instrucción INSERT de SQL con los siguientes valores para hostgroup_id, hostname y port:

      • INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (1, '127.0.0.1', 3306);

      Para aplicar los cambios, ejecute LOAD y SAVE de nuevo:

      • LOAD MYSQL SERVERS TO RUNTIME;
      • SAVE MYSQL SERVERS TO DISK;

      Finalmente, indicará a ProxySQL el usuario que se conectará con el servidor de backend; establezca sammy como el usuario y sustituya sammy_password por la contraseña que creó antes:

      • INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('sammy', 'sammy_password', 1);

      La tabla mysql_users contiene información sobre los usuarios empleados para establecer conexión con los servidores de backend; especificó username, password y default_hostgroup.

      Aplique LOAD y SAVE a los cambios:

      • LOAD MYSQL USERS TO RUNTIME;
      • SAVE MYSQL USERS TO DISK;

      Finalmente, cierre el shell mysql:

      Para probar que pueda establecer conexión con su servidor de backend usando ProxySQL, ejecute la siguiente consulta de prueba:

      • mysql -usammy -h127.0.0.1 -p -P6033 -e "SELECT @@HOSTNAME as hostname"

      En este comando, usó el indicador -e para ejecutar una consulta y cerrar la conexión. La consulta imprime el nombre de host del servidor de backend.

      Nota: ProxySQL utiliza el puerto 6033 por defeto para escuchar las conexiones entrantes.

      El resultado tendrá este aspecto y your_hostname se sustituirá por su nombre de host:

      Output

      +----------------------------+ | hostname | +----------------------------+ | your_hostname | +----------------------------+

      Para obtener más información sobre la configuración de ProxySQL, consulte el paso 3 de Cómo usar ProxySQL como equilibrador de carga para MySQL en Ubuntu 16.04.

      Hasta ahora, configuró ProxySQL para que utilice su servidor de MySQL como backend y estableció conexión con el este último usando ProxySQL. Ahora, estará listo para usar mysqlslap para hacer referencia al rendimiento de la consulta sin almacenamiento en caché.

      Paso 3: Probar mysqlslap sin almacenamiento en caché

      En este paso, descargará una base de datos de prueba para poder ejecutar consultas en ella con mysqlslap para probar la latencia sin almacenamiento en caché, estableciendo una referencia para la velocidad de sus consultas. También verá la forma en que ProxySQL lleva registros de las consultas en la tabla stats_mysql_query_digest.

      mysqlslap es un cliente de emulación de carga que se usa como herramienta de prueba de carga para MySQL. Puede probar un servidor MySQL con consultas autogeneradas o con algunas consultas personalizadas ejecutadas en una base de datos. Viene instalado con el paquete cliente de MySQL, de modo que no necesita instalarlo. En vez de eso, descargará una base de datos solo para pruebas en la cual puede usar mysqlslap.

      En este tutorial, usará una base de datos de empleados de muestra. Usará esta base de datos de empleados porque cuenta con un gran conjunto de datos que puede ilustrar las diferencias en la optimización de consultas. La base de datos tiene seis tablas, pero los datos que contiene tienen más de 300.000 registros de empleados. Esto le permitirá emular una carga de trabajo de producción a gran escala.

      Para descargar la base de datos, primero clone el repositorio de Github usando este comando:

      • git clone https://github.com/datacharmer/test_db.git

      A continuación, introduzca el directorio test_db y cargue la base de datos en el servidor MySQL usando estos comandos:

      • cd test_db
      • mysql -uroot -p < employees.sql

      Este comando utiliza redireccionamiento de shell para leer las consultas SQL en el archivo employees.sql y las ejecuta en el servidor MySQL para crear la estructura de la base de datos.

      Verá un resultado similar a este:

      Output

      INFO CREATING DATABASE STRUCTURE INFO storage engine: InnoDB INFO LOADING departments INFO LOADING employees INFO LOADING dept_emp INFO LOADING dept_manager INFO LOADING titles INFO LOADING salaries data_load_time_diff 00:00:32

      Una vez que la base de datos se cargue en su servidor MySQL, pruebe que mysqlslap funcione con la siguiente consulta:

      • mysqlslap -usammy -p -P6033 -h127.0.0.1 --auto-generate-sql --verbose

      mysqlslap tiene indicadores similares a los del cliente mysql; aquí están los que se utilizan en este comando:

      • -u especifica el usuario usado para establecer conexión con el servidor.
      • -p pide la contraseña del usuario.
      • -P establece conexión usando el puerto especificado.
      • -h establece conexión con el host especificado.
      • --auto-generate-sql permite que MySQL realice una prueba de carga usando sus propias consultas generadas.
      • --verbose hace que en el resultado se muestre más información.

      Obtendrá un resultado similar al siguiente:

      Output

      Benchmark Average number of seconds to run all queries: 0.015 seconds Minimum number of seconds to run all queries: 0.015 seconds Maximum number of seconds to run all queries: 0.015 seconds Number of clients running queries: 1 Average number of queries per client: 0

      En este resultado, puede ver los números de segundos promedio, mínimo y máximo utilizados para ejecutar todas las consultas. Esto le proporciona una indicación sobre la cantidad de tiempo necesario para ejecutar las consultas por un número de clientes. En este resultado, solo se utilizó un cliente para ejecutar las consultas.

      A continuación, descubra las consultas que mysqlslap ejecutó en el último comando mirando stats_mysql_query_digest de ProxySQL. Esto nos dará información, como el* resumen* de las consultas, que es una forma normalizada de la instrucción de SQL a la que se puede hacer referenciad más tarde para habilitar el almacenamiento en caché.

      Ingrese en la interfaz de administración de ProxySQL con este comando:

      • mysql -uadmin -p -h 127.0.0.1 -P6032

      A continuación, ejecute esta consulta para buscar la información en la tabla stats_mysql_query_digest:

      • SELECT count_star,sum_time,hostgroup,digest,digest_text FROM stats_mysql_query_digest ORDER BY sum_time DESC;

      Verá resultados similares al siguiente:

      +------------+----------+-----------+--------------------+----------------------------------+
      | count_star | sum_time | hostgroup | digest             | digest_text                      |
      +------------+----------+-----------+--------------------+----------------------------------+
      | 1          | 598      | 1         | 0xF8F780C47A8D1D82 | SELECT @@HOSTNAME as hostname    |
      | 1          | 0        | 1         | 0x226CD90D52A2BA0B | select @@version_comment limit ? |
      +------------+----------+-----------+--------------------+----------------------------------+
      2 rows in set (0.01 sec)
      

      Con la consulta previa se seleccionan datos de la tabla stats_mysql_query_digest, que contiene información sobre todas las consultas ejecutadas en ProxySQL. A continuación, se muestran cinco columnas seleccionadas:

      • count_star: número de veces que se ejecutó esta consulta.
      • sum_time: tiempo total en milisegundos que tardó esta consulta en ejecutarse.
      • hotsgroup: hostgroup usado para ejecutar la consulta.
      • digest: resumen de la consulta ejecutada.
      • digest_text: la consulta real. En este ejemplo del tutorial, la segunda consulta se parametriza usando signos ? en lugar de parámetros variables. select @@version_comment limit 1 y select @@version_comment limit 2, por lo tanto, se agrupan como la misma consulta con el mismo resumen.

      Ahora que sabe comprobar los datos de la consulta en la tabla stats_mysql_query_digest, cierre el shell de mysql:

      La base de datos que descargó contiene algunas tablas con datos de demostración. Ahora, probará las consultas en la tabla dept_emp seleccionando cualquier registro cuya from_date sea mayor que 2000-04-20 y registrando el tiempo medio de ejecución.

      Utilice este comando para ejecutar la prueba:

      • mysqlslap -usammy -P6033 -p -h127.0.0.1 --concurrency=100 --iterations=20 --create-schema=employees --query="SELECT * from dept_emp WHERE from_date>'2000-04-20'" --verbose

      Aquí usa algunos indicadores nuevos:

      • --concurrency=100: esto establece el número de usuarios que se simulará; en este caso, 100.
      • --iterations=20: esto hace que la prueba se ejecute 20 veces y calcule los resultados de todas ellas.
      • --create-schema=employees: aquí seleccionó la base de datos employees.
      • --query="SELECT * from dept_emp WHERE from_date>'2000-04-20'": aquí especificó la consulta ejecutada en la prueba.

      La prueba tardará unos minutos. Una vez que esta se realice, obtendrá resultados similares a los siguientes:

      Output

      Benchmark Average number of seconds to run all queries: 18.117 seconds Minimum number of seconds to run all queries: 8.726 seconds Maximum number of seconds to run all queries: 22.697 seconds Number of clients running queries: 100 Average number of queries per client: 1

      Sus números podrían ser un poco diferentes. Mantenga estos números en algún lugar para compararlos con los resultados obtenidos tras habilitar el almacenamiento en caché.

      Una vez que pruebe ProxySQL sin almacenamiento en caché, será el momento de ejecutar la misma prueba de nuevo, pero esta vez con el almacenamiento en caché habilitado.

      Paso 4: Probar mysqlslap con almacenamiento en caché

      En este paso, el almacenamiento en caché nos ayudará a disminuir la latencia al ejecutar consultas similares. Aquí identificará las consultas ejecutadas, obtendrá sus resúmenes desde la tabla stats:mysql_query_digest de ProxySQL y los usará para habilitar el almacenamiento en caché. A continuación, hará otra prueba para comprobar la diferencia.

      Para habilitar el almacenamiento en caché, deberá conocer los resúmenes de las consultas que se almacenarán en caché. Inicie sesión en la interfaz de administración de ProxySQL usando este comando:

      • mysql -uadmin -p -h127.0.0.1 -P6032

      A continuación, ejecute esta consulta de nuevo para obtener una lista de las consultas ejecutadas y sus resúmenes:

      • SELECT count_star,sum_time,hostgroup,digest,digest_text FROM stats_mysql_query_digest ORDER BY sum_time DESC;

      Verá un resultado similar a este:

      Output

      +------------+-------------+-----------+--------------------+------------------------------------------+ | count_star | sum_time | hostgroup | digest | digest_text | +------------+-------------+-----------+--------------------+------------------------------------------+ | 2000 | 33727110501 | 1 | 0xC5DDECD7E966A6C4 | SELECT * from dept_emp WHERE from_date>? | | 1 | 601 | 1 | 0xF8F780C47A8D1D82 | SELECT @@HOSTNAME as hostname | | 1 | 0 | 1 | 0x226CD90D52A2BA0B | select @@version_comment limit ? | +------------+-------------+-----------+--------------------+------------------------------------------+ 3 rows in set (0.00 sec)

      Observe la primera fila. Se relaciona con una consulta que se ejecutó 2000 veces. Esta es la consulta que se ejecutó previamente y a la que se hizo referencia. Tome su resumen y guárdelo para usarlo a la hora de añadir una regla de consulta para el almacenamiento en caché.

      Con las siguientes consultas se añadirá una nueva regla de consulta a ProxySQL que coincidirá con el resumen de la consulta anterior y pondrá un valor cache_ttl para ella. cache_ttl es el número de milisegundos durante los cuales el resultado está almacenado en la memoria caché:

      • INSERT INTO mysql_query_rules(active, digest, cache_ttl, apply) VALUES(1,'0xC5DDECD7E966A6C4',2000,1);

      En este comando, añade un nuevo registro a la tabla mysql_query_rules; esta tabla contiene todas las reglas aplicadas antes de ejecutar una consulta. En este ejemplo, agrega un valor para la columna cache_ttl que hará que la consulta conciliada debido al resumen dado se almacene en caché durante un número de milisegundos especificado en esta columna. Usted dispone 1 en la columna apply para garantizar que la regla se aplique a las consultas.

      Aplique LOAD y SAVE a estos cambios, y luego cierre el shell de mysql:

      • LOAD MYSQL QUERY RULES TO RUNTIME;
      • SAVE MYSQL QUERY RULES TO DISK;
      • exit;

      Ahora que el almacenamiento en caché está habilitado, vuelva a ejecutar la prueba de nuevo para comprobar el resultado:

      • mysqlslap -usammy -P6033 -p -h127.0.0.1 --concurrency=100 --iterations=20 --create-schema=employees --query="SELECT * from dept_emp WHERE from_date>'2000-04-20'" --verbose

      Con esto, se mostrará un resultado similar al siguiente:

      Output

      Benchmark Average number of seconds to run all queries: 7.020 seconds Minimum number of seconds to run all queries: 0.274 seconds Maximum number of seconds to run all queries: 23.014 seconds Number of clients running queries: 100 Average number of queries per client: 1

      Aquí puede ver la gran diferencia en el tiempo de ejecución promedio: se redujo de 18.117 a 7.020 segundos.

      Conclusión

      A través de este artículo, configuró un almacenamiento en caché transparente con ProxySQL para almacenar en caché resultados de consultas a la base de datos. También probó la velocidad de las consultas con y sin almacenamiento en caché para ver la diferencia que este puede suponer.

      Durante este tutorial, usó un nivel de almacenamiento en caché. También podría probar el almacenamiento en caché web, que se dispone delante de un servidor web, almacena las respuestas a solicitudes similares y envía la respuesta de vuelta al cliente sin llegar a los servidores de backend. Esto es muy similar al almacenamiento en caché de ProxySQL, pero a un nivel diferente. Para obtener más información sobre el almacenamiento en caché, consulte nuestro artículo introductorio Principios básicos del almacenamiento en caché web: terminología, encabezados HTTP y estrategias de almacenamiento en caché.

      El servidor MySQL también tiene su propia memoria caché de consultas; puede obtener más información sobre ella en el tutorial Cómo optimizar MySQL con memoria caché de consultas en Ubuntu 18.04.



      Source link

      Cómo inspeccionar las redes de Kubernetes


      Introducción

      Kubernetes es un sistema de orquestación de contenedores que puede gestionar aplicaciones en contenedores a través de un clúster de nodos de servidor. Para el mantenimiento de la conectividad de red entre todos los contenedores de un clúster se requieren técnicas avanzadas de red. En este artículo, abordaremos brevemente algunas herramientas y técnicas para inspeccionar esta configuración de red.

      Estas herramientas pueden ser útiles si depura errores de conectividad, investiga problemas de rendimiento de la red o explora Kubernetes para aprender cómo funciona.

      Si desea conocer más sobre Kubernetes en general, en nuestra guía Introducción a Kubernetes se abarcan los aspectos básicos. Para acceder a una descripción general específica de Kubernetes, lea Análisis exhaustivo de las redes de Kubernetes.

      Primeros pasos

      Para este tutorial se espera que tenga un clúster de Kubernetes, con kubectl instalado localmente y configurado para conectarse al clúster.

      Las siguientes secciones contienen muchos comandos pensados para ejecutarse en un nodo de Kubernetes. Tendrán el siguiente aspecto:

      • echo 'this is a node command'

      Los comandos que deben ejecutarse en su máquina local tendrán el siguiente aspecto:

      • echo 'this is a local command'

      Nota: La mayoría de los comandos de este tutorial deberán ejecutarse a través del usuario root. Si en su lugar utiliza un usuario habilitado para sudo en sus nodos de Kubernetes, añada sudo para ejecutar los comandos cuando sea necesario.

      Encontrar el IP del clúster de un pod

      Para encontrar la dirección IP del clúster de un pod de Kubernetes, utilice el comando kubectl get pod en su máquina local, con la opción -o wide. Esta opción mostrará más información, incluido el nodo en el que reside el pod y ek IP del clúster del pod.

      Output

      NAME READY STATUS RESTARTS AGE IP NODE hello-world-5b446dd74b-7c7pk 1/1 Running 0 22m 10.244.18.4 node-one hello-world-5b446dd74b-pxtzt 1/1 Running 0 22m 10.244.3.4 node-two

      La columna IP contendrá la dirección IP del clúster interno de cada pod.

      Si no ve el pod que busca, asegúrese de estar posicionado en el espacio de nombres correcto. Puede listar todos los pods en todos los espacios de nombres añadiendo el indicador --all-namespaces.

      Encontrar el IP de un servicio

      También se puede encontrar un IP de servicio con kubectl. En este caso listaremos todos los servicios en todos los espacios de nombres:

      • kubectl get service --all-namespaces

      Output

      NAMESPACE NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE default kubernetes ClusterIP 10.32.0.1 <none> 443/TCP 6d kube-system csi-attacher-doplugin ClusterIP 10.32.159.128 <none> 12345/TCP 6d kube-system csi-provisioner-doplugin ClusterIP 10.32.61.61 <none> 12345/TCP 6d kube-system kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 6d kube-system kubernetes-dashboard ClusterIP 10.32.226.209 <none> 443/TCP 6d

      El IP del servicio se encuentra en la columna CLUSTER-IP.

      Buscar e ingresar espacios de nombres de red de pods

      A cada pod de Kubernetes se le asigna su propio espacio de nombres de red. Los espacios de nombres de red (o netns) son una primitiva red de Linux que proporciona aislamiento entre dispositivos de red.

      Puede ser útil ejecutar comandos desde dentro de los netns de un pod, para comprobar la resolución de DNS o la conectividad general de la red. Para ello, primero tenemos que buscar el ID de proceso de uno de los contenedores de un pod. En el caso de Docker, podemos hacerlo con una serie de dos comandos. Primero, listar los contenedores que se ejecutan en un nodo:

      Output

      CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 173ee46a3926 gcr.io/google-samples/node-hello "/bin/sh -c 'node se…" 9 days ago Up 9 days k8s_hello-world_hello-world-5b446dd74b-pxtzt_default_386a9073-7e35-11e8-8a3d-bae97d2c1afd_0 11ad51cb72df k8s.gcr.io/pause-amd64:3.1 "/pause" 9 days ago Up 9 days k8s_POD_hello-world-5b446dd74b-pxtzt_default_386a9073-7e35-11e8-8a3d-bae97d2c1afd_0 . . .

      Encuentre el ID de contenedor *o *nombre de cualquier contenedor en el pod que le interese. En la imagen anterior, mostramos dos contenedores:

      • El primer contenedor es la aplicación hello-world que se ejecuta en el pod hello-world.
      • El segundo es un contenedor de pausa que funciona en el pod hello-world. Este contenedor existe únicamente para preservar el espacio de nombres de red del pod.

      Para obtener el ID de proceso de cualquiera de los contenedores, tome nota del ID o nombre del contenedor y utilícelo en el siguiente comando docker.

      • docker inspect --format '{{ .State.Pid }}' container-id-or-name

      Output

      14552

      Se emitirá un ID de proceso (o PID). Ahora podemos utilizar el programa nsenter para ejecutar un comando en el espacio de nombres de red de ese proceso:

      • nsenter -t your-container-pid -n ip addr

      Asegúrese de utilizar su propio PID, y reemplace ip addr por el comando que le gustaría ejecutar dentro del espacio de nombres de red del pod.

      Nota: Una ventaja de utilizar nsenter para ejecutar comandos en el espacio de nombres de un pod (frente al uso de una opción como docker exec) es que se puede acceder a todos los comandos disponibles en el nodo, en lugar del conjunto normalmente limitado de comandos instalados en contenedores.

      Encontrar la interfaz Ethernet virtual de un pod

      El espacio de nombres de red de cada pod se comunica con netns root del nodo a través de un conducto Ethernet virtual. Del lado del nodo, este conducto aparece como un dispositivo que normalmente comienza con veth y termina en un identificador único, como veth77f2275 o veth01. Dentro del pod, este conducto aparece como eth0.

      Puede ser útil para correlacionar el dispositivo veth que se empareja con un pod determinado. Para ello, listaremos todos los dispositivos de red del nodo y luego los dispositivos del espacio de nombres de red del pod. A continuación, podremos correlacionar los números de dispositivo entre los dos listados para realizar la conexión.

      Primero, ejecute ip addr en el espacio de nombres de red del pod con nsenter. Consulte la sección anterior Buscar e ingresar espacios de nombres de red de pods para obtener información sobre cómo hacer esto:

      • nsenter -t your-container-pid -n ip addr

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 10: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default link/ether 02:42:0a:f4:03:04 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.244.3.4/24 brd 10.244.3.255 scope global eth0 valid_lft forever preferred_lft forever

      El comando emitirá una lista de las interfaces del pod. Observe el número if11 después de eth0@ en la imagen de ejemplo. Esto significa que el eth0 de este pod está vinculado a la interfaz 11 del nodo. Ahora ejecute ip addr en el espacio de nombres predeterminado del nodo para listar sus interfaces:

      Output

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever . . . 7: veth77f2275@if6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether 26:05:99:58:0d:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::2405:99ff:fe58:db9/64 scope link valid_lft forever preferred_lft forever 9: vethd36cef3@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether ae:05:21:a2:9a:2b brd ff:ff:ff:ff:ff:ff link-netnsid 1 inet6 fe80::ac05:21ff:fea2:9a2b/64 scope link valid_lft forever preferred_lft forever 11: veth4f7342d@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master docker0 state UP group default link/ether e6:4d:7b:6f:56:4c brd ff:ff:ff:ff:ff:ff link-netnsid 2 inet6 fe80::e44d:7bff:fe6f:564c/64 scope link valid_lft forever preferred_lft forever

      La interfaz 11 es veth4f7342d en esta imagen de ejemplo. Este es el conducto Ethernet virtual al pod que investigaremos.

      Inspeccionar el seguimiento de la conexión del conntrack

      Antes de la versión 1.11, en Kubernetes se utilizaban iptables NAT y el módulo kernel del conntrack para controlar las conexiones. Para listar todas las conexiones actualmente controladas, utilice el comando conntrack:

      Para buscar continuamente nuevas conexiones, utilice el indicador -E:

      Para listar las conexiones controladas por conntrack a una dirección de destino concreta, utilice el indicador -d:

      • conntrack -L -d 10.32.0.1

      Si sus nodos tienen problemas para establecer conexiones fiables con los servicios, es posible que la tabla de seguimiento de conexiones esté llena y que se inhabiliten las nuevas conexiones. En este caso, es posible que vea mensajes como los siguientes en sus registros de sistema:

      /var/log/syslog

      Jul 12 15:32:11 worker-528 kernel: nf_conntrack: table full, dropping packet.
      

      Existe una configuración de sysctl para el número máximo de conexiones que se controlarán. Puede hacer una lista de su valor actual con el siguiente comando:

      • sysctl net.netfilter.nf_conntrack_max

      Output

      net.netfilter.nf_conntrack_max = 131072

      Para establecer un nuevo valor, utilice el indicador -w:

      • sysctl -w net.netfilter.nf_conntrack_max=198000

      Para que este ajuste sea permanente, agréguelo al archivo sysctl.conf:

      /etc/sysctl.conf

      . . .
      net.ipv4.netfilter.ip_conntrack_max = 198000
      

      Inspeccionar reglas de iptables

      Antes de la versión 1.11, Kubernetes utilizaba iptables NAT para implementar la conversión de IP virtuales y el balanceo de carga para los IP de servicios.

      Para volcar todas las reglas de iptables en un nodo, utilice el comando iptables-save:

      Dado que el resultado puede ser muy extenso, es posible que desee realizar una transferencia a un archivo (iptables-save > output.txt) o a un localizador (iptables-save | less) para revisar más fácilmente las reglas.

      Para listar solo las reglas de NAT del servicio de Kubernetes, utilice el comando iptables y el indicador -L a fin de especificar la cadena correcta:

      • iptables -t nat -L KUBE-SERVICES

      Output

      Chain KUBE-SERVICES (2 references) target prot opt source destination KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns cluster IP */ udp dpt:domain KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 10.32.0.10 /* kube-system/kube-dns:dns-tcp cluster IP */ tcp dpt:domain KUBE-SVC-XGLOHA7QRQ3V22RZ tcp -- anywhere 10.32.226.209 /* kube-system/kubernetes-dashboard: cluster IP */ tcp dpt:https . . .

      Consultas al DNS del clúster

      Una forma de depurar la resolución del DNS de su clúster es implementar un contenedor de depuración con todas las herramientas que necesite y utilizar kubectl para ejecutar nslookup en él. Esto se describe en la documentación oficial de Kubernetes.

      Otra forma de consultar el clúster DNS es utilizar dig y nsenter de un nodo. Si dig no está instalado, puede instalarse con apt en las distribuciones de Linux basadas en Debian:

      Primero, busque el IP del clúster del servicio kube-dns:

      • kubectl get service -n kube-system kube-dns

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kube-dns ClusterIP 10.32.0.10 <none> 53/UDP,53/TCP 15d

      El IP del clúster se resalta arriba. A continuación, utilizaremos nsenter para ejecutar dig en el espacio de nombres de un contenedor. Consulte la sección Encontrar e ingresar espacios de nombres de red de pod para obtener más información al respecto:

      • nsenter -t 14346 -n dig kubernetes.default.svc.cluster.local @10.32.0.10

      Este comando dig busca el nombre de dominio completo del servicio de service-name.namespace.svc.cluster.local y especifica el IP de servicio del DNS del clúster (@10.32.0.10) .

      Revisión de la información de IPVS

      A partir de la versión 1.11, kube-proxy puede configurar IPVS para gestionar la conversión de los IP de servicios virtuales a IP de pod. Puede listar la tabla de conversión de IP con ipvsadm:

      Output

      IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 100.64.0.1:443 rr -> 178.128.226.86:443 Masq 1 0 0 TCP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0 UDP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0

      Para mostrar un solo IP de servicio, utilice la opción -t y especifique el IP deseado:

      • ipvsadm -Ln -t 100.64.0.10:53

      Output

      Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 100.64.0.10:53 rr -> 100.96.1.3:53 Masq 1 0 0 -> 100.96.1.4:53 Masq 1 0 0

      Conclusión

      A lo largo de este artículo, revisamos comandos y técnicas para explorar e inspeccionar los detalles de la red de su clúster de Kubernetes. Para obtener más información sobre Kubernetes, consulte el tema de nuestros tutoriales de Kubernetes y la documentación oficial de Kubernetes.



      Source link