GaGa

docker依赖技术

Docker是一种开源的容器化平台，用于构建、打包、分发和运行应用,它依赖于一系列技术来实现容器化和虚拟化，主要包括以下几种关键技术：

1. Linux 容器 (LXC)

• 早期的 Docker 主要依赖于 LXC 技术来提供容器化环境。LXC 是一个操作系统级别的虚拟化技术，可以让多个隔离的 Linux 系统共享同一个操作系统内核。Docker 在这个基础上进一步发展，提供了更简便的接口和更轻量的容器化体验。

日常中遇到elk中性能问题

• 1.遇到过logstash写es提示429写尝试拒绝

  • 1.后台es写压力大可以提升es thread_pool.write.queue_size/size大写（缓解）
  • 2.es存储使用ssd，建议冷热分离，扩增数据存储节点(治本)

• 2.新增索引提示403（indice ready only）

  • 1.临时关闭写保护，清理历史索引释放空间
  • 2.调整es磁盘写保护阀值
    • cluster.routing.allocation.disk.watermark.low，默认85%，用于控制磁盘的最小使用率；
  • cluster.routing.allocation.disk.watermark.high，默认90%，用于控制磁盘的最大使用率；
  • cluster.routing.allocation.disk.watermark.flood_stage，默认95%超过此值时，Elasticsearch变成只读模式，无法写入数据

• 3.logstash解析压力过大导致机器负载飙升，日志存在很大时延

  • 1.kafka日志扩大分区，扩充logstash服务
  • 2.改用gohangout解析，显著降低cpu/loadavg

• 4.提高可用性、增加redis/kafka作为日志缓冲组件

• 5.elasticsearch查询缓慢

  • 合理设置分片，冷热区分，jvm堆内存预留50%，设置合理查询条件(防止全文查询)

• 6.kibana查询崩溃

  • 设置nodejs内存(–max-old-space-size=4096)

k8s pod访问方式

• podid
• kube-proxy
• clusterip
• nodeport
• ingress
• loadbalance
• hostnetwork
• externalname //内 -> 外

在 Kubernetes (k8s) 中，Pod是运行在集群中的最小部署单元，可以采用以下几种主要方式来访问 Pod：

kube-proxy

Kubernetes中的kube-proxy是一个关键的网络组件，负责实现集群内部的服务发现和负载均衡。

kube-proxy 出现问题或停止工作影响如下

• 1.服务发现中断：

  • kube-proxy 负责监听 Kubernetes API Server 中 service 和 endpoint 的变化情况，并通过代理的方式为服务配置负载均衡。如果 kube-proxy 停止工作，集群中的服务发现机制将无法正常运作，新的服务变化将无法被正确地传播和应用。

• 2.负载均衡失效：

  • kube-proxy 通过为每个 Service 创建虚拟 IP 地址（VIP）和相应的网络代理规则，实现请求的负载均衡。如果 kube-proxy 出现问题，这些负载均衡规则将无法更新，导致流量无法正确地分发到后端的 Pod 上。

• 3.Pod间通信受阻：

  • 在 Kubernetes 集群中，Pod 之间可以通过 Service 进行通信。如果 kube-proxy 故障，Pod 将无法通过 Service 访问其他 Pod 提供的服务，这将直接影响到依赖这些服务的应用程序的正常运行。

• 4.外部访问受限：

  • 对于设置了NodePort的Service，kube-proxy 负责将从 NodePort 进入的请求转发到后端 Pod。如果 kube-proxy 出现问题，外部通过 NodePort 的访问请求将无法被正确转发，导致外部服务访问受限。

• 5.性能下降：

  • kube-proxy 通过 iptables 或 ipvs 等机制来实现高效的网络流量转发。如果 kube-proxy 故障，可能会导致网络流量无法被高效处理，从而影响整个集群的性能。

登陆系统后，环境变量加载顺序

• 登陆shell:（SSH或在控制台登录）需要输入账户密码

  • /etc/profile -> /etc/profile.d/*.sh -> /etc/bashrc -> ~/.bashrc -> ~/.bash_profile

• 非登陆shell:(不需要输入账户密码)

  • ~/.bashrc -> /etc/bashrc -> /etc/profile.d/*.sh

验证可以通过每个文件新增echo输出，su - xxx / su xxx

• 1.系统日志(自检、启动、服务、授权、内核)

  • /var/log/message

    • 事件日志

  • /var/log/auth.log

  • /var/log/secure

    • 登陆、认证授权日志

  • /var/log/dmesg

    • 启动硬件诊断、驱动日志

  • /var/log/kern.log

    • 记录内核日志，比dmesg日志更加全面

  • /var/log/cron

    • 执行计划日志

  • /var/log/btmp

    • 失败登陆尝试日志

  • /var/log/wtmp

    • 注销事件日志

  • /var/log/journal

    • systemd管理服务日志

• 2.应用日志（一般都是有日志输出定义）

  • 运行日志
  • 错误日志
  • 访问日志
  • 埋点日志

• 3.crash 崩溃日志

  • /var/crash/xxx kernel崩溃日志
  • ～/core application崩溃日志
  • ～/hs_err_pid.log jvm崩溃日志

centos启动过程

• 1.硬件初始化

  • 电源开机后主板自检

• 2.bios、uefi引导

  • 硬盘mbr/esp引导加载程序

• 3.加载grub/grub2程序

  • 引导用户内核选择等

• 4.内核初始化

  • initramfs/加载模块及驱动程序

• 5.systemd初始化

  • systemdz作为超级父进程pid=1，负责管理协调整个系统服务
  • 解析/etc/systemd/system/xxx目标单元及依赖启动

• 6.运行mingetty进程(图形化登陆界面)

目的

新建基于GTID从节点，先从master上备份历史数据过来，导入到从节点，在定义从节点复制开始位置。

对于比较大的库，建议用冷备份 + 自定义复制起点。

env

MySQL 的 GTID（Global Transaction Identifier，全局事务标识符）复制机制是 MySQL 5.6 及以上版本引入的一种高级复制功能，旨在简化主从复制的管理，提高数据一致性和故障恢复的可靠性。相比传统的基于二进制日志位置（binlog position）的复制方式，GTID 复制通过为每个事务分配一个全局唯一标识符，极大地方便了复制的配置和维护。

GTID 复制的基本原理

GTID 是一个全局唯一的事务 ID，由两部分组成：

• 服务器 UUID：每个 MySQL 实例有一个唯一的标识符，通常在服务器启动时生成，存储在 auto.cnf 文件中。
• 事务序列号：一个递增的数字，表示该服务器上的事务顺序。

在 MySQL 中配置 GTID（全局事务标识符，Global Transaction Identifier）以支持主从切换和故障转移是一个常见的高可用性需求。

1. 什么是 GTID？

GTID 是一个全局唯一的事务标识符，用于标记每个事务。它在主从复制中简化了故障转移，因为从库可以根据 GTID 自动定位到主库的事务位置，避免了传统基于二进制日志文件和位置（binlog file + position）的手动定位。（1.简化定位主库binlog-file pos 2.第一次建立自动同步主库所有数据？如果主库binlog刷新了会同步吗？待确认）

位图和矢量图是两种常见的数字图像格式，它们在生成方式、用途和特性上有很大不同。

位图（Bitmap）

位图，也叫光栅图，是由像素（小方格）组成的图像。每个像素都有特定的颜色值，组合起来形成完整的画面。

在 Kubernetes 中，Pod 是最小的部署单位，是容器的封装，可以包含一个或多个容器。Pod 的创建过程涉及多个步骤。

1. 用户发起 Pod 创建请求

用户可以通过 kubectl 命令行工具、Kubernetes API 或者 YAML 配置文件来创建 Pod。最常见的方式是通过定义一个 YAML 文件来描述 Pod 的配置。