Cylon's Collection

Moto G75解锁和国际版rom安装步骤

Tue, 25 Nov 2025 00:00:00 +0000

前言 motorola 和 one plus 应该是目前中国大陆的手机品牌最容易解锁的一款了，其他的都已经被招安内置审查app了。 G75 版本更新策略，找到有两种一个是 5 个系统版本更新，6个安全更新 Thank you for taking the time to reach out to us. I understand how important updates are to everyone. The device is planned to receive 5 OS upgrades and 6 years of bimonthly security updates from the time of release. [1] 一个是 3 个系统大版本号，6个安全更新 Thanks for reaching out! The Motorola G75 is confirmed to receive 3 major Android updates along with 6 years of security patches.

利用github构建个人yum仓库

Mon, 30 Jun 2025 00:00:00 +0000

为什么选择 GitHub 作为 YUM 仓库？免费托管：GitHub 提供免费的文件存储和 HTTP 服务。 CDN：结合 jsDelivr 等 CDN 服务，可以加速用户的访问速度。无成本：无需自己搭建服务器，降低维护成本。使用便利：可以一条命令完成安装，无需再上传安装包了，也可以用来制作下线版本的 yum 仓库。基本思路 YUM 仓库的核心是文件索引（repodata）和 HTTP 服务。GitHub 提供静态文件托管和 HTTP 访问支持，可以作为 YUM 仓库的存储平台。此外，可以通过 CDN 服务（如 jsDelivr）加速访问（可选）。存储：将 RPM 包和仓库索引文件存储在 GitHub 仓库中。访问：通过 GitHub 的 raw 文件访问路径或 jsDelivr 提供 HTTP 服务。生成索引：使用 createrepo 工具生成 YUM 仓库的元数据（repodata）。步骤 1：生成 repodata 安装 createrepo 工具确保已安装 createrepo 工具，用于生成 YUM 仓库的元数据。 bash 1 sudo yum install createrepo -y 创建目录结构为不同发行版（这里为 CentOS 7 和 Rocky 9）创建对应的目录结构：

记录一次服务器断电引起的etcd无法启动问题处理

Fri, 27 Jun 2025 00:00:00 +0000

背景在一次物理机断电回复后，Kubernetes 集群因断电或其他原因导致 etcd 启动时出现 “panic: lease ID must be 8-byte” 错误。本文记录如何诊断和修复 etcd 数据损坏，并恢复 Kubernetes 集群的过程。问题描述在尝试启动 etcd 服务时，日志显示以下错误： bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 {"level":"warn","ts":"2025-06-26T08:46:12.

CoreDNS 开发系列-4：高并发域名平台架构设计

Sun, 15 Jun 2025 00:00:00 +0000

本文是CoreDNS 开发系列第4章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计在本章节中将创建一个项目，旨在构建一个基于 CoreDNS 的域名系统，该项目目的是可以构建一个完整的 DNS 平台而不是管理平台，可以作为独立的 DNS Provider 运行业务域名解析；也可以作为企业内部 DNS的使用。分层架构设计系统采用四层架构设计：视图层：也称为 API 层，负责提供 DNS 的管理后台， API 接口。业务层：主要作为 CoreDNS Plugins 实现，用于集成 DNS Server。数据层：视图层与业务层的联动，多数据库支持（SQLite/MySQL/PostgreSQL）、Redis 缓存、数据同步。基础设施层：提供 command line 工具，并为 DNS Server 提供四层防火墙、监控告警数据。并提供整个公司生态的服务注册、服务发现等功能。系统功能需求功能模块详细描述优先级 View 支持多视图配置，智能解析高 Zone 管理 DNS 区域管理与配置高域名管理管理域中的域名解析高 Transfer 与云 DNS 供应商数据同步高白名单域名解析黑白名单控制，包含全局和单域名高证书管理 Let’s Encrypt 证书自动申请与续期高解析切换提供多解析功能，实现故障切换高域名检测域名可用性检测，可以配合切换功能完成故障自动切换高 CDN 集成 CDN 切换与管理功能中运维工具提供命令行工具中 GeoIP 基于地理位置的智能 DNS 解析低外部系统注册服务自动注册与发现低性能需求性能指标目标值备注 QPS 100,000 一个 view 内的集群至少达到的值项目分模块设计视图层模块名称功能描述域、域名管理完成基础 Zone, Domain的管理功能证书管理 Let’s Encrypt 证书自动申请与续期 View管理管理域与业务层插件进行联动白名单管理域名解析黑白名单控制 Geo 管理基于地理位置的智能 DNS 解析 CDN 集成集成CDN联动功能服务注册插件提供全企业内的服务注册功能（View+业务）业务层模块名称功能描述实现方式 DNS 服务 DNS 查询处理、插件加载管理原生 coredns 数据库 Zone, Domain 信息入库，通过库 Custom Plugin Redis 缓存插件 Zone, Domain 的热点缓存功能 Custom Plugin GeoIP 插件基于地理位置的智能解析 Custom Plugin View View 的管理和配置 Custom Plugin 白名单域名访问控制 Custom Plugin Transfer 区域传送与同步 Custom Plugin 基础设施层模块名称功能描述实现技术服务发现服务注册与发现 Nacos DNS查询流程设计多级缓存策略

CoreDNS 开发系列-3：开发自定义插件

Fri, 13 Jun 2025 00:00:00 +0000

本文是CoreDNS 开发系列第3章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计在上一篇文章中，我们了解了 CoreDNS 的基本概念、安装和配置文件的说明，与 CoreDNS 中的插件，本文将从零开始，深入学习 CoreDNS 插件开发的完整流程，让您能够开发出满足特定业务需求的高质量插件。在最后我们学习一下 CoreDNS 中的外部插件用以引入开发思路，来解决我们平台中的一些难点。代码构成在学习开发插件之前，我们先需要了解下 CoreDNS 的代码目录构成。 text 1 2 3 4 5 6 7 8 9 10 11 coredns/ ├── core/ # 核心组件 │ ├── dnsserver/ # DNS 服务器实现 │ └── plugin/ # 插件管理框架 ├── plugin/ # 内置插件目录 │ ├── cache/ # 缓存插件 │ ├── forward/ # 转发插件 │ ├── kubernetes/ # Kubernetes插件 │ └── .

解决AWS EKS error You must be logged in to the server (Unauthorized)

Sat, 07 Jun 2025 00:00:00 +0000

问题描述当获取了 EKS kubeconfig 后，使用该 kubeconfig 提示如下报错 bash 1 2 $ kubectl get pod --kubeconfig kubeconfig error: You must be logged in to the server (Unauthorized) 但该 IAM 用户已经存在了管理员权限了问题原因该文章有对这个问题进行描述 quote 您不是集群创建者如果您的 IAM 实体未用于创建集群，说明您不是集群创建者。在这种情况下，请完成以下步骤，将您的 IAM 实体映射到 aws-auth ConfigMap 以允许访问集群 [1] 这里检查和文章描述一致, 但还是这样的问题 bash 1 2 3 4 5 6 $ aws sts get-caller-identity { "UserId": "AIDAXxxxxxxxIIWKMR22Q", "Account": "55555555496", "Arn": "arn:aws:iam::55555555496:user/eks-user" } quote 这是因为，必须将该用户作为集群的 Access 进行关联，而不是授权 “EKS*” 相关权限图 - 集群用户选择已经存在的 IAM 用户

解决openvpn与其他vpn路由冲突问题

Sat, 07 Jun 2025 00:00:00 +0000

需求分析 openvpn在调研时不支持分流配置，需求是openvpn的开启不要影响现有的网络环境。在经过调研，发现 openvpn配置文件可以使用一些指令来指定访问某些地址的路由经过openvpn的设备，这样就可以实现了流量分流。配置指令说明这里主要用到了下面的参数指令说明 dhcp-option 添加额外的网络参数，可以是在客户端配置，或者服务端推送，这里有指定 DNS redirect-gateway def1 使用这个 def1 flag 可以使用0.0.0.0/1 and 128.0.0.0/1 来覆盖默认路由，这里的好处是不会擦除原有的默认网关 route 可以在建立连接后，自动添加一些路由，并且在TUN/TAP设备关闭后，自动销毁 gateway 默认来自第二参数或者默认网关，第二参数为 vpn_gateway 指远端的vpn地址 net_gateway 指 per-existing IP默认网关 route-nopull 当在客户端使用时，此选项有效禁止从Server将路由添加到客户端的路由表中，但是请注意，此选项仍然允许 Server 设置TCP/IP 客户端TUN/TAP接口的属性（这里主要用作创建openvpn自己的网络接口）。 pull-filter 忽略server端push 的资源，这些选项就是来自 —pul 或者其他选项的，例如其他选项 dhcp-option/route/gateway 等。最终的配置为 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 client proto udp explicit-exit-notify remote x.

jenkins pipeline关联aws access key

Fri, 06 Jun 2025 00:00:00 +0000

插件说明 Jenkins 有一个 aws credentials 插件，可以关联到 pipeline 中使用 https://plugins.jenkins.io/aws-credentials/ 官方也有给出示例，如何使用 pipeline 关联 ecr text 1 2 3 withCredentials([[ $class: 'AmazonWebServicesCredentialsBinding', credentialsId: 'plt-ia-dev-images-ecr-use1-read', roleArn: 'arn:aws:iam::130312249203:role/PullDockerImages', roleSessionName: 'PullDockerImages']]){ sh "aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin ecr_registry } 配置过程创建一个 iam 用户，用于 jenkins 获取 ecr token使用图 - IAM User 图创建用户 - 创建ecr-user note 不要选择 “Provide user access to the AWS Management Console - optional ” 权限可以选择 “AmazonEC2ContainerRegistryFullAccess”，也可根据自己需求进行选择

CoreDNS 开发系列-2：CoreDNS插件详解

Wed, 04 Jun 2025 00:00:00 +0000

本文是CoreDNS 开发系列第2章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计在上一篇文章中，我们了解了 CoreDNS 的基本概念、安装和配置文件的说明。在本文将深入探讨 CoreDNS 的插件 (Plugins)，这是 CoreDNS 强大功能的核心所在。通过理解插件机制和核心插件的工作原理，我们将为后续开发自定义插件和构建 DNS 平台奠定坚实基础。插件系统设计理念通常情况下，CoreDNS Plugins在设计上围绕下面的原则进行的单一职责：每个插件只负责自己负责的功能链式处理：插件按配置顺序执行链处理请求可插拔性：插件可以灵活组合和替换扩展性：支持用户自定义插件开发插件来扩展功能基于这些原则，使得 CoreDNS 非常强大，非常易于扩展性（对比与最流行的两款开源 DNS 产品来说，Bind, PowerDNS）。 CoreDNS与主流DNS服务产品的对比下表是调研了三款最流行的 DNS 开源产品来对最符合本项目的后端作为对比，CoreDNS的灵活性相对比较适宜特性 CoreDNS BIND9 PowerDNS 类型权威/递归权威/递归权威/递归 AXFR/IXFR 支持支持, trasfer 插件支持支持 view 支持（geo, view插件）原生支持（view 指令）支持（仅仅LMDB后端）数据库支持支持（通过自定义插件 mysql, redis）有限 DLZ模块 (Dynamically Loadable Zones) [1] 原生有限支持 [2] DNSSEC 支持（NSEC）全面支持（NSEC/NSEC3）全面支持（NSEC/NSEC3）扩展性极佳（插件架构）有限扩展，支持c语言库作为plugins 良好易用性高（简单配置，现代化）中（配置复杂，需经验）高（Web 界面、API）社区与生态活跃（CNCF 项目，Kubernetes 生态）非常活跃（ISC 维护）活跃（商业支持）与本项目需求契合度极高（插件化支持View, AXFR/IXFR, GEO）高（原生支持VIEW, AXFR/IXFR）高（数据库支持强，API 同步简单） CoreDNS插件的类型 CoreDNS插件分为两种类型插件，“In-tree Plugins” [3] 和 “External Plugins” [4]；“In-tree Plugins” 是 CoreDNS 官方在提供 coredns 二进制文件时就内置编译到程序内的插件，用户可以自己去配置使用这些插件；“External Plugins” 是包含 CoreDNS 官方与三方作者维护的插件，用户如果想使用的话，需要自行编译 coredns 版本使用。

CVE-2024-6387漏洞修复(Rocky9)

Mon, 02 Jun 2025 00:00:00 +0000

下载 openssh-9.9p 源码包下载地址下载之后解压看 README 和 INSTALL text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 libcrypto from either of LibreSSL or OpenSSL. Building without libcrypto is supported but severely restricts the available ciphers and algorithms. - LibreSSL (https://www.libressl.org/) 3.1.0 or greater - OpenSSL (https://www.openssl.org) 1.1.1 or greater LibreSSL/OpenSSL should be compiled as a position-independent library (i.e. -fPIC, eg by configuring OpenSSL as ".

CoreDNS开发系列-1：CoreDNS核心概念和安装配置说明

Tue, 20 May 2025 00:00:00 +0000

本文是CoreDNS 开发系列第1章 CoreDNS 开发系列-1：CoreDNS核心概念和安装配置说明 CoreDNS 开发系列-2：CoreDNS插件详解 CoreDNS 开发系列-3：开发自定义插件 CoreDNS 开发系列-4：高并发域名平台架构设计 CoreDNS 概述什么是CoreDNS CoreDNS 是一个由 Go 编写的灵活、可扩展的 DNS 服务器。他非常灵活，几乎全部功能都由 plugin 来实现，CoreDNS 官网也有说 “CoreDNS is powered by plugins.” 。Plugins 能够作为 “独立” 或和 CoreDNS “共同” 来执行 “DNS Function” 在 CoreDNS 中被设计为是一个由 “软件实现的 CoreDNS Plugin API”，例如 Kubernetes Provider 可以提供在 k8s 集群里的服务发现。再例如 file 可以提供作为一个 DB 来使用。 CoreDNS 的设计与与 Caddy 一样也是通过 “插件” 进行扩展，并原生支持 Prometheus 也是 CoreDNS 的一大优势，这意味着我们可以将其连接到现有的 Prometheus 基础架构中进行监控、警报和仪表板管理。 CoreDNS 核心架构 Server：负责监听 DNS 查询请求 Plugins Chain：按照配置顺序串联起来的插件序列 Handler：每个插件实现的请求处理器 Middleware：在请求处理过程中的中间件 DNS 请求在 CoreDNS 中的处理流程如下：

Amazon ECR自动创建不存在的存储库

Fri, 02 May 2025 00:00:00 +0000

Amazon ECR 目前不支持镜像存储库的自动创建。当开发人员向 Amazon ECR 推送一个新进项，如果与其对应的存储库不存在，推送就会失败。Amazon ECR 相比起其他公有云，他的镜像是必须要求 dockerhub.io/test/nginx:version, 这里 nginx 才会被是为一个镜像存储库，而 GCP 的 Artifact registry 是 test (Project )才会被视为一个镜像存储库。这样对于存储仓库就不需要额外创建了。下文阐述 Amazon ECR创建仓库的方法方法1：awscli awscli 中有 create-repository 子命令，允许用户创建一个仓库 bash 1 aws ecr create-repository --repository-name ${REPO_NAME} 可以使用脚本来检测仓库是否存在 [1] bash 1 2 3 4 5 6 7 8 9 output=$(aws ecr describe-repositories --repository-names ${REPO_NAME} 2>&1) if [ $? -ne 0 ]; then if echo ${output} | grep -q RepositoryNotFoundException; then aws ecr create-repository --repository-name ${REPO_NAME} else >&2 echo ${output} fi fi 或 [1]

创建一个aws ecr自动刷新密钥的sidecar

Fri, 02 May 2025 00:00:00 +0000

创建 Dockerfile, 因为需要 aws 命令，就不特别去安装了，直接使用 awslinux 的镜像 docker 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 FROM amazonlinux:2 RUN yum update -y && \ yum install -y awscli jq && \ yum clean all WORKDIR /app COPY refresh-ecr-credentials.sh ENV AWS_REGION=${AWS_REGION:-us-east-1} ENV REFRESH_INTERVAL=${REFRESH_INTERVAL:-3600} ENV CREDENTIALS_DIR=${CREDENTIALS_DIR:-/shared_credentials} ENV AWS_CREDENTIALS_FILE=${AWS_CREDENTIALS_FILE:-/opt/password} RUN mkdir -p ${CREDENTIALS_DIR} ~/.aws /opt && \ chmod 700 ${CREDENTIALS_DIR} ~/.aws /opt && \ chmod +x /app/refresh-ecr-credentials.

Demo - Pod终止的生命周期

Tue, 29 Apr 2025 00:00:00 +0000

原理通常 Pod 体面终止的过程为：kubelet 先发送一个带有体面超时限期的 TERM（又名 SIGTERM，根据参数terminationGracePeriodSeconds来决定）信号到每个容器中的主进程，将请求发送到容器运行时来尝试停止 Pod 中的容器。停止容器的这些请求由容器运行时以异步方式处理。这些请求的处理顺序无法被保证。许多容器运行时遵循容器镜像内定义的 STOPSIGNAL 值，如果不同，则发送容器镜像中配置的 STOPSIGNAL，而不是 TERM 信号。一旦超出了体面终止限期，容器运行时会向所有剩余进程发送 KILL 信号，之后 Pod 就会被从 API 服务器上移除。如果 kubelet 或者容器运行时的管理服务在等待进程终止期间被重启，集群会从头开始重试，赋予 Pod 完整的体面终止限期。通常终止流程按照下面约束进行：如果 Pod 中的容器之一定义了 preStop 回调且 Pod 规约中的 terminationGracePeriodSeconds 未设为 0， kubelet 开始在容器内运行该回调逻辑。默认的 terminationGracePeriodSeconds 设置为 30 秒. 如果 Pod 未定义 preStop 回调，根据默认的 terminationGracePeriodSeconds 设置为 30 秒。进行 kill -9（无论terminationGracePeriodSeconds 有没有配置）如果 preStop 回调在体面期结束后仍在运行，kubelet 将请求短暂的、一次性的体面期延长 2 秒。即 30 + 2 s 后删除Pod。

🙋🏻‍♂️关于

Sat, 26 Apr 2025 22:23:25 +0800

Hi, I am Cylon I am a programmer. At the same time, I work full time is Kubernetes Engineer, If I were to express my occupation about this sector with three words, it would be engineering, research and practicality. I liked Linux, Network and Programming. In a free time, I generally study programming language and network technology 🙂 about me Event logs about me 2015 Graduated from HBU. 2016 PHP Programmer.

物理机断电导致osd故障排查记录

Wed, 16 Apr 2025 00:00:00 +0000

ceph版本 nautilus 处理过程查看 ceph 集群状态 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ceph -s cluster: id: baf87797-3ec1-4f2c-8126-bf0a44051b13 health: HEALTH_WARN 3 osds down 1 host (3 osds) down 1 pools have many more objects per pg than average Degraded data redundancy: 1167403/4841062 objects degraded (24.115%), 391 pgs degraded, 412 pgs undersized services: mon: 3 daemons, quorum 10.

spinnaker对接AWS ECR

Mon, 31 Mar 2025 00:00:00 +0000

问题描述当在使用 docker login 登录 ECR 时需要获取对应的密钥，而在 aws 中可以运行 aws ecr get-login 以获取登录的密钥。这里存在的问题是，AWS ECR 的密钥有效期是 12 小时，必须做到每 12 小时轮换一次。在配置时，就需要解决 clouddriver 可以实时使用最新密钥登录来获取镜像仓库中容器版本。那么问题就变成了：如何可以解决这个限制并允许 Spinnaker 与 AWS ECR 交互？问题参考 ecr-token-refresh 在实施过程中，参考了 “Using AWS ECR with Spinnaker and Kubernetes” [1] 文章，这篇文章属于官方博客。在这里提到一个方法：“使用 sidecar 来间接刷新 aws ecr 密钥，来完成 clouddriver 可以正常获取密钥。这里提到的一个项目 ”ecr-token-refresh“ [2] ，这是作者自己编写的一个程序，该程序会定期刷新 ecr 的身份验证令牌。在参考这个项目实施时，官方提示是下面配置，但和其他传统的 spinnaker 镜像仓库的配置是相同的，要让 --password-file 是动态的。 bash 1 2 3 4 5 $ hal config provider docker-registry account add my-docker-registry \ --address https://<aws-account-number>.

深入理解Kubernetes Pod网络原理 - CNI

Sun, 02 Feb 2025 00:00:00 +0000

本文是关于深入理解Kubernetes网络原理系列第3章深入理解Kubernetes Pod网络原理 - 网络名称空间深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路概述这是我在 kubernetes 网络之旅中的中的第4部分，主要学习 CNI 规范（5要素，旧版本是4要素）。要深深记住这些，在后面旅程中常常被用到。 Notes 本文讲解均按照 1.

使用WSL2安装kind (Win10 & DockerDesktop)

Sun, 12 Jan 2025 00:00:00 +0000

本文说明如何使用 Windows 10 创建单节点的 kind 集群 (KinD Kubernetes in Docker)。先提条件条件版本操作系统：Windows 10 或 Windows 11 May 2020 Update (build 19041) Docker in WSL2 推荐安装Docker Desktop WSL2 distro 镜像这里采用Debian 内存至少 8GB 内存方式1：直接使用 docker desktop进行安装软件版本 Docker Desktop 4.8.1 WSL Linux Ubuntu 22 kubectl 使用 wsl ubuntu 22 作为客户端安装 Docker Desktop 首先完成 Windows 开启 WSL2 和安装好 Docker Desktop, 可以参考附录1 [1] 安装 kubectl 这里使用和 kind 版本一致的 kubectl 1.

filebeat helm chart多配置文件配置

Thu, 02 Jan 2025 00:00:00 +0000

filebeat helm chart 在配置 filebeatConfig 想配置成多配置文件模式，但是网上没有找到对应配置，单配置文件模式如下所示 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 filebeatConfig: filebeat.yml: | filebeat.inputs: - type: container paths: - /var/log/containers/*.log processors: - add_kubernetes_metadata: host: ${NODE_NAME} matchers: - logs_path: logs_path: "/var/log/containers/" output.elasticsearch: host: '${NODE_NAME}' hosts: '["https://${ELASTICSEARCH_HOSTS:elasticsearch-master:9200}"]' username: '${ELASTICSEARCH_USERNAME}' password: '${ELASTICSEARCH_PASSWORD}' protocol: https ssl.certificate_authorities: ["/usr/share/filebeat/certs/ca.crt"] 在网上有找到一个配置 [1] 是讲启用 filebeat module yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 filebeatConfig: filebeat.

grafana loki的理解与配置(2.9)

Wed, 25 Dec 2024 00:00:00 +0000

loki的部署模式 grafana loki 在 helm 中版本变化很大，理解部署模式有助于快速 run 一组 loki 服务；loki 服务是一个单体二进制文件运行的微服务架构模式，具体运行的角色通过 -target 参数来区分运行什么组件。单体模式单体模式又称整体模式，源自官网 (Monolithic mode)，这个模式指的是 -target=all 时运行的服务。需要注意的是单体模式下，每天读写量为 20GB. Monolithic mode is useful for getting started quickly to experiment with Loki, as well as for small read/write volumes of up to approximately 20GB per day. [1] 该模式下loki 所有的组件都为二进制文件或者容器作为单一进程运行。 SSD SSD (Simple Scalable deployment mode) 简单可扩展部署模式，是 loki 对内部组件进行分类，当参数 target 我i -target=write , -target=read, -target=backend 时，是作为 SSD mode 启动。其中 write 和 backend 是有状态服务，read 是无状态服务。

Hugo博客添加标签云

Wed, 27 Nov 2024 00:00:00 +0000

因为 www.sulvblog.cn 域名过期，正好需要查看这个配置，发现搜索引擎已经被删除了特备份一份 1.逻辑控制定位到layouts/_default/terms.html，把之前的terms-tags标签控制代码注释掉，换成如下代码 html 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 <ul class="terms-tags"> {{- $type := .Type }} {{- range $key, $value := .Data.Terms.Alphabetical }} {{- $name := .Name }} {{- $count := .Count }} {{- with $.Site.GetPage (printf "/%s/%s" $type $name) }} <li> {{ $largestFontSize := 1.5 }} {{ $smallestFontSize := 1 }} {{ $fontSpread := sub $largestFontSize $smallestFontSize }} {{ $max := add (len (index $.

debian12 - 高版本系统安装旧版本k8s异常处理

Sun, 24 Nov 2024 00:00:00 +0000

今日在部署旧版本 k8s 集群 (1.16.10) 时出现错误，主要是在新版本操作系统上部署老版本 k8s，kubelet会出现如下错误 bash 1 2 W1123 22:31:47.383423 3686 server.go:605] failed to get the kubelet's cgroup: mountpoint for cpu not found. Kubelet system container metrics may be missing. W1123 22:31:47.383572 3686 server.go:612] failed to get the container runtime's cgroup: failed to get container name for docker process: mountpoint for cpu not found. Runtime system container metrics may be missing. 错误原因上面的报错是 Kubelet 无法正确访问 Docker 容器运行时的 cgroup 信息，特别是关于 CPU 使用的 cgroup 信息

TLS Everywhere - 解密kubernetes集群的安全认证

Sun, 24 Nov 2024 00:00:00 +0000

本文是关于Kubernetes 4A解析的第5章深入理解Kubernetes 4A - Authentication源码解析深入理解Kubernetes 4A - Authorization源码解析深入理解Kubernetes 4A - Admission Control源码解析深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A 在 kubernetes 集群中，所有的通讯都是用 TLS 进行加密和认证，本文使用一次老集群（二进制部署集群）证书更换作为记录，通过这种方式深入对 kubernetes 的认证方式来了解更换证书的步骤，以及一次模拟老集群的更换步骤。本文使用证书生成工具为 “kubernetes-generator” [1] 专用于 k8s 二进制部署生成证书和安装包的工具。 note 本文中的引用文档使用 web.archive 进行保存，避免官方版本更新，其概念与文档中的概念有变动导致，资料引用失败。 Kubernetes认证方式为了了解证书更换需要做那些步骤，所以必须了解 k8s 的认证方式，这样才能更好的在更换证书时对集群上部署的业务系统的影响降低到最低。 X509 证书 kube-apiserver 的启动参数 --client-ca-file，可以使用客户端办法机构，英文代号就是熟悉的 “CA” (Certificate authority)，当这个证书传递后，可以验证 kube-apiserver 用于验证向 kube-apiserver 提供的客户端证书，这里包含 k8s 中提供的用户种类的两种：用户名：对应证书的 CN (Common Name) 用户组：对应证书的O (organization)，用于对一个用户组进行授权，例如 “system:masters” 表示一个组 [1]，允许不受限制地访问 kube-apiserver 静态token kube-apiserver 的启动参数 --token-auth-file，是以文件提供给 kube-apiserver，该 Token 会长期有效，并且如果不重启服务 Token 是不会更新。

openssl.cnf详解

Sat, 23 Nov 2024 00:00:00 +0000

下面是一个完整 openssl.cnf 配置文件 ini 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 BASE_DOMAIN= CLUSTER_NAME= CERT_DIR= APISERVER_CLUSTER_IP= MASTER_NAME= [ ca ] # man ca default_ca = CA_default [ CA_default ] # Directory and file locations.

zookeeper版本升级 - from 3.4 to 3.8

Thu, 21 Nov 2024 00:00:00 +0000

最近，我不得不将 Zookeeper 3.4.18 集群升级到 3.6+。要求是：无感升级，不丢失数据，并且尽量不向任何用户发出通知。在调研zookeeper 版本后，发现 3.6+ 支持了 metrics 模块，比较符合需求，所以需要从 3.4.18 升级至 3.6.4 3.5 + 支持动态配置 3.6.0+ 支持内置 metrics 模块现有集群配置集群IP 当前目录新版本目录 192.240.16.18 /usr/local/zookeeper-3.4.14/ /usr/local/apache-zookeeper-3.6.4-bin/ 192.240.16.21 /usr/local/zookeeper-3.4.14/ /usr/local/apache-zookeeper-3.6.4-bin/ 192.240.16.28 /usr/local/zookeeper-3.4.14/ /usr/local/apache-zookeeper-3.6.4-bin/ 192.240.16.147 /usr/local/zookeeper-3.4.14/ /usr/local/apache-zookeeper-3.6.4-bin/ 192.240.16.202 /usr/local/zookeeper-3.4.14/ /usr/local/apache-zookeeper-3.6.4-bin/ 下载安装包在官方 archive 找到对应安装包从 zk 3.5 起安装包分为带 “bin” 和不带 “bin” 的带 “bin” 的包含所需jar包不带 “bin” 的需要自行编译 bash 1 wget https://archive.apache.org/dist/zookeeper/zookeeper-3.6.4/ 解压 bash 1 tar Czxf /usr/local/ apache-zookeeper-3.6.4-bin.tar.gz && cd /usr/local 升级版本注意以下步骤需要对每个 zk 服务器都执行一边

CentOS7&Rocky9更新xz

Fri, 01 Nov 2024 00:00:00 +0000

centos&rocky 升级 xz，需要和目前系统对比每个xz包，和每个xz包内的文件有哪些；然后，根据不同类型的包（base, devel, lib)，三个进行打包操作。下载curl源码包升级至少需要更新至 xz 5.4.6 ，首先从官网下载源码包 [1] 将xz作为rpm 下面是 rpm 的规格文件 spec 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 Name: xz Version: 5.

使用terraform利用已有资源创建GKE集群

Wed, 02 Oct 2024 00:00:00 +0000

近日创建GKE集群，需要使用现有的VPC进行创建，所以需要掌握两个步骤，导入资源，创建集群 terraform 导入命令 GCP中的资源地址和 ID。资源地址是指向配置中的资源实例的标识符。ID 是标识 Google Cloud 中要导入的资源的标识符资源地址通常为 terraform在定义这类资源时配置的（对应提供商支持），以 GCP 为例 Cloud Storage 存储桶， google_storage_bucket.sample，sample 为 id，定义如下 yaml 1 2 3 4 5 6 resource "google_storage_bucket" "sample" { name = "my-bucket" project = "sample-project" location = "US" force_destroy = true } 示例 - 导入现有GKE集群语法 bash 1 terraform import <resource_name>.<name> <project>/<locations>/<real_resource_name> 实例 bash 1 terraform import google_container_cluster.gke project20231124/asia-east2/gke-prd-cluster-02 输出结果如下 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 $ terraform import google_container_cluster.

使用rclone工具完成bucket数据同步

Tue, 24 Sep 2024 00:00:00 +0000

rclone工具的特点支持增量，配置简单，支持参数调节吞吐量（不同吞吐量使用内存不同，传输差异也不同） copy是复制 source 到 dst sync是根据 src 的内容对比 dst，删除dst不存在的内容下面是写了一同步的脚本 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 #!

Goswagger - Skipping '', recursion detected

Sat, 21 Sep 2024 00:00:00 +0000

问题：当使用的结构体为嵌套格式，会提示 recursion detected 或 cannot find type definition go 1 2 3 4 5 6 7 8 9 10 11 type Instance struct { metav1.TypeMeta Instances []InstanceItem `json:"instances" yaml:"instances" form:"instances" binding:"required"` ServiceSelector map[string]string `json:"serivce_selector" yaml:"serivce_selector" form:"serivce_selector"` } type InstanceItem struct { Name string `json:"name" yaml:"name" form:"name" binding:"required"` PromEndpoint string `json:"prom_endpoint" yaml:"prom_endpoint" form:"prom_endpoint" binding:"required"` Labels map[string]string `json:"labels" yaml:"labels" form:"labels"` } go swagger 注释为 text 1 2 3 4 5 6 7 8 9 10 // deleteInstance godoc // @Summary Remove prometheus instance.

Gin - 参数默认值问题

Fri, 20 Sep 2024 00:00:00 +0000

遇到问题：gin 使用 Bind 时无法填充，改成下面代码可以获取到 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 type User struct { Name string `form:"name,default=user1" json:"name,default=user2"` Age int `form:"age,default=10" json:"age,default=20"` } r := gin.Default() // way1 curl 127.0.0.1:8900/bind?name=aa // way2 curl -X POST 127.0.0.1:8900/bind -d "name=aa&age=30" // way3 curl -X POST 127.0.0.1:8900/bind -H "Content-Type: application/json" -d "{\"name\": \"aa\"}" r.

Gorm - BeforeDelete无法获取正确条目

Fri, 20 Sep 2024 00:00:00 +0000

遇到问题：BeforeDelete 在删除时获取 SQL 不正确 BeforeDelete 代码如下 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 func (t *Target) BeforeDelete(tx *gorm.DB) (err error) { // 找到与此 Target 相关的所有 Labels var labels []Label if err := tx.Model(t).Association("Labels").Find(&labels); err != nil { klog.V(4).Infof("Error fetching labels: %v", err) return err } for _, label := range labels { if err := tx.Delete(&label).Error; err != nil { klog.

Kubernetes公有云集群中部署Nacos集群

Fri, 20 Sep 2024 00:00:00 +0000

nacos-k8s nacos-k8s 是Nacos官方维护的项目，可以使用 helm 直接在 k8s 集群中部署 nacos 集群（包含公有云）部署步骤找到数据库表结构在你要安装的版本号的配置中找到 SQL 文件进行创建库操作，例如 github.com/alibaba/nacos/tree/2.4.1/distribution/conf 自定义 helm 资源和配置在公有云上部署，还需要修改下对应资源的类型，例如建立 LB service 增加了自动获取 gcp 预留的 IP，和service改为LB类型 yaml 1 2 3 4 5 6 7 8 9 10 11 12 service: #type: ClusterIP #type: NodePort type: LoadBalancer port: 8848 nodePort: 30000 # 这样可以使用静态IP loadBalancerIP: 192.168.0.1 annotations: # 这个annotation 原自官方创建 load-balancer的方式 cloud.google.com/load-balancer-type: Internal labels: {} cloud.google.com/load-balancer-type GKE 的 service LB 类型的参数 [1] service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: “intranet” ACK 的 service LB 类型的参数 [2]

Ceph OSD内存优化与建议

Fri, 13 Sep 2024 00:00:00 +0000

本文记录了在使用 ceph 集群时遭遇到的内存问题，以及引用和参考一些资料用于对在 ceph 集群使用时的内存预估。 OSD的内存需求如何评估 Ceph OSD 所需的硬件也是对于集群选型，集群优化的一个必要条件，这里主要找到两个可靠的参考资料用于评估 OSD 内存配置大小 IBM Storage Ceph IBM Storage Ceph 提供了一个运行 Ceph 用于预估系统配置的一个最小推荐列表 [1]，个人感觉可以参考这些信息用于自己集群的优化。主要用于容器化的 Ceph 集群 Process Criteria Minimum Recommended ceph-osd-container Processor 1x AMD64 or Intel 64 CPU CORE per OSD container RAM Minimum of 5 GB of RAM per OSD container OS Disk 1x OS disk per host OSD Storage 1x storage drive per OSD container. Cannot be shared with OS Disk.

记录一次失败的radosgw问题排查记录

Thu, 12 Sep 2024 00:00:00 +0000

本文是Ceph集群部署系列第4章使用cephadm纯离线安装Ceph集群使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 记录一次因着急没有检查原因而直接下线 ceph 对象存储的的失败记录操作流程 ceph 节点内存持续超过90%，因为本身有三个 OSD，检查内存使用情况发现 radosgw bash 1 2 3 4 5 6 7 8 9 10 11 $ ps aux --sort=-%mem | head -10 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ceph 1702 0.4 32.9 10128296 4550760 ? Ssl May03 919:18 /usr/bin/radosgw -f --cluster ceph --name client.rgw.node01 --setuser ceph --setgroup ceph ceph 1721 0.

GKE强制升级后JAVA Pod无法识别limit限制

Wed, 11 Sep 2024 00:00:00 +0000

今日 GKE EOL，kubelet 自动升级至1.28后，Java程序在启动后无法识别资源清单中的限制，被大量OOMKill Deployment清单中已经配置了资源限制，例如下面的参数 yaml 1 2 3 4 5 resources: limits: memory: "1Gi" requests: memory: "600Mi" JAVA_OPS参数配置是使用百分比 bash 1 -XX:+UseContainerSupport -XX:InitialRAMPercentage=70.0 -XX:MaxRAMPercentage=70.0 但是启动后无法识别参数，使用 gcloud 登录到主机内查看 jvm 运行状态（因为容器使用 distroless） bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 project-20220325-asia-east-2-pool-221ab289-hgnf ~ # nsenter -t 274655 --mount --uts --ipc --net --pid /opt/java/openjdk/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintContainerInfo -version OSContainer::init: Initializing Container Support Detected cgroups v2 unified hierarchy Path to /cpu.

Uranus installation

Fri, 23 Aug 2024 00:00:00 +0000

What is an Uranus? Uranus is a Linux firewalld central controller. In Greek mythology, Uranus king of gods. The firewall gateway is the Uranus for iptables. Prerequisites Hardware requirements We recommend these hardware requirements for production systems or for development systems that are designed to demonstrate production use cases: Item Description Minimum requirements Recommended Per instance You can install on one node but many features require at least one node. 1 instance > 1 instances RAM per instance Defining your RAM size must be part of the capacity planning for your Uranus usage.

Spinnaker 基于判断的条件分支流水线

Sat, 27 Jul 2024 00:00:00 +0000

Manual Judgment Stage “Manual Judgment Stage” 是 Spinnaker Pipeline 中的一种阶段 (“Stage”) 类型，该类型可以作为流水线的门户，作为带外 (Out-of-Bound) 流水线检查，等待手动检查，并且判断结果会终止或继续流水线的执行。创建一个基于Manual Judgment的流水线创建一个流水线，添加一个新的 Stage，选择 “Manual Judgment” 图：Manual Judgment创建页面 Jugement Inputs 部分添加对应的选项，选项可以带入变量 $judgment 中图：Manual Judgment 在执行时 Jugement Inputs Option 的展示或者是不添加任何选项，那么这个时候就会只有 Stop 和 Continue 两个按钮图：当 Manual Judgment 没有配置Jugement Inputs Option 的展示如果添加了选项，可以根据 “选项” 来判断执行的分支判断可以使用每个阶段内的条件表达式 ”Conditional on Expression“，或者 Check Precondition 类型的阶段图：根据 “Stage Conditional on Expression” 来定义的选项 “Check Precondition” 是 Spinnaker 流水线中的一个阶段，它可以先前条件并且判断是否继续，这里主要检查该流水线之前所有的流水线你定义要检查的内容，并继续执行接下分支或者阶段图：“Check Precondition” 的三种类型图：“Check Precondition” 选择添加表达式的页面这里选择使用表达式 (Expression) 来判断前置条件，例如我判断前置 Stage 的选择是否为 “aaaa”

Spinnaker 自定义Pipeline模板思路

Sat, 27 Jul 2024 00:00:00 +0000

流水线模板组合思路官方流水线示例中没有给出完整的流水线模板和完整的字段，只给出了一个大致的 schema [1]，如下所示 json 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 { "schema": "v2", "variables": [ { "type": "<type>", "defaultValue": <value>, "description": "<description>", "name": "<varName>" } ], "id": "<templateName>", # The pipeline instance references the template using this "protect": <true | false>, "metadata": { "name": "displayName", # The display name shown in Deck "description": "<description>", "owner": "example@example.

Hugo - 为文章页面增加相关阅读区域

Wed, 17 Jul 2024 00:00:00 +0000

需求在页面底部增加相关阅读区域：简单实现与文章相同 tag 的文章列出到文章底部实验步骤新增 related 模板在 layouts/partials/related.html 新创建一个模板，增加如下内容，本文主题为 PaperModX ，不同的主题，文件在不同目录下 html 1 2 3 4 5 6 7 8 9 {{ $related := .Site.RegularPages.Related . | first 3 }} {{ with $related }} <h3>Related Posts</h3> <ul> {{ range . }} <li><a href="{{ .RelPermalink }}">{{ .Title }}</a></li> {{ end }} </ul> {{ end }} 将模板加载到文章列表模板内然后需要在文章列表页底部包含这个 “模板” _default/single.html 不同主题在不同的目录下 html 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 .

PromQL复杂使用示例

Wed, 17 Jul 2024 00:00:00 +0000

查询结果删除某些指标 without without 属于聚合查询的子句，必须在聚合查询中使用语法： bash 1 <aggr-op> [without|by (<label list>)] ([parameter,] <vector expression>) 可以看到属于 <aggr-op> 例如 text 1 sum without(instance) (http_requests_total) ignoring ignoring 属于 “向量匹配” (Vector matching) 关键词，可以在一对多，和多对多查询中使用语法 bash 1 <vector expr> <bin-op> ignoring(<label list>) <vector expr> 例如 bash 1 method_code:http_errors:rate5m{code="500"} / ignoring(code) method:http_requests:rate5m 与查询可以查询满足多个条件的指标，例如下列是查询 jvm 内存 $\frac{used}{committed} > 80%$ 并且 Pod WSS 使用大于 80% 的指标 promql 1 2 3 4 5 6 sum by(pod) (jvm_memory_used_bytes{}) / sum by(pod) (jvm_memory_committed_bytes{}) > .

Hugo - 去除Sitemap中的tags search等页面

Sat, 13 Jul 2024 00:00:00 +0000

需求在不禁用分类的情况下，关闭对应 sitemap.xml 中的条目以优化 SEO 去除所有tag 去除所有分类去除 search about me 这类页面实验步骤 sitemap 是通过 go-template 目标进行的，只要可以使用对应语法过滤了相关路径即可以排除对应的页面首先在配置文件增加 taxonomiesExcludedFromSitemap 选项，这个选项排除了 “hugo中分类法” 中的所有子类；其次使用 if not 来排除所有对应首页面。如下列所示本文已 PaperModX 为例，修改文件 layouts\sitemap.xml xml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 {{ printf "<?

构建集群kubernetes v1.28并使用kine和mysql替换etcd

Sun, 30 Jun 2024 00:00:00 +0000

在本文中，将探讨使用 k3s 的 kine 项目来替换掉 etcd，并通过实验使用 kubeadm 去 run 一个 k8s 集群，并用 k3s 的 kine 项目来替换掉 etcd。为什么使用 kine etcd 在 Kubernetes 之外基本上没有应用的场景，并且 etcd 迭代也比较慢，由于没有人愿意维护因此一直在衰退 [1]，并且，Kubernetes 集群中，etcd 也是一个影响集群规模的重大因素。并且 K3S 存在一个项目 Kine 可以使用关系型数据库运行，这样对集群维护者来说可以不需要维护复杂的 etcd 集群，由于关系型数据库有很多高可用方案，这将使得 k8s 集群规模变成了无限可能。 Kine 介绍前文提到，kubernetes (kube-apiserver) 与 etcd 是耦合的，如果我们要使用 RDBMS 去替换 etcd 就需要实现 etcd 的接口，那么这个项目就是 Kine [2]。 Kine 是一个 etcdshim，处于 kube-apiserver 和 RDBMS 的中间层，它实现了 etcdAPI的子集（不是etcd的全部功能），Kine 在 RDBMS 数据库之上实现了简单的多版本并发控制；将所有信息存储在一个表中；每行存储此 key 的修订, key, 当前值, 先前值, 先前修订，以及表示该 Key 是已创建还是已删除的标记，通过这种机制可以作为 shim 层来替换 etcd。

Debian网络配置

Sat, 29 Jun 2024 00:00:00 +0000

设置一个网络接口 debian 中网络接口的配置文件是在 /etc/network/interfaces，可以设置 “静态地址” 或 “DHCP” text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.

安装Debian12 (Bookworm) Step-by-Step

Sat, 29 Jun 2024 00:00:00 +0000

Preparation debian12 几乎可以使用任何旧的计算机硬件，因为最小安装的要求非常低。以下是最低要求和推荐要求：最低要求推荐要求存储：10 Gigabytes 内存：512 Megabytes CPU: 1 GigaHertz 存储：10 Gigabytes内存：2 GigabytesCPU: 1 GigaHertz or more 如何选择下载安装包 offical mirror aliyun mirror 官网提供了安装包的下载，其中CD是网络安装，DVD是离线安装 debian官方下载页面 Notes：CD安装包很小，下载下来是 debian-11.4.0-amd64-netinst.iso 如名所示，这是一个网络安装包，所以推荐下载DVD部分，可以达到离线安装的效果截至文章编写日期，debian-12.5.0-amd64-DVD-1.iso 大小是 3.7G Debian12 EOL：June 30th, 2028 安装步骤在界面中选择“Install”，安装将开始。如果图形化安装可以选择“Graphical install”，这里选择“Install”。欢迎页面完成后，系统将提示选择安装时的“语言”。选择喜欢的语言，然后按“Enter”。这里选择英文选择语言页面这将是接下来安装步骤安装步骤概述选择位置与键盘布局选择地区，这里选择美国选择区域下面部署时选择键盘布局：中国大陆使用的键盘布局是美国-英语，不要选择英国-英语之类，布局是不一样的，会存在按键输出的结果会不同选择键盘布局完成上述操作后，将开始加载镜像。等待扫描完成。。。。等待扫描组件设置主机名和域名这步骤中将配置一个“主机名”。与一个“域”名称。配置主机名 “域” 可以选择留空确定配置域完成上述操作后，安装程序将提示需要设置 root 密码。输入您的 root 密码，然后在重新输入以进行验证后继续。 Tips: 这里建议设置密码，不设置密码会导致安装完成后无法进入 root 用户**，**这样就需要根据先登录普通用户，然后通过 sudo切换过去。设置Root密码设置Root密码 - 二次确认设置非ROOT用户名、账户和密码下一步创建一个非ROOT用户，这个步骤是必须的，并为这个新创建的帐户分配一个密码。以下截图将描述将如何完成此操作。

Go每日一库 - 使用 gin + goswagger 构建 REST API 文档

Wed, 19 Jun 2024 00:00:00 +0000

OpenAPI 什么是OpenAPI Swagger 是一套围绕 OpenAPI 规范构建的开源工具，可帮助我们设计，构建，记录和使用 REST API。 OpenAPI 规范（前名称为 Swagger 规范）是 REST API 的 API 描述格式。包括：可用端点 ( 例如 /users) 以及每个 endpoint 上的操作 (例如 GET /users, POST /users) 操作参数，每个操作的输入和输出认证方法联系信息，许可证，使用条款等其他信息。什么是 Swagger？ Swagger 是一组围绕 OpenAPI 规范构建的开源工具，有助于用户设计，构建，记录和使用 REST API，支持整个 API 生命周期的开发，从设计和文档到测试和部署。使用 Swagger 的目的标准化文档格式：Swagger (OpenAPI) 采用了准化 API 文档格式。通过使用 Swaggo（将注释转换为 Swagger2.0文档的包）生成 Swagger 文档，Swagger 的结构化格式的文档，使开发人员更容易理解产品的 API 交互。交互式文档体验：Swagger UI 与 Swaggo 集成，提供交互式且用户友好的界面，用于测试 API。Swaggo提供了一个自动生成的界面，允许开发人员浏览 Endpoint，查看请求/响应示例，甚至可以直接从文档执行 API 请求。这种交互式体验可提高开发人员的工作效率并加速 API 的采用。自动且最新的文档：Swaggo 可自动从用户的 Go 代码生成 API 文档。这种自动化无需手动维护单独的文档文件。Swaggo 直接从用户的代码库中提取信息，包括 endpoint 详细信息，请求/响应模型和注释。使用这种方法可确保用户的 API 文档随着代码的更新而保持最新。 Swagger 与 Gin 的集成拉取 Swaggo 使用如下命令下载swag

使用docker管理谷歌物件仓库gcr上的镜像

Sat, 01 Jun 2024 00:00:00 +0000

创建服务账户首先可以到「 IAM管理 -> 服务帐户」新增帐户。在新增完成后，会得到一把 key，将它下载后请妥善保管，因为所有相关的身份认证都会用到，这个 key 在下载后就无法继续下载了。授权接着到「IAM -> 新增」成员，并且选择角色，这里选择「Cloud Storage -> 储存空间物件检视者」，让此帐户具备有 read（读取） storage 的功能。登录 bash 1 2 cat KEY-FILE | docker login -u KEY-TYPE --password-stdin \ https://LOCATION-docker.pkg.dev GCP 的 KEY-TYPE 通为 json_key，但这里包含两种类型 _json_key 和 _json_key_base64 KEY-FILE 就是下载的 Service account key 的文件 bash 1 2 cat KEY-FILE | docker login -u _json_key --password-stdin \ https://LOCATION-docker.pkg.dev 通常 Service account key 文件内容如下 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 { "type": "service_account", "project_id": "project2024-0101", "private_key_id": "bdfsd612779509406bb8452c3ek12d730ed547e722d", "private_key": "-----BEGIN PRIVATE KEY----.

深入解析Kubernetes监控体系与prometheus-adapter

Fri, 31 May 2024 00:00:00 +0000

Kubernetes监控架构设计 k8s监控设计背景说明根据 Kubernetes监控架构 1，Kubernetes 集群中的 metrcis 可以分为系统指标 (Core Metrics) 和服务指标 (service metrics) ; 系统指标(System metrics) 是通用的指标，通常可以从每一个被监控的实体中获得（例如，容器和节点的CPU和内存使用情况）。服务指标(Service metrics) 是在应用程序代码中显式定义并暴露的 (例如，API Server 处理的 500 错误数量)。 Kubernetes将系统指标分为两部分：核心指标 (core metrics) 是 Kubernetes 理解和用于其内部组件和核心工具操作的指标，例如：用于调度的指标 (包括资源估算算法的输入, 初始资源/VPA (vertical autoscaling)，集群自动扩缩 (cluster autoscaling)，水平Pod自动扩缩 (horizontal pod autoscaling ) 除自定义指标之外的指标)；Kube Dashboard 使用的指标，以及 “kubectl top” 命令使用的指标。非核心指标 (non-core metrics) 是指不被 Kubernetes 解释的指标。我们一般假设这些指标包含核心指标 (但不一定是 Kubernetes 可理解的格式)，以及其他额外的指标。所以，kubernetes monitoring 的架构被设计拥有如下特点：通过标准的主 API (当前为主监控 API) 提供关于Node, Pod 和容器的核心系统指标，使得核心 Kubernetes 功能不依赖于非核心组件 kubelet 只导出有限的指标集，即核心 Kubernetes 组件正常运行所需的指标。 … 监控管道 Kubernetes 监控管道分为两个：

StackStorm自动化 - 工作流模型

Fri, 24 May 2024 00:00:00 +0000

工作流模型是指 Stackstorm 中 Orquesta 工作流的定义，包含工作流的执行方式，也可以理解为工作流模型就是 Workflow DSL 定义任务执行的有向图工作流模型下表是工作流模型 (Workflow Model) 的属性。工作流接受 Input，按预定义顺序执行一组任务 (Task)，并返回输出 (Output)。此处的工作流模型是一个有向图 (directed graph)，其中 Task 是节点，Taskt 之间的转换及其条件形成边。组成工作流的任务将在 DSL 中定义为名为 Task 的字典，其中 Key 和 Value 分别是任务名称和任务模型。 Attribute Required Description version Yes The version of the spec being used in this workflow DSL. description No The description of the workflow. input No A list of input arguments for this workflow. vars No A list of variables defined for the scope of this workflow.

nacos code=403,msg=user not found!

Mon, 20 May 2024 00:00:00 +0000

应用连接 nacos 时报错 403，用户密码均正确，用户存在，并且权限正确 text 1 2 2024-05-20 10:36:11,593 - [ERROR] - [ropertySourceBuilder][main][n.c.NacosPropertySourceBuilder: 101][]: get data from Nacos error,dataId:admin-server.yaml - com.alibaba.nacos.api.exception.NacosException: http error, code=403,msg=user not found!,dataId=admin-server.yaml,group=DEFAULT_GROUP,tenant=cced143f-5adb-4cb8-a580-28802ea8f203 at com.alibaba.nacos.client.config.impl.ClientWorker$ConfigRpcTransportClient.queryConfig(ClientWorker.java:979) 原因：nacos 地址应该和应用连接的不一致，修改一致后恢复正常 nacos 配置文件配置 “/nacos”，应用直接连接 “/” bash 1 server.servlet.contextPath=/nacos

GCP机器类型

Thu, 02 May 2024 00:00:00 +0000

本文档使用以下术语机器系列：针对特定工作负载优化的一组精选处理器和硬件配置。创建虚拟机时，您可以从首选机器系列中选择预定义或自定义机器类型。机器系列：机器系列按系列和世代进一步分类。例如，通用机器系列中的 N1 系列是 N2 系列的旧版本。世代编号或系列号越高，表示底层 CPU 平台或技术较新。例如，M3 系列是 M2 系列的较新世代。机器类型：每个机器类型都有一个预定义机器类型，用于为您的虚拟机提供一组资源。如果预定义机器类型不能满足您的需求，您还可以为某些机器系列创建自定义机器类型。代 Intel AMD Arm 第 4 代机器系列 N4, C4, X4 N/A C4A 第 3 代机器系列 C3、Z3、H3、M3、A3 C3D N/A 第 2 代机器系列 E2、N2、C2、M2、A2、G2 N2D、C2D、T2D、E2 T2A 第 1 代机器系列 N1、M1 机器系列和系列建议下表提供了针对不同工作负载的建议。通用工作负载 E2 N2、N2D、N1 C3、C3D Tau T2D、Tau T2A 以更低的费用进行日常计算在多种机器类型之间实现均衡的性价比在各种工作负载中始终如一地保持高性能最佳每核心性能/费用（适用于横向扩容工作负载）低流量 Web 服务器后台应用容器化的微服务微服务虚拟桌面开发和测试环境中低流量 Web 和应用服务器容器化的微服务商业智能应用虚拟桌面 CRM 应用

GKE - 为GKE集群增加VPC防火墙规则

Thu, 02 May 2024 00:00:00 +0000

GKE添加VPC防火墙规则有与GCE有一些区别，必须找到GKE的”网络标记“才可以，如下选择 Kubernetes Engine => 选择 ”集群“ 进入 GKE 集群主页随便选择一个集群，进入集群详细页面选择集群中的任意一个节点池找到节点池中任意一个节点，点击进入进入后向下拉找到”网络标记“部分，这个网络标记可以标记这个集群的所有节点如果想自定义”网络标记“的名称，可以在集群首页选择标记进行修改

探索kubectl - kubectl诊断命令集合

Sat, 20 Apr 2024 00:00:00 +0000

工具命令集合长期总结 - Linux日志查询命令长期总结 - Linux网络命令合集长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例探索kubectl - 巧用jsonpath提取有用数据探索kubectl - kubectl诊断命令集合 Pod 检查 Pod 就绪探针 bash 1 kubectl get pods <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 查看 Pod 事件 bash 1 kubectl get events -n <namespace> --field-selector involvedObject.name=<pod-name> 获取 Pod Affinity 和 Anti-Affinity bash 1 kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.spec.affinity}' 列出 Pod 的 anti-affinity 规则 bash 1 kubectl get pod <pod-name> -n <namespace> -o=jsonpath='{.

批量更新harbor版本 1.10 to 2.10

Fri, 29 Mar 2024 00:00:00 +0000

本文将介绍 Harbor 从 v1.10.7 升级到 v2.10.0，以及如何将 Harbor 从 v2.10 回滚到 v1.10.7。升级条件 Linux服务器 4 个 CPU 和 8 GB 内存（强要求），100G可用空间（跨多版本时存放备份文件以及镜像文件，这部分要求） Docker-compose > 1.19.0+ 备份现有的 Harbor /data/database 目录本次升级主要是使用了 harbor 内置的数据库，所以升级步骤比较容易。官方升级路线 harbor 的升级，是不能跨很多版本进行升级，官方对此有详细说明 [1] ，可以看到路线为： 1.10.0 [1] => 2.4.0 [2] => 2.6.0 [3] => 2.8.0 [4] => 2.10.0 [5] 模拟升级步骤 github release 页下载对应的安装包解压 bash 1 2 # 命令主要为将harbor压缩包内文件解压到指定目录中，由于 harbor 解压后文件名无论版本如何都为“harbor” $ mkdir ./harbor-v1.10 && tar -xf harbor-offline-installer-v1.10.0.tgz -C ./harbor-v1.10 --strip-components 1 备份默认的配置文件（仅限于 v1.

Kubernetes维护 - secret批量更新

Tue, 20 Feb 2024 00:00:00 +0000

tls 证书在 k8s 集群上大量使用的话，当到期时会存在批量替换的难度，比如说每个名称空间，多个业务的使用，在这篇博文中，将尝试批量替换整个集群的证书（前提，在没有使用 vault, cert-manager这类组件的集群之上）。基本操作步骤1：首先不知道有多少个名称空间使用了这个证书，所以需要遍历所有的名称空间，这里使用 kubectl 的 json path 实现 bash 1 $ kubectl get ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}' 步骤2：拿到名称空间的名字后，就需要循环这个名称空间下所有的 secret bash 1 2 3 4 for ns in `kubectl get ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}'` do kubectl get secret -n $ns -o jsonpath='{range $.items[*]}{.metadata.name}{"\n"}{end}' done 步骤3：找到与这个匹配的证书进行替换把步骤3拆解为下面几个步骤：拿去到符合要求的secret的名字匹配名称是否为修改的secret 做替换操作由于步骤2使用的是 jsonpath 拿到的 secret name，由于 kubectl 并不支持高级jsonpath语法，官方推荐使用jq，那么使用jq获取名字 bash 1 kubectl get secret -n $ns -o json|jq -r .

使用虚拟机部署nacos

Tue, 20 Feb 2024 00:00:00 +0000

下载 nacos-server bash 1 $ tar zxvf nacos-server-2.2.3.tar.gz -C /opt/ 创建nacos用户 bash 1 useradd nacos -s /sbin/nologin -M 修改 java 环境变量使用openjdk启动，需要配置JAVA_HOME在启动脚本中 bash 1 2 3 4 $ rpm -ql java-1.8.0-openjdk-headless # 找到 jre 根目录配置 JAVA_HOME # /opt/nacos/bin/startup.sh JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.412.b08-1.el7_9.x86_64/jre 启动命令集群模式需要同时启动多个节点 bash 1 2 3 4 5 6 7 启动命令 # 单机 sudo -u nacos /opt/nacos/bin/startup.sh -m standalone # 集群 sudo -u nacos /opt/nacos/bin/startup.sh -m cluster # 停止服务 sudo -u nacos /opt/nacos/bin/shutdown.

k8s - jsonnet从入门到放弃

Sun, 18 Feb 2024 00:00:00 +0000

什么是jsonnet jsonnet是用于app或开发工具的数据模板语言，主要用于json的扩展，具有下面功能：生成配置数据无副作用组织化，简化，统一化管理无序的配置 jsonnet可以通过面向对象消除重复。或者，使用函数。与现有/自定义应用程序集成。生成 JSON、YAML、INI 和其他格式。安装jsonnet Jsonnet 有两种实现（C++ 和 Go）在 Debian/Ubuntu 之上，可以直接使用 apt 源来安装 bash 1 apt install jsonnet -y 安装 go 实现的，可以用下面命令，前提是安装了go bash 1 go get github.com/google/go-jsonnet/cmd/jsonnet 什么是jsonnet-bundler jsonnet-bundler 是 Jsonnet 的包管理器，用于个简化 jsonnet 项目中依赖关系管理的工具。使用 Jsonnet Bundler 可以带来下面便利之处：使用 jsonnetfile.json 作为依赖关系管理自动安装和更新依赖项。版本选择，使用 jsonnetfile.json 可以确保项目使用正确版本的依赖。可重复构建，使用 jsonnetfile.json 管理的项目可以在不同环境中构建并确保结果的一致性。更方便的与 GitOps 结合， Jsonnet Bundler 提供与 GitOps 的集成。 jsonnet-bundler 安装 Jsonnet Bundler 有两种安装模式，实际上就是 Go 程序通用的安装方式：

记录一次ceph集群故障处理记录

Tue, 13 Feb 2024 00:00:00 +0000

处理记录 Ceph版本：octopus 首先遇到問題是，业务端无法挂在 cephfs 查看内核日志发现是 bad authorize reply ，以为是 ceph keyring被替换了 text 1 2 3 4 5 6 7 8 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.80.20.100:6801 bad authorize reply 2019-01-30 17:26:58 localhost kernel: libceph: mds0 10.

深入理解Kubernetes - 基于OOMKill的QoS的设计

Tue, 30 Jan 2024 00:00:00 +0000

Overview 阅读完本文，您当了解 Linux oom kill Kubernetes oom 算法 Kubernetes QoS 本文只是个人理解，如果有大佬觉得不是这样的可以留言一起讨论，参考源码版本为 1.18.20，与高版本相差不大什么是OOM Kill 当你的Linux机器内存不足时，内核会调用Out of Memory (OOM) killer来释放一些内存。这经常在运行许多内存密集型进程的服务器上遇到。 OOM Killer是如何选择要杀死的进程的？ Linux内核为每个运行的进程分配一个分数，称为 oom_score，==显示在内存紧张时终止该进程的可能性有多大==。该 Score 与进程使用的内存量成比例。 Score 是进程使用内存的百分比乘以10。因此，最大分数是 $100% \times 10 = 1000$。此外，如果一个进程以特权用户身份运行，那么与普通用户进程相比，它的 oom_score 会稍低。在主发行版内核会将 /proc/sys/vm/overcommit_memory 的默认值设置为零，这意味着进程可以请求比系统中当前可用的内存更多的内存。这是基于以下启发式完成的：分配的内存不会立即使用，并且进程在其生命周期内也不会使用它们分配的所有内存。如果没有过度使用，系统将无法充分利用其内存，从而浪费一些内存。过量使用内存允许系统以更有效的方式使用内存，但存在 OOM 情况的风险。占用内存的程序会耗尽系统内存，使整个系统陷入瘫痪。当内存太低时，这可能会导致这样的情况：即使是单个页面也无法分配给用户进程，从而允许管理员终止适当的任务，或者内核执行重要操作，例如释放内存。在这种情况下，OOM Killer 就会介入，并将该进程识别为牺牲品，以保证系统其余部分的利益。用户和系统管理员经常询问控制 OOM Killer 行为的方法。为了方便控制，引入了 /proc/<pid>/oom_adj 来防止系统中的重要进程被杀死，并定义进程被杀死的顺序。 oom_adj 的可能值范围为 -17 到 +15。Score 越高，相关进程就越有可能被 OOM-killer Kill。如果 oom_adj 设置为 -17，则 OOM Killer 不会 Kill 该进程。 oom_score 分数为 1 ~ 1000，值越低，程序被杀死的机会就越小。 oom_score 0 表示该进程未使用任何可用内存。 oom_score 1000 表示该进程正在使用 100% 的可用内存，大于1000，也取1000。谁是糟糕的进程？在内存不足的情况下选择要被终止的进程是基于其 oom_score 。糟糕进程 Score 被记录在 /proc/<pid>/oom_score 文件中。该值是基于系统损失的最小工作量、回收的大量内存、不终止任何消耗大量内存的无辜进程以及终止的进程数量最小化（如果可能限制在一个）等因素来确定的。糟糕程度得分是使用进程的原始内存大小、其 CPU 时间（utime + stime）、运行时间（uptime - 启动时间）以及其 oom_adj 值计算的。进程使用的内存越多，得分越高。进程在系统中存在的时间越长，得分越小。

使用keycloak作为grafana的OAuth2认证

Tue, 19 Dec 2023 00:00:00 +0000

本文使用 helm 方式部署 grafana 9 并同样将 keycloak 部署在 kubernetes 集群之上；接下来使用 keycloak 作为 grafana authentication，并实现 oauth2 的用户权限管理。在Kubernetes 集群之上使用helm部署keycloak 在 kubernetes 集群安装 keycloak 有两种方式： bitnami helm offical 下面使用 offical 提供的方式进行部署 bash 1 kubectl create -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/kubernetes/keycloak.yaml helm 部署完成后默认密码是存储在 secret 中，上面方式安装的密码默认为 admin/admin Keycloak configuration 创建realm Realm 管理这一组用户(users), 凭据(credentials), 角色(roles) 和组(groups)，realm之间是相互隔离，一个用户属于并登录到某个 realm，只能管理和验证其控制的用户。下面为 grafana 创建一个 realm，如果你的环境已经存在通用的 realm，则可以使用这个 realm，默认 keycloak 的 realm 是 master，超级管理员属于这个 realm。创建 client Client 是可以请求Keycloak对用户进行身份验证的实体。最常见用途是希望使用Keycloak来保护自己并提供单点登录(SSO)解决方案的应用程序和服务。客户端也可以是只希望请求身份信息或访问令牌的实体，以便它们可以安全地调用由 Keycloak 保护的网络上的其他服务。因此，我们需要为 grafana 创建一个 client

在隔离网络中的多k8s集群中的实现JProfiler的自动化映射方案的设计与实现

Mon, 11 Dec 2023 00:00:00 +0000

背景与架构设计网络中存在的挑战挑战1：Kubernetes 的每个 Pod 拥有一个独立的 IP 地址。对外部访问则依赖 NodePort、LoadBalancer 或 Ingress，出于安全考虑不可能对每个 Pod 都暴露其 8849 端口 (NodePort) 或者使用 Ingress 配置大量的域名，这样无法连接到单独的某一个 Pod (通过Service)。挑战2：网络环境是完全隔离的，用户无法通过 Pod IP 直接访问 Pod，所有的用户流量只能通过对应 IDC 的唯一入口进入。挑战3：出于安全考虑不可能对每一个 Java 服务 (Pod) 在他的工作周期期间所有时间都暴露对应的 Jprofiler 端口，而仅仅想使用时可以连接，用后关闭。 JProfiler网络需求 JProfiler 可以通过加载 JVM 代理（libjprofilerti.so）与远程 GUI 通信，他的实现原理如下： JVM 启动时加载 JProfiler 代理，绑定到一个特定端口（如 8849）。本地 JProfiler GUI 通过该端口连接到远程 JVM。代理与 GUI 之间通过 TCP 传输性能数据。在 Kubernetes 中，JProfiler 代理运行在 Pod 内部，但由于网络隔离和动态 IP，GUI 无法直接连接到 Pod。因此，我们需要一种机制将 JProfiler 的端口动态映射到可访问的外部端点。需要实现的架构下图是基于上面提到的问题从而设计的集群架构

StackStorm自动化 - Sensor

Sat, 02 Dec 2023 00:00:00 +0000

什么是传感器传感器 (Sensor) 是将外部系统和事件与 StackStorm 集成的一种方式。传感器是 Python 代码片段，它们要么定期轮询某些外部系统，要么被动等待入站事件，通常示例用于每隔一段时间去轮询某一个对象，然后他们将 Trigger 注入 StackStorm，可以通过规则进行匹配，以执行潜在的 Action。 Sensor 是用 Python 编写的，并且必须遵循 StackStorm 定义的传感器接口要求。什么是触发器触发器 (Trigger) 是 StackStorm 中用于识别 StackStorm 的传入事件。Trigger 是类型（字符串）和可选参数（对象）的元组。编写 Rule 是为了与 Trigger 一起使用。Sensor 通常会记录 Trigger，但这并不是严格要求的。例如，有一个向 StackStorm 注册的通用Webhooks触发器，它不需要自定义传感器。 Stackstorm内置触发器默认情况下，StackStorm 会发出一些内部 Trigger，您可以在规则中利用它们。这些触发器可以与非系统触发器区分开来，因为它们的前缀为 “st2”。下面包含每个资源的可用 Trigger 列表： Action Reference Description Properties core.st2.generic.actiontrigger 封装 Action 执行完成的触发器 execution_id, status, start_timestamp, action_name, action_ref, runner_ref, parameters, result core.st2.generic.notifytrigger 通知触发器 execution_id, status, start_timestamp, end_timestamp, action_ref, runner_ref, channel, route, message, data core.

StackStorm自动化 - 包

Thu, 30 Nov 2023 00:00:00 +0000

什么是包包 “pack” 是扩展 StackStorm 的集成和自动化的部署单元。通常， pack 是沿着服务或产品边界组织的，例如 AWS、Docker、Sensu 等。 pack 包含Actions、Workflows、Rules、 Sensors和Aliases。StackStorm 内容始终是 pack 的一部分，因此了解如何创建 pack 并使用它们非常重要。一些 pack 扩展了 StackStorm 以将其与外部系统集成，例如 AWS，GitHub，JIRA。我们称它们为“集成 pack ”。有些 pack 捕获自动化模式：这类 pack 含特定自动化过程的 workflow, Rule 和 Action - 例如st2 演示 pack 。我们称它们为“自动化 pack ”。这种命名主要是一种约定：StackStorm 本身对两者没有区别。任何使用该 pack 所针对的服务的人都可以共享和重用集成 pack 。您可以在StackStorm Exchange找到许多这样的示例。自动化 pack 通常是特定于站点的，并且在特定团队或公司之外几乎没有用处；它们通常在内部共享。总结：Packs是StackStorm中组织工作流、动作和传感器的方式。它们是一组相关的动作、工作流和传感器的集合，通常用于实现特定的自动化任务或集成。包管理 StackStorm pack 通过命令进行管理：将为您提供有用的概述。st2 pack <...> / st2 pack -h 有些（例如core 基本 StackStorm action）是随 StackStorm 预装的。所有其他 pack 都需要您安装。幸运的是，这很容易！ list和get是获取有关本地 pack 信息的主要命令：

StackStorm自动化 - Rules

Sat, 25 Nov 2023 00:00:00 +0000

StackStorm 使用 Rules 和 Workflows 来捕获操作模式并进行自动化。rule将 Triggers 映射到 Actions（或 Workflow），应用匹配条件( Criteria)，并将 Triggers payloads 映射到 Actions 的 Input。注意 rule不按预期工作吗？请查看rule故障排除文档。其中介绍了rule测试、检查执行、记录和故障排除等内容。 Rule 的配置结构 stackstorm 中的 Rule 是以 YAML 格式来定义。以下是 Rule 定义结构以及 “必需”和 “可选” rule 元素的列表： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 --- name: "rule_name" # required pack: "examples" # optional description: "Rule description." # optional enabled: true # required trigger: # required type: "trigger_type_ref" criteria: # optional trigger.

client-go - Pod使用in-cluster方式访问集群

Wed, 15 Nov 2023 00:00:00 +0000

在我们基于 Kubernetes 编写云原生 GoLang 代码时，通常在本地调试时，使用 kubeconfig 文件，以构建基于 clientSet 的客户端。而在将代码作为容器部署到集群时，则会使用集群 (in-cluster) 内的配置。 clientcmd 模块用于通过传递本地 kubeconfig 文件构建 clientSet。因此，在容器内使用相同模块构建 clientSet 将需要维护容器进程可访问的 kubeconfig 文件，并设置具有访问 Kubernetes 资源权限的 serviceaccount token。下面是一个基于 kubeconfig 访问集群的代码模式 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 var ( k8sconfig *string //使用kubeconfig配置文件进行集群权限认证 restConfig *rest.Config err error ) if home := homedir.HomeDir(); home != "" { k8sconfig = flag.String("kubeconfig", fmt.Sprintf("./admin.conf"), "kubernetes auth config") } flag.

当cephfs和fscache结合时在K8s环境下的全集群规模故障

Sat, 11 Nov 2023 00:00:00 +0000

本文记录了在 kubernetes 环境中，使用 cephfs 时当启用了 fscache 时，由于网络问题，或者 ceph 集群问题导致的整个 k8s 集群规模的挂载故障问题。结合fscache的kubernetes中使用cephfs造成的集群规模故障在了解了上面的基础知识后，就可以引入故障了，下面是故障产生环境的配置故障发生环境软件版本 Centos 7.9 Ceph nautilus (14.20) Kernel 4.18.16 故障现象在 k8s 集群中挂在 cephfs 的场景下，新启动的 Pod 报错无法启动，报错信息如下 bash 1 ContainerCannotRun: error while creating mount source path /var/lib/kubelet/pods/5446c441-9162-45e8-0e93-b59be74d13b/volumes/kubernetesio-cephfs/{dir name} mkcir /var/lib/kubelet/pods/5446c441-9162-45e8-de93-b59bte74d13b/volumes/kubernetes.io~cephfs/ip-ib file existe 主要表现的现象大概为如下三个特征对于该节点故障之前运行的 Pod 是正常运行，但是无法写入和读取数据无法写入数据 permission denied 无法读取数据 kublet 的日志报错截图如下彻底解决方法需要驱逐该节点上所有挂在 cephfs 的 Pod，之后新调度来的 Pod 就可以正常启动了故障的分析当网络出现问题时，如果使用了 cephfs 的 Pod 就会出现大量故障，具体故障表现方式有下面几种新部署的 Pod 处于 Waiting 状态

初识Argo cd - 注册/删除k8s集群

Sun, 05 Nov 2023 00:00:00 +0000

登录argo cd bash 1 argocd login argocd_server:argocd_port_here 执行后输入admin/sercert bash 1 2 3 4 5 6 $ argocd login 10.0.0.5:30908 WARNING: server certificate had error: x509: cannot validate certificate for 10.0.0.5 because it doesn't contain any IP SANs. Proceed insecurely (y/n)? y Username: admin Password: 'admin:login' logged in successfully Context '10.0.0.5:30908' updated argocd cli 登录后的文件保存在 ~/.argocd/config 中注册一个新集群 argocd 通过 kubectl 来获取集群的信息，所以 argocd 的主机上必须有 kubeconfig 文件 Note: KUBECONFIG 文件地址必须为实际路径，比如 ~/ 这种方式不可以

深入Argo - Application resources

Sun, 05 Nov 2023 00:00:00 +0000

在安装和注册集群完成后，就需要引入第一个概念 “Application”（如何管理所有我的应用程序？）什么是 Application 什么是 ArgoCD “Application”？对于 ArgoCD “Application”的快速解释：它是托管 ArgoCD 部署的 Kubernetes 集群 CRD 包含了应用程序的所有设置，如：要部署到哪个集群？与哪个 Git 存储库进行同步？其他部署设置应用程序的 YAML 包含了部署您的存储库资源所需的所有信息，充当了在 ArgoCD 中管理应用程序的关键控制点。 Reference [1] docs/operator-manual/argocd-cm.yaml [2] Getting started with multi-cluster K8S deployments using Argo CD [3] https://medium.com/notive/managing-argocd-application-resources-1b2b4742ab90

nginx中的多路分支 - nginx map

Sat, 04 Nov 2023 00:00:00 +0000

引言在 NGINX 中常用一种 “比较变量” 的手法，在编程语言中称为 “多路分支” (Case statement)，也就是 nginx map，需要注意的一点是，太低版本 NGINX MAP 中只能使用单变量 Before version 0.9.0 only a single variable could be specified in the first parameter. [1] 下面将了解下 nginx map 的具体使用方式 nginx map使用 Nginx 配置主要是声明性的，这同样应用于 MAP 指令，NGINX MAP 是定义在 http{} 级别，最大的特点是仅在引用时进行处理，如果请求未触及使用 NGINX MAP 变量的配置部分，则不会执行该 map 变量查找。换句话来理解，当在上下文 server, Location, if 等中使用结果变量时（指定的不是计算结果，而是在需要时计算该结果的公式），才会被使用，在 NGINX 需要使用该变量之前，NGINX MAP 不会给请求增加任何开销。 NGINX MAP 用于根据另一个变量的值创建一个变量，如下所示： text 1 2 3 4 map $variable_to_check $variable_to_set { "check_if_variable_matches_me" "variable_matches_checked_value"; default "no_match"; } 在上面的例子中，变量 $variable_to_set 的被设置的结果为：如果 $variable_to_check 值为 “check_if_variable_matches_me”，那么 $variable_to_set 将被设置为值 “variable_matches_checked_value” ，否则将设置为 “no_match”。

GKE标准集群价格选择示例

Thu, 02 Nov 2023 00:00:00 +0000

GKE标准机器通常费用组成为 “集群管理费” + 标准GCE主机费用，以香港为例主机规格 CPU (CORE/Mon) MEM (GB/Mon) E2( E2Balanced: N1, N2)：费用优化 $23.77 $2.99 N1 (旧型号的Intel Sandy Bridge、Ivy Bridge、Haswell、Broadwell、Skylake) $38.45 $4.55 N2 CPU $31.9 $4.01 N2D CPU $27.75 $3.48 选择核心的标准（强要求） intel 2的公差，例如1, 2, 4, 6, 8, 10 AMD 2, 4, 8, 16, 32 只有 “费用优化” (cose-optimized) 的可以自定义配置，计算优化，内存优化等都是固定配置新加坡的价格是香港价格的 “90%”

K8S Admission Webhook官方扩展版 - ValidatingAdmissionPolicy

Wed, 01 Nov 2023 00:00:00 +0000

相关阅读：深入理解Kubernetes 4A - Admission Control源码解析准入 (Admission) 是 Kubernetes 提供 4A 安全认证中的一个步骤，在以前版本中 (1,26-)，官方提供了 webhook 功能，使用户可以自行的定义 Kubernetes 资源准入规则，但这些是有成本的，需要自行开发 webhook，下图是 Kubernetes准入控制流程。图：Kubernetes API 请求的请求处理步骤图 Source：https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ 在 Kubernetes 1.26 时引入了 ValidatingAdmissionPolicy alpha 版，这个功能等于将 Admission Webhook controller 作为了一个官方扩展版，通过资源进行自行扩展，通过这种方式带来下面优势：减少了准入请求延迟，提高可靠性和可用性能够在不影响可用性的情况下失败关闭避免 webhooks 的操作负担 ValidatingAdmissionPolicy 说明验证准入策略提供一种声明式的、进程内的替代方案来验证准入 Webhook。验证准入策略使用通用表达语言 (Common Expression Language，CEL) 来声明策略的验证规则。验证准入策略是高度可配置的，使配置策略的作者能够根据集群管理员的需要，定义可以参数化并限定到资源的策略下面是一个 ValidatingAdmissionPolicy 的示例，配置 Deployment 必须拥有的副本数的限制 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: admissionregistration.

Kubernetes集群中的IP伪装 - ip-masq-agent

Sat, 28 Oct 2023 00:00:00 +0000

“IP 伪装” 通常应用于云环境中，例如 GKE, AWS, CCE 等云厂商都有使用 “IP伪装” 技术，本文将围绕 “IP伪装” 技术本身，以及这项技术在 Kubernetes 集群中的实现应用 ip-masq-agent 的源码分析，以及 ”IP伪装“ 能为 Kubernetes 带来什么作用，这三个方向阐述。什么是IP伪装？ IP 伪装 (IP Masquerade) 是 Linux 中的一个网络功能，一对多 (1 to Many) 的网络地址转换 (NAT) 的功能。 IP 伪装允许一组计算机通过 “伪装” 网关无形地访问互联网。对于互联网上的其他计算机，出站流量将看起来来自于 IP MASQ 服务器本身。互联网上任何希望发回数据包（作为答复）的主机必须将该数据包发送到网关（IP MASQ 服务器本身）。记住，网关（IP MASQ 服务器本身）是互联网上唯一可见的主机。网关重写目标地址，用被伪装的机器的 IP 地址替换自己的地址，并将该数据包转发到本地网络进行传递。除了增加的功能之外，IP Masquerade 为创建一个高度安全的网络环境提供了基础。通过良好构建的防火墙，突破经过良好配置的伪装系统和内部局域网的安全性应该会相当困难。 IP Masquerade 从 Linux 1.3.x 开始支持，目前基本所有 Linux 发行版都带有 IP 伪装的功能什么情况下不需要IP伪装已经连接到互联网的独立主机为其他主机分配了多个公共地址 IP伪装在Kubernetes集群中的应用 IP 伪装通常应用在大规模 Kubernetes 集群中，主要用于解决 “地址冲突” 的问题，例如在 GCP 中，通常是一种 IP 可路由的网络模型，例如分配给 Pod service 的 ClusterIP 只能在 Kubernetes 集群内部可用，而分配 IP CIDR 又是一种不可控的情况，假设，我们为 k8s 分配的 IP CIDR 段如下表所示：

Linux网络子系统中的计数器

Thu, 26 Oct 2023 00:00:00 +0000

在Prometheus node-exporter中，存在多个网络监控指标指标标志着主机的网络状态，但是大家常常忽略这些指标，而这些指标又很重要，这些指标的来源是根据Linux网络子系统中的多个计数器定义的，本文就解开这些TCP计数器的面目。 TcpExtListenOverflows 和 TcpExtListenDrops 当内核从客户端接收到 SYN 时，如果 TCP 接受队列已满，内核将丢弃 SYN 并将 TcpExtListenOverflows +1。同时内核也会给TcpExtListenDrops +1。当 TCP 套接字处于 LISTEN 状态，并且内核需要丢弃数据包时，内核总是将 TcpExtListenDrops +1。因此，增加 TcpExtListenOverflows 将使 TcpExtListenDrops 同时增加，但在不增加 TcpExtListenOverflows 的情况下，TcpExtListenDrops 也会增加，例如内存分配失败也会导致 TcpExtListenDrops 增加。以上解释基于内核 4.10 或更高版本，在旧内核上，当 TCP 接受队列已满时，TCP Stack有不同的行为。在旧内核上，TCP Stack不会丢弃 SYN，它会完成 3 次握手。当接受队列已满时，TCP 堆栈会将套接字保留在 TCP 半开队列中。由于处于半开队列中，TCP 堆栈将在指数退避计时器上发送 SYN+ACK，在客户端回复 ACK 后，TCP Stack检查接受队列是否仍满，如果未满，则将套接字移至接受队列如果队列已满，则将套接字保留在半开队列中，下次客户端回复ACK时，该套接字将有另一次机会移至接受队列。这两个计数器在 node_expoter 中的指标是： node_netstat_TcpExt_ListenDrops node_netstat_TcpExt_ListenOverflows TcpInSegs 和 TcpOutSegs TcpInSegs 和 TcpOutSegs 都是被定义在 RFC1213 [1] TcpInSegs 是指 TCP layer 接收到的数据包数量，包括错误接收的数据包，例如校验和错误、无效的TCP头等。只有一个错误不会被包含在内：如果第 2 层目标地址不是 NIC 的第 2 层地址。如果数据包是多播或广播数据包，或者 NIC 处于混杂模式，则可能会发生这种情况。在这些情况下，数据包将被传递到 TCP 层，但 TCP 层将在增加 TcpInSegs 之前丢弃这些数据包。 TcpInSegs 计数器不知道 GRO (Generic Receive Offload)。因此，如果两个数据包被 GRO 合并，TcpInSegs 计数器只会增加 1。

初识Argo cd - 在k8s集群上安装argo cd

Tue, 24 Oct 2023 00:00:00 +0000

GitOps 最初由 Weaveworks (weave cni的组织) 在 2017 年的博客中提出 [1]，使用 “Git” 作为 CI/CD 的 “单一事实来源”，将代码的更改集成到每个项目的存储库中，并使用拉取请求来管理 infra 和部署。在理解上就可以理解为 “是一种基于 git 的操作框架” Argo CD 是一种 kubernetes 之上的 “声明式” (declarative) 的 gitops CD，在本文作为了解如何在 Kubernetes 集群中安装和配置 Argo CD。前提准备想要安装 Argo CD 首先环境需要具备如下：已经安装好 kubectl 命令行工具拥有 kubeconfig 文件一个可供测试的 Kubernetes 集群，如：kind, minikube, kubeadm, binary 等任意的集群步骤1 - 选择适配 kubernetes 版本的 Argo 根据官方的解释， Argo CD 在任何给定时刻所支持的版本，这些版本是 N 和 N - 1 次要版本的最新修补版本 (x.x.new)。这些 Argo CD 版本与 Kubernetes 项目官方支持的 Kubernetes 版本相一致，通常是 Kubernetes 的最近发布的 3 个版本。

初识Argo cd - argo cd架构

Sun, 22 Oct 2023 00:00:00 +0000

Argo组件 API Server Repository Server Application Controller API Server：一个 gRPC/REST 服务器，提供了 “Web UI”、“CLI” 和 “CI/CD” 使用的 API 应用管理和状态报告调用应用操作（例如同步、回滚、用户定义的操作）存储库和 Cluster credential 管理（作为 kubernetes secret 存储）为外部提供身份认证和代理授权功能 RBAC 试试 Git webhook 事件的 listener/forwarder Repository Server：内部服务，用于维护 git 中的应用清单 (manifests) 的本地缓存。负责接收生成和返回 kubernetes 清单仓库URL revision (commit, tag, branch) APP PATH 模板特定的参数 Application Controller：Kubernetes controller，主要做的工作是持续监控运行的 Application，并于当前实时状态和目标所需状态进行对比（与 Kubernetes Controller 功能是相同的），并且不仅仅是 KC 还会和存储库中指定目标状态进行比较，检测到 OutOfSync 状态将进行纠正。 Argo 架构 Argo CD 时最常见的三种架构：单实例方案, 集群级方案，以及折衷方案 (compromise between the two)。

CentOS6/7 curl SOCKS5堆溢出漏洞修复 CVE-2023-38545 CVE-2023-38546

Fri, 13 Oct 2023 00:00:00 +0000

10月11日发布的 curl 8.4.0版本，在新版本中修复漏洞 CVE-2023-38545 和 CVE-2023-38546 CVE-2023-38545: This flaw makes curl overflow a heap based buffer in the SOCKS5 proxy handshake. [1] CVE-2023-38546: This flaw allows an attacker to insert cookies at will into a running program using libcurl, if the specific series of conditions are met. [2] 安装方式有两种，“编译” 与 “更新RPM”，本文以 RPM 方式更新 curl 到 8.4.0 版本下载curl源码包升级至少需要更新至 curl 8.4 ，首先从官网下载源码包 [3] 将curl打包为rpm 因为 curl 源码包内没有提供 rpm 的规格文件，所以我们需要自己编写，但是比较麻烦，可以让 chatgpt 生成一个，这里使用 centos7 的 curl.

Docker运行PostgreSQL

Thu, 05 Oct 2023 00:00:00 +0000

在本文，尝试使用 Docker 运行 PostgreSQL ，为了适配 goalert 项目，因为从来没有尝试过使用 PostgreSQL 了解PostgreSQL数据库在我们继续运行 PostgreSQL 数据库的 Docker 容器之前，我们先来了解一下 PostgreSQL 数据库。 PostgreSQL 是一个开源 RDMS，类似于 MySQL。它是一个面向对象的数据库，但我们可以处理结构化和非结构化数据。 PostgreSQL 数据库可以运行在各种平台上，包括 Windows、Mac OS X 和 Linux。它还提供高级数据类型和性能优化功能来存储和扩展复杂的数据库工作负载。一些常见的 postgres 镜像镜像说明 postgres:latest 最新的一个稳定版本 postgres:17 PostgreSQL version 14.x （x为最近的一次 patch） postgres:17.4 17.4 一个具体的版本 postgres:bookworm 使用 Debian Bookworm (12) 构建的 PostgreSQL postgres:15-bookworm 使用 Debian Bookworm (12) 构建的 PostgreSQL 15 使用公共镜像运行PostgreSQL 要使用 Docker 运行 PostgreSQL，我们首先需要拉取 Docker Hub 上可用的 postgres 公共镜像： bash 1 docker pull postgres 在上面的命令中，我们拉取了 postgres 最新的稳定版镜像。如果要指定版本的 postgres 镜像，可以使用以下命令

探索kubectl - 巧用jsonpath提取有用数据

Mon, 25 Sep 2023 00:00:00 +0000

工具命令集合长期总结 - Linux日志查询命令长期总结 - Linux网络命令合集长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例探索kubectl - 巧用jsonpath提取有用数据探索kubectl - kubectl诊断命令集合 kubernetes集群工具 kubect 提供了一种强大的数据提取的模式，jsonpath，相对于 yaml 来说，jsonpath 拥有高度的自制提取功能，以及一些更便于提取字段的模式，使得过去 kubernetes 资源信息时更便捷，在本文中将解开 jsonpath 的神秘面纱。什么是jsonpath JSONPath 是一种用于查询 JSON 数据结构中特定元素的查询语言。它类似于 XPath 用于 XML 数据的查询。JSONPath 允许您以一种简单而灵活的方式从 JSON 对象中提取数据，而不需要编写复杂的代码来解析 JSON 结构。 JSONPath 使用路径表达式来指定您要检索的 JSON 数据的位置。这些路径表达式类似于文件系统中的路径，但用于导航 JSON 结构。以下是一些常见的 JSONPath 表达式示例： $：表示 JSON 根对象。 $.store：表示从根对象中获取名为 “store” 的属性。 $.store.book：表示从根对象中获取 “store” 属性中的 “book” 属性。 $.store.book[0]：表示获取 “store” 属性中的 “book” 属性的第一个元素。 $.store.book[?(@.price < 10)]：表示选择 “store” 属性中的 “book” 属性中价格小于 10 的所有元素。 Function Description Example Result text the plain text kind is {.

Ceph对象存储 - windows上安装s3cmd

Sun, 24 Sep 2023 00:00:00 +0000

s3cmd 是为了管理 Linux 服务器上的 S3 存储桶而创建的。但我们也在 Windows 服务器上使用这个工具。本文将帮助您在 Windows 系统中设置 s3cmd Requirment s3cmd 系统要求： s3cmd 需要 Python 2.7 或更高版本才能运行，还需要安装GPG。步骤1：安装 Python 从 python 官方网站下载并安装 python 2.7 或更高版本并安装。安装python后，将将其加到 PATH 环境变量。步骤 2：在 Windows 上安装 GPG Gpg4win (GNU Privacy Guard for Windows) 是一款用于数字加密 (file, email) 的免费软件，可以使用以下链接下载并安装它。步骤3：配置 s3cmd 下载最新的 s3cmd 源代码从s3cmd 官方页面并解压；提取源代码后，使用以下命令设置 s3 环境。它会询问您的对象存储的 AccessKey 和 SecretKey，即 GPG 命令的路径 bat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 C:s3cmd> python s3cmd --configure Enter new values or accept defaults in brackets with Enter.

Ceph对象存储 - 使用s3cmd管理对象存储

Sun, 24 Sep 2023 00:00:00 +0000

s3cmd 是一个 Amazon S3 工具，可以用于创建 s3 bucket、向对象存储中上传，检索和管理数据，在下文将如何在 Linux 上如何安装和使用 “s3cmd” 工具。在 Linux 上安装 s3cmd s3cmd 在 Ubuntu/Debian, Fedora/CentOS/RHEL 这类发行版上的默认软件包存储库中都是可用的，只需在执行对应发行版的安装命令即可安装。 CentOS/RHEL/Fedora bash 1 2 3 4 # centos 8 $ sudo dnf install s3cmd # centos 7 $ sudo yum install s3cmd Ubuntu/Debian bash 1 sudo apt-get install s3cmd 安装最新版本通常包管理仓库中的版本比较旧，或者使用的 Linux 没有包管理来获取最新版本的 s3cmd，那么可以使用源代码在系统上安装最新版本的 s3cmd，下载地址可以参考附录1 [1] 下面以 2.2 版本进行安装 bash 1 2 $ wget https://sourceforge.net/projects/s3tools/files/s3cmd/2.2.0/s3cmd-2.2.0.tar.gz $ tar xzf s3cmd-2.2.0.tar.gz 使用以下命令和源文件安装

修改ingress-nginx中default backend默认状态码

Thu, 21 Sep 2023 00:00:00 +0000

什么是 default backend default backend 是 ingress-nginx 中的一个服务，主要用于处理 nginx controller 无法识别的而请求的服务主要提供了两个接口 /healthz that returns 200 /that returns 404 如何改default backend 状态码需求：修改 default backend 状态码 404 为 403 原理：nginx-controller 启动时指定了一个 default backend 容器，如下所示 bash 1 2 3 4 5 6 7 8 9 10 11 12 containers: - args: - /nginx-ingress-controller # 这里指的是 default-backend 的名称 {namespace_name}/{service_name} - --default-backend-service=$(POD_NAMESPACE)/ingress-nginx-ext-defaultbackend - --publish-service=$(POD_NAMESPACE)/ingress-nginx-ext-controller - --election-id=ingress-controller-leader - --ingress-class=nginx-yewu-ext - --configmap=$(POD_NAMESPACE)/ingress-nginx-ext-controller - --validating-webhook=:8443 - --validating-webhook-certificate=/usr/local/certificates/cert - --validating-webhook-key=/usr/local/certificates/key 通常情况下在通过定义配置文件方式改变是不容易做的，ingress-nginx 提供了一种自定义方式 “custom-error-pages“ 可以完成，完成后该 defaultBackend 支持使用 X-code方式自定义任意的错误页即错误码。

Ceph对象存储 - 桶策略 Bucket Policy

Mon, 18 Sep 2023 00:00:00 +0000

CEPH RGW 支持 Bucket 的 S3 策略语言，但又不完全类似于 S3 的策略，因为 S3 中策略是基于 AWS 的，某些属性在 CEPH 中并不存在，下面就解开 RGW 关于桶策略的配置。 Bucket Policy (桶策略，下文中统称为 BP) 是对象存储中的管理权限和对象存储访问的机制。 Policy Language 的组成 BP 的格式采用了 JSON 语言，也就是 PL 是基于 JSON 的一种策略语言，他的格式主要为几个元素 json 1 2 3 4 5 6 7 8 9 { "Version": "2012-10-17", "Statement": [{ "Effect": ..., "Principal": ..., "Action": ..., "Resource": ... }] } 该结构由 ==一个== Version (表示当前版本) 和 ==一个或多个== Statement 数组组成，这些数组定义了希望应用的策略。每个语句数组中都有Effect, Principal, Action, Resource 和可选的 Condition 元素。

kube-proxy参数ClusterCIDR做什么

Fri, 15 Sep 2023 00:00:00 +0000

我们可以看到，kube-proxy 有一个 –cluster-cidr 的参数，我们就来解开这个参数究竟有没有用 bash 1 2 $ kube-proxy -h|grep cidr --cluster-cidr string The CIDR range of pods in the cluster. When configured, traffic sent to a Service cluster IP from outside this range will be masqueraded and traffic sent from pods to an external LoadBalancer IP will be directed to the respective cluster IP instead 可以看到，参数说明是说，如果配置，那么从外部发往 Service Cluster IP 的流量将被伪装，从 Pod 发往外部 LB 将被直接发往对应的 cluster IP。但实际上做了什么并不知道，那么就从源码解决这个问题。首先我们知道，参数是作为 kube-proxy server 的参数，位于 cmd/kube-proxy 下，而对应的逻辑则位于 pkg/kube-proxy 下，参数很明显，就是 clusterCIDR，那么我们就寻找这个参数的调用即可。

ceph常用命令

Wed, 13 Sep 2023 00:00:00 +0000

测试上传/下载对象存取故据时，客户端必须首先连接至RAD05集群上某存储地，而后根据对像名称由相关的中CRUSH规则完成数据对象寻址。于是为了测试集群的数据存储功能，首先创建一个用于测试的存储池mypool，并设定其PG数量为16个。 sh 1 ceph osd pool create mypool 16 16 而后，即可将测试文件上传至存储池中。例如下面的rados put命令将/etc/hosts rados lspool 显示存储池 rmpool 删除存储池 mkpool 创建存储池 rados mkpool mypool 32 32 sh 1 2 rados mkpool {name} {pgnum} {pgpnum} rados mkpool test 32 32 sh 1 2 $ ceph osd pool create testpool 32 32 pool 'testpool' created 列出存储池 text 1 2 3 4 5 6 7 8 9 $ ceph osd pool ls mypool rbdpool testpool $ rados lspools mypool rbdpool testpool 而后即可将测试文件上传到存储池中，例如将rados put命令将/etc/issue文件上传至testpool存储池，对象名称仍然较保留文件名issue，而rados ls可以列出指定存储池中的数据对象

Ceph重新平衡 - Rebalance

Sun, 03 Sep 2023 00:00:00 +0000

Rebalance 当 Ceph 集群在扩容/缩容后，Ceph会更新 Cluster map, 在更新时会更新 Cluster map 也会更新 “对象的放置” CRUSH 会平均但随机的将对象放置在现有的 OSD 之上，在 Rebalancing 时，只有少量数据进行移动而不是全部数据进行移动，直到达到 OSD 与对象之间的平衡，这个过程就叫做 Ceph 的 Rebalance。需要注意的是，当集群中的 OSD 数量越多，那么在做 Rebalance 时所移动的就越少。例如，在具有 50 个 OSD 的集群中，在添加 OSD 时可能会移动 1/50th 或 2% 的数据。如下图所示，当前集群有两个 OSD，当在集群中添加一个 OSD，使其数量达到3时，这个时候会触发 Rebalance，所移动的数量为 OSD1 上的 PG3 与 OSD2 上的 PG 6和9 图：Ceph Rebalancing 示意图 Source：https://access.redhat.com/documentation/zh-cn/red_hat_ceph_storage/4/html/architecture_guide/ceph-rebalancing-and-recovery_arch Balancer 执行 Rebalance 的模块时 Balancer，其可以优化 OSD 上的放置组 (PG) ，以实现平衡分配。可以通过命令查看 balancer 的状态 bash 1 ceph balancer status https://docs.

深入理解kubelet - VolumeManager源码解析

Sun, 20 Aug 2023 00:00:00 +0000

Overview 阅读完本文，您当了解 Kubernetes 卷 CephFS 在 kubernetes 中的挂载 Kubelet VolumeManager 本文只是个人理解，如果有大佬觉得不是这样的可以留言一起讨论，参考源码版本为 1.18.20，与高版本相差不大 VolumeManager VolumeManager VM 是在 kubelet 启动时被初始化的一个异步进程，主要是维护 “Pod" 卷的两个状态，”desiredStateOfWorld“ 和 ”actualStateOfWorld“；这两个状态用于将节点上的卷 “协调” 到所需的状态。 VM 实际上包含三个 “异步进程” (goroutine)，其中有一个 reconciler 就是用于协调与挂载的，下面就来阐述 VM 的挂载过程。 VM中的重要组件 actualStateOfWorld mountedPod desiredStateOfWorld VolumeToMount podToMount VM的组成 VM 的代码位于，由图可以看出，主要包含三个重要部分： reconciler：协调器 populator：填充器 cache：包含 ”desiredStateOfWorld“ 和 ”actualStateOfWorld“ 图：VM的目录组成在代码结构上，volumeManager 如下所示 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 // volumeManager implements the VolumeManager interface type volumeManager struct { // DesiredStateOfWorldPopulator 用来与 API 服务器通信以获取 PV 和 PVC 对象的 API 客户端 kubeClient clientset.

记录kubernetes node label的面板实施

Sat, 19 Aug 2023 00:00:00 +0000

背景目前的 Kubernetes 集群资源面板是基于集群的使用资源，因为是多集群，业务同时运行字啊不同集群上，如果通过 label 来划分业务使用的资源情况，这个才是真的和每个集群的每个业务使用的资源有关。对于这种场景的划分，Kubernetes 中有一个专门的名词是 Pod 的拓扑域；基于这些需要做的事情就如下步骤首先确定node label可以搜集到，如果不存在需要收集当收集到node label 时，需要根据对应的 label 将一个域中的根据域（label）做变量注入到对应的查询语句中以生成图表收集 node label 在使用 kube-prometheus-stack 中收集 kubernetes 的 node label 需要手动启动参数 - --metric-labels-allowlist=nodes=[*] 才可以收集到 node label，手动给Node 打上标签，test 拓扑域为 aaaa bbbb两个在 helm 中直接增加如下： bash 1 - nodes=[*] 查看 label bash 1 2 3 4 $ kubectl get node --show-labels NAME STATUS ROLES AGE VERSION LABELS node01 Ready <none> 13d v1.16.10 beta.

存储概念 - 存储类型对比

Tue, 15 Aug 2023 00:00:00 +0000

存储选择需要考虑的问题：不同的文件访问方式? 在关注存储之前，需要关注下面一些问题： “应用” 访问数据的方式是什么？一次读取或分块读取一个连续的“流”传输最好的方式是什么有序的或随机的 “数据的类型是什么”？数据库，Text，视频/音频，图像… 静态 / 固定 / 动态是否需要数据共享？由应用共享 / 由存储共享读 / 写共享方面关注的问题？ Narrow (只需要更新部分内容，这可以共享特定部分内容，这将不是一个广泛共享) / Broad 安全和访问控制：应用什么级别的的安全性？访问性会影响存储的选择： Local / Network 介质：光纤，以太网，SAS，SATA，PCIe… 有了这些问题，就可以引入存储的类型，以便选择最佳的存储（Balance performance and cost ） DAS Direct Attached Storage (DAS) 直接附加存储是指，直接连接到服务器存储系统，通俗来讲就是直接连接磁盘，服务器与存储系统之间“没有经过网络设备” (如交换机等)，服务器与存储直接由专用的“连接技术”进行连接，如 SCSI, 但现在更常见的是 “eSATA”, “SAS”, 或 “光纤通道”。图：DAS结构图 Source：https://www.pcmag.com/encyclopedia/term/direct-attached-storage 图：DAS接口类型 Source：https://ramsaihan.wordpress.com/2017/10/16/the-sas-sata-scsi-and-ata-in-storage-and-peripheral-communication/ 外部连接直连存储也可以通过连接电缆从服务器连接到存储设备，但服务器中必须存在 SAS、以太网或 FC 控制器，只有该服务器可以使用外部磁盘空间。因此直连存储也可以作为是服务器的扩展 SAS 作为连接介质价格低廉，但距离仅限于几米（最大 5 或 10 米，具体取决于制造商）；光纤通道的传输距离可达数公里，因此也可用作灾备系统。

picgo + github 给typora做图床

Tue, 08 Aug 2023 00:00:00 +0000

在配置好 github 仓库后，需要将对应的信息填写在 picgo 中，可以按照如下进行配置仓库名：xxxx/xxx 无需写 github.com/xxx/xxx 分支名：直接填写分支名即可 Token：在 github 上面配置的仓库 token 设定存储路径：这里填写 github 仓库上传到的路径设置自定义域名：https://cdn.jsdelivr.net/gh/<github_username>@<branch_name>/<repo_name>/<path> 例如：https://cdn.jsdelivr.net/gh/cylonchau/blogs@img/img/image-20241129232645456.png

使用cephadm纯离线安装Ceph集群

Sun, 30 Jul 2023 00:00:00 +0000

本文是Ceph集群部署系列第1章使用cephadm纯离线安装Ceph集群使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 开篇常例 - 概述 Ceph 是一个广泛使用的开源存储平台。它提供高性能、可靠性和可扩展性。 Ceph 分布式存储系统提供了对象存储、块存储和文件级存储。 Ceph 旨在提供无单点故障的分布式存储系统。在本教程中，将通过 ceph-adm 方式在 CentOS 7 上安装和构建 Ceph 集群。该实验的 Ceph 集群需要以下 Ceph 组件： Ceph OSD (ceph-osd) - 处理数据存储、数据复制和恢复；通常一个Ceph集群至少需要两台 OSD 服务器。 Ceph Monitor (ceph-mon) - 监视集群状态、OSD 映射和 CRUSH 映射，我们在这里与 cephadm 或 OSD 公用一个节点 Ceph 元数据服务器 (ceph-mds) - 这是使用 CephFS 所需的组件。有了上面的条件，我们实验环境所需要的节点如下：三台服务器节点，CentOS 7 注：CentOS 7 可安装最高级别的 ceph 版本就是 O 版

使用cephadm纯离线安装Ceph集群2

Sun, 30 Jul 2023 00:00:00 +0000

本文是Ceph集群部署系列第2章使用cephadm纯离线安装Ceph集群使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 离线安装 - ceph-mds ceph-mds (metadata server daemon) 是 cephfs 功能中所需要的组件，是用于收集和管理文件系统名称空间，协调和共享 OSD 集群的组件。 cephadm 部署集群所有组件都打包在 ceph 镜像内，只需要修改一遍就可以全局离线安装了要部署 cephfs 就需要有一个或多个 ceph-mds 使用 cephadm 部署 mds bash 1 2 ceph orch apply mds *<fs-name>* --placement="*<num-daemons>* [*<host1>* ...]" ceph orch apply mds kubernetes01 --placement="hostname01,hostname02,hostname03" 删除 mds bash 1 2 ceph config set mon mon_allow_pool_delete true ceph fs volume rm kubernetes01 --yes-i-really-mean-it 离线安装 - Ceph Object Gateway Ceph 从 0.

在 Kubernetes 集群中使用 blackbox exporter监控外部IP

Wed, 12 Jul 2023 00:00:00 +0000

背景在云原生环境中，特别是基于 Kubernetes，集群中的 “服务” 在与外部交互时，例如，一个外部的第三方 Web 服务/API 等，而监控这些不同的 endpoint 诊断服务可用性的一个关键点，这里将阐述基于 Kube-prometheus-stacks 如果做到可以监控外部 IP/URL，例如，HTTP/TCP/ICMP 等。 blackbox_exporter 是 Prometheus 官方维护的 exporter之一，是提供一种用于检测 HTTP/S、DNS、TCP 和 ICMP 端点的可用性。基于 kube-prometheus-stack 安装 blackbox 本文使用了 helm 安装的 prometheus-community/prometheus-blackbox-exporter ，在安装前，需要自行修改要启动的 prober，与是否开启默认的 servicemonitor yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 secretConfig: false config: modules: ping: prober: icmp timeout: 5s icmp: preferred_ip_protocol: "ip4" http_2xx: prober: http timeout: 5s http: valid_http_versions: ["HTTP/1.1", "HTTP/2.

无互联网环境下安装Spinnaker - Offline Install Spinnaker

Mon, 10 Jul 2023 00:00:00 +0000

Prerequisites 具有一个 Kubernetes 集群以部署 Spinnaker 可运行 Docker 的环境 (1 vCPU, 3.75 GB) 或者是 Ubuntu，用以安装 Halyard (用于 spinnaker 的服务) 对象存储 (MinIO)，用于持久化 Spinnaker 的数据对象存储的 Bucket 的访问账号安装执行步骤安装 Halyard 可以直接使用 Docker 方式安装，这个没什么必要性，就是管理工具而已，参考附录1 [1] 首先创建映射目录 bash 1 2 mkdir ~/.hal -pv mkdir ~/.kubeconfig -pv 然后执行 docker run 运行容器 bash 1 2 3 4 5 6 7 docker run -d -p 8084:8084 -p 9000:9000 \ --name halyard --rm \ -v ~/.hal:/home/spinnaker/.hal \ -v ~/.

使用Thanos强化Prometheus

Sun, 02 Jul 2023 00:00:00 +0000

背景 Prometheus 是目前云原生架构中监控解决方案中的基石，而对于 “metrics”，“traces” 和 “logs” 是组成云原生架构中“可观测性”的一个基础，当在扩展 Prometheus，那么 Prometheus 提供的基础架构是无法满足需求的（高可用性和可扩展性），而高可用性与可扩展性是满足不断增长基础设施的一个基本条件。而 Prometheus 本身并没有提供“弹性”的集群配置，也就是说，多个副本的 Prometheus 实例，对于分布在每个 Pod 上的数据也会不一致，这时也需要保证指标的归档问题。并且在一定的集群规模下，问题的出现远远大于 Prometheus 本身的能力，例如：如何经济且搞笑的存储历史数据（TB, PB）？如何快速的查询历史数据？如何合并 Promehtues 多个实例收集来的副本数据？以及多集群间的监控？由于 TSDB 的块同步，Prometheus 严重依赖内存，使得 Prometheus 监控项的扩展将导致集群中的CPU/MEM 的使用加大 .. 解决 Thanos 是一款可以使 Prometheus 获得 ”长期存储“，并具体有”高可用性“ 的 Prometheus 的功能扩展，“Thanos” 源自希腊语“ Athanasios”，英文意思是”不朽“。这也正是 ”Thanos“ 提供的功能：”无限制的对象存储“，并与原生 Prometheus API 高度兼容，你可以理解为 Thanos API 就是 Prometheus API。 Cortexmetrics 与 Thanos 类似，是用通过将 Prometheus 实例的”存储“和”查询“等功能分离到独立的组件中，实现水平扩展。它使用对象存储来持久化历史指标，块存储（TSDB）是他的存储后端；此外，Cortex 还提供了多租户与多租户隔离等功能联邦集群，联邦集群是 Prometheus 官方提供的一个概念，使用了联邦将允许 Prometheus 从另一个 Prometheus 中抓取选定的指标。可以使用的一些模型如下：分层联邦：大规模的集群中，Prometheus 部署模型如一个”树形“，高级别的从多个低级实例中抓取指标，并存储聚合跨服务联邦：Prometheus 从另一个 Prometheus 只抓取指定的数据图：Prometheus 联邦 Source：https://www.

Spinnaker接入keycloak认证

Wed, 21 Jun 2023 00:00:00 +0000

Spinnaker的认证 spinnaker 中提供了认证 ( Authentication) 的机制流为 Deck <=> Gate <=> Identity Provider Deck 是 spinnaker 的 WEB UI (由 apache server服务的一组静态文件) Gate 是 API Gateway，所有的进入 Spinnaker 的流量都会通过 Gate 处理，这里完成 authentication 和 authorization。 Identity Provider：用于用户身份认证的外部服务或系统，例如 LDAP, OAuth 2.0(行业标准鉴权协议), SAML, X.509 等。更多 spinnaker Authentication 工作流可以参考 Spinnaker 认证配置启动配置 bash 1 hal config security authn oauth2 enable --no-validate 使用 hal 命令配置 redirect URI bash 1 hal config security authn oauth2 edit --pre-established-redirect-uri https://my-real-gate-address.

在Kubernetes集群上安装 Calico cni 的注意事项

Wed, 21 Jun 2023 00:00:00 +0000

开始前的实验环境 Resources controller worker-1 worker-2 OS CentOS 7.9 CentOS 7.9 CentOS 7.9 Storage 20GB 20GB 20GB vCPU 2 2 2 RAM 4GB 4GB 4GB NIC 10.0.0.4 10.0.0.4 10.0.0.4 Kubernetes Version 1.19.10 1.19.10 1.19.10 选择匹配 Kubernetes 版本的 Calico 版本通常情况下，查看 Calico 所支持的 Kubernetes 版本，可以通过路径 Install Calico ==> Kubernetes ==> System requirements 可以找到自己的 Kubernetes 集群所支持的 Calico 版本。例如在实验环境中，Kubernetes 1.19 版本所支持的版本有 Calico 3.20，这个时候直接 apply 这个版本提供的资源清单即可如何开启纯 BGP 模式默认情况下下，Calico 使用的是 full mesh 和 IPIP，如果想通过在部署时就修改关闭 IPIP 模式，可以通过修改资源清单中的环境变量来关闭 CALICO_IPV4POOL_IPIP: Never。

Spinnaker template

Tue, 20 Jun 2023 00:00:00 +0000

spinnaker 的模板是通过 spin 命令行去创建的，spin 是 spinnaker 的套件，可以使用 spin 获取到存在的pipeline与 template，还可以创建一个新的模板或者替换就得；cli获取到的数据是 json 类型配置spin bash 1 2 3 4 5 6 7 mkdir ~/spin # Inside the dir, setup ‘config’ file using the sample # https://github.com/spinnaker/spin/blob/master/config/example.yaml #Sample ~/.spin/config gate: endpoint: http://demospin.net:9000/gateauth: enabled: false spin 配置文件 spin 默认从 ~/spin/config 读取配置，可以通过 –config 指定 spin 的配置文件。下面是一个官方给的一个 spin config 的 example，在配置时只需要选择一个认证方式即可 iap/x.509/oauth2 这个选择的是 oauth2 json 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 # NOTE: Copy this file to ~/.

Kubernetes中的资源限制 - Request&Limit

Sat, 17 Jun 2023 00:00:00 +0000

原作者 Javier Martínez 背景在学习 Kubernetes 调度时，有两个重要的概念，“request “与 “limit”，而对应的资源就是“内存” 与 “CPU” ，而这两个决定了 Pod 将如何调度；“request “与 “limit” 也是整个调度系统中的基数因子。什么是 request 和 limit 在 Kubernetes 中，Limit 是容器可以使用的最大资源量，这表示 “容器” 的内存或 CPU 的使用，永远不会超过 Limit 配置的值。而另一方面，Request 则是为 “容器” 保留的最低资源保障；换句话来说，Request 则是在调度时，容器被允许所需的配置。图：Kubernetes 中Limit 和 Request 图示 Source：https://sysdig.com/blog/kubernetes-limits-requests/ 如何配置 request 和 limit 下列清单是 Deployment 的部署清单，他将部署一个 redis 与一个 busybox yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 kind: Deployment apiVersion: extensions/v1beta1 … template: spec: containers: - name: redis image: redis:5.

我在Prometheus监控中高基数问题中的优化之路

Wed, 14 Jun 2023 00:00:00 +0000

背景对于整个 Kubernetes 集群来说，随着业务不断地打磨，新增指标，那么对于 Prometheus 特性来说，那么内存与存储的使用势必是增加。这是对于存储压力是很重的，通常情况下，使用 Prometheus，都会是用于 Kubernetes 集群中，而应用于 Kubernetes 集中的存储势必是 PVC 之类的网络存储。这种场景中，我将尝试拆解如何分析和配置 Prometheus 以显著的减少其资源使用并解决高基数问题高基数基数 (cardinality) 通俗来说是一个集合中的元素数量 [1] 基数的来源通常为： label 的数量 series(指标) 的数量时间：label 或者 series 随时间而流失或增加，通常是增加那么这么看来高基数就是，label, series, 时间这三个集合的笛卡尔积，那么高基数的情况就很正常了。而高基数带来的则是 Prometheus 资源使用，以及监控的性能。下图是 Grafana Lab 提到的一张图，很好的阐述了高基数这个问题图：Prometheus中的基数 Source：https://grafana.com/blog/2022/02/15/what-are-cardinality-spikes-and-why-do-they-matter 如图所示：一个指标 server_responses 他的 label 存在两个 status_code 与 environment ，这代表了一个集合，那他的 label value 是 1~5xx，这个指标的笛卡尔积就是10。那么此时存在一个问题，如何能定位基数高不高，Grafana Lab 给出了下面的数据 [1]，但是我不清楚具体的来源或者如何得到的这些值。也就是 label:value 低基数：1: 5 标准基数：1: 80 高基数：1: 10000 为什么指标会指数级增长在以 Kubernetes 为基础的架构中，随着抽象级别的提高（通常为Pod, Label, 以及更多抽象的拓扑），指标的时间序列也越来越多。因为在这种基础架构中，在传统架构中运行的一个应用的单个裸机，被许多运行分散在许多不同节点上的许多不同微服务的 Pod 所取代。在这些抽象层中的每一个都需要一个标签，以便可以唯一地标识它们，并且这些组件中的每一个都会生成自己的指标，从而创建其独特的时间序列集。

踩坑nginx proxy_pass GET 参数传递

Sat, 20 May 2023 00:00:00 +0000

场景在配置代理后，GET 请求的变量全部失效，配置如下 text 1 2 3 location /fw { proxy_pass http://127.0.0.1:2952; } 我的需求是，/fw/ 的都发往 2952端口，但实际情况是404，原因为“在没有指定 URI 的情况下，在1.12版本后会传递原有的URI” 这时会导致一个404错误，因为我的后端接口本身就是 /fw/xxx/ 会出现重复接下来做了一个变量传递 text 1 2 3 location ~* /fw/(?<section>.*) { proxy_pass http://127.0.0.1:2952/fw/$section; } 这时存在一个问题，就是 GET 请求的变量无法传递过去解决 nginx 官方给出一个样例，说明了，存在某种情况下，nginx 不会确定请求 URI 中的部分参数使用正则表达式时在 localtion 名称内例如，在这个场景下，proxy_pass 就会忽略原有的请求的URI，而将拼接后的请求转发 text 1 2 3 4 location /name/ { rewrite /name/([^/]+) /users?name=$1 break; proxy_pass http://127.0.0.1; } 那么这服务我遇到的问题，nginx官方给出了使用方式当在 proxy_pass 中需要变量，可以使用 $request_uri; 另外也可以使用 $is_args$args 参数来保证原有的请求参数被传递

Docker中的多进程管理 s6-overlay

Thu, 18 May 2023 00:00:00 +0000

什么是容器中的多进程管理在容器中的主进程 (main running process) 是指 Dockerfile中 ENTRYPOINT 或 CMD 指定运行的命令，通常情况下一个进程（服务）为一个容器；也存在一种场景，就是主进程会fork多个子进程，例如nginx，不过这种多进程通常为nginx主进程进行管理。而一些场景下，我们的业务本身就需要多个启用独立的多个进程。在Docker官方提到了在容器中运行多个服务的方式，官方提出，应该避免这种情况 but to get the most benefit out of Docker, avoid one container being responsible for multiple aspects of your overall application. 但也给出了如何管理多进程的一种思路， Use a wrapper script Use Bash job controls Use a process manager 下面就通过官方给出的这三种方式阐述容器中的多进程管理 Use a wrapper script 对于使用脚本来管理多进程来说，本质上是可以实现多进程的启动，但是你没法去监控(管理)多个进程的运行时，例如 Nginx + PHP 模式， PHP或nginx全部挂掉，只要脚本还在运行，那么这个容器的生命周期还是处于Running Use Bash job controls 这种模式是利用了Bash的后台模式进行短暂的切换进程，但有些镜像不提供Bash这时应该怎么办 Use a process manager 进程管理器，通常情况下大家想到的就是顶顶大名的 supervisor 和 systemd，但这两个程序运行的环境十分苛刻，例如 supervisor 是Python开发的程序，运行需要依赖 Python；而 systemd 的运行条件更为苛刻，例如需要额外运行dbus-damon进行注册到dbus总线之上，这种进程管理器可能运行的进程比我们要管理的进程都要多。在这种场景下，有一个部署简单，配置简单，无依赖的轻量级容器多进程管理器 s6-overlay

StackStorm自动化 - 包配置

Thu, 18 May 2023 00:00:00 +0000

基本概念从版本 2.4 开始，如果包包含.config.yaml ，可以使用包配置，包配置可以使用配置文件来设置包中资源通用的值，例如 API 凭证、连接详细信息、限制和阈值。这些值在运行时可供操作和传感器使用。包配置和 Action 参数之间的区别在于，配置通常包含包中所有资源通用的值，并且很少更改。动作参数是随每个动作调用动态提供的，并且可能会发生变化 - 例如，它们可能来自映射某些输入事件的规则。包配置遵循基础架构即代码方法，并存储在特殊目录中的 YAML 格式文件中（默认情况下 /opt/stackstorm/configs）。每个包都为此配置文件定义自己的架构。配置 Schema 配置文件的结构是一个 YAML 格式的文件，它定义了该包的配置文件。该配置由包作者自行编写，包含有关每个可用配置项的信息，例如名称, Secret等）。该文件已命名 config.schema.yaml 并位于包目录 /opt/stackstorm/packs/<mypack> 的根目录中。这是一个示例包配置文件： yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 --- api_key: description: "API key" type: "string" required: true api_secret: description: "API secret" type: "string" secret: true required: true region: description: "API region to use" type: "string" required: true default: "us-east-1" private_key_path: description: "Path to the private key file to use" type: "string" required: false 在该示例中，配置文件由 4 项配置组成 (api_key, api_secret, region, private_key_path)

解决nginx在docker中报错 [rewrite or internal redirection cycle while internally redirecting to "/index.html]

Thu, 18 May 2023 00:00:00 +0000

vue项目部署在裸机Linux上运行正常，部署在docker中nginx出现下列错误 text 1 Nginx "rewrite or internal redirection cycle while internally redirecting to "/index.html" 表现在用户界面 500 Internal Server Error 原因：nginx配置路径不对，改成正确的后恢复

Awesome kubernetes

Wed, 03 May 2023 00:00:00 +0000

Deployment Recommended Cluster Architecture - rancher Hardware recommendations - etcd A simple shell script for backing up etcd v2 and v3 datastores Considerations for large clusters - kubernetes cluster Operating etcd clusters for Kubernetes Recommended performance and scalability practices Binary deploy script pure shell Managing Kubernetes Traffic with F5 NGINX Eraser - Cleaning up Images from Kubernetes Nodes 对于不同规模的 Kubernetes 集群所需要的 etcd 规模推荐 datree: allowing you to scan your k8s configs during development Performance etcd: getting 30% more write/s 蚂蚁集团万级规模 K8s 集群 etcd 高可用建设之路各组件参数配置调优万级K8s集群背后etcd稳定性及性能优化实践 K8s 集群稳定性：LIST 请求源码分析、性能评估与大规模基础服务部署调优 Comparing comparing Kubernetes ingress controller Troubleshooting 一次Etcd集群宕机引发的思考 Stern: allows you to tail multiple pods on Kubernetes Diagnosis Kubernetes 自动化诊断工具：k8sgpt-operator ktop: displays useful metrics information about kubernetes cluster Dashboard KDash - A fast and simple dashboard for Kubernetes Security Kubernetes 加固指南 Popeye 扫描实时 Kubernetes 集群并报告已部署资源和配置的潜在问题 Test kube-monkey It randomly deletes Kubernetes (k8s) pods in the cluster encouraging and validating the development of failure-resilient services.

firewalld去除polkit验证

Wed, 19 Apr 2023 00:00:00 +0000

为什么去除polkit验证在2021年询问过firewalld项目组，firewalld在dbus通讯时，会进行两部认证 policy kit 和 UID checking，正是因为这种情况，使得firewalld不能够通过TCP/IP连接，如果你需要连接，因为存在 UID checking ，这时会因为没有UID会报错。 firewalld needs to do some authorization on the dbus request. It currently tries two ways, in order of preference: policy kit UID checking Neither of these are available over a TCP/IP dbus connection. [1] 如何去除polkit 首选需要确定你的firewalld版本，例如Centos7系列，那么你的 firewalld 版本为 0.6.3，那么你需要修改的包为 python-firewall-0.6.3, 在 debian11 上 firewalld版本默认为 0.9.3，那么需要关注的版本为：python3-firewall_0.9.3 在确定版本后直接从github仓库进行拉去修改就可以 bash 1 2 git fetch v0.9.3 git checkout v0.9.3 对于 python-firewall-0.6.3 来说。直接注释掉 slip.dbus.polkit.require_auth 就可以了

删除github上面的历史提交记录

Sun, 02 Apr 2023 00:00:00 +0000

如果不小心提交github提交错了，而 --amend 也不能修改提交者的信息，可以通过尝试下面的方式 Checkout bash 1 git checkout --orphan <latest_branch> Add all the files bash 1 git add -A Commit the changes bash 1 git commit -am "commit message" Delete the branch bash 1 git branch -D main Rename the current branch to main bash 1 git branch -m main Finally, force update your repository bash 1 git push -f origin main 缺点是：所有该分支的提交记录都将被删除 Reference how to delete all commit history in github?

Unix归档模式Unix ar - 深入剖析与构建deb包

Wed, 29 Mar 2023 00:00:00 +0000

deb 概述 deb包（.deb）是 Debian 和基于 Debian衍生操作系统（如Ubuntu）中使用的一种软件包的格式。deb是一种基于 Unix ar [3] (Unix archiver) 的归档文件。其中包含二进制文件、配置文件和其他软件所需的资源。deb包可用于安装、升级和卸载软件包。通常，Debian操作系统的用户使用apt（Advanced Package Tool）等软件包管理器工具来管理deb包。通过这些工具，用户可以轻松下载、安装和管理软件包，而无需手动编译、安装和解决软件包之间的依赖关系。 deb VS rpm 包的归档格式不同：deb是基于 ar 的归档模式，而RPM是基于 cpio 的归档模式包的结构不同：deb包要求必须包含一个 DEBIAN 目录；而RPM不需要以来额外的目录结构包的依赖机制不同： Deb使用epoch，而RPM使用build number：在Deb中，epoch是一个可选的字段，它允许呈现基准日期之前的先前版本。而在RPM中，build number表示软件包编译的次数。因此，在Deb中，为了解决版本控制问题，epoch是非常重要的，而在RPM中，则更关注build number。 Deb使用逆向依赖关系，而RPM使用依赖关系：在Deb中，依赖项是从包本身向外扩展，在解决依赖问题时可以通过逆向依赖关系进行。而在RPM中，则更喜欢使用依赖关系直接指向其他包。 Deb允许代理软件包，而RPM则不允许代理软件包：Deb中，软件包可以使用另一种软件包的代理来提供功能。在RPM中，软件包需要直接引用相关的软件包。这意味着在Deb中，对于版本控制，可以用另一种代理软件包来解决问题，而在RPM中必须直接引用包。 Deb允许多重依赖关系，RPM则不允许：Deb允许使用多个依赖项列表，以便包与不同版本的库兼容。在RPM中，需要在每个包中定义依赖项和其版本，不能使用多重依赖。 deb包的分析 deb包的结构 deb 最重要的是控制文件 Control ，该文件记录了deb包与其安装的程序的信息。在deb包内部包含一组模拟 Linux 文件系统的文件夹，例如 /usr, /usr/bin, /opt等等。放置在其中一个目录中的文件将在安装期间复制到实际文件系统中的相同位置。因此，例如将二进制文件放入 <.deb>/usr/local/bin/binaryfile 将被安装到 /usr/local/bin/binaryfile. 对于deb 包的命名是遵循着一个特定的格式： text 1 <name>_<version>-<revision>_<architecture>.deb <name> 构建的deb包名称，如nginx <version> 程序的版本号，如1.20 <revision> 当前 deb 包的版本号 <architecture> 表示构建出的包的操作系统架构，如，amd64、i386 如果你构建一个nginx-1.20的arm操作系统下的，那么deb包名格式则为 nginx_1.20-1_arm64.deb control文件 [2] Deb软件包（.

alpine安装网络工具

Wed, 22 Mar 2023 23:00:36 +0800

telnet：busybox-extras net-tools: net-tools tcpdump: tcpdump wget: wget dig nslookup: bind-tools curl: curl nmap: nmap wget ifconfig nc traceroute.. : busybox ssh: openssh-client ss iptables: iproute2 ethtool: ethtool yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 FROM alpine MAINTAINER RUN sed -i 's@http://dl-cdn.alpinelinux.org/@https://mirrors.aliyun.com/@g' /etc/apk/repositories RUN apk add --no-cache --virtual .persistent-deps \ curl \ tcpdump \ iproute2 \ bind-tools \ ethtool \ busybox-extras \ libressl \ openssh-client \ busybox CMD [ "tail", "-f" ]

Linux Dbus中的ACL策略

Wed, 22 Mar 2023 00:00:00 +0000

D-Bus 是 Linux 系统中的一种通信机制，用于在进程之间进行通信。D-Bus 配置文件则是一种用于配置 D-Bus 的文件，其中包含有关系统总线 (system bus)，会话总线 (session bus) 和各种系统服务的详细信息。本文将解析 D-Bus 配置文件，侧重点则为权限的配置配置文件的基本结构 D-Bus 配置文件使用 XML 格式进行编写，具有以下基本结构： xml 1 2 3 4 5 6 7 8 9 10 11 12 <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/D-Bus/1.0/busconfig.dtd"> <busconfig> <policy group="wheel">  </policy> <policy context="default">  </policy> <include filename="other-config.xml"/> <listen>unix:path=/var/run/D-Bus/system_bus_socket</listen> </busconfig> 什么是D-Bus Policy？ D-Bus Policy是D-Bus配置文件中最重要的字段之一，用于定义D-Bus服务的访问控制策略。D-Bus Policy包含了一组规则，用于限制D-Bus服务的使用者对D-Bus服务的访问，确保D-Bus服务的安全性。

Go设计模式

Fri, 10 Mar 2023 00:00:00 +0000

创建型模式工厂模式概念说明工厂模式 (factory pattern) 是在父类中提供一个创建对象的方法，是用于创建不同类型的对象，而无需指定对象的真实的类工厂模式的特点：对客户端隐藏对象创建的复杂逻辑可以通过修改工厂类来创建对象而不影响客户端代码提供创建对象的单一来源。单个工厂类用以各组件保持一致性。允许子类创建对象类型图：工厂设计模式的示意图 Source：https://www.techcrashcourse.com/2015/10/factory-design-pattern.html 图片说明： Owl, Eagle, Sparrow 类都必须实现 Brid 接口，该接口声明了一个名为 fly() 的方法。每个类都将以不同的方式实现该方法。而使用工厂模式后的代码机构则为图所示，当 Owl, Eagle, Sparrow 实现了共同的接口，就可以将其对象传递给客户代码，而无需提供额外数据。而 “调用工厂方法的代码” 称为 “客户端代码”，这样可以做到 “不需要了解不同子类返回实际对象之间的差别”。客户端代码将所有 Brid Sanctuary 视为抽象的 Brid ，这样 ”客户端代码“ 知道所有鸟类对象都提供 fly() 方法，但是并不关心其实现方式。代码实现 brid.go go 1 2 3 4 5 package main type Brid interface { Fly() } Owl.go go 1 2 3 4 5 type Owl struct {} func (g *Owl) Fly() { fmt.

kube-proxy如何保证规则的一致性

Thu, 09 Mar 2023 00:00:00 +0000

本文是关于Kubernetes service解析的第5章深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？深入理解Kubernetes service - kube-proxy架构分析深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy 前景这里谈 kube-proxy 如何保证规则的一致性以及提升 kube-proxy 性能点的地方，这也是 kubernetes 使用稳定性的一部分。 kube-proxy 如何做到的CRUD kube-proxy 实际上与其他内置 controller 架构是相同的，实际上也属于一个 controller ，但它属于一个 service, endpoints 的可读可写的控制器，node的读控制器。对于CRUD方面，kube-proxy，在设计上分为增/改两方面。正如下面代码所示 pkg/proxy/ipvs/proxier.go go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 func (proxier *Proxier) OnServiceAdd(service *v1.Service) { proxier.OnServiceUpdate(nil, service) } // OnServiceUpdate is called whenever modification of an existing service object is observed.

扫盲Kubernetes负载均衡 - 从Ingress聊到LB

Sun, 26 Feb 2023 00:00:00 +0000

概述在之前有一个系列提到了扩展proxier，但可能细心的同学注意到，作为一个外部的LB，市场上存在一些开源的为kubernetes集群提供的LB，这不是舍近求远吗？而 Google工程师 Adam Dunstan 的文章 [1] 对比了这些LB的区别（中文翻译备份 [2] ），例如： MetalLB：最流行的负载均衡控制器 PureLB：新产品 (文章作者 Adam Dunstan 参与了 PureLB的开发工作) OpenELB：相对较新的产品，最初该LB仅关注路由方向文章提出了一个LB实现的基本目标为：必要的简单网络组件，与可扩展的集群操作启动受控的集群service/应用的外部访问外部资源的预配置易于整合自动化的工作流程（CI/CD）那么这些LB与 kube-proxy 甚至于 IPVS/IPTables 有什么区别呢？这些LB的核心是为集群service提供一个外部IP，而service功能本身还是由 kube-proxy,IPVS 提供，在这点 MetalLB 介绍中提到了这个问题 In layer 2 mode, all traffic for a service IP goes to one node. From there, kube-proxy spreads the traffic to all the service’s pods. [3] After the packets arrive at the node, kube-proxy is responsible for the final hop of traffic routing, to get the packets to one specific pod in the service.

红米手机安装 Pixel Experience

Sat, 25 Feb 2023 00:00:00 +0000

前言 MIUI13 石锤了内置反诈APP后，我的是MIUI12, 接到公安的私人电话，系统直接弹出国家反诈的弹窗，关键我是印度版的Rom，一身冷汗，估计当局审查是通过系统组件更新了，直接装Pixel Experience，以后换设备永远不换最新的，让网友们踩坑吧注：隐私是一种权利，电信诈骗请问骗子怎么知道我的金融信息，怎么知道我的出入境信息。上海公安10亿信息泄露是怎么情况，当公权力无法保证用户隐私时，请不要实名制，参考韩国。隐私权参考欧洲操作进入fastboot(power button + volume button up)，然后使用数据线连接至PC(windows),然后下载MiFlash 首次弹出时需要安装驱动，以便PC可以识别到手机给手机安装TWRP [1]，通过搜索找到你的手机型号例如 Redmi Note5。(可以去小米ROM网上对照下你的手机代号时什么例如 Note7 Pro 代号为紫罗兰 violet) 在下载时TWRP网站上会提示你先安装 Play Stroe(这是包含了adb fastboot等工具的工具包，有的话可以不装) 安装步骤可以参考 [2] 选择 Wipe – Advance Wipe – 选上 System, Data, Dalvik, Cache 四个擦除下载 firmware 与 PixelExperience 去 https://download.pixelexperience.org/ 下载 PixelExperience 找到自己的手机型号，参考1 去 https://xiaomifirmwareupdater.com/firmware/ 下载 fireware 找到自己的手机型号，参考1 注：建议直接搜代号如violet，搜型号太多不好找向手机复制 firmware [3] 和固件 fw_violet_miui_VIOLET_9.9.3_79d3ccd33b_9.0.zip PixelExperience_violet-10.0-20191021-1744-BETA-OFFICIAL.zip 复制命令参考 [10] 按先后顺序安装后，重启就安装好google pixel experience了 enjoy 🤞

深入理解Kubernetes service - EndpointSlices做了什么？

Sat, 25 Feb 2023 00:00:00 +0000

本文是关于Kubernetes service解析的第2章深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？深入理解Kubernetes service - kube-proxy架构分析深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy Endpoint Endpoints 就是 service 中后端的server，通常来说 endpoint 与 service是关联的，例如下面的一个endpoints 资源。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 apiVersion: v1 kind: Endpoints metadata: name: nginx subsets: - addresses: - ip: 172.17.0.2 - ip: 172.17.0.3 ports: - port: 80 name: "111" # 多个端口需要用name - port: 88 name: "222" 而 Endpoints 资源是由控制平面的 Endpoints controller 进行管理的，主要用于将外部server引入至集群内时使用的，例如Kube-apiserver 在集群外的地址，以及external service所需要创建的。

深入理解Kubernetes service - 如何扩展现有的kube-proxy架构？

Sun, 12 Feb 2023 00:00:00 +0000

本文是关于Kubernetes service解析的第4章深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？深入理解Kubernetes service - kube-proxy架构分析深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy Overview 在前两部分中，学习了一些 service,于kube-proxy在设计架构，但存在扩展问题将引入了一些问题：为什么需要了解这部分内容呢？与传统架构有什么区别呢？于eBPF 的 cilium又有什么区别呢？既然eBPF可以做到，那为什么要这部分内容呢？接下来的内容将围绕这四个问题展开来讲，而不是代码的讲解，代码可以看置顶 IPVS与iptables在kubernetes中应用时的问题对于在使用了kubernetes用户以及了解 kube-proxy 架构后，知道当集群规模过大时，service必将增多，而一个service未必是一条iptables/ipvs规则，对于kubernetes这种分布式架构来说，集群规模越大，集群状态就越不可控，尤其时kube-proxy。为什么单指kube-proxy呢？想想可以知道，pod的故障或 node 的故障对于kubernetes集群来说却不是致命的，因为这些资源集群中存在避免方案，例如Pod的驱逐。而kube-proxy或iptables/IPVS问题将导致服务的不可控『抖动』例如规则生成的快慢和Pod就绪的快慢不一致，部分节点不存在 service 此时服务必然抖动。再例如 iptables/IPVS 排查的难度对于普通运维工程师或开发工程师的技术水平有很高的要求，网上随处可见分析该类问题的帖子： kube-proxy源码分析与问题定位案例分析：怎么解决海量IPVS规则带来的网络延时抖动问题？ ipvs 连接复用引发的系列问题 Investigating Causes of Jitter in Container Networking ContainerNative network LoadBalancer IPVS jitter 对于上述问题，相信遇到了很难定位处理，虽然现在已fixed，并有eBPF技术的加入减少了此类问题的发生，但是eBPF实际同理于IPVS 都是需要对Linux内核有一定了解后才可以，这也就是为什么需要了解这部分如果需要自定义proxier为什么会解决这个问题这里就是放大到kubernetes意外的传统架构中，当直接部署于Linux系统上使用nginx等传统LB时就很少有人提到这些问题了，而这些问题存在一个关键字「Container」；而引发这个问题的则是 service。去除 service 的功能，传统架构于Kubernetes架构部署的应用则是相同的，只是区分了名称空间。

深入理解Kubernetes service - kube-proxy架构分析

Mon, 06 Feb 2023 00:00:00 +0000

本文是关于Kubernetes service解析的第3章深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？深入理解Kubernetes service - kube-proxy架构分析深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy 前提概述 kubernetes集群中运行在每个Worker节点上的组件 kube-proxy，本文讲解的是如何快速的了解 kube-proxy 的软件架构，而不是流程的分析，专注于 proxy 层面的设计讲解，而不会贴大量的代码 kube-proxy软件设计 kube-proxy 在设计上分为三个模块 server 于 proxy： server: 是一个常驻进程用于处理service的事件 proxy: 是 kube-proxy 的工作核心，实际上的角色是一个 service controller，通过监听 node, service, endpoint 而生成规则 proxier: 是实现service的组件，例如iptables, ipvs…. 如何快速读懂kube-proxy源码要想快速读懂 kube-proxy 源码就需要对 kube-proxy 设计有深刻的了解，例如需要看 kube-proxy 的实现，我们就可以看 proxy的部分，下列是 proxy 部分的目录结构 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 $ tree -L 1 .

深入理解Kubernetes service - 你真的理解service吗？

Mon, 06 Feb 2023 00:00:00 +0000

本文是关于Kubernetes service解析的第1章深入理解Kubernetes service - 你真的理解service吗? 深入理解Kubernetes service - EndpointSlices做了什么？深入理解Kubernetes service - kube-proxy架构分析深入理解Kubernetes service - 如何扩展现有的kube-proxy架构 kube-proxy如何保证规则的一致性所有关于Kubernetes service 部分代码上传至仓库 github.com/cylonchau/kube-haproxy 前景对于了解kubernetes架构时，已知的是 service 是kubernetes在设计时为了避免Pod在频繁创建和销毁时IP变更问题，从而给集群内服务（一组Pod）提供访问的一个入口。而Pod在这里的角色是『后端』( backend ) ，而 service 的角色是『前端』( frontend )。本文将阐述service的生命周期为什么需要了解这部分内容呢对于 without kube-proxy来说，这部分是最重要的部分，因为service的生成不是kube-proxy来完成的，而这部分也就是service ip定义的核心。控制器 service的资源创建很奇妙，继不属于 controller-manager 组件，也不属于 kube-proxy 组件，而是存在于 apiserver 中的一个被成为控制器的组件；而这个控制器又区别于准入控制器。更准确来说，准入控制器是位于kubeapiserver中的组件，而控制器则是存在于单独的一个包，这里包含了很多kubernetes集群的公共组件的功能，其中就有service。这也就是在操作kubernetes时当 controller-manager 于 kube-proxy 未工作时，也可以准确的为service分配IP。首先在构建出apiserver时，也就是代码 cmd/kube-apiserver/app/server.go go 1 2 3 4 serviceIPRange, apiServerServiceIP, err := master.ServiceIPRange(s.PrimaryServiceClusterIPRange) if err !

haproxy 中 http 代理的连接模式

Tue, 31 Jan 2023 00:00:00 +0000

haproxy作为一个『代理软件』如果当工作与 HTTP 模式下，所有经由haproxy的的连接的请求和响应都取决于 frondend 中配置的『http_connection_mode』即 haproxy 中 frontend 与 backend 的组合，而haproxy 支持 3 种连接模式： KAL keep alive: frontend 中配置为 http-keep-alive ; 这是默认模式，这也是http中的keepalive 表示所有请求和响应都得到处理，连接保持打开状态，但在响应和新请求之间处于空闲状态。 SCL server close : frontend 中配置为 http-server-close ; 接收到响应结束后，面向服务器的连接关闭，但面向客户端的连接保持打开状态 CLO close: frontend 中配置为 httpclose ；连接在响应结束后关闭，并在两个方向上附加 “Connection: close” 。下列矩阵表示的是通过 frondend 与 backend 之间两端的代理模式，这个模式是对称的 text 1 2 3 4 5 6 7 | KAL | SCL | CLO ----+-----+-----+---- KAL | KAL | SCL | CLO ----+-----+-----+---- mode SCL | SCL | SCL | CLO ----+-----+-----+---- CLO | CLO | CLO | CLO 对于http选项的说明选项说明 forwardfor 这个选项同时存在于backend 与 frontend端，但backend中的优先级超过frontend 如果同时设置了这个参数，那么 backend段的子参数将优先与 frontend 一端 httpchk 启用http协议检查来检测server的健康状态，默认情况下状态检查是仅建立一个tcp连接 httpclose 这个选项代表了haproxy 对于http协议持久连接方便的配置 Reference：configuration.

git在windows上常用配置

Tue, 24 Jan 2023 00:00:00 +0000

Windows git “warning: LF will be replaced by CRLF” [1] bash 1 git config --global core.autocrlf false Disable Credential Manager bash 1 2 3 4 5 git config --global credential.modalprompt false git credential-manager remove -force git credential-manager uninstall --force Multi account management [2] step1: clean globle setting bash 1 2 git config --global --unset user.name git config --global --unset user.email step2： change config file only ssh bash Do not Pop-ups authtication [3] This question is the git shell prompt input user and password in an openssh popup on windows plateform

Go中的类型断言与类型转换

Tue, 24 Jan 2023 00:00:00 +0000

类型断言类型断言 type assertion 并不是真正的将 interface 类型转换为另一种确定的类型，只是提供了对 interface 类型的值的访问，通常情况下，这是常见的需求类型断言通过语法 x.(T) ，这将会确定 x 变量中存储的值是否属于 T 类型，通常场景有两种：如果 T 不是 interface 类型，而是一个具体的类型，那么这次断言将断言 x 的动态类型是否与 T 相同如果 T 是 interface 类型，这次断言 x 的动态类型是否实现了 T go 1 2 3 4 5 6 7 8 9 10 11 12 var x interface{} = "foo" var s string = x.(string) fmt.Println(s) // "foo" s, ok := x.(string) fmt.Println(s, ok) // "foo true" n, ok := x.

如何使用go语言来检查端口可用性

Fri, 06 Jan 2023 00:00:00 +0000

方法1：dial 使用 net.DialTimeout 去检查端口的技巧：在通过Dial检查端口占用时，需要知道网络中常见的报错状态，而不是 err != nil 都为可用 Connection reset by peer connection reset by peer 这种错误情况下有以下几种场景：基于包过滤的防火墙给予 RST；对于此情况，基于网络模型来说处于网络层与传输层之间的netfilter，如果是防火墙拒绝那么未到应用层无法确认端口对端应用资源限制而reset，通常为负载过高；对于此场景是已到达应用层客户端关闭了连接，而服务器还在给客户端发送数据；对于端口检查来说不会到这步由上面可知，这种错误一定为占用 Connection timed out Connection timed out 这种场景根本就dial不成功，go中给出了一个专门的事件 opErr.Timeout() 来说明这个错误，故此错误将不能确认端口是否占用 Connection refused Connection refused 这种场景催在两种情况对于 local 场景来说，这将表示端口未监听对于远端场景来说，这种基本上表示 client 发往 remote ，remote不能接受 host:port 这个连接通常对于存在两种情况，但多数为端口为监听 Misconfiguration, such as where a user has mistyped the port number, or is using stale information about what port the service they require is running on.

haproxy v1 与 haproxy v2

Wed, 14 Dec 2022 00:00:00 +0000

haproxy1 VS haproxy2 haproxy2由 2019-06-16 被发布，对于与haproxy1版本来说，haproxy 2.0 增加了对云原生的支持，这使得haproxy 2.0 更适用于云原生环境，对比于 haproxy1.0 在2001年发布来，到 1.9.16 在 2020/07/31 最后一次更新也代表haproxy1.0的结束维护为什么选择haproxy2.0 haproxy2.0的核心功能就是集成了云原生架构的支持。包含L7重试, Prometheus metrics, 流量镜像 (traffic shadowing), 多语言可扩展性, gRPC 。haproxy2.0 还增加基于haproxy2.0 的 Kubernetes Ingress Controller 和强大的 HAProxy Data Plane API，这提供了用于配置和管理 HAProxy 的 REST API 安装haproxy2.0 对于 Ubuntu/Debian 来说，社区版haproxy提供了更友好的安装方式，用户直接添加对应仓库可以直接安装最新版本的haproxy Debian/Ubuntu HAProxy packages 对于 CentOS/Fedora 来说，只有Fedora 仓库提供了较为新版的haproxy，通常来在这类平台的Linux都是通过编译安装haproxy 下载haproxy2.6源码 [ haproxy下载 ] 安装依赖包 bash 1 yum install gcc pcre-devel openssl-devel tar make -y 编译程序 bash 1 2 3 4 5 6 7 8 9 tar xf haproxy-2.

长期总结 - Linux性能分析命令

Mon, 12 Dec 2022 00:00:00 +0000

工具命令集合长期总结 - Linux日志查询命令长期总结 - Linux网络命令合集长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例探索kubectl - 巧用jsonpath提取有用数据探索kubectl - kubectl诊断命令集合 perf [1] perf 是基于内核子系统的Linux的性能计数器，也被称为 perf_events，它提供了为所有事件进行性能分析的框架，perf 由两部分组成：内核系统调用，用于提供对这些性能数据的访问用户空间工具，用于提供收集，显示分析这些性能数据的用户空间程序由于 perf 是内核的一部分，但要想使用 perf 还需要安装另外一部分，通常情况下安装的版本是Linux内核版本，如操作系统内核版本为 5.10 那么安装 linux-tool 后则为 5.10 bash 1 2 3 4 $ apt-get install linux-perf $ perf --version perf version 5.10.149 各系统下的包名与安装 Ubuntu/Debian: linux-perf | linux-tools ；apt-get install linux-perf CentOS/Fedora: perf ；yum install -y perf list - 列出可用事件描述符使用 perf 子命令 list 可以列出所有的 perf 可测量事件

debian11更新内核版本

Sun, 11 Dec 2022 00:00:00 +0000

搜索linux 内核 image bash 1 apt-cache search linux-image 然后安装对应image bash 1 sudo apt install linux-image-<flavour> 安装完成后可以看到对应的image bash 1 2 3 4 $ dpkg -l|grep linux-image ri linux-image-5.10.0-16-amd64 5.10.127-2 amd64 Linux 5.10 for 64-bit PCs (signed) ii linux-image-5.10.0-16-amd64-dbg 5.10.127-2 amd64 Debug symbols for linux-image-5.10.0-16-amd64 ii linux-image-amd64 5.10.127-2 amd64 Linux for 64-bit PCs (meta-package) 可以通过命令查看拥有的内核启动项 bash 1 grep -e "menuentry " -e submenu -e linux /boot/grub/grub.cfg 需要修改至新内核可以修改 /etc/default/grub 下的 GRUB_DEFAULT= 这里要填的值为上面命令查询出的，例如 menuentry 'Debian GNU/Linux, with Linux 5.

理解Kubernetes驱逐核心 - Pod QoS

Thu, 01 Dec 2022 00:00:00 +0000

服务质量 Quality of Service (QoS)，在Kubernetes是用于解决资源抢占，延迟等方向的一种技术，是服务于调度与抢占之间的条件。 QoS 级别 QoS 与资源限制紧密相关，正如下属展示，是一个Pod资源限制部分的配置 yaml 1 2 3 4 5 6 7 resources: limits: cpu: 200m memory: 1G requests: cpu: 500m memory: 1G 而Kubernetes 将Pod QoS 根据 CPU 与内存的配置，将QoS分为三个等级： Guaranteed：确保的，只设置 limits 或者 requests 与 limits 为相同时则为该等级 Burstable：可突发的，只设置 requests 或 requests 低于 limits 的场景 Best-effort：默认值，如果不设置则为这个等级为什么要关心Pod QoS级别在Kubernetes中，将资源分为两类：可压缩性资源 “CPU”，不可压缩性资源 “内存”。当可压缩性资源用尽时，不会被终止与驱逐，而不可压缩性资源用尽时，即Pod内存不足，此时会被OOMKiller杀掉，也就是被驱逐等操作，而了解Pod 的QoS级别可以有效避免关键Pod被驱逐。图：Pod QoS分类 Source：https://doc.kaas.thalesdigital.io/docs/BestPractices/QOS 有上图可知，BestEffort 级别的 Pod 能够使用节点上所有资源，浙江导致其他 Pod 出现资源问题。所以这类 Pod 优先级最低，如果系统没有内存，将首先被杀死。 Pod是如何被驱逐的当节点的计算资源不足时，kubelet 会发起驱逐，这个操作是为了避免系统OOM事件，而QoS的等级决定了驱逐的优先级，没有限制资源的 BestEffort 类型的Pod最先被驱逐，接下来资源使用率低于 Requests 的 Guaranteed 与 Burstable 将不会被其他Pod的资源使用量而驱逐，其次对于此类Pod而言，如果Pod使用了比配置（Requests）更多的资源时，会根据这两个级别Pod的优先级进行驱逐。 BestEffort 与 **Burstable **将按照先优先级，后资源使用率顺序进行驱逐

kubernetes概念 - 理解Kubernetes的驱逐机制

Tue, 29 Nov 2022 00:00:00 +0000

驱逐 (eviction) 是指终止在Node上运行的Pod，保证workload的可用性，对于使用Kubernetes，了解驱逐机制是很有必要性的，因为通常情况下，Pod被驱逐是需要解决驱逐背后导致的问题，而想要快速定位就需要对驱逐机制进行了解。 Pod被驱逐原因 Kubernetes官方给出了下属Pod被驱逐的原因：抢占驱逐 (Preemption and Eviction) [1] 节点压力驱逐 (Node-pressure) [2] 污点驱逐 (Taints) [3] 使用API发起驱逐 (API-initiated) [4] 排出Node上的Pod (drain) [5] 被 controller-manager 驱逐抢占和优先级抢占是指当节点资源不足以运行新添加的Pod时，kube-scheduler 会检查低优先级Pod而后驱逐掉这些Pod以将资源分配给优先级高的Pod。这个过程称为 “抢占” 例如这个实例是 kube-proxy 被驱逐的场景节点压力驱逐节点压力驱逐是指，Pod所在节点的资源，如CPU, 内存, inode等，这些资源被分为可压缩资源CPU (compressible resources) 与不可压缩资源 (incompressible resources) 磁盘IO, 内存等，当不可压缩资源不足时，Pod会被驱逐。对于此类问题的驱逐是每个计算节点的 kubelet 通过捕获 cAdvisor 指标来监控节点的资源使用情况。被 controller-manager 驱逐 kube-controller-manager 会定期检查节点的状态，如节点处于 NotReady 超过一定时间，或Pod部署长时间失败，这些Pod由控制平面 controller-manager 创建新的Pod已替换存在问题的Pod 通过API发起驱逐 Kubernetes为用户提供了驱逐的API，用户可以通过调用API来实现自定义的驱逐。对于 1.22 以上版本，可以通过API policy/v1 进行驱逐 bash 1 2 3 4 5 6 7 8 9 10 11 curl -v \ -H 'Content-type: application/json' \ https://your-cluster-api-endpoint.

深入理解Kubernetes 4A - Audit源码解析

Thu, 24 Nov 2022 00:00:00 +0000

本文是关于Kubernetes 4A解析的第4章深入理解Kubernetes 4A - Authentication源码解析深入理解Kubernetes 4A - Authorization源码解析深入理解Kubernetes 4A - Admission Control源码解析深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A Overview 审计是信息系统中非常重要的一部分，Kubernetes 1.11中也增加了审计 (Auditing) 功能，通过审计功能获得 deployment, ns,等资源操作的事件。 objective：从设计角度了解Auditing在kubernets中是如何实现的了解kubernetes auditing webhook 完成实验，通过webhook来收集审计日志如有错别字或理解错误地方请多多担待，代码是以1.24进行整理，实验是以1.19环境进行，差别不大。 Kubernetes Auditing 根据Kubernetes官方描述审计在kubernetes中是有控制平面 kube-apiserver 中产生的一个事件，记录了集群中所操作的资源，审计围绕下列几个维度来记录事件的：发生了什么发生的事件谁触发的发生动作的对象在哪里检查到动作的从哪触发的处理行为是什么审计生命周期开始于组件 kube-apiserver 准入控制阶段，在每个阶段内都会产生审计事件并经过预处理后写入后端，目前后端包含webhook与日志文件。审计日志功能增加了 kube-apiserver 的内存消耗，因为会为每个请求存储了审计所需的上下文。内存的消耗取决于审计日志配置 [1]。审计事件设计审计的schema不同于资源API的设计，没有 metav1.ObjectMeta 属性，Event是一个事件的结构体，Policy是事件配置，属于kubernetes资源，在代码 k8s.io/apiserver/pkg/apis/audit/types.go 可以看到 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 type Event struct { metav1.

深入理解Kubernetes 4A - Authorization源码解析

Thu, 24 Nov 2022 00:00:00 +0000

本文是关于Kubernetes 4A解析的第2章深入理解Kubernetes 4A - Authentication源码解析深入理解Kubernetes 4A - Authorization源码解析深入理解Kubernetes 4A - Admission Control源码解析深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A Overview 在 Kubernetes 中，当一个访问请求通过了登录阶段（Authentication），必须还需要请求拥有该对象的访问权限，而授权部分也是Kubernetes API 访问控制中的第二个部分 Authorization . Authorization 在 Kubernetes中是以评估发起请求的用户，根据其身份特性评估这次请求是被 ”拒绝“ 还是 “允许”，同访问控制三部曲中其他两个插件 (Authentication, Adminssion Control) 一样，Authorization 也可以同时配置多个，当收到用户的请求时，会依次检查这个阶段配置的所有模块，如果任何一个模块对该请求授予权限（拒绝或允许），那么该阶段会直接返回，当所有模块都没有该用户所属的权限时，默认是拒绝，在Kubernetes中，被该插件拒绝的用户显示为HTTP 403。如有错别字或理解错误地方请多多担待，代码是以1.24进行整理，实验是以1.19环境进行，差别不大 objective：了解kubernetes Authorization机制了解授权系统的设计完成实验，使用 OPA 作为 Kubernetes 外部用户，权限认证模型 RBAC 的替代品 Kubernetes是如何对用户授权的 kubernetes对用户授权需要遵守的shema必须拥有下列属性，代码位于pkg\apis\authorization\types.go go 1 2 3 4 5 6 7 8 9 type SubjectAccessReview struct { // API必须实现的部分 metav1.

深入理解Kubernetes 4A - Authentication源码解析

Wed, 16 Nov 2022 00:00:00 +0000

本文是关于Kubernetes 4A解析的第1章深入理解Kubernetes 4A - Authentication源码解析深入理解Kubernetes 4A - Authorization源码解析深入理解Kubernetes 4A - Admission Control源码解析深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A Overview 本章主要简单阐述kubernetes 认证相关原理，最后以实验来阐述kubernetes用户系统的思路 objective：了解kubernetes 各种认证机制的原理了解kubernetes 用户的概念了解kubernetes authentication webhook 完成实验，如何将其他用户系统接入到kubernetes中的一个思路如有错别字或理解错误地方请多多担待，代码是以1.24进行整理，实验是以1.19环境进行，差别不大。 Kubernetes 认证在Kubernetes apiserver对于认证部分所描述的，对于所有用户访问Kubernetes API（通过任何客户端，客户端库，kubectl 等）时都会经历验证 (Authentication) , 授权 (Authorization), 和准入控制 (Admission control) 三个阶段来完成对 “用户” 进行授权，整个流程正如下图所示图：Kubernetes API 请求的请求处理步骤图 Source：https://www.armosec.io/blog/kubernetes-admission-controller/ 其中在大多数教程中，在对这三个阶段所做的工作大致上为： Authentication 阶段所指用于确认请求访问Kubernetes API 用户是否为合法用户，拒绝为401 Authorization 阶段所指的将是这个用户是否有对操作的资源的权限，拒绝为403 Admission control 阶段所指控制对请求资源进行控制，通俗来说，就是一票否决权，即使前两个步骤完成

理解ldap - 使用SSSD接入OpenLDAP实现身份验证

Tue, 15 Nov 2022 00:00:00 +0000

ipset性能测试

Fri, 04 Nov 2022 00:00:00 +0000

测试方法基于使用场景，最后⽣成的规则会是按照 ip 或者 ip:port 来进行过滤，测试时将使用10万条 iptables 规则来模拟对性能的压力；为了最大化测试压力情况，10万条 iptables 规则将都是==不会匹配==机房流量，通俗来讲，就是链式匹配会进行所有匹配并最后以无匹配告终。网络负载的模拟将使用同机房 scp 来模拟，并按照下述条件进行匹配：查看正常的拷贝速度，cpu负载等我们建⽴10万条的普通 iptables 规则，查看规则建立速度，拷贝速度，CPU负载，CPU主要耗时操作等我们建⽴10万的 ipset ，并把普通的 iptables 规则转为结合 ipset 的规则，查看规则建立速度，拷贝速度，CPU负载，CPU主要耗时等。实验开始步骤一：在同机房的⼀个机器构造⼀个大文件同机房拷贝观察网卡速度，CPU，系统主要耗时操作的等，此场景将在iptables 规则为空的情况下进行观察使用 sar 观测网卡速度使用 top 观察CPU负载使用 perf top -G 观察CPU占用步骤二：创建10万条iptables，观察⽹卡速度、cpu、系统主要耗时操作的等，会发现cpu利⽤率⼤部分被ipt占⽤，拷⻉速度下降到不到⼗分之⼀ bash 1 2 3 4 5 6 7 8 #!/bin/bash echo *filter for ((i=1;i<=$1;i++)) do echo -I INPUT -S $i -j ACCEPT done echo COMMIT 执行脚本 bash 1 $ time .

Linux网络栈

Fri, 28 Oct 2022 00:00:00 +0000

Linux 架构概述 [1] 本章节简单阐述Linux系统的结构，并讨论子系统中的模块之间以及与其他子系统之间的关系。 Linux内核本身鼓励无用，是作为一个操作系统的一部分参与的，只有为一个整体时他才是一个有用的实体，下图展示了Linux操作系统的分层图：Linux子系统分层图 Source：https://docs.huihoo.com/linux/kernel/a1/index.html 由图可以看出Linux操作系统由四部分组成：用户应用 OS服务，操作系统的一部分（例如shell）内核编程接口等内核硬件控制器，CPU、内存硬件、硬盘和NIC等都数据这部分 Linux内核阐述 Linux内核将所有硬件抽象为一致的接口，为用户进程提供了一个虚拟接口，使用户无需知道计算机上安装了哪些物理硬件即可编写进程，并且Linux支持用户进程的多任务处理，每个进程都可以视作为操作系统的唯一进程独享硬件资源。内核负责维护多个用户进程，并协调其对硬件资源的访问，使得每个进程都可以公平的访问资源，并保证进程间安全。 Linux内核主要为五个子系统组成：进程调度器(SCHED)，控制进程对 CPU 的访问。调度程序执行策略，确保进程可以公平地访问 CPU。内存管理器 (MM)，允许多个进程安全地共享操作系统的内存虚拟文件系统 (VFS)，向所有设备提供通用文件接口来抽象出各种硬件设备网络接口 (NET)，提供对多种网络标准与各种网络硬件的访问进程间通信 (IPC)，在单个操作系统上的多种机制进程间通信机制网络子系统架构 [2] 网络子系统功能主要是允许 Linux 系统通过网络连接到其他系统。支持多种硬件设备，以及可以使用的多种网络协议。网络子系统抽象了这两个实现细节，以便用户进程和其他内核子系统可以访问网络，而不必知道使用什么物理设备或协议。子系统模块包含网络设备驱动层 (Network device drivers)，网络设备驱动程序与硬件设备通信。每个硬件设备都有对应的设备驱动程序模块。独立设备接口层(device independent interface)，设备独立接口提供了所有硬件设备的统一视图，因此在网络子系统之上的级别无需了解硬件信息网络协议层 (network protocol)，网络协议实现了网络传输的协议协议独立/无关接口层 (protocol independent interface)，提供了独立于硬件设备的网络接口，为内核内其他子系统访问网络时不依赖特定的协议和硬件接口。系统调用层 (system call) 用于限制用户进程导出资源的访问网络子系统的结构图如下图所示，图：网络子系统中的上下文 Source：https://docs.huihoo.com/linux/kernel/a1/index.html 当网络子系统转换为网络栈时，如下图所示图：ISO Stack与TCP/IP Stack Source：https://www.washington.edu/R870/Networking.html 当然Linux网络子系统是类似于TCP/IP栈的一种结构，当发生一个网络传输时，数据包会按照所经过的层进行封装。例如应用层应用提供了REST API，那么应用将要传输的数据封装为HTTP协议，然后传递给向下的传输层。传输层是TCP协议就会被添加对应的TCP包头。整个封装过程原始包保持不变，会根据所经过层的不同增加固定格式的包头。图：数据包传输在每层被封装的过程 Source：http://www.embeddedlinux.org.cn/linux_net/0596002556/understandlni-CHP-13-SECT-1.html 对于Linux来说TCP/IP 的五层结构则是构成网络子系统的的核心组件，下图是Linux网络栈结构图图：Linux网络栈的结构图 Source：https://medium.com/geekculture/linux-networking-deep-dive-731848d791c0 图中橙色部分是位于TCP/IP的五层结构中的应用层，应用层向下通讯通过 system call 与 socket接口进行交互蓝色部分是位于内核空间，socket向下则是传输层与网络层最底层是物理层包含网卡驱动与NIC 通过图可以看出，NIC是发送与接收数据包的基本单位，当系统启动时内核通过驱动程序向操作系统注册网卡，当数据包到达网卡时，被放入队列中。内核通过硬中断，运行中断处理程序，为网络帧分配内核数据结构(sk_buff)，并将其拷贝到缓冲区中，此为内核与网卡交互的过程。

为什么网络是分层的

Fri, 28 Oct 2022 00:00:00 +0000

Overview [1] 协议数据单元 Protocol Data Unit (PDU) 是应用于OSI模型中的数据结构，在OSI模型中每一层都会被添加一个header，tailer进行封装，header, tailer加原始报文的组合就是PDU。在每层中，PDU的名称都是不同的，这也是很多人的疑问，一会数据报文称为数据包，一会数据报文成为数据帧，该文介绍网络中的单元，以了解之间的区别物理层物理层数据的呈现方式是以 “位” (bit) 为单位的，即0 1，在该层中数据以二进制形式进行传输数据链路层 [2] 到达数据链路层，实际上可以说进入了TCP/IP栈对底层，而该层的单位为 ”帧“ (frame)，该层中，MAC地址会被封装到数据包中，比如以太网帧，PPP帧都是指该层的数据包该层中数据帧包含：源MAC 目的MAC 数据，由网络层给出的数据的总长度校验序列网络层 [3] 在网络层中协议数据单元被称为数据 “包" (package) ，是网络间节点通讯的基本单位。该层中IP地址会被封装到数据包内。该层中数据包包含：标头：源IP，目的IP，协议，数据包编号，帮助数据包匹配网络的位 payload：数据包的主体标尾：包含几个位，用于告知已到达数据包的末尾与错误检查（循环冗余检查 (CRC)）图：数据包组成 Source：https://computer.howstuffworks.com/question525.htm 例如一个电子邮件，假设电子邮件大小尾3500bit，发送时使用1024的固定大小数据包进行发送，那么每个数据包标头为 96bits，标尾为 32bit，剩余 896bits 将用于实际的数据大小。这里为3500bits，会被分为4个数据包，前三个数据包为 896bits，最后一个数据包大小为 812bits。接收端会根据包编号进行解包重组传输层 Segment 在传输层TCP协议的协议数据单元被称为 ”段“ (Segment) ，上面讲到，IP数据包会以固定大小的数据包进行发送，如果超出大小的会被划分为多个数据包，每个数据包的碎片就被称之为Segment。数据包分割通常会发生在该层，当发生下列场景时会需要分段数据包大于网络支持的最大传输单元 (MTU) 网络不可靠，将数据包分为更小的包 datagram [4] 在传输层UDP协议的协议数据单元被称为 ”数据报“ (datagram) ，datagram是一种逐层增加的设计，用于无连接通讯下图是一个UDP数据报被封装位一个IP数据包：IPv4字段值位17 表示udp协议图：udp的IP包 Source：https://notes.shichao.io/tcpv1/ch10 对于udp数据报的组成包含header与payload，udp的header大小为固定的8字节源端口：可选目的端口：识别接收信息的进程 Length：udp header + udp payload的长度，最小值为8 checksum：与lenght一样其实是多余的，因为第三层包含了这两个信息图：udp数据报组成 Source：https://notes.

科普ebpf

Sun, 02 Oct 2022 00:00:00 +0000

eBPF介绍 eBPF是 Extended Berkeley Packet Filter，主要是用于包过滤的。为什么叫Berkeley Packet Filter 是因为论文出自 Lawrence Berkeley Laboratory（相对的论文可以参考 [1]）。“E" 是使BPF不仅仅是包过滤。 eBPF 目前提供的功能不仅仅是包过滤，它是一个允许用户在操作系统内核加载自定义程序的框架，来自于 ”What Is eBPF?“ eBPF is a framework that allows users to load and run custom programs within the kernel of the operating system. That means it can extend or even modify the way the kernel behaves. [2] eBPF验证器对于如果想改变Linux内核功能需要合并代码到内核或者编写内核模块。前者需要被社区接受，这需要很长一个周期；而后者可以很好的扩展内核功能，但都存在一个问题 ”==安全运行==“ ”安全运行“ 问题包含”漏洞“和“崩溃”，考虑到这些，eBPF为安全运行提供了一个非常不同的方法**：eBPF verifier** ，eBPF verifier 将确保应用只能够在安全情况下被运行。 eBPF verifier 保证了 eBPF 程序运行的 ”安全“ 和 ”验证“

ch0 ide

Wed, 28 Sep 2022 00:00:00 +0000

Visual Studio使用离线安装包在页面 [4] 下载安装引导命令，下载完成后使用命令（对于C++来说） bat 1 vs_Professional.exe --layout ‪1111 --add Microsoft.VisualStudio.Workload.NativeDesktop --includeRecommended --lang en-US zh-CN 随后会触发下载，等待下载完成后，在 --layout 指定的目录上点击 vs_setup 开始离线安装。 Note: 对于完全脱离C盘安装可以使用下面的脚本，更改变量为要安装的路径 bat 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 :: 关闭终端回显 @echo off SET ROOT_PATH=D:\Program Files\Microsoft Visual Studio SET X86_PATH=%ROOT_PATH%\Program Files (x86) SET X86_VS_PATH=%X86_PATH%\Microsoft Visual Studio SET X86_SDK_PATH=%X86_PATH%\Microsoft SDKs SET X86_KITS_PATH=%X86_PATH%\Windows Kits SET X86_AV_PATH=%X86_PATH%\Application Verifier SET X64_PATH=%ROOT_PATH%\Program Files rem SET X64_VS_PATH=%X64_PATH%\Microsoft Visual Studio SET X64_AV_PATH=%X64_PATH%\Application Verifier SET X64_SQL_PATH=%X64_PATH%\Microsoft SQL Server SET PD_PATH=%ROOT_PATH%\ProgramData SET PD_VS_PATH=%PD_PATH%\Microsoft\VisualStudio SET PD_PC_PATH=%PD_PATH%\Package Cache @echo =======link directory to %ROOT_PATH%=======: SET S_X86_SKD_PATH=C:\Program Files (x86)\Microsoft SDKs SET S_X86_VS_PATH=C:\Program Files (x86)\Microsoft Visual Studio SET S_X86_KITS_PATH=C:\Program Files (x86)\Windows Kits SET S_X86_AV_PATH=C:\Program Files (x86)\Application Verifier SET S_X64_AV_PATH=C:\Program Files\Application Verifier SET S_X64_SQL_PATH=C:\Program Files\Microsoft SQL Server SET S_PD_VS_PATH=C:\ProgramData\Microsoft\VisualStudio SET S_PD_PC_PATH=C:\ProgramData\Package Cache pause @echo =======setting visual studio environment=======: @echo =======check directory exist=======: if not exist %ROOT_PATH% ( echo "%ROOT_PATH%目录不存在，已创建该目录！" md "%ROOT_PATH%" ) if not exist %X86_PATH% ( echo "%X86_PATH%目录不存在，已创建该目录！" md "%X86_PATH%" ) if not exist %X86_VS_PATH% ( echo "%X86_VS_PATH%目录不存在，已创建该目录！" md "%X86_VS_PATH%" ) if not exist %X86_SDK_PATH% ( echo "%X86_SDK_PATH%目录不存在，已创建该目录！" md "%X86_SDK_PATH%" ) if not exist %X86_KITS_PATH% ( echo "%X86_KITS_PATH%目录不存在，已创建该目录！" md "%X86_KITS_PATH%" ) if not exist %X86_AV_PATH% ( echo "%X86_AV_PATH%目录不存在，已创建该目录！" md "%X86_AV_PATH%" ) if not exist %X64_PATH% ( echo "%X64_PATH%目录不存在，已创建该目录！" md "%X64_PATH%" ) if not exist %X64_AV_PATH% ( echo "%X64_AV_PATH%目录不存在，已创建该目录！" md "%X64_AV_PATH%" ) if not exist %X64_SQL_PATH% ( echo "%X64_SQL_PATH%目录不存在，已创建该目录！" md "%X64_SQL_PATH%" ) if not exist %PD_PATH% ( echo "%PD_PATH%目录不存在，已创建该目录！" md "%PD_PATH%" ) if not exist %PD_VS_PATH% ( echo "%PD_VS_PATH%目录不存在，已创建该目录！" md "%PD_VS_PATH%" ) if not exist %PD_PC_PATH% ( echo "%PD_PC_PATH%目录不存在，已创建该目录！" md "%PD_PC_PATH%" ) @echo =======link directory to %ROOT_PATH%=======: :: x86 link mklink /j "%S_X86_SKD_PATH%" "%X86_SDK_PATH%" mklink /j "%S_X86_VS_PATH%" "%X86_VS_PATH%" mklink /j "%S_X86_KITS_PATH%" "%X86_KITS_PATH%" mklink /j "%S_X86_AV_PATH%" "%X86_AV_PATH%" :: x64 link mklink /j "%S_X64_AV_PATH%" "%X64_AV_PATH%" mklink /j "%S_X64_SQL_PATH%" "%X64_SQL_PATH%" :: ProgramData link mklink /j "%S_PD_VS_PATH%" "%PD_VS_PATH%" mklink /j "%S_PD_PC_PATH%" "%PD_PC_PATH%" pause VS快捷键快捷键含义 Ctrl + k,Ctrl + f 自动格式化代码 Ctrl + k,Ctrl + c 注释代码 Ctrl + k,Ctrl + u 取消注释代码 F9 设置断点 F5 调试运行 Ctrl + F5 不调试运行 Ctrl + Shift + b 编译，不运行 F10 next调试 F11 step调试调试添加行号：工具–》选项 –》文本编辑器–》C/C++ –》行号

ch01 变量和数据类型

Wed, 28 Sep 2022 00:00:00 +0000

C语言关键字 [1] ==C语言有32个关键字== auto：定义自动变量，主要是声明变量的生存周期 break, continue : break 语句在遇到最内层循环时立即终止。还用于终止 switch 语句。 case, switch, default：使用 switch 和 case 语句声明一个switch分支 char：用于声明character 类型的变量 const：声明常量 do…while： double： double-precision 浮点数变量类型 float：single-precision 浮点数的变量类型 if, else：声明if/else 条件判断 enum：用于声明枚举类型 extern：关键字声明变量或函数在其声明的文件之外具有外部链接。 for：C 语言的三种循环之一，for循环 goto：用于将程序的控制权转移到指定的标签 int：声明 integer 类型的变量 short, long, signed, unsigned：是类型修饰符，它们改变基本数据类型的含义以产生新类型。 short int： -32768 to 32767 long int： -2147483648 to 214743648 signed int： -32768 to 32767 unsigned int： 0 to 65535 return：终止函数并返回值 sizeof：评估变量或常量的大小 register：创建比普通变量快得多的寄存器变量。 static：创建一个静态变量。静态变量的值持续到程序结束。 struct：用于声明结构体。结构体可以包含不同类型的变量。 typedef：用于将类型与标识符显式关联。 union：用于将不同类型的变量分组在一个名称下。 void：没有任何意义，函数修饰为没有返回值，参数修饰为没有参数 volatile：提醒编译器它后面所定义的变量随时都有可能改变 C语言控制语句 ==C语言有9种控制语句== (control statements)

ch02 格式化与流程控制

Wed, 28 Sep 2022 00:00:00 +0000

格式化 printf printf() 用于打印消息以及变量的值。 c 1 2 3 4 5 6 7 8 #include<stdio.h> int main() { int a = 24; printf("Welcome! \n"); printf("The value of a : %d",a); getchar(); return 0; } sprintf sprintf() 不打印字符串，是将字符值和格式化结构一并存储在一个数组中。 c 1 2 3 4 5 6 7 8 9 10 11 12 13 int main() { char buffer[50]; int a = 10, b = 20, c; c = a + b; sprintf(buffer, "Sum of %d and %d is %d", a, b, c); // The string "sum of 10 and 20 is 30" is stored // into buffer instead of printing on stdout printf("%s", buffer); return 0; } scanf 从标准输入读取用户输入的

ch03 数组

Wed, 28 Sep 2022 00:00:00 +0000

Array [1] 数组是由单个元素组成的一组数据类型的变量数组的元素存储在连续的内存位置声明数组时应提及数组的大小数组的计数从0开始数组为一位数组与多维数组数组首元素的地址与数组地址相同数组包含 int, float, char, double 数据类型 Declaration and Initialization 表达式说明 int my_array1[20]; 指定大小，来声明一个有20个元素的int数组 char my_array2[5]; 指定大小，来声明一个有5个元素的char数组 int my_array[] = {100, 200, 300, 400, 500} 声明时初始化一个数组（编译器自动求数组元素个数） int my_array1[5] = {100, 200, 300, 400, 500}; 声明时初始化 int my_array2[5] = {100, 200, 300}; 声明时初始化（剩余未初始化的元素，默认 0 值） int my_array2[5] = {0}; 声明时初始化（声明一个全0值的数组） int arr[10]; arr[0] = 5;arr[1] = 6;arr[2] = 7; 声明数组并初始化值（这种方法为初始化部分的默认值为随机数） char str[] = “zhangsan” 声明一个字符串（字符串是一个char类型数组） Advantages and Disadvantages 缺点**：大小限制**：声明（定义）后是固定的大小，不能通过运行时改变其大小

ch04 函数

Wed, 28 Sep 2022 00:00:00 +0000

concept [1] 函数 (function) 是执行任务的语句块。函数的作用：提高代码的可重用性并减少冗余代码模块化代码易读性使代码模块化函数的分类 C语言中有两种类型的函数：标准库函数：C中的内置函数，在头文件中定义 #include <stdio.h> 用户自定义函数：用户自定义的函数 #include "stdio.h" 函数三部曲 C语言中函数分为三个方面，声明(declaration)，定义(defining)，调用(calling) 声明声明是让编译器知道函数的名称、参数信息、参数的返回值的类型。 c 1 (type) function_name({type args...}); 隐式声明(implicit) ：当在main之后定义的函数而未声明，默认编译器会做隐式声明。 ISO/IEC 9899:1990 中关于函数声明的部分：函数在调用前必须有一个可用的声明，如果没有被声明，则该函数默认被隐式声明，该隐式声明没有参数，返回值为int [2] 定义 C中函数定义的语法如下 c 1 2 3 4 return_type function_name(arg1, arg2, ... argn) { function body // 函数中要处理任务的逻辑 } return_type：函数返回值的数据类型 function_name：函数名 arg1, arg2, …argn：参数列表（可选），定义传递给函数的数据类型、顺序和参数的数量。 function body：调用函数时任务处理和执行的语句调用调用是指要由编译器执行的函数，可以在任何部分调用虚函数void 如果函数没有返回值，则使用关键字 void，主要用于两个方面：打印具体信息供用户阅读的函数引用参数，函数通常不是用于返回一个内容，而是修改引用参数的，无需返回值 void 关键字使用注意： void仅用于限定函数返回值，函数参数，不可以修饰变量，因为无法对无类型的变量分配指针

ch05 指针

Wed, 28 Sep 2022 00:00:00 +0000

指针指针声明 [1] 指针/指针变量 (pointer) 是用于存储地址的变量使用 & 运算符来访问变量的地址。例如 c 1 2 3 4 5 6 7 #include <stdio.h> void main() { int a = 100; printf("%x", &a); } 输出结果为 16进制的内存地址 c 1 61fe1c 使用地址运算符 * 可以从变量地址中获取变量的值，这个行为被称为间接引用/解引用(indirection/dereferencing)。例如： c 1 2 3 4 5 6 7 8 9 #include <stdio.h> void main() { int a = 100; printf("%d", *(&a)); // 也可以写为，因为*与&优先级相同，从右到左的顺序，所以有没有()意思是相同的 printf("%d", *&a); } 输出结果为 100 指针变量指针变量是指存储一个变量的地址的变量，可以使用符号 * 来修饰变量，定义语法为：

ch06 内存布局

Wed, 28 Sep 2022 00:00:00 +0000

Overview 在编写程序时包含任意指令如，已初始化和未初始化数据，局部变量，函数等都是用于动态分配内存的指令。当程序编译后（默认生成 x.out 文件）这是一个可执行的链接文件( Executable and linking format)。在执行时这些不组织成几部分，包含不同的内存分段 (segments) ELF：这是系统中标准二进制格式，其一些功能包含，动态链接，动态加载，对程序运行时控制。可以使用 size {ELF_file} 查看被分配的每个段的大小（Linux操作系统）； dec 列给出的是这个程序 text + data + bss 段的总大小，用十进制表示 text 段是存储可执行命令的段 data 段包含所有初始化数据，全局与静态变量 BSS 段包含未初始化数据 bash 1 2 3 $ size 1 text data bss dec hex filename 1843 584 8 2435 983 1 Memory Layout in C [1] 在C语言中内存布局模型包含六个部分命令行参数 (Command Line Arguments) 栈 (Stack) 堆 (Heap) 未初始化数据段 (Uninitialized Data Segment BSS) 已初始化数据段 (Initialized Data Segment) 文本/代码段 (Text/Code Segment) 这6部分结构可以再划分为两种类型：

ch07 复合类型

Wed, 28 Sep 2022 00:00:00 +0000

Overview C语言中复合类型 (composite type) 是指用户自定义类型，通常由多种元素组成的类型，其元素被紧密存储在内存中。C语言常见的复合类型有：数组字符串结构体联合类型结构体 [1] 结构体 (structure) 是指用户定义的数据类型，允许将不同类型的多个元素组合在一起，来创建出更复杂的数据类型，类似于数组，但又区别于数组，数组只能保存同类型的元素，而结构体可以保存不同类型的元素。定义声明结构体的语法如下 c 1 2 3 4 5 6 struct structureName { dataType memberVariable1; datatype memberVariable2; ... } variable01, variable02...; 这里需要注意的一些地方： struct是关键字，structureName定义的新数据类型，variable{}是作为使用 structureName 声明的新变量名每个成员方法结尾都是 “;" 而不是逗号 ”," 结构体不能递归变量可以有多个例如声明一个学生的结构体，而student是作为一个新的数据类型存在 c 1 2 3 4 5 6 struct student { char name[20]; int roll; char gender; }; Notes：在定义（创建）结构体变量前，结构体成员不会占用内存声明使用结构体声明变量也可以一次性定义结构体和声明变量 c 1 2 3 4 5 6 7 8 9 10 11 12 13 struct student { char name[20]; int roll; char gender; } stu1,stu2; // 结构体名称可以省略 struct { char name[20]; int roll; char gender; } stu1,stu2; 赋值在声明结构体后，student结构体只是自定义数据结构，要使用还需要进行初始化，或者赋值

ch08 文件处理

Wed, 28 Sep 2022 00:00:00 +0000

文件类型文件是指以字节的形式存储的数据源，使用C语言将文件数据以输出输出的形式处理叫做文件处理。文件在C语言中以两种形式存在：文本文件：文本文件是简单的文件类型，这些文件内容以 ASCII 字符格式存储信息。二进制文件：二进制文件以 0 和 1 的二进制格式存储数据，不是人类可读的文件文件指针文件指针 (FILE) 是一种数据类型，是被定义在 stdio.h 中的一种结构体，包含了文件的一些信息 c 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 typedef struct { // fill/empty level of buffer int level; // File status flags unsigned flags; // File descripter char fd; // ungetc char if no buffer unsigned char hold; // buffer size int bsize; // data transfer buffer unsigned char *buffer; // Current active pointer unsigned char *curp; //Temporary file indicator unsigned istemp; //Used for validity checking short token; } FILE; // This is FILE object 文件指针通常被用于处理正在访问的文件，fopen() 是用于打开文件并返回文件的 FILE 指针，而后通过文件只恨进行I/O操作。fopen() 会发生下列事件：

漏桶算法与令牌桶算法

Sun, 28 Aug 2022 00:00:00 +0000

Principle of token bucket 随着互联网的发展，在处理流量的方法也不仅仅为 first-come，first-served，而在共享网络中实现流量管理的基本机制就是排队。而公平算法则是实现在优先级队列中基于哪些策略来排队的 “公平队列” 。Token Bucket 则是为公平排队提供了替代方案。Fair Queue 与 Token Bucket的区别主要在，对于Fair Queue来讲，如果请求者目前空闲，Queue会将该请求者的带宽分配给其他请求者；而 Token Bucket 则是分配给请求者的带宽是带宽的上限。通过例子了解算法原理假设出站带宽是 4个数据包/ms，此时有一个需求为，为一个特定的发送端 A 来分配 1个数据包/ms的带宽。此时可以使用公平排队的方法分给发送 A 25%的带宽。此时存在的问题是我们希望可以灵活地允许 A 的数据包以无规则的时间间隔发送。例如假设 A 在每个数据包发送后等待1毫秒后再开始下一个数据包的发送。 sence1：此时假设 A 以 1ms 的间隔去发送数据包，而由于某种原因导致应该在 t=6 到达的数据包却在 t=6.5 到达。随后的数据包在 t=7 准时到达，在这种情况下是否应该保留到t=7.5？ sence2：或者是否允许在 t=6.5 发送一个迟到的数据包，在 t=7 发送下一个数据包，此时理论上平均速率仍然还是 1 个数据包/ms？显然sence2是合理的，这个场景的解决方法就是令牌桶算法，规定 A 的配额，允许指定平均速率和突发容量。当数据包不符合令牌桶规范，那么就认为其不合理，此时会做出一下相应： delay，直到桶准备好 drop mark，标记为不合规的数据包 delay 被称为整形 shaping , shaping 是指在某个时间间隔内发送超过 Bc（Committed Burst）的大小，Bc 在这里指桶的尺寸。由于数据流量是突发性的，当在一段时间内不活动后，再次激活后的在一个间隔内发送的数量大于 Bc ，那么额外的流量被称为Be （burst excess）。将流量丢弃或标记超额流量，保持在一个流量速率限制称为 “管制” policing。

Kubernetes Pod网络排错思路

Wed, 17 Aug 2022 00:00:00 +0000

本文是关于深入理解Kubernetes网络原理系列第4章深入理解Kubernetes Pod网络原理 - 网络名称空间深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将引入一个思路：“在Kubernetes集群发生网络异常时如何排查”。文章将引入Kubernetes 集群中网络排查的思路，包含网络异常模型，常用工具，并且提出一些案例以供学习。 Pod常见网络异常分类网络排查工具 Pod网络异常排查思路及流程模型 CNI网络异常排查步骤案例学习 Pod网络异常网络异常大概分为如下几类：

深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1

Wed, 17 Aug 2022 00:00:00 +0000

本文是关于深入理解Kubernetes网络原理系列第4章深入理解Kubernetes Pod网络原理 - 网络名称空间深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路概述本文将简述探讨 Kubernetes 中常见的网络模型，以及对这些网络模型的 route path 进行分析。本章节是作为CNI 原理的前置条件，也为后续的练习提供一些基础知识。

基于Prometheus的Kubernetes网络调度器

Mon, 08 Aug 2022 00:00:00 +0000

Overview 本文将深入讲解如何扩展 Kubernetes scheduler 中各个扩展点如何使用，与扩展scheduler的原理，这些是作为扩展 scheduler 的所需的知识点。最后会完成一个实验，基于网络流量的调度器。 kubernetes调度配置 kubernetes集群中允许运行多个不同的 scheduler ，也可以为Pod指定不同的调度器进行调度。在一般的Kubernetes调度教程中并没有提到这点，这也就是说，对于亲和性，污点等策略实际上并没有完全的使用kubernetes调度功能，在之前的文章中提到的一些调度插件，如基于端口占用的调度 NodePorts 等策略一般情况下是没有使用到的，本章节就是对这部分内容进行讲解，这也是作为扩展调度器的一个基础。 Scheduler Configuration [1] kube-scheduler 提供了配置文件的资源，作为给 kube-scheduler 的配置文件，启动时通过 --onfig= 来指定文件。目前各个kubernetes版本中使用的 KubeSchedulerConfiguration 为， 1.21 之前版本使用 v1beta1 1.22 版本使用 v1beta2 ，但保留了 v1beta1 1.23, 1.24, 1.25 版本使用 v1beta3 ，但保留了 v1beta2，删除了 v1beta1 下面是一个简单的 kubeSchedulerConfiguration 示例，其中 kubeconfig 与启动参数 --kubeconfig 是相同的功效。而 kubeSchedulerConfiguration 与其他组件的配置文件类似，如 kubeletConfiguration 都是作为服务启动的配置文件。 yaml 1 2 3 4 apiVersion: kubescheduler.config.k8s.io/v1beta1 kind: KubeSchedulerConfiguration clientConnection: kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig Notes: --kubeconfig 与 --config 是不可以同时指定的，指定了 --config 则其他参数自然失效 [2]

如何理解kubernetes调度框架与插件？

Wed, 27 Jul 2022 00:00:00 +0000

调度框架 [1] 本文基于 kubernetes 1.24 进行分析调度框架（Scheduling Framework）是Kubernetes 的调度器 kube-scheduler 设计的的可插拔架构，将插件（调度算法）嵌入到调度上下文的每个扩展点中，并编译为 kube-scheduler 在 kube-scheduler 1.22 之后，在 pkg/scheduler/framework/interface.go 中定义了一个 Plugin 的 interface，这个 interface 作为了所有插件的父级。而每个未调度的 Pod，Kubernetes 调度器会根据一组规则尝试在集群中寻找一个节点。 go 1 2 3 type Plugin interface { Name() string } 下面会对每个算法是如何实现的进行分析在初始化 scheduler 时，会创建一个 profile，profile是关于 scheduler 调度配置相关的定义 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 func New(client clientset.Interface, .

kube-scheduler的调度上下文

Thu, 21 Jul 2022 00:00:00 +0000

Scheduler Scheduler 是整个 kube-scheduler 的一个 structure，提供了 kube-scheduler 运行所需的组件。 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 type Scheduler struct { // Cache是一个抽象，会缓存pod的信息，作为scheduler进行查找，操作是基于Pod进行增加 Cache internalcache.Cache // Extenders 算是调度框架中提供的调度插件，会影响kubernetes中的调度策略 Extenders []framework.Extender // NextPod 作为一个函数提供，会阻塞获取下一个ke'diao'du NextPod func() *framework.QueuedPodInfo // Error is called if there is an error. It is passed the pod in // question, and the error Error func(*framework.

kubernetes的决策组件 - kube-scheduler原理分析

Mon, 18 Jul 2022 00:00:00 +0000

Overview [1] kubernetes集群中的调度程序 kube-scheduler 会 watch 未分配节点的新创建的Pod，并未该Pod找到可运行的最佳（特定）节点。那么这些动作或者说这些原理是怎么实现的呢，让我们往下剖析下。对于新创建的 pod 或其他未调度的 pod来讲，kube-scheduler 选择一个最佳节点供它们运行。但是，Pod 中的每个容器对资源的要求都不同，每个 Pod 也有不同的要求。因此，需要根据具体的调度要求对现有节点进行过滤。在Kubernetes集群中，满足 Pod 调度要求的节点称为可行节点（ feasible nodes FN）。如果没有合适的节点，则 pod 将保持未调度状态，直到调度程序能够放置它。也就是说，当我们创建Pod时，如果长期处于 Pending 状态，这个时候应该看你的集群调度器是否因为某些问题没有合适的节点了调度器为 Pod 找到 FN 后，然后运行一组函数对 FN 进行评分，并在 FN 中找到得分最高的节点来运行 Pod。调度策略在决策时需要考虑的因素包括个人和集体资源需求、硬件/软件/策略约束（constraints）、亲和性 (affinity) 和反亲和性（ anti-affinity ）规范、数据局部性、工作负载间干扰等。如何为pod选择节点？ kube-scheduler 为pod选择节点会分位两部：过滤 (Filtering) 打分 (Scoring) 过滤也被称为预选（Predicates），该步骤会找到可调度的节点集，然后通过是否满足特定资源的请求，例如通过 PodFitsResources 过滤器检查候选节点是否有足够的资源来满足 Pod 资源的请求。这个步骤完成后会得到一个包含合适的节点的列表（通常为多个），如果列表为空，则Pod不可调度。打分也被称为优选（Priorities），在该步骤中，会对上一个步骤的输出进行打分，Scheduer 通过打分的规则为每个通过 Filtering 步骤的节点计算出一个分数。完成上述两个步骤之后，kube-scheduler 会将Pod分配给分数最高的 Node，如果存在多个相同分数的节点，会随机选择一个。 kubernetes的调度策略 Kubernetes 1.21之前版本可以在代码 kubernetes\pkg\scheduler\algorithmprovider\registry.go 中看到对应的注册模式，在1.22 scheduler 更换了其路径，对于registry文件更换到了kubernetes\pkg\scheduler\framework\plugins\registry.go ；对于kubernetes官方说法为，调度策略是用于“预选” (Predicates )或过滤（filtering ）和用于优选（Priorities）或评分 (scoring)的

深入理解Kubernetes 4A - Admission Control源码解析

Mon, 11 Jul 2022 00:00:00 +0000

本文是关于Kubernetes 4A解析的第3章深入理解Kubernetes 4A - Authentication源码解析深入理解Kubernetes 4A - Authorization源码解析深入理解Kubernetes 4A - Admission Control源码解析深入理解Kubernetes 4A - Audit源码解析 TLS Everywhere - 解密kubernetes集群的安全认证所有关于Kubernetes 4A部分代码上传至仓库 github.com/cylonchau/hello-k8s-4A 如有错别字或理解错误地方请多多担待，代码是以1.24进行整理，实验是以1.19环境进行，差别不大 BACKGROUND admission controllers的特点：可定制性：准入功能可针对不同的场景进行调整。可预防性：审计则是为了检测问题，而准入控制器可以预防问题发生可扩展性：在kubernetes自有的验证机制外，增加了另外的防线，弥补了RBAC仅能对资源提供安全保证。下图，显示了用户操作资源的流程，可以看出 admission controllers 作用是在通过身份验证资源持久化之前起到拦截作用。在准入控制器的加入会使kubernetes增加了更高级的安全功能。图：Kubernetes API 请求的请求处理步骤图 Source：https://kubernetes.io/blog/2019/03/21/a-guide-to-kubernetes-admission-controllers/ 这里找到一个大佬博客画的图，通过两张图可以很清晰的了解到admission webhook流程，与官方给出的不一样的地方在于，这里清楚地定位了kubernetes admission webhook 处于准入控制中，RBAC之后，push 之前。图：Kubernetes API 请求的请求处理步骤图（详细） Source：https://www.armosec.io/blog/kubernetes-admission-controller/ 两种控制器有什么区别？根据官方提供的说法是 Mutating controllers may modify related objects to the requests they admit; validating controllers may not 从结构图中也可以看出，validating 是在持久化之前，而 Mutating 是在结构验证前，根据这些特性我们可以使用 Mutating 修改这个资源对象内容（如增加验证的信息），在 validating 中验证是否合法。

如何为visio扩展云服务图标

Wed, 06 Jul 2022 00:00:00 +0000

各个云厂商都会为自己的服务提供通用可缩放矢量图形 (SVG) 图标，以便用户为自己的软件绘制架构图，例如Microsoft 为Visio 提供 Azure 服务的图标。文本在这里简单整理了几个关于云服务的图标 Azure-Design 提供了大量并完整的azure的一些图标 AWS-Architecture-Icons 提供了一些关于AWS的图标，不过图标为2019年时的 Microsoft-Integration-and-Azure 整合了一些关于微软的图标，并附带了矢量图更多的图标可以在github或google搜索相关关键词 visio stencil 网络上还是有很多相关的图标库将图标导入到visio中为了能使下载的图标在Visio 中可用，只需要简单的一个步骤即可。将下载下来的图标放置到 C:\Users\<UserName>\Documents\My Shapes 中文系统为用户目录\文档\我的图形我的图形需要安装visio后才会有这个文件夹如图所示：测试导入后的效果，我们在这里导入了aws与azure的图标库，故可以看到有两个，但是两个中又包含很多，已经足够使用了最后再附上一个大神制作的 VISIO Protable 版本，匿名网盘，失效不补

使nginx支持分布式追踪

Sat, 02 Jul 2022 00:00:00 +0000

Background NGINX 是一个通用且流行的应用程序。也是最流行的 Web 服务器，它可用于提供静态文件内容，但也通常与其他服务一起用作分布式系统中的组件，在其中它用作反向代理、负载均衡或 API 网关。分布式追踪 distributed tracing 是一种可用于分析与监控应用程序的机制，将追踪在从源到目的的整个过程中的单个请求，这与仅通过单个应用程序域来追踪请求的形式不同。换句话说，我们可以说分布式追踪是对跨多个系统的多个请求的拼接。拼接通常由一个或多个相关 ID 完成，并且跟踪通常是一组记录的、跨所有系统的结构化日志事件，存储在一个中心位置。在这种背景的情况下， OpenTracing 应运而生。OpenTracing 是一个与应用供应商无关的 API，它可帮助开发人员轻松地跟踪单一请求的域。目前有多种开源产品都支持 OpenTracing（例如，Jaeger, skywalking 等），并将其作为一种检测分布式追踪的标准化方法。本文将围绕，从0到1实现在nginx配置分布式追踪的架构的简单实例说明。本文实例使用的组件为 nginx v1.22 jaeger-all-in-on v1.38 nginx-opentracing v1.22 jaeger-client-cpp v0.9 源码构建nginx-opentracing 准备nginx-opentracing nginx-opentracing 仓库中可以看到，官方为每个nginx版本都提供了一个编译好的动态库（Nginx1.19.13+），我们可以直接拿来使用这个动态库，如果你想将这个利用Nginx 提供的编译参数 --add-module=/path/to/module 构建为nginx的内置功能的话，可能会出现一些问题，例如下面的一些错误： text 1 ngx_http_opentracing_module.so/config was found bash 1 2 3 /root/nginx-opentracing-0.25.0/opentracing//src/ngx_http_opentracing_module.cpp In file included from /root/nginx-opentracing-0.25.0/opentracing//src/ngx_http_opentracing_module.cpp:1:0: /root/nginx-opentracing-0.25.0/opentracing//src/load_tracer.h:3:38: fatal error: opentracing/dynamic_load.h: No such file or directory 根据 issue 中查询得知 nginx-opentracing 需要嵌入到nginx中，是需要一些 opentracing-cpp 因为对c++不熟，尝试调试很久还是上面的错误，故直接使用了官方提供的动态库。

利用kubernetes中的leader选举机制自定义HA应用

Wed, 29 Jun 2022 00:00:00 +0000

Backgroud 前一章中，对kubernetes的选举原理进行了深度剖析，下面就通过一个example来实现一个，利用kubernetes提供的选举机制完成的高可用应用。对于此章需要提前对一些概念有所了解后才可以继续看下去 leader election mechanism RBCA Pod runtime mechanism Implementation 代码实现如果仅仅是使用Kubernetes中的锁，实现的代码也只有几行而已。 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 package main import ( "context" "flag" "fmt" "os" "os/signal" "syscall" "time" metav1 "k8s.

源码分析Kubernetes HA机制 - leader election

Tue, 28 Jun 2022 00:00:00 +0000

Overview 在 Kubernetes的 kube-controller-manager , kube-scheduler, 以及使用 Operator 的底层实现 controller-rumtime 都支持高可用系统中的leader选举，本文将以理解 controller-rumtime （底层的实现是 client-go）中的leader选举以在kubernetes controller中是如何实现的。 Background 在运行 kube-controller-manager 时，是有一些参数提供给cm进行leader选举使用的，可以参考官方文档提供的参数来了解相关参数。 bash 1 2 3 4 5 6 7 --leader-elect Default: true --leader-elect-renew-deadline duration Default: 10s --leader-elect-resource-lock string Default: "leases" --leader-elect-resource-name string Default: "kube-controller-manager" --leader-elect-resource-namespace string Default: "kube-system" --leader-elect-retry-period duration Default: 2s ... 本身以为这些组件的选举动作时通过etcd进行的，但是后面对 controller-runtime 学习时，发现并没有配置其相关的etcd相关参数，这就引起了对选举机制的好奇。怀着这种好奇心搜索了下有关于 kubernetes的选举，发现官网是这么介绍的，下面是对官方的说明进行一个通俗总结。simple leader election with kubernetes 通过阅读文章得知，kubernetes API 提供了一中选举机制，只要运行在集群内的容器，都是可以实现选举功能的。 Kubernetes API通过提供了两个属性来完成选举动作的 ResourceVersions：每个API对象唯一一个ResourceVersion Annotations：每个API对象都可以对这些key进行注释注：这种选举会增加APIServer的压力。也就对etcd会产生影响

源码分析Kubernetes controller组件 - controller-runtime

Mon, 27 Jun 2022 00:00:00 +0000

Overview controller-runtime 是 Kubernetes 社区提供可供快速搭建一套实现了controller 功能的工具，无需自行实现Controller的功能了；在 Kubebuilder 与 Operator SDK 也是使用 controller-runtime 。本文将对 controller-runtime 的工作原理以及在不同场景下的使用方式进行简要的总结和介绍。 controller-runtime structure controller-runtime 主要组成是需要用户创建的 Manager 和 Reconciler 以及 Controller Runtime 自己启动的 Cache 和 Controller 。 Manager：是用户在初始化时创建的，用于启动 Controller Runtime 组件 Reconciler：是用户需要提供来处理自己的业务逻辑的组件（即在通过 code-generator 生成的api-like而实现的controller中的业务处理部分）。 Cache：一个缓存，用来建立 Informer 到 ApiServer 的连接来监听资源并将被监听的对象推送到queue中。 Controller：一方面向 Informer 注册 eventHandler，另一方面从队列中获取数据。controller 将从队列中获取数据并执行用户自定义的 Reconciler 功能。图：controller-runtime structure 图：controller-runtime flowchart 由图可知，Controller会向 Informer 注册一些列eventHandler；然后Cache启动Informer（informer属于cache包中），与ApiServer建立监听；当Informer检测到资源变化时，将对象加入queue，Controller 将元素取出并在用户端执行 Reconciler。 Controller引入我们从 controller-rumtime项目的 example 进行引入看下，整个架构都是如何实现的。可以看到 example 下的实际上实现了一个 reconciler 的结构体，实现了 Reconciler 抽象和 Client 结构体

扩展Kubernetes API的另一种方式 - APIServer aggregation

Wed, 22 Jun 2022 00:00:00 +0000

Overview What is Kubernetes aggregation Kubernetes apiserver aggregation AA 是Kubernetes提供的一种扩展API的方法，目前并没有GA Difference between CRD and AA 众所周知，kubernetes扩展API的方法大概为三种：CRD、AA、手动扩展源码。根据CNCF分享中Min Kim说的AA更关注于实践，而用户无需了解底层的原理，这里使用过 kubebuilder， code-generator 的用户是很能体会到这点。官方也给出了CRD与AA的区别 API Access Control Authentication CR: All strategies supported. Configured by root apiserver. AA: Supporting all root apiserver’s authenticating strategies but it has to be done via authentication token review api except for authentication proxy which will cause an extra cost of network RTT. Authorization CR: All strategies supported. Configured by root apiserver.

kubernetes代码生成器 - code-generator

Mon, 20 Jun 2022 00:00:00 +0000

Overview Kubernetes中提供了多种自定义控制器的方式： code-generator kubebuilder Operator Controller 作为CRD的核心，这里将解释如何使用 code-generator 来创建自定义的控制器，作为文章的案例，将完成一个 Firewalld Port 规则的控制器作为描述，通过 Kubernetes 规则来生成对应节点上的 iptables规则。 Prerequisites CRD yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: ports.firewalld.fedoraproject.org spec: group: firewalld.fedoraproject.org scope: Namespaced names: plural: ports singular: port kind: PortRule shortNames: - fp versions: - name: v1 served: true storage: true schema: openAPIV3Schema: type: object properties: spec: type: object properties: name: type: string port: type: integer host: type: string isPermanent: type: boolean code-generator 需要预先下载 code-generator 。因为这个工具不是必需要求的。

手写一个kubernetes controller

Mon, 20 Jun 2022 00:00:00 +0000

Overview 根据Kuberneter文档对Controller的描述，Controller在kubernetes中是负责协调的组件，根据设计模式可知，controller会不断的你的对象（如Pod）从当前状态与期望状态同步的一个过程。当然Controller会监听你的实际状态与期望状态。 Writing Controllers go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 package main import ( "flag" "fmt" "os" "time" v1 "k8s.

使用CRD扩展Kubernetes API

Sun, 19 Jun 2022 00:00:00 +0000

Kubernetes的主节点或控制面板当中主要有三个组件，其中apiserver是整个系统的数据库，借助于Cluster Store（etcd）服务，来实现所有的包括用户所期望状态的定义，以及集群上资源当前状态的实时记录等。 etcd是分布式通用的K/V系统 KV Store ，可存储用户所定义的任何由KV Store所支持的可持久化的数据。它不仅仅被apiserver所使用，如flannel、calico二者也需要以etcd来保存当前应用程序对应的存储数据。任何一个分布式应用程序几乎都会用到一个高可用的存储系统。 apiserver将etcd所提供的存储接口做了高度抽象，使用户通过apiserver来完成数据存取时，只能使用apiserver中所内建支持的数据范式。在某种情况之下，我们所期望管理的资源或存储对象在现有的Kubernetes资源无法满足需求时。 Operator本身是建构在StatefulSet以及本身的基本Kubernetes资源之上，由开发者自定义的更高级的、更抽象的自定义资源类型。他可借助于底层的Pod、Service功能，再次抽象出新资源类型。更重要的是，整个集群本身可抽象成一个单一资源。为了实现更高级的资源管理，需要利用已有的基础资源类型，做一个更高级的抽象，来定义成更能符合用户所需要的、可单一管理的资源类型，而无需去分别管理每一个资源。在Kubernetes之上自定义资源一般被称为扩展Kubernetes所支持的资源类型，自定义资源类型 CRD Custom Resource Definition 自定义apiserver 修改APIServer源代码，改动内部的资源类型定义 CRD是kubernetes内建的资源类型，从而使得用户可以定义的不是具体的资源，而是资源类型，也是扩展Kubernetes最简单的方式。 Intorduction CRD 什么是CRD 在 Kubernetes API 中，resources 是存储 API 对象集合的endpoint。例如，内置 Pod resource 包含 Pod 对象的集合。当我们想扩展API，原生的Kubernetes就不能满足我们的需求了，这时 CRD (CustomResourceDefinition) 就出现了。在 Kubernetes 中创建了 CRD 后，就可以像使用任何其他原生 Kubernetes 对象一样使用它，从而利用 Kubernetes 的所有功能、如安全性、API 服务、RBAC 等。 Kubernetes 1.7 之后增加了对 CRD 自定义资源二次开发能力来扩展 Kubernetes API，通过 CRD 我们可以向 Kubernetes API 中增加新资源类型，而不需要修改 Kubernetes 源码来创建自定义的 API server，该功能大大提高了 Kubernetes 的扩展能力。创建 CRD 前提条件： Kubernetes 服务器版本必须不低于版本 1.

OSI模型与IP协议

Sat, 18 Jun 2022 00:00:00 +0000

OSI Model OSI 七层网络模型如下（由下到上）：应用层 Application layer ：直接接触用户数据的层。软件应用程序依靠应用层发起通信。这里的应用值得是协议而不是客户端软件；应用层协议包括 HTTP, SMTP, FTP, DNS,Telnet, etc.. 表示层 Presentation layer：表示层充当角色为网络数据转换器，负责完成数据转换，加密和压缩会话层 Session layer：负责建立、管理和终止两个设备之间的通信传输层 Transport layer：负责两个设备间的端到端通信。包括从会话层提取数据，将数据分解为多个区块（称为数据段）；传输层协议包括，TCP, UDP 网络层 Network layer：负责管理网络地址，定位设备，决定路由，通俗来讲是负责*“不同”*网络之间的传输，也就是路由功能；网络层协议包括 IP,ARP,ICMP；代表设备 3 layer swtich, router, firewall。相应就代表对应网络协议也是三层的，如RIP, OSPF, BGP 数据链路层 Data link layer：数据链路层负责*“同一”*网络上设备之间的数据传输；该层协议包括 Ethernet, PPP(Point-to-Point Protocol)；代表设备 Switch,Bridges，同样的MAC地址也是该层的物理层 Physical layer：该层表示参与数据传输的物理设备，如网线，同时还负责将数据转换为位流，也就是由 1 和 0 构成的字符串。图：OSI七层模型 Source：https://www.cloudflare.com/zh-cn/learning/ddos/glossary/open-systems-interconnection-model-osi/ MAC MAC地址介绍 MAC (Media Access Control) 地址用来定义网络设备的位置，由48比特长，12位的16进制组成，其中从左到右，0-23bit为厂商想IETF等机构申请用来标识厂商的代码OUI Organizationally-Unique Identifier，24-47bit由厂商自行分配，是厂商制造所有网卡的唯一编号。如00-50-56-C0-00-08 MAC地址类型 MAC地址分为三种类型：物理MAC地址：Mac地址唯一的标识了以太网的一个终端，该地址为全球唯一的硬件地址。广播(broadcast) MAC地址：每个比特都是 1 的 MAC 地址。广播 MAC 地址是组播 MAC 地址的一个特例。11111111-11111111-11111111-11111111-11111111-11111111 16进制表示为 FF-FF-FF-FF-FF-FF。组播(multicast) MAC地址：第一个字节的最低位是 1 的 MAC 地址。二进制表示为 xxxxxxx1-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx ；16进制表示为01-00-00-00-00-00。如 a5-a9-a6-aa-5a-a6 这个mac地址的第一个字节的最低位 16进制a5 转换为二进制为10100101 最后一位为1就是组播MAC地址。单播 (unicast) MAC 地址：第一个字节的最低位是 0 的 MAC 地址 xxxxxxx0-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx。静态MAC地址由用户通过命令配置的静态转发的MAC地址，静态MAC地址和动态MAC地址的功能不同，静态地址一旦被加入，该地址在删除之前将一直有效，不受最大老化时间的限制

源码分析client-go架构 - queue

Fri, 17 Jun 2022 00:00:00 +0000

通用队列在kubernetes中，使用go的channel无法满足kubernetes的应用场景，如延迟、限速等；在kubernetes中存在三种队列通用队列 common queue ，延迟队列 delaying queue，和限速队列 rate limiters queue Inferface Interface作为所有队列的一个抽象定义 go 1 2 3 4 5 6 7 8 type Interface interface { Add(item interface{}) Len() int Get() (item interface{}, shutdown bool) Done(item interface{}) ShutDown() ShuttingDown() bool } Implementation go 1 2 3 4 5 6 7 8 9 10 11 12 13 type Type struct { // 一个work queue queue []t // queue用slice做存储 dirty set // 脏位，定义了需要处理的元素，类似于操作系统，表示已修改但为写入 processing set // 当前正在处理的元素集合 cond *sync.

KNN算法

Wed, 01 Jun 2022 00:00:00 +0000

Overview K近邻值算法 KNN (K — Nearest Neighbors) 是一种机器学习中的分类算法；K-NN是一种非参数的惰性学习算法。非参数意味着没有对基础数据分布的假设，即模型结构是从数据集确定的。它被称为惰性算法的原因是，因为它**不需要任何训练数据点来生成模型。**所有训练数据都用于测试阶段，这使得训练更快，测试阶段更慢且成本更高。如何工作 KNN 算法是通过计算新对象与训练数据集中所有对象之间的距离，对新实例进行分类或回归预测。然后选择训练数据集中距离最小的 K 个示例，并通过平均结果进行预测。如图所示：一个未分类的数据（红色）和所有其他已分类的数据（黄色和紫色），每个数据都属于一个类别。因此，计算未分类数据与所有其他数据的距离，以了解哪些距离最小，因此当K= 3 （或K= 6 ）最接近的数据并检查出现最多的类，如下图所示，与新数据最接近的数据是在第一个圆圈内（圆圈内）的数据，在这个圆圈内还有 3 个其他数据（已经用黄色分类），我们将检查其中的主要类别，会被归类为紫色，因为有2个紫色球，1个黄色球。 KNN算法要执行的步骤将数据分为训练数据和测试数据选择一个值 K 确定要使用的距离算法从需要分类的测试数据中选择一个样本，计算到它的 n 个训练样本的距离。对获得的距离进行排序并取 k最近的数据样本。根据 k 个邻居的多数票将测试类分配给该类。影响KNN算法性能的因素用于确定最近邻居的距离的算法用于从 K 近邻派生分类的决策规则用于对新示例进行分类的邻居数如何计算距离测量距离是KNN算法的核心，总结了问题域中两个对象之间的相对差异。比较常见的是，这两个对象是描述主题（例如人、汽车或房屋）或事件（例如购买、索赔或诊断）的数据行。汉明距离汉明距离（Hamming Distance）计算两个二进制向量之间的距离，也简称为二进制串 binary strings 或位串 bitstrings ；换句话说，汉明距离是将一个字符串更改为另一个字符串所需的最小替换次数，或将一个字符串转换为另一个字符串的最小错误数。示例：如一列具有类别 “红色”、“绿色” 和 “蓝色”，您可以将每个示例独热编码为一个位串，每列一个位。注：独热编码 one-hot encoding：将分类数据，转换成二进制向量表示，这个二进制向量用来表示一种特殊的bit（二进制位）组合，该字节里，仅容许单一bit为1，其他bit都必须为0 如： apple banana pineapple 1 0 0 0 1 0 0 0 1 100 表示苹果，100就是苹果的二进制向量 010 表示香蕉，010就是香蕉的二进制向量

决策边界算法

Wed, 01 Jun 2022 00:00:00 +0000

决策边界 (decision boundary) 支持向量机获取这些数据点并输出最能分离标签的超平面。这条线是决策边界决策平面（ decision surface ），是将空间划分为不同的区域。位于决策平面一侧的数据被定义为与位于另一侧的数据属于不同的类别。决策面可以作为学习过程的结果创建或修改，它们经常用于机器学习、模式识别和分类系统。环境空间 ( Ambient Space)，围绕数学对象即对象本身的空间，如一维 Line ，可以独立研究，这种情况下L则是L；再例如将L作为二维空间 $R^2$ 的对象进行研究，这种情况下 L 的环境空间是 $R^2$。超平面（Hyperplane）是一个子空间， N维空间的超平面是其具有维数的平面的子集。就其性质而言，它将空间分成两个半空间，其维度比其环境空间的维度小 1。如果空间是三维的，那么它的超平面就是二维维平面，而如果空间是 2 维的，那么它的超平面就是一维线。支持向量机 (SVM) 通过找到使两个类之间的边距最大化的超平面来执行分类。法向量（Normal）是垂直于该平面、另一个向量的 90° 角倾斜什么是支持向量支持向量（Support vectors），靠近决策平面（超平面）的数据点。如图所示，从一维平面来看，哪个是分离的超平面？一般而言，会有很多种解决方法（超平面），支持向量机就是如何找到最佳方法的解决方案。转置运算矩阵的转置是原始矩阵的翻转版本，可以通过转换矩阵的行和列来转置矩阵。我们用 $A^T$ 表示矩阵 A 的转置。例如， $$A=\left[ \begin{matrix} 1 & 2 & 3 \\ 4 & 5 & 6 \\ \end{matrix} \right]$$ ；那么 A 的转置就为 $$A=\left[ \begin{matrix} 1 & 4 \\ 2 & 5 \\ 3 & 6 \\ \end{matrix} \right]$$ ；

决策树

Wed, 01 Jun 2022 00:00:00 +0000

熵和基尼指数信息增益信息增益 information gain 是用于训练决策树的指标。具体来说，是指这些指标衡量拆分的质量。通俗来说是通过根据随机变量的给定值拆分数据集来衡量熵。通过描述一个事件是否"惊讶"，通常低概率事件更令人惊讶，因此具有更大的信息量。而具有相同可能性的事件的概率分布更"惊讶"并且具有更大的熵。定义：熵 entropy是一组例子中杂质、无序或不确定性的度量。熵控制决策树如何决定拆分数据。它实际上影响了决策树如何绘制边界。熵熵的计算公式为：$E=-\sum^i_{i=1}(p_i\times\log_2(p_i))$ ；$P_i$ 是类别 $i$ 的概率。我们来举一个例子来更好地理解熵及其计算。假设有一个由三种颜色组成的数据集，红色、紫色和黄色。如果我们的集合中有一个红色、三个紫色和四个黄色的观测值，我们的方程变为：$E=-(p_r \times \log_2(p_r) + p_p \times \log_2(p_p) + p_y \times \log_2(p_y)$ 其中 $p_r$ 、$p_p$ 和 $p_y$ 分别是选择红色、紫色和黄色的概率。假设 $p_r=\frac{1}{8}$，$p_p=\frac{3}{8}$ ，$p_y=\frac{4}{8}$ 现在等式变为变为： $E=-(\frac{1}{8} \times \log_2(\frac{1}{8}) + \frac{3}{8} \times \log_2(\frac{3}{8}) + \frac{4}{8} \times \log_2(\frac{4}{8}))$ $0.125 \times log_2(0.125) + 0.375 \times log_2(0.375) + 0.5 \times log_2(0.375)$ $0.125 \times -3 + 0.375 \times -1.415 + 0.5 \times -1 = -0.375+-0.425 +-0.5 = 1.

逻辑回归

Wed, 01 Jun 2022 00:00:00 +0000

Overview 逻辑回归通常用于分类算法，例如预测某事是 true 还是 false（二元分类）。例如，对电子邮件进行分类，该算法将使用电子邮件中的单词作为特征，并据此预测电子邮件是否为垃圾邮件。用数学来讲就是指，假设因变量是 Y，而自变量集是 X，那么逻辑回归将预测因变量 $P(Y=1)$ 作为自变量集 X 的函数。逻辑回归性能在线性分类中是最好的，其核心为基于样本属于某个类别的概率。这里的概率必须是连续的并且在 (0, 1) 之间（有界）。它依赖于阈值函数来做出称为 Sigmoid 或 Logistic 函数决定的。学好逻辑回归，需要了解逻辑回归的概念、优势比 (OR) 、Logit 函数、Sigmoid 函数、 Logistic 函数及交叉熵或Log Loss Prerequisite odds ratio explain odds ratio是预测变量的影响。优势比取决于预测变量是分类变量还是连续变量。连续预测变量：$OR > 1$ 表示，随着预测变量的增加，事件发生的可能性增加。$OR < 1$ 表示随着预测变量的增加，事件发生的可能性较小。分类预测变量：事件发生在预测变量的 2 个不同级别的几率；如 A,B，$OR > 1$ 表示事件在 A 级别的可能性更大。$OR<1$ 表示事件更低的可能是在A。例如，假设 X 是受影响的概率，Y 是不受影响的概率，则 $OR= \frac{X}{Y}$ ，那么 $OR = \frac{P}{(1-P)}$ ，P是事件的概率。让概率的范围为 [0,1] ，假设 $P(success)=0.8$ ，$Q(failure) = 0.2$ ；$OR$ 则是成功概率和失败概率的比值，如：$O(success)=\frac{P}{Q} = \frac{0.

朴素贝叶斯算法

Wed, 01 Jun 2022 00:00:00 +0000

什么是naive bayes 朴素贝叶斯 naive bayes，是一种概率类的机器学习算法，主要用于解决分类问题为什么被称为朴素贝叶斯？为什么被称为朴素，难道仅仅是因为贝叶斯很天真吗？实际上是因为，朴素贝叶斯会假设数据属性之间具有很强的的独立性。即该模型中的所有属性彼此之间都是独立的，改变一个属性的值，不会直接影响或改变算法中其他的属性的值贝叶斯定理了解朴素贝叶斯之前，需要掌握一些概念才可继续条件概率 Conditional probability：在另一个事件已经发生的情况下，另外一个时间发生的概率。如，==在多云天气，下雨的概率是多少？== 这是一个条件概率联合概率 Joint Probability：计算两个或多个事件同时发生的可能性边界概率 Marginal Probability：事件发生的概率，与另一个变量的结果无关比例 Proportionality 贝叶斯定理 Bayes' Theorem：概率的公式；贝叶斯定律是指根据可能与事件的先验概率描述了事件的后验概率边界概率边界概率是指事件发生的概率，可以认为是无条件概率。不以另一个事件为条件；用公式表示为 $P(X)$ 如：抽到的牌是红色的概率是 $P(red) = 0.5$ ；联合概率联合概率是指两个事件在同一时间点发生的可能性，公式可以表示为 $P(A \cap B)$ A 和 B 是两个不同的事件相同相交，$P(A \and B)$ $P(A,B)$ = A 和 B 的联合概率概率用于处理事件或现象发生的可能性。它被量化为介于 0 和 1 之间的数字，其中 0 表示不可能发生的机会，1 表示事件的一定结果。如，从一副牌中抽到一张红牌的概率是 $\frac{1}{2}$。这意味着抽到红色和抽到黑色的概率相同；因为一副牌中有52张牌，其中 26 张是红色的，26 张是黑色的，所以抽到一张红牌与抽到一张黑牌的概率是 50%。而联合概率是对测量同时发生的两个事件，只能应用于可能同时发生多个情况。例如，从一副52张牌扑克中，拿起一张既是红色又是6的牌的联合概率是 $P(6\cap red) = \frac{2}{52} = \frac{1}{26}$ ；这个是怎么得到的呢？因为抽到红色的概率为50%，而一副牌中有两个红色6（红桃6，方片6），而6和红色是两个独立的概率，那么计算公式就为：$P(6 \cap red) = P(6) \times P(red) = \frac{4}{52} \times \frac{26}{52} = \frac{1}{26}$

安装Debian11 (bullseye) Step-by-Step

Wed, 25 May 2022 00:00:00 +0000

Preparation debian11几乎可以使用任何旧的计算机硬件，因为最小安装的要求非常低。以下是最低要求和推荐要求：最低要求推荐要求存储：10 Gigabytes 内存：512 Megabytes CPU: 1 GigaHertz 存储：10 Gigabytes内存：2 GigabytesCPU: 1 GigaHertz or more Debian11 EOL：August 31st, 2026 如何选择下载安装包 offical mirror aliyun mirror 官网提供了安装包的下载，其中CD是网络安装，DVD是离线安装 debian官方下载页面 Notes：CD安装包很小，下载下来是 debian-11.4.0-amd64-netinst.iso 如名所示，这是一个网络安装包，所以推荐下载DVD部分，可以达到离线安装的效果安装步骤在界面中选择“Install”，安装将开始。如果图形化安装可以选择“Graphical install”，这里选择“Install”。欢迎页面完成后，系统将提示选择安装时的“语言”。选择喜欢的语言，然后按“Enter”。这里选择英文选择语言页面这将是接下来安装步骤安装步骤概述选择位置与键盘布局选择区域选择区域下面部署时选择键盘布局：中国大陆使用的键盘布局是美国-英语，不要选择英国-英语之类，布局是不一样的，会存在按键输出的结果会不同选择键盘布局完成上述操作后，将开始加载镜像。等待扫描完成。。。。等待扫描组件设置主机名和域名这步骤中将配置一个“主机名”。与一个“域”名称。配置主机名 “域” 可以选择留空确定配置域完成上述操作后，安装程序将提示需要设置 root 密码。输入您的 root 密码，然后在重新输入以进行验证后继续。设置Root密码设置非ROOT用户名、账户和密码下一步创建一个非ROOT用户，这个步骤是必须的，并为这个新创建的帐户分配一个密码。以下截图将描述将如何完成此操作。配置普通用户为这个用户配置密码为普通用户配置密码为普通用户配置密码——二次确认设置时钟时区 Eastern 美东时间 Central 北美中部

源码分析client-go架构 - 什么是informer

Wed, 25 May 2022 00:00:00 +0000

之前了解了client-go中的架构设计，也就是 tools/cache 下面的一些概念，那么下面将对informer进行分析 Controller 在client-go informer架构中存在一个 controller ，这个不是 Kubernetes 中的Controller组件；而是在 tools/cache 中的一个概念，controller 位于 informer 之下，Reflector 之上。code Config 从严格意义上来讲，controller 是作为一个 sharedInformer 使用，通过接受一个 Config ，而 Reflector 则作为 controller 的 slot。Config 则包含了这个 controller 里所有的设置。 go 1 2 3 4 5 6 7 8 9 type Config struct { Queue // DeltaFIFO ListerWatcher // 用于list watch的 Process ProcessFunc // 定义如何从DeltaFIFO中弹出数据后处理的操作 ObjectType runtime.Object // Controller处理的对象数据，实际上就是kubernetes中的资源 FullResyncPeriod time.Duration // 全量同步的周期 ShouldResync ShouldResyncFunc // Reflector通过该标记来确定是否应该重新同步 RetryOnError bool } controller 然后 controller 又为 reflertor 的上层

Kubernetes组件核心 - client-go

Sun, 22 May 2022 00:00:00 +0000

Prepare Introduction 从2016年8月起，Kubernetes官方提取了与Kubernetes相关的核心源代码，形成了一个独立的项目，即client-go，作为官方提供的go客户端。Kubernetes的部分代码也是基于这个项目的。 client-go 是kubernetes中广义的客户端基础库，在Kubernetes各个组件中或多或少都有使用其功能。。也就是说，client-go可以在kubernetes集群中添加、删除和查询资源对象（包括deployment、service、pod、ns等）。在了解client-go前，还需要掌握一些概念在客户端验证 API 使用证书和使用令牌，来验证客户端 kubernetes集群的访问模式使用证书和令牌来验证客户端在访问apiserver时，会对访问者进行鉴权，因为是https请求，在请求时是需要ca的，也可以使用 -k 使用insecure模式 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 $ curl --cacert /etc/kubernetes/pki/ca.crt https://10.0.0.4:6443/version \{ "major": "1", "minor": "18+", "gitVersion": "v1.18.20-dirty", "gitCommit": "1f3e19b7beb1cc0110255668c4238ed63dadb7ad", "gitTreeState": "dirty", "buildDate": "2022-05-17T12:45:14Z", "goVersion": "go1.16.15", "compiler": "gc", "platform": "linux/amd64" } $ curl -k https://10.

H3C Cloud与WSL2共存

Wed, 18 May 2022 00:00:00 +0000

背景由于Windows10 开启WSL2后无法和 eNSP 做到兼容，但是 H3C HCL 在版本 HCL_v2.1.2.1 提供了 VirtualBox 6.0.14 作为虚拟化后端，理论上来说可以做到 WSL2 与 HCL 共存。并且开启了WSL2后并于其他虚拟化平台（VirtualBox, Vmvare）做到兼容的情况下，这种情况大部分禁止套娃（虚拟化下在虚拟化），通过安装虚拟机的方式再安装 eNSP 发现启动不报错，但是很长时间起不来。 Notes [1]：HCL官方给的建议是，对于windows7装的版本为HCL_v2.1.1；对于Windows10 并且开启了 Hype-v 或者 Dokcer-Desktop，推荐使用 HCL_v3.0.1.1 下载地址：HCL Download 安装过程下载好安装时，直接下一步直至完成即可，VirtualBox已被内嵌至安装包内了。图：HCL安装界面 Notes：如果需要抓包，自行安装Wireshark，安装好后，在HCL设置中配置 wireshark.exe 的路径即可 VirtualBox启用hyper-v支持 [2] 进入VirtualBox安装目录, 确定当前目录下存在VBoxManage.exe文件, 在当前目录打开powershell. 或者你将VBoxManage.exe所在目录加入环境变量, 任意路径下打开powershell. powershell 1 2 # 或指定vbox所有虚拟系统开启 ./VBoxManage.exe setextradata global "VBoxInternal/NEM/UseRing0Runloop" 0 开启后，HCL所有的设备就工作正常了，这种情况下也不用牺牲WSL2或者Dokcer-Desktop。因为eNSP官方没有再更新，导致hype-v与VirtualBox无法兼容，暂时无解。 Reference [1] H3C Cloud Lab [2] Windows 10 (2004) 启用wsl2, 并与VirtualBox 6.0+共存

PC端利用google翻译实现同声翻译

Wed, 18 May 2022 00:00:00 +0000

疫情期间上网课，对于英语听力较差或者需要观看英文视频，但实际上并没有双语字幕的这种情况下需要找一个实时的翻译工具。虽然说手机上此类软件比较多，但电脑上没有特别合适的应用可以做为一个免费实时翻译。哪怕是收费翻译工具实际上翻译效果也是很差，并且语种比较单一。电脑端有一个 speechlogger，可以做到实时翻译，但实际上也是使用的Google翻译，那么实际上我们就可以直接使用Google翻译作为一个同声翻译电脑的声音。此时就遇到一个问题，就是Google翻译无法识别到电脑的声音，只能识别到麦克风的声音。这里就需要将电脑输出的作为麦克风的输出。使用Windows电脑的可以尝试以下操作。以windows电脑为例： Step 1：电脑右下角调整音量图标，右键选择声音 Step2：选择录音设备，立体声混音，将其启动并设置为默认设备（可选） Step3：右键属性，选择侦听，通过此设备播放选择扬声器对应的设备。 Tips：注意，无用选择侦听此设备，这个选项勾选后的意思是，你可以通过扬声器听到扬声器声音，此时会发生混音。影响我们听到的效果。 Step4：可选步骤，如果Step2没有设置为默认设备，可以在浏览器选择对应的设备作为麦克风，如使用了立体声混音作为电脑的输入设备，那么不是默认设备情况下在浏览器选择该设备作为输入设备即可。 Tips：Google翻译的语音翻译功能貌似只能在Chrome里使用，其他有可能会出现无法使用语音设备的功能这样就做到了一个免费，无杂音，多语种的同声翻译，不管是上网课学习，还是说做笔记（同语言下还可以作为声音转换为文字）都是一个很不错的选择。后面再说下，科大讯飞的录音设备实际上翻译功能很差，语种也少，并且专业术语翻译的很烂，最便宜的小2000块钱，大量依赖云服务，实际上可以不用买这种产品，我是已经买过体验的，翻译结果实际上比Google翻译要差。如果不是在现场，没有网络或者声音很嘈杂（他的十几个麦克风其实效果也不咋地）的情况下可以选择其他方案，例如Google的同声翻译。如果你需要对翻译的结果划分角色的话，还是可以使用 speechlogger，这个也是使用的Google翻译作为翻译引擎的 Reference 如何将电脑的输出作为电脑麦克风的输入免费的实时翻译工具

如何通过源码编译Kubernetes

Mon, 16 May 2022 00:00:00 +0000

本地构建选择要构建的版本 text 1 git checkout tags/v1.19.5 将依赖包复制到对应路径下 text 1 cp staging/src/k8s.io vendor/ 调整makefile 在windows上编译的克隆下可能文件编码变了，需要手动修改下文件编码。比如说出现 \r not found 类似关键词时这里转换编码使用了 dos2unix，需要提前安装下 text 1 apt install dos2unix 转换原因是因为对于bash 脚本执行识别不了windows的换行 text 1 find . -name '*.sh' -exec dos2unix {} \; 然后将 build/root/ 的文件复制到项目根目录 text 1 cp build/root/Makefile* ./ 编译查看帮助 make help 编译 make all WHAT=cmd/kube-apiserver GOFLAGS=-v WHAT=cmd/kube-apiserver 为仅编译单一组件，all 为所有的组件还可以增加其他的一些环境变量 KUBE_BUILD_PLATFORMS= 如编译的平台更多的可以 make help 查看帮助编译中问题 Makefile:93: recipe for target ‘all’ failed

深入理解kubernetes API

Mon, 16 May 2022 00:00:00 +0000

APIServer 在kubernetes架构概念层面上，Kubernetes由一些具有不同角色的服务节点组成。而master的控制平面由 Apiserver Controller-manager 和 Scheduler 组成。 Apiserver 从概念上理解可以分为 api 和 object 的集合，api 可以理解为，处理读写请求来修改相应 object 的组件；而 object 可以表示为 kubernetes 对象，如 Pod， Deployment 等。基于声明式的API 在命令式 API 中，会直接发送要执行的命令，例如：运行、停止等命令。在声明式API 中，将声明希望系统执行的操作，系统将不断将自身状态朝希望状态改变。为什么使用声明式在分布式系统中，任何组件随时都可能发生故障，当组件故障恢复时，需要明白自己需要做什么。在使用命令式时，出现故障的组件可能在异常时错过调用，并且在恢复时需要其他外部组件进行干预。而声明式仅需要在恢复时确定当前状态以确定他需要做什么。 External APIs 在kubernetes中，控制平面是透明的，及没有internal APIs。这就意味着Kubernetes组件间使用相同的API交互。这里通过一个例子来说明外部APIs与声明式的关系。例如，创建一个Pod对象，Scheduler 会监听 API来完成创建，创建完成后，调度程序不会命令被分配节点启动Pod。而在kubelet端，发现pod具有与自己相同的一些信息时，会监听pod状态。如改变kubelet则修改状态，如果删除掉Pod（对象资源不存在与API中），那么kubelet则将终止他。为什么不使用Internal API 使用External API可以使kubernetes组件都使用相同的API，使得kubernetes具有可扩展性和可组合性。对于kubernetes中任何默认组件，如不足满足需求时，都可以更换为使用相同API的组件。另外，外部API还可轻松的使用公共API来扩展kubernetes的功能 API资源从广义上讲，kubernetes对象可以用任何数据结构来表示，如：资源实例、配置（审计策略）或持久化实体（Pod）；在使用中，常见到的就是对应YAML的资源清单。转换出来就是RESTful地址，那么应该怎么理解这个呢？即，对资源的动作（操作）如图所示。但如果需要了解Kubernetes API需要掌握一些概念才可继续。 Group 出于对kubernetes扩展性的原因，将资源类型分为了API组进行独立管理，可以通过 kubectl api-resources查看。在代码部分为 vendor/k8s.io/api 也可以通过 kubectl xxx -v 6 来查看 kubectl 命令进行了那些API调用 text 1 2 3 4 5 6 7 8 9 10 11 $ kubectl get pods -v 6 I0513 21:54:33.

ch12 进程间通讯

Tue, 03 May 2022 00:00:00 +0000

Overview 进程间是相互保持独立的，内存管理中，就是保护进程的地址空间不被其他进程访问。而进程间通信 ( Inter-process Communication IPC) 用于在一个或多个进程间交换数据进程间合作是那些可以影响或受其他过程影响的过程。例如网站包含 JS、H5、Flash，当有一个相应缓慢时，会发生整个网站的布局或其他功能的展示。通常情况下进程间合作被允许的原因有：信息共享：多个进程需要访问同一个文件。（如管道）计算加速：将复杂功能拆分为多个子任务（多处理器时效果更佳），可以更快地解决问题模块化：将整体系统架构分为不同功能模块，模块间相互协作便利：单用户可以同时多任务处理，如编辑、编译、打印等 Communications model (a) 消息队列（间接通信） (b) 共享内存（直接通信） Message Passing IPC背后关键的一点是消息的传递，即一个进程发消息，一个进程接收消息而为了使进程间通信，就必须在进程间建立连接，连接可以是单/双向。连接可以使用直接通信和间接通信来实现 Direct Communication 直接通信，必须明确声明发送者或接收者的名称，通常定义为： Send(P, message)：发送信息到进程 P Receive(Q, message)：接收来自进程 Q 的信息在直接通信中，一般连接的属性有以下特征：一个链路与一对进程相关联自动建立链接链接是通用的双向链接 Indirect Communication 间接通信，为异步通信，通常情况下互通信都需要有消息队列；发送者将信息放置消息队列中，接受者从消息队列中取出消息 Send(P, message)：像消息队列发送消息 Receive(Q, message)：接受消息队列中的消息每个进程都有唯一ID 共享一个消息队列在间接通信中，一般连接的属性有以下特征：一对进程共享消息队列时，才会在进程之间建立链接链接可以被许多进程关联链接可以是单向也可以是双向每个进程可以有多个链接直接通信间接通信 Synchronization 从另一方面来讲，消息传递可以是阻塞 Blocking 或非阻塞 Non-Blocking 的；同步 synchronous 会阻塞一个进程，直到发送完成。异步 asynchronous 则是是非阻塞的，发送操作完成后会立即返回不等待返回结果 Buffer 消息通过队列传递，队列的容量则具有下列三种配置之一： 0容量：消息不能存储在队列中，因此发送者必须阻塞，直到接收者接受消息有限容量：队列中有一定的预先约定大小的容量。如果队列已满，发送者必须阻塞，直到队列中有可用空间（反之为空，接受者阻塞），否则可能是阻塞的或非阻塞的无限容量：具有无限容量的队列，发送者永远不会被迫阻塞至此整节围绕对消息传递功能的三个方面做了介绍：

ch13 file system

Tue, 03 May 2022 00:00:00 +0000

Overview 文件系统和文件文件系统: 一种用于持久性存储的系统抽象，决定了辅存中的内容如何组织与存储的抽象概念文件：文件系统中的一个单元的相关数据在操作系统中的抽象，展现给用户的抽象概念文件系统的功能：分配文件磁盘空间管理文件块(哪一块属于哪一个文件) 管理空闲空间(哪一块是空闲的) 分配算法(策略) 管理文件集合定位文件及其内容命名：通过名字找到文件的接口最常见：分层文件系统文件系统类型(组织文件的不同方式) 提供的便利及特征保护：分层来保护数据安全可靠性，持久性：保持文件的持久即使发生崩溃,媒体错误,攻击等为什么需要文件系统：如果将文件放入一个房间中，整个房间都是堆积的文件有了文件系统的存在将会改变一切空间管理、元数据、数据加密、文件访问控制和数据完整性等等都是文件系统的职责。文件属性文件具有名称和数据，还存储文件创建日期和时间、当前大小、上次修改日期等元信息。所有这些信息都称为文件系统的属性。常见的文件属性有名称：它是以人类可理解的形式。标识符：每个文件都由文件系统中的唯一标记号标识，称为标识符。位置：设备上的文件位置。类型：支持各种类型文件的系统需要此属性。大小：当前文件大小的属性。保护：分配和控制读、写和执行文件的访问权限。时间、日期和安全：用于对文件的保护、安全，也用于监控文件描述符文件头 File Header；类似于Unix的 inode，在存储元数据中保存了每个文件的信息，保存文件的属性，跟踪哪一块存储块属于逻辑上文件结构的哪个偏移文件描述符（file-descriptor）；是唯一标识操作系统中打开文件的数字（整形），用于用户和内核空间之间的接口，以识别文件/Socket 资源。因此，当使用 open() 或 socket()（与内核接口的系统调用）时，会得到一个文件描述符，一个整数。因此，如果直接与内核交互，使用系统调用 read(), write() 等 close()。使用的是一个文件描述符句柄。在 C 语言中 stdin，stdout、和 stderr ，在 UNIX 中分别映射到文件描述符 0 1 2 text 1 2 3 4 5 f = open(name, flag); ... .

ch11 死锁

Mon, 02 May 2022 00:00:00 +0000

死锁问题死锁 deadlock；是一组阻塞的进程，每个进程都持有一个资源并等待获取另一个进程持有的资源。死锁的示例：交通桥如图所示，桥是资源，进程是车辆，两个不同方向的车辆同时占用桥，此时发生谁也过不去的情况（死锁的发生）；当死锁发生时，如果一辆车倒车（抢占资源和回滚）就可以解决死锁问题死锁发生时，可能需要后退多台车辆饥饿，而饥饿并不一定是死锁系统模型在正常情况下，进程必须在使用之前请求资源，并在完成后释放它，顺序如下：请求：如果不能立即授予请求，则进程等待，直到它需要的资源变得可用。例如，系统调用 open()、malloc()、new() 、request() 等。使用：进程使用资源，例如文件中读取数据；使用硬件。释放：进程完成后放弃资源，以便其可用于其他进程。如，close()、free()、delete() 、 release()。当在集合中的每个进程都在等待当前分配给集合中另一个进程的资源时，这一组进程就会发生死锁资源分配通过实例来理解死锁，一组资源： ${ R_1,\ R_2,\ R_3,\ ….,\ R_N }$；为方形，图形内的点代表资源数量一组进程： ${ P_1,\ P_2,\ P_3,\ ….,\ P_N }$ 请求边缘 Request Edge：进程需要一些资源，被称为请求边缘；如 $P_i\ →\ R_j$ 分配边缘 Assign Edge：当资源已经被分配给进程，被称为分配边缘；如 $R_j\ →\ P_i$ 当请求被授予时，可以通过反转方向的线将请求边缘转换为分配边缘类型示意图 Process Resource $P_i$ 请求的 $R_j$ 实例 $P_i$ 持有一个 $R_j$ 的实例也可以说 $R_j$ 被 $P_i$ 所持有资源分配图资源分配图如图所示，资源类型为：

ch10 信号量和监视器

Sun, 01 May 2022 00:00:00 +0000

Backgound 信号量 semaphores，是操作系统中非常重要的技术，通过使用一个简单的整数值来管理并发进程，信号量只是一个在线程之间共享的整数变量。该变量用于解决临界区问题并实现进程同步。信号量具有两个原子操作： P()：sem减一，如果sem<0，等待；否则继续 V()：sem加一，如果sem≤0，唤醒一个等待的P； Semaphore 信号量的使用型号量的特点：两个类型信号量二进制信号量 Binary Semaphore：也称为互斥锁。它只能有两个值0和1。它的值被初始化为1。它用于实现多进程临界区问题的解决。计数信号量 Counting Semaphore：值可以跨越一个不受限制的域（可以取任何非负数）。它用于控制对具有多个实例的资源的访问。信号量是被保护的变量初始化完成后，唯一改变一个信号量的值的办法是通过P() 和 V() 操作必须是原子 P() 能够阻塞，V() 不会阻塞信号量可以用在2个方面互斥条件同步(调度约束 —— 一个线程等待另一个线程的事情发生) 信号量实现的互斥 c 1 2 3 4 5 6 7 mutex = new Semaphore(1); mutex->P(); // 临界区前p ... critical section ... mutex->V(); // 临界区后v 信号量实现调度约束 c 1 2 3 4 5 6 7 8 9 10 condition = new Semaphore(0); // Thread A .

ch8 CPU调度算法

Sat, 30 Apr 2022 00:00:00 +0000

Overview CPU调度 (cpu scheduling )，是决定在一个时间窗口内，哪个进程可以拥有CPU而另外一个个进程会被暂停的过程。CPU调度的作用是为了确保每当CPU空闲时，操作系统至少选择就绪队列中一个可用的进程执行。这个选择过程将由CPU调度器来执行。调度程序：挑选就绪进程的内核函数调度策略：依据什么挑选进程？调度时机：什么时间进行调度？进程从运行状态切换到等待状态进程退出非抢占式：当前进程主从放弃CPU时，抢占式：当前进程被抢占时间片用完进程从等待切换到就绪（当前就绪进程优先级高于当前运行进程）调度准则 CPU的调度策略抢占式调度抢占式调度（Preemptive）在分配进程时有对应的优先级。而在另一个较低优先级进程之前运行具有较高优先级的进程很重要，即使较低优先级的进程仍在运行。较低优先级的进程扔会等待一段时间，让较高优先级的进程完成执行后恢复。抢占式调度主要发生在运行状态切换到就绪或等待状态非抢占式调度非抢占式调度（Non-Preemptive），在这种类型的调度中，一旦将资源（CPU 周期）分配给一个进程，该进程就会持有CPU使用权，直到它被终止或达到等待状态。抢占式调度主要发生在运行状态终止的情况下如何确定调度是抢占式还是非抢占式？一般来讲，确定调度的方式是通过以下四点来确定的：当进程从运行状态切换到等待状态；如I/O请求或调用 wait() 系统调用当进程从运行状态切换到就绪状态；如响应中断。当进程从等待状态切换到就绪状态；如在 I/O 完成或从 wait() 返回时。进程完成执行并终止；如果调度发生在1 4情况下，则为非抢占式，否则为抢占式程序执行模型需要关注的是进程在计算机系统中运行时存在什么状态？几乎所有进程都在一个连续的循环的两种模型之间交替：即CPU突发和I/O突发中交替每个调度决定都是关于在下一个CPU突发时将哪个工作交给CPU 在时间分片机制下，线程可能在结束当前CPU突发前被迫放弃CPU CPU突发和 I/O突发的交替序列逻辑 CPU 突发型的持续时间调度指标在了解评价指标前，需要对CPU调度中的一些术语需要了解 CPU突发（Burst Time BT）：进程开始执行的时间，从到达到开始执行花费的时间到达时间（Arrival Time AT）：进程到达就绪队列的时间完成时间（End Time ET 或 Completion Time CT）：进程执行完成的时间等待时间（Waiting Time WT）：进程在就绪队列中等待轮到 CPU 占用的时间；$WT = TT - BT$ 周转时间（Turnaround Time TT）：完成时间和到达时间的差 $TT=CT-AT$ 相应时间（Response Time RT）：开始响应请求所需的时间。第一次请求到相应的时间。吞吐量 (Throughput)：单位时间内完成的进程数。$Throughput = (Number\ of\ processes\ completed) \div (Time\ unit)$ 一般情况下，需要的服务”越快“越好，而快的定义：

ch9 同步

Sat, 30 Apr 2022 00:00:00 +0000

Background 多进程作为现代操作系统的重要特性，交互则会引起同时对共享资源的访问，当这些资源访问不正确会出现冲突或产生不适当的输出（冲突、死锁、饥饿）；而在同步的基础上，进程被分为以下两种类型：独立进程 Independent Process 不和其他进程共享资源或状态确定性，输入状态确定结果可重现，能够重现起始条件，I/O 调度的顺序不重要协作进程 Cooperative Process；多进程共享资源或状态不确定性 probabilistic 不可重现不确定性和不可重现意味着bug可能是间歇性发生的 Cooperation 进程的互相影响，即进程间的合作（相互或破坏）；最简单的例子就是两个进程使用同一个文件，一个进程读，一个进程写。读进程的结果会被写进程所影响。进程需要合作的原因：资源共享：多个进程访问相同的数据一台电脑，多个用户一个银行存款余额,多台ATM机嵌入式系统（机器人手臂和收的协调）计算加速： I/O 和 CPU计算可重叠多处理器 - 将任务分解为子任务并分布在不同的进程中，它通常可以更快地运行（也需要多个可共享的 CPU）模块化：复杂的任务组织成单独的子任务，让不同的进程运行大程序分成小程序是系统易于扩展程序可以调用函数fork()来创建一个新的进程操作系统需要分配一个新的并且唯一的进程ID 因此在内核中,这个系统调用会运行 new_pid = next_pid++; 翻译成机器指令: Load next_pid Reg1 STORE Reg1 new_pid INC Reg1 STORE Reg1 next_pid 假设两个进程并发执行如果next_pid等于100, 那么其中一个进程得到的ID应该是100, 另一个进程的ID应该是101, next_pid应该增加到102 可能在INC前进行了上下文切换, 最终导致两个进程的pid都是100,而next_pid也是101 无论多个线程的指令序列怎样交替执行,程序都必须正常工作多线程程序具有不确定性和不可重现的特点不经过专门设计,调试难度很高不确定性要求并行程序的正确性先思考清楚问题，把程序的行为设计清楚切忌给予着手编写代码，碰到问题再调试 Race Condition 竞态条件是由操作系统软件中的同步错误。出现在进程试图同时执行两个或多个操作时，这是一种不希望出现的情况。怎么样避免竞态?

ch7 进程管理

Fri, 29 Apr 2022 00:00:00 +0000

Overview 进程的描述进程的状态 State 线程 Thread 进程间通信 Inter-Process Communication 进程互斥与同步死锁 DeadLock 进程的描述在操作系统中，通常来说进程 Process 是当前正在执行的东西。因此，一个具有一定独立功能的程序在一个数据集合上的一次动态执行过程，可以称之为进程。程序是静态的文件进程是程序动态执行的过程进程的组成进程包括 : 程序的代码程序处理的数据程序计数器 (PC) 中的值, 指示下一条将运行的指令一组通用的寄存器的当前值, 堆 Heap , 栈 Stack 一组系统资源(如打开的文件、内存、网络) 而进程的主要构成如下， Stack Section Heap Section Data Section Text Section Stack Stack部分包含：局部变量函数和返回地址 main函数如上图所示，Stack和 heap 以相反的方向增长，如果两者都以相同的方向增长，那么其两者可能会重叠，因此如果它们以相反的方向增长则很好。示例：如，调用下列函数时，将存储在Stack部分，一旦函数返回，该函数堆栈部分的值将被删除。 Stack上有一个堆栈帧，其中包含main函数以及局部变量a, b sum 。使用 printf()，创建的帧以及局部变量只能在内存中访问，帧的持续时间在从函数 return 0 后释放。 c 1 2 3 4 5 6 7 8 int main(void) { int a, b, sum; a = 2; b = 3; sum = a + b; printf("%d\n", sum); return 0 } Stack是一种后进先出 (LIFO) 数据结构，最后一个被推到Stack上的内容就是从顶部弹出的第一个内容。不允许从Stack的中间插入或移除。因此Stack必须至少支持两种操作：push 和 pop ；其他操作也是可以，但不是必需的。

ch6 页面置换算法

Thu, 28 Apr 2022 00:00:00 +0000

Overviews 功能与目标实验设置与评价方法局部页面算法最优页面置换算法先进先出算法最近最久未使用算法时钟页面置换算法最不常用置换算法 Belady现象 LRU FIFO Clock对比全局页面置换算法工作集模型工作集页面置换算法缺页率置换算法功能与目标功能 : 当缺页中断发生，需要调入新的页面而内存已满时，选择内存当中哪个物理页面被置换。目标 : 尽可能地减少页面的换进换出次数(即缺页中断的次数)。具体来说，把未来不再使用的或短期内较少使用的页面换出，通常只能在局部性原理指导下依据过去的统计数据来进行预测。页面锁定 frame locking：用于描述必须常驻内存的操作系统的关键部分或时间关键（time critical）的应用进程。实现的方式是：在页表中添加锁定标记位(lock bit)。实验设置与评价方法实例：记录一个进程对页访问的一个轨迹举例 : 模拟一个实验环境，记录对应的地址访问序列，虚拟地址跟踪(页号, 偏移)… (3,0) (1,9) (4,1) (2,1) (5,3) (2,0) … 而offset可以忽略（页不存在才会产生 page fault），生成的页面轨迹 3, 1, 4, 2, 5, 2, 1, …（替换为，3,1,4,2,5,2,1）模拟一个页面置换的行为并且记录产生页缺失数的数量更少的缺失，更好的性能局部页面置换算法最优页面置换算法基本思路：当一个缺页中断发生时，对于保存在内存当中的每一个逻辑页面，计算在它的下一次访问之前，还需等待多长时间，从中选择等待时间最长的那个，作为被置换的页面。这是一种理想情况, 在实际系统中是无法实现的, 因为操作系统无法知道每一个页面要等待多长时间以后才会再次被访问. 最优页面置换算法（Optimal Page Replacement）可用作其他算法的性能评价的依据，(在一个模拟器上运行某个程序, 并记录每一次的页面访问情况，在第二遍运行时即可使用最优算法) 在该算法中，会替换在未来最长持续时间内不会使用的页面。如下图所示有 a b c d e五个页，但是只有四个页帧。此时会产生物理页不够，会产生 Page Fault。

ch5 虚拟内存

Wed, 27 Apr 2022 00:00:00 +0000

Objective 覆盖技术交换技术虚拟内存目标程序局部性原理基本概念基本特征虚拟页式内存管理覆盖技术 overlay 在固定分区中的主要遇到的问题是进程的大小受到分区的最大大小的限制，这将意味着一个进程将不能跨越另一个进程。为了解决这个问题，早期使用了称为覆盖(overlay) 的解决方案，覆盖技术是为了在较小的可用内存中运行较大的程序。常用于多道程序系统，与分区存储管理配合使用。这样并非所有模块都需要同时存在于内存中，实现了运行大于物理内存大小的程序的技术。覆盖技术的原理：将程序按照执行逻辑拆分为多个功能上相对独立的部分（overlays）, 那些不会同时执行的模块共享同一块内存区域, 按时间先后来运行（分时）。必要部分，常驻内存的代码和数据，负责管理，在某个时间片将相应的程序和数据导入或导出内存。可选部分，在其他程序模块中实现, 平时存放在外存中, 在需要用到时才装入内存; 不存在调用关系的模块不必同时装入到内存, 从而可以相互覆盖, 即这些模块共用一个分区. 覆盖技术实例覆盖技术说明：有一个程序，分位A B C D E F G 六个模块，每一个模块占用了一定空间，程序的覆盖树如图所示。问：当满足加载（和运行）该程序所需物理内存中的大小是多少？使用覆盖技术，实际上不需要将整个程序放在主内存中。只需要在对应时间片时所需要的部分即可，其逻辑调用关系树可以分为：Root-A-D或者 Root-A-E ; Root-B-F 或 Root-C-G 部分。 Root是常驻内存，因为其需要调用A B C D E F G 六个模块，占用2KB 如图：加载与运行改程序所需的物理内存大小是多少？ (a) 12 KB (b) 14 KB (c) 10 KB (d) 8 KB 答：由公式可得，最大运行层所需的物理内存为14KB，即拥有 14KB 大小的分区就可以运行上图任意一个分区

ch4 操作内存管理 - 非连续内存分配

Tue, 26 Apr 2022 00:00:00 +0000

overview Q1: 为什么需要非连续内存分配连续内存管理（contiguous memory allocation）, 即 : 操作系统加载到内存以及程序加载到内存中时, 分配一块连续的内存块. 但这种方式会出现碎片问题，而非连续内存分配（Non-contiguous memory allocation ）可以有效的减少碎片（Fragmentation）的出现。 Q2: 主要的非连续内存分配的管理方法分段（Segmentation）分页（Paging）页表（Page Table） 1.非连续内存分配的必要性连续内存管理的缺陷：内存利用率较低（memory wastage），在程序运行时分配的内存是增长的，但在进程使用为达到分配大小时，分配的块并未使用，并且也不能给其他进程使用，造成了内存的浪费。分配给一个程序的物理内存必须是连续的。碎片化问题不灵活（inflexibility），当进程或文件使用的内存超出预期时（即：超出分配的内存块大小），将停止并抛出异常，例如：No disk space。非连续内存分配的优点: 一个程序的物理地址空间是非连续的更好的内存利用和管理，（减少了内存浪费）允许共享代码与数据(共享库等…) 支持动态加载和动态链接非连续内存分配的缺点：建立虚拟地址和物理地址的转换难度大软件方案硬件方案(采用硬件方案) : 分段 / 分页分段（segmentation）首先 segmentation mechanism需要考虑的问题：程序的分段地址空间分段寻址方案什么是segmentation 段（segmentation）是一个逻辑单元 (logical unit)，例如：主程序 main program 程序（主要是指功能的代码，如一段函数） procedure 函数 function 方法 method 对象 object 局部变量和全局变量 local variables, global variables 公共块 common block 堆 stack 符号表 symbol table 数组 arrays [segmentation的逻辑视图] 可以看到左边是逻辑地址，右边是不连续的物理地址，中间有一个映射机制将两边建立了一个关联关系（ST Segment Table）。通过映射机制将不同的块（如stack，function.

ch3 操作内存管理 - 连续内存分配

Mon, 25 Apr 2022 00:00:00 +0000

一计算机体系结构及内存分层体系 1.计算机硬件体系结构大致分为 CPU，完成程序的执行控制主存（main memory），放置程序代码和数据 I/O（外）设备，配合程序工作。 2.内存分层体系（金字塔结构) 什么是内存结构：CPU所访问的指令和数据在什么地方。第一类：位于CPU内部，操作操作系统无法直接进行管理的，寄存器，cache；特点，速度快，容量小第二类：主存或物理内存，主要用来放置操作系统本身及要运行的代码；其特点是，容量比cache要大很多，单速度交于cache要慢一些。第三类：磁盘，永久保存的数据及代码，当对于主存要慢，容量比主存大很多。操作系统的作用可以将数据访问的速度（cache与内存）与存储的大小（硬盘）很好的融合在一起 3.OS管理内存时需要完成的目标 ① 抽象：逻辑地址空间（将物理内存，外设等抽象成逻辑地址空间，只需要访问对应地址空间) ② 保护（独立）：操作系统完成隔离机制实现，独立地址空间（每段程序执行时，不受其他程序的影响） ③ 共享：进程间安全，可靠，有效，进行数据传递，访问相同的内存。 ④ 虚拟化：更多的地址空间（利用磁盘的空间) 4.需要完成在操作系统中管理内存的不同方法操作系统层面程序重定位分段分页虚拟内存按需分页虚拟内存硬件层面必须知道内存架构 MMU(内存管理单元)：处理CPU的内存访问请求二地址空间&地址生成地址空间的定义地址生成器地址安全检查 1.内存地址的定义 ① 物理内存地址：硬件支持的地址空间，如主存（内存）和硬盘，由硬件完成管理和控制 ② 逻辑内存地址：一个程序运行时所需要的内存范围。两者间的关系：逻辑地址空间最终是一个存在的物理地址空间，两者间的映射关系是由操作系统来管理的 2.逻辑地址生成过程（把代码转化为计算机能理解语言）一段代码运行→编译→汇编语言→机器语言→产生链接文件→将硬盘中程序载入到内存当中运行（完成逻辑地址的分配）如C中变量的名字，函数的位置，为逻辑地址。 3.物理地址生成（逻辑地址对应的物理地址的过程） CPU方面 MMU表示映射关系 ① CPU ALU Arithmetic logic unit 发出请求，为逻辑地址 ② CPU MMU Memory management unit 查找逻辑地址映射表，不存在会去内存中找 ③ 控制器提出内存请求（需要的内容，内容即指令）内存方面 ④ 内存通过bus发送物理内存地址的内容给CPU OS方面建立逻辑地址和物理地址之间的映射关系（需在前四部前将映射管理建立好）

Windows Terminal无法加载WSL [process exited with code 4294967295 (0xffffffff)]

Wed, 30 Mar 2022 00:00:00 +0000

在Windows Terminal中WSL无法打开错误代码是 process exited with code 4294967295 (0xffffffff)，但在命令行中通过 "C:\Windows\System32\wsl.exe" -d ubuntu18 是正常的解决方法是：通过修改启动的命令为 wsl.exe ~ -d Ubuntu 中间加一个 ~ 可以很好的解决掉这种方法存在一个问题，打开的wsl终端将为根目录而不是当前windows目录 Reference Unable to launch WSL Ubuntu

Go每日一库 - gocolly

Tue, 29 Mar 2022 00:00:00 +0000

Introduction 本文对colly如何使用，整个代码架构设计，以及一些使用实例的收集。 Colly是Go语言开发的Crawler Framework，并不是一个完整的产品，Colly提供了类似于Python的同类产品（BeautifulSoup 或 Scrapy）相似的表现力和灵活性。 Colly这个名称源自 Collector 的简写，而Collector 也是 Colly的核心。 Colly Official Docs，内容不是很多，最新的消息也很就远了，仅仅是活跃在Github Concepts Architecture 从理解上来说，Colly的设计分为两层，核心层和解析层， Collector ：是Colly实现，该组件负责网络通信，并负责在Collector 作业运行时执行对应事件的回调。 Parser ：这个其实是抽象的，官网并未对此说明，goquery和一些htmlquery，通过这些就可以将访问的结果解析成类Jquery对象，使html拥有了，XPath选择器和CSS选择器通常情况下Crawler的工作流生命周期大致为构建客户端发送请求获取响应的数据将相应的数据解析对所需数据处理持久化而Colly则是将这些概念进行封装，通过将事件注册到每个步骤中，通过事件的方式对数据进行清理，抽象来说，Colly面向的是过程而不是对象。大概的工作架构如图 event 通过上述的概念，可以大概了解到 Colly 是一个基于事件的Crawler，通过开发者自行注册事件函数来触发整个流水线的工作 Colly 具有以下事件处理程序： OnRequest：在请求之前调用 OnError ：在请求期间发生错误时调用 OnResponseHeaders ：在收到响应头后调用 OnResponse：在收到响应后调用 OnHTML：如果接收到的内容是 HTML，则在 OnResponse 之后立即调用 OnXML ：如果接收到的内容是 HTML 或 XML，则在 OnHTML 之后立即调用 OnScraped：在 OnXML 回调之后调用 OnHTMLDetach：取消注册一个OnHTML事件函数，取消后，如未执行过得事件将不会再被执行 OnXMLDetach：取消注册一个OnXML事件函数，取消后，如未执行过得事件将不会再被执行 Reference goquery htmlquery Utilities 简单使用 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 package main import ( "fmt" "github.

grafana v8.0+ 隐藏表格字段

Fri, 17 Dec 2021 00:00:00 +0000

Select panel title → Inspect → Panel JSON Set “type” to “table-old” Apply The visualization should now appear as Table (old) and in the right side will appear Column Styles Column Styles → Options → Name pattern set the name of the column to hide Type → Hidden Reference：Hide column in table in v8.0

理解kubernetes listwatch机制原理

Sun, 12 Dec 2021 00:00:00 +0000

overview kubernetes的设计里面大致上分为3部分： API驱动型的特点 (API-driven) 控制循环（control loops）与条件触发（Level Trigger） API的可延伸性而正因为这些设计特性，才使得kubernetes工作非常稳定。什么是Level Trigger与 Edge trigger 看到网上有资料是这么解释两个属于的：条件触发(level-trigger，也被称为水平触发)LT指：只要满足条件，就触发一个事件(只要有数据没有被获取，就不断通知)。边缘触发(edge-trigger)ET: 每当状态变化时，触发一个事件。通过查询了一些资料，实际上也不明白这些究竟属于哪门科学中的理论，但是具体解释起来看的很明白。 LEVEL TRIGGERING：当电流有两个级别，VH 和 VL。代表了两个触发事件的级别。如果将VH 设置为LED在正时钟。当电压为VH时，LED可以在该时间线任何时刻点亮。这称为LEVEL TRIGGERING，每当遇到VH 时间线就会触发事件。事件是在时间内的任何时刻开始，直到满足条件。 Edge TRIGGERING: 如图所示，会看到上升线与下降线，当事件在上升/下降边缘触发时（两个状态的交点），称为边缘触发（Edge TRIGGERING:）。如果需要打开LED灯，则当时钟从VL转换到VH时才会亮起，而不是一家处在对应的时钟线上，仅仅是在过渡时亮起。为什么kubernetes使用Level Trigger而不使用Edge trigger 如图所述，两种不同的设计模式，随着时间形状进行相应，当系统在由高转低，或由低转高时，系统处在关闭或者不可控的异常状态下，应如何触发对应的事件呢。换一种方式来来解释，比如说通过加法运算，如下，i=3，当给I+4作为一个操作触发事件。 text 1 2 3 4 5 # let i=3 # let i+=4 # let i # echo $i 7 当为Edge trigger时操作的情况下，将看到 i+4 ,而在 level trigger 时看到的是 i=7。这里将会从``i+4` 一直到下一个信号的触发。信号的干扰通常情况下，两者是没有区别的，但在大规模分布式网络环境中，有很多因素的影响下，任何都是不可靠的，在这种情况下会改变了我们对事件信号的感知。如图所示，图为Level Trigger与Edge trigger 的信号发生模拟，在理想情况下，两者间并没有什么不同。

理解kubernetes schema

Mon, 22 Nov 2021 00:00:00 +0000

什么是schema schema一词起源于希腊语中的form或figure，但具体应该如何定义schema取决于应用环境的上下文。schema有不同的类型，其含义与数据科学、教育、营销和SEO以及心理学等领域密切相关。在维基百科中将schema解释为，图式，在心里学中主要描述一种思维或行为类型，用来组织资讯的类别，以及资讯之间的关系。它也可以被描述为先入为主思想的心理结构，表示世界某些观点的框架，或是用于组织和感知新资讯的系统。但在计算机科学中，从很多地方都可以看到 schema 这个名词，例如 database，openldap，programing language等的。这里可以简单的吧schema 理解为元数据集合（metadata component）数据模型，主要包含元素及属性的声明，与其他数据结构组成。数据库中的schema 在数据库中，schema 就像一个骨架结构，代表整个数据库的逻辑视图。它设计了应用于特定数据库中数据的所有约束。当在数据建模时，就会产生一个schema。在谈到关系数据库]和面向对象数据库时经常使用schema。有时也指将结构或文本的描述。数据库中schema描述数据的形状以及它与其他模型、表和库之间的关系。在这种情况下，数据库条目是schema的一个实例，包含schema中描述的所有属性。数据库schema通常分为两类：定义数据文件实际存储方式的**物理数据库schema ；和逻辑数据库schema **，它描述了应用于存储数据的所有逻辑约束，包括完整性、表和视图。常见包括星型模式（star schema）雪花模式（snowflake schema）事实星座模型（fact constellation schema 或 galaxy schema）星型模式是类似于一个简单的数据仓库图，包括一对多的事实表和维度表。它使用非规范化数据。雪花模式是更为复杂的一种流行的数据库模式，在该模式下，维度表是规范化的，可以节省存储空间并最大限度地减少数据冗余。事实星座模式远比星型模式和雪花模式复杂得多。它拥有多个共享多个维度表的事实表。 Kubernetes中的schema 通过上面的阐述，大概上可以明白 schema究竟是什么东西了，在Kubernetes中也有schema的概念，通过对kubernetes中资源（GVK）的规范定义、相互关系间的映射等，schema即k8s资源对象元数据。而kubernetes中资源对象即 Group Version Kind 这些被定义在 staging/src/k8s.io/api/type.go中，即平时所操作的yaml文件，例如 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 apiVersion: apps/v1 kind: Deployment metadata: name: ngx namespace: default spec: selector: matchLabels: app: ngx template: metadata: labels: app: nginx spec: containers: - name: ngx-schema image: nginx ports: - containerPort: 80 而对应的的即为TypeMeta 、ObjectMeta 和 DeploymentSpec,

k8s开发环境准备 - 如何配置开发环境

Fri, 19 Nov 2021 00:00:00 +0000

下载源码根据kubernetes github 方式可以 text 1 2 3 4 5 mkdir -p $GOPATH/src/k8s.io cd $GOPATH/src/k8s.io git clone https://github.com/kubernetes/kubernetes cd kubernetes make 如果有需要可以切换到对应的版本进行学习或者修改，一般kubernetes版本为对应tag text 1 2 3 git fetch origin [远程tag名] git checkout [远程tag名] git branch 配置goland kubernetes本身是支持 go mod 的，但源码这里提供了所有的依赖在 staging/src/k8s.io/ 目录下，可以将此目录内的文件复制到 vendor下。 bash 1 cp -a staging/src/k8s.io/* vendor/k8s.io/ 对于 k8s.io/kubernetes/pkg/ 发红的（找不到依赖的），可以将手动创建一个目录在 vendor/k8s.io/ 将克隆下来的根目录 pkg 复制到刚才的目录下。 goland中，此时不推荐使用go mod模式了，这里goland一定要配置GOPATH的模式。对应的GOPATH加入 {project}/vender即可。这里可以添加到 goland中 project GOPATH里。

Linux高级IPC - DBus

Thu, 18 Nov 2021 00:00:00 +0000

What is IPC IPC [Inter-Process Communication] 进程间通信，指至少两个进程或线程间传送数据或信号的一些技术或方法。在Linux/Unix中，提供了许多IPC。Unix七大IPC： Pipe：无名管道，最基本的IPC，单向通信，仅在父/子进程之间，也就是将一个程序的输出直接交给另一个程序的输入。常见使用为 ps -ef|grep xxx FIFO [(First in, First out)] 或有名管道（named pipe）:与Pipe不同，FIFO可以让两个不相关的进程可以使用FIFO。单向。 Socket 和 Unix Domain Socket：socket和Unix套接字，双向。适用于网络通信，但也可以在本地使用。适用于不同的协议。消息队列 Message Queue: SysV 消息队列、POSIX 消息队列。 Signal: 信号，是发送到正在运行的进程通知以触发其事件的特定行为，是IPC的一种有限形式。 Semaphore：信号量，通常用于IPC或同一进程内的线程间通信。他们之间使用队列进行消息传递、控制或内容的传递。（常见SysV 信号量、POSIX 信号量） Shared memory：（常见SysV 共享内存、POSIX 共享内存）。共享内存，是在进程（程序）之间传递数据的有效方式，目的是在其之间提供通信。每种IPC都有不通的特点，每种方式对资源的使用及性能都是不通的管道 I/O是最快的，但为单向通信，需要工作在父/子进程关系之间。 UNIX 套接字可以在本地连接不同的进程，并且具有更高的带宽，并且没有固有的消息边界。 TCP/IP套接字可以连接任何进程。并且可以通过网络连接，但是对资源会有更多的开销，同样的没有固定的消息边界。 Reference comparsion Unix/Linux IPC What is D-Bus 提到，D-Bus就不能不提一下freedesktop，而 D-Bus 仅仅作为freedesktop.org的一部分。 D-Bus 桌面总线 (Desktop Bus)，的简写，也是Linux- IPC机制，不同于Unix 7大基础IPC的是，D-Bus是在这些IPC类型之上实现的中间件IPC，D-Bus使用了基础IPC中一种过多种，其设计的目的是在Linux桌面环境，提供服务的标准化。但目前并没有合入主线内核中。作为中间件IPC，D-Bus的性能较低与其他IPC模式，因为在通信过程中会进行很多上下文切换，如果通过Dbus来发送消息，会先将其发送到内核，然后将其送回D-Bus。AF_BUS 补丁是新的套接字类型，用来减少D-Bus上下文的切换。更多可参考：https://en.wikipedia.org/wiki/D-Bus D-Bus组成 D-Bus是一个IPC的实现方式，在架构上分位三层。 Layer 1 libdbus：freedesktop机构提供的一个免费开源的一个由C语言编写的 low-level API 。是提供dbus功能的库。是高级API绑定的低级API。 Layer 2 dbus daemon：dbus实现的IPC守护进行，随Linux启动，通过不通进程对其的连接，实现了多进程间消息的路由（包含内核、网络、桌面等） Layer 3 Wapper libraries （high-level API）：对 low-level API libdbus的封装，例如 libdbus-qt libdbus-python github.

使用firewalld dbus接口配置iptables

Thu, 18 Nov 2021 00:00:00 +0000

firewalld，一个基于动态区的iptables/nftables守护程序，自2009年左右开始开发，CentOS7基于 firewalld-0.6.3 ，发布于2018年10月11日。主要的开发人员是托马斯·沃纳，他目前为红帽公司工作。这是因为为Federal 18 的默认防火墙机制，随后在 Rhel7 和 Centos 7 中使用。 firewalld比旧的 iptable 机制有许多优势。值得注意的是，它解决了 iptable 要求每次更改时重新启动防火墙的问题，从而中断了任何状态连接。它还提供了丰富的 D-Bus 方法、信号和属性。这里并不是从firewalld操作使用方式来介绍firewalld的改名，想反，是介绍firewalld D-Bus API来检索信息或更改设置。 firewalld被配置为系统 D-Bus 服务，注意看 systemd file中的" Type=dbus “参数。 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 $ cat /usr/lib/systemd/system/firewalld.service [Unit] Description=firewalld - dynamic firewall daemon Before=network-pre.target Wants=network-pre.target After=dbus.service After=polkit.service Conflicts=iptables.service ip6tables.service ebtables.service ipset.

通俗易懂的dbus数据结构

Thu, 18 Nov 2021 00:00:00 +0000

DBus中也是类似于静态语言，使用了“强类型”数据格式。在DBus上传递的所有数据都需要声明其对应的类型，下面整理了下，DBus中的数据类型，以及在DBus中声明的数据类型是什么意思。 dbus类型说明 s string 字符串类型，可以声明 s: a array 数组，可以声明为 a: v variant，variant:: () 结构体，声明时为双括号中间的为类型，可以是多个，例如(ss) 即这个结构体内包含两个字符串属性 b 布尔值 SIGNATURE signature类型 y BYTE d DOUBLE t UINT64 x INT64 u UINT32 i INT32 q uint16 n INT16 {} 词典，这里声明为两个括号，中间为其对应的 key value，例如 {sv} 即 key是字符串类型，value是variant类型。 o OBJECT_PATH 对象路径 a{sv} : 是一个数组，为一个键值对的词典，里面仅有一个 (ssssa{ss}as）为一个结构体，里面属性有7个两个词典（数组），五个字符串类型 (sssbsasa(ss)asba(ssss)asasasasa(ss)b) 这个类型拆开为下：共16个属性 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 ( s string s string s string b bool s string as array only one string a(ss) two string type in the array as array only one string b bool a(ssss) four string type in the array as array only one string as array only one string as array only one string as array only one string a(ss) two string type in the array b bool ) 对上述类型，python中就可以很灵活的声明

C程序编译错误记录

Tue, 02 Nov 2021 00:00:00 +0000

Question1: Similar to pause command in linux text 1 read -n 1 Question2 read : Illegal option -n 原因为ubuntu 默认的是dash 不是 bash Reference Question3: How to Compile C programing Language text 1 gcc hello.c -o hello Question4: Segmentation fault (core dumped) 编译正常执行错误，在linux中使用 strace 查看具体报错。 Reference

elasticsearch mapping

Tue, 02 Nov 2021 00:00:00 +0000

索引管理创建索引直接创建索引 PUT newindex1，创建索引可以通过 number_of_shares 和 number_of_replicas 数量来修饰分片和副本的数量。 text 1 2 3 4 5 6 7 8 9 PUT newindex { "settings": { "index" : { "number_of_shares" : 2, "number_of_replicas": 1 } } } number_of_shares 分片数在创建索引后不能修改 number_of_replicas 副本数可以随时完成修改删除索引 DEL index_name 打开/关闭索引 POST {index_name}/_close POST {index_name}/_open 关闭的索引无法进行【增删改查】操作 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 { "error" : { "root_cause" : [ { "type" : "index_closed_exception", "reason" : "closed", "index_uuid" : "3eCslZZ3Q9amlUyDtqTXWA", "index" : "newindex" } ], "type" : "index_closed_exception", "reason" : "closed", "index_uuid" : "3eCslZZ3Q9amlUyDtqTXWA", "index" : "newindex" }, "status" : 400 } 索引的映射 mapping mapping是定义文档及包含字段的存储与索引方式。可以理解为是elasticsearch的表结构，定义mapping，即在创建index时，自行判断每个字段的类型，而不是有ES自动自动判断每个纬度的类型。这种更贴合业务场景，如分词、存储。

Go每日一库 - deepcopier

Sat, 30 Oct 2021 00:00:00 +0000

question: How use golang Copy one struct to another where structs have same members and different types 此时需要的库 github.com/ulule/deepcopier github.com/jinzhu/copier E.g. go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 package main import ( "fmt" "github.

bash shell常用示例

Fri, 22 Oct 2021 00:00:00 +0000

工具命令集合长期总结 - Linux日志查询命令长期总结 - Linux网络命令合集长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例探索kubectl - 巧用jsonpath提取有用数据探索kubectl - kubectl诊断命令集合该文整理一些常用的shell用法，及语法，并非介绍如何使用变量变量可分为两类：环境变量ENV（全局）和局部变量。 bash环境变量变量名含义 _= 上一条命令的最后一个参数 BASH_VERSION=“4.1.2(1)-release” 当前bash实例的版本号 COLORS="/etc/DIR_COLORS" COLUMNS=80 设置该变量就给shell编辑模式和选择命令定义了编辑窗口的宽度 CVS_RSH=“ssh” DIRSTACK 代表目录栈当前的内容 EUID=0 为在shell启动时被初始化的当前用户的有效ID G_BROKEN_FILENAMES=1 GROUPS=() 当前用户所属组 HISTFILE=/root/.bash_history 历史记录文件的全路径 HISTFILESIZE=50 历史文件能包含的最大行数 HISTSIZE=50 记录在命令行历史文件中的命令行数 HOME=/root 当前用户家目录 HOSTNAME= 当前主机机器名称 HOSTTYPE=x86_64 IFS=$’\t\n' 内容字段分隔符，一般是空格符、制表符、和换行符，用于由命令替换，循环结构中的表和读取的输入产生的词的字段划分。 INPUTRC=/etc/inputrc readline启动文件的文件名。取代默认的~/.inputrc JAVA_HOME=/app/jdk1.6 KDENIR=/usr KDE IS PRELINKED=1 LANG=zh_CN.GB18030 LESSONPEN LINES=36 LONGNAME=root 登陆的用户名 LS_COLORS=xx MACHTYPE=x86_64-redhat-linux-gnu 包含一个描述正在运行bash的系统串 MAILCHECK=60 这个参数定义shell将隔多长时间（以秒为单位检查一次由参数MAILPATH或MAILFILE）指定的文件，看看是否有邮件到达。默认600秒 MAIL=/var/spool/mail/root 邮件全路径 OLDPWD=/root 前一个当前工作目录 OPTERR=1 如果设置为1，秒年十时毫，来自getopts内置命令的错误信息。 OPTIND=1 下一个有getopts内置命令处理的参数序号 OSTYPE=linux-gnu 自动设置称一个串，该串标书正在运行bash的操作系统，默认值有系统决定 PATH 全局PATH路径。命令搜索路径。一个有冒号分隔的目录列表，shell用它来搜索命令。默认路径有系统决定，并且由安装bash的管理员设置。 PIPESTATUS=([0]=0 [1]=1) 一个数组，包含一列最进在管道执行的前台作业的进程退出状态值。 PPID=1112 父进程的进程ID PS1=[\u@\h \W]$ 主提示符串，默认值是$ PS2= > 次提示符串，默认值是> PS4=+ 当开启追踪时使用的调试提示符串，默认值是+，追踪可用set-x开启。 PWD 当前用户家目录。 SHELL=/bin/bash SHLVL=1 每启动一个bash实例就将其加1 TMOUT=3600 退出前等待超时的秒数。 UID=0 当前用户的UID，在shell启动时初始化。 USER=root 当前用户的用户名，在shell启动时初始化。自定义环境变量 export

Account locked due to 10 failed logins

Tue, 19 Oct 2021 00:00:00 +0000

进入后，找到linux16 开头的一行！将ro改为 rw init=/sysroot/bin/sh 查看passwd和 shadow 发现用户并没有锁，于是想到，应该是pam的设置。 text 1 pam_tally2.so deny=6 onerr=fail unlock_time=120 默认log在： /var/log/tallylog text 1 2 3 4 chroot /sysroot # 使用pam_tally2命令解锁 pam_tally2 --user=root --reset rw init=/sysroot/bin/sh Reference Centos7.x破解密码 pam_tally2锁用户

goland设置import规范

Thu, 14 Oct 2021 00:00:00 +0000

import 规范引入了三种类型的包，标准库包，第三方包，程序内部包，建议采用如下方式进行组织你的包：有顺序的引入包，不同的类型采用空格分离，第一种标准库第二是第三方包第三是项目包。在项目中不要使用相对路径引入包，在goland中可以使用如下设置自动格式化为引入标准打开设置：Editor > Code Style > Go，选择import标签，将排序改为goimports, 剩下的按照自己喜好进行修改即可 Reference goimports-group

Linux dbus命令行套件

Mon, 11 Oct 2021 00:00:00 +0000

D-Bus是Linux使用的进程间通信机制，允许各个进程互相访问，而不需要为每个其他组件实现自定义代码。即使对于系统管理员来说，这也是一个相当深奥的主题，但它确实有助于解释linux的另一部分是如何工作的。这里主要介绍 dbus-send 与 GDbus cli工具，其他的还有QtDbus , d-feet… 命令行工具dbus-send ，是freedesktoop提供的dbus包配套的命令客户端工具，可用于发送dbus消息。 GDbus GLib实现的dbus工具。较与 dbus-send，拥有更完整的功能。 d-feet: 可以处理所有D-Bus服务的GUI应用程序。 dbus-send dbus有两种消息总线（message bus）：system bus 和 session bus，通过使用 --system和 --session 选项来通过dbus-send 向系统总线或会话总线发送消息。如果两者都未指定，默认为**session bus*. 借此，顺道聊下 system bus 和 session bus： System Bus: 在桌面上，为所有用户提供一条总线. 专用于系统服务。有关于低级时间，例如网络连接，USB设备。在嵌入式Linux系统中，system bus是唯一D-Bus类型。 Session Bus: 每个用户会话一个实例为用户应用提供那个桌面服务。连接到 X-session 参数选项参数说明 --dest=NAME 这个是必选的参数，指定要接收消息的接口名称。例如 org.freedesktop.ExampleName --print-reply 打印回复消息 --print-reply=literal 如选项一样，打印回复正文。如有特殊字符，如对象或 object 则按字面打印，没有标点符号、转义字符等。 --reply-timeout= 可选参数，等待回复的超时时长，单位为毫秒。 --system --session --type=method_call signal 必须始终指定要发送的消息的对象路径和名称。以下参数（如果有）是消息内容（消息参数）。这些值作为类型指定的值给出，可能包括如下所述的容器（数组、dict和变体）。支持参数 dbus-send 发送的消息，在调用方法需要传参数时，必须将这些值给出。dbus-send 支持传入的参数的类型，并不为D-Bus支持的所有的数据类型，仅为一些简单的类型：如

python drf之viewset

Wed, 06 Oct 2021 00:00:00 +0000

What is Views drf提供了两个基类，五个视图扩展类，9个视图集 drf提供了一个Django中view的子类APIView ,主要变动大概为以下：重新封装了Request 与 Response实例。使用了独有的Request与Response对象，并且提供了专有的解析器 Parser 可以根据HTTP Content-Type 指明的请求数据进行解析。增加了自有的鉴权/节流在django中dispatch() 分发前，会对请求进行身份认证、权限检查、流量控制。异常捕获 APIException。 APIView implement python 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 @classmethod def as_view(cls, **initkwargs): .... # 调用父类的方法，Python 3 可以使用直接使用 super().xxx 代替 super(Class, self).xxx view = super(APIView, cls).as_view(**initkwargs) view.cls = cls # 并且生成一个新的request view.initkwargs = initkwargs # Note: session based authentication is explicitly CSRF validated, # all other authentication is CSRF exempt.

python drf之Serializer

Mon, 04 Oct 2021 00:00:00 +0000

What is serializers？ serializers主要作用是将原生的Python数据类型（如 model querysets ）转换为web中通用的JSON，XML或其他内容类型。 DRF 提供了一个Serializer类，它为您提供了种强大的通用方法来控制响应的输出，以及一个ModelSerializer 类，它为创建处理 model instance 和 serializers 提供了一个序列化的快捷方式。 Reference drf serializers manual How to Declaring Serializers? 序列化一个django model python 1 2 3 4 5 6 7 class Comment: def __init__(self, email, content, created=None): self.email = email self.content = content self.created = created or datetime.now() comment = Comment(email='leila@example.com', content='foo bar') 声明Serializers，可以用来序列化与反序列化对象 Comment的属性及值。 python 1 2 3 4 5 6 from rest_framework import serializers class CommentSerializer(serializers.

python django使用

Sun, 03 Oct 2021 00:00:00 +0000

路由匹配 django中默认匹配页 text 1 url(r'^$', views.login), django中404匹配 text 1 url(r'^$', views.login), # 需要放置最后，不过一般不推荐，都是通过异常捕获处理 named group 名称组 https://docs.djangoproject.com/en/1.11/topics/http/urls/#named-groups text 1 url(r'^test[0-9]{4}',views.login) 反向解析别名不能出现冲突 text 1 2 from django.shortcuts import reverse reverse(xxx) 名称组反向解析无名分组 python 1 2 3 4 5 6 # 路由部分 url(r'^index/(\d+)/', views.home, name='xxx') # 前端 <a href="{% url 'id' obj.id %}" class="btn btn-primary btn-xs">remove</a>s # 后端 print reverse('id', args=(id,)) 有名称分组 python 1 2 3 4 5 6 7 8 # 路由部分 url(r"^userdel/(?

django ORM

Sat, 02 Oct 2021 00:00:00 +0000

https://www.cnblogs.com/Dominic-Ji/p/11516152.html 对象关系映射（Object Relational Mapping，简称ORM）模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。 ORM在业务逻辑层和数据库层之间充当了桥梁的作用。 django中仅测试ORM 导入model，然后直接使用对应对象进行ORM操作。 text 1 2 3 4 5 6 7 import os if __name__ == "__main__": os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings") import django django.setup() from xxx import models models.User.objects.all() 连接数据库 django配置数据库 python 1 2 3 4 5 6 7 8 9 10 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'USER': 'root', 'PASSWORD': '111', 'HOST':'127.0.0.1', 'NAME': 'book', 'CHARSET': 'utf8' } } 可选：pymysql 使用模块连接MySQL数据库:：在项目中__init__.py 文件中添加配置： python 1 2 import pymysql pymysql.

mysql5.6 innodb_large_prefix引起的一个异常

Sat, 02 Oct 2021 00:00:00 +0000

phenomenon： Specified key was too long; max key length is 3072 bytes 在修改一个数据库字段时，字段容量被限制为了表前缀的大小而不是本身的容量大小查了一下innodb_large_prefix究竟是什么？动态行格式DYNAMIC row format 支持最大的索引前缀(3072)。由变量innodb_large_prefix进行控制。 By default, the index key prefix length limit is 767 bytes. See Section 13.1.13, “CREATE INDEX Statement”. For example, you might hit this limit with a column prefix index of more than 255 characters on a TEXT or VARCHAR column, assuming a utf8mb3 character set and the maximum of 3 bytes for each character.

由PIPE size 引起的线上故障

Sat, 02 Oct 2021 00:00:00 +0000

sence：python中使用subprocess.Popen(cmd, stdout=sys.STDOUT, stderr=sys.STDERR, shell=True) ，stdout, stderr 为None. 在错误中执行是无法捕获 stderr的内容，后面将上面的改为 subprocess.Popen(cmd, stdout=PIPE, stderr=PIPE, shell=True),发现是可以拿到 stderr, 但是会遇到大量任务hanging，造成线上事故。为此特意查询subprocess的一些参数的说明。 stdin stdout stderr 如果这些参数为 PIPE, 此时会为一个文件句柄，而传入其他（例如 sys.stdout 、None 等）的则为None 正如这里介绍的一样，subprocess 。而使用 PIPE，却导致程序 hanging。一般来说不推荐使用 stdout=PIPE stderr=PIPE，这样会导致一个死锁，子进程会将输入的内容输入到 pipe，直到操作系统从buffer中读取出输入的内容。查询手册可以看到确实是这个问题 Refernce Warning This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.

go面试题收集

Fri, 01 Oct 2021 00:00:00 +0000

数据结构数据类型总结 Go语言将数据类型分为四类：基础类型、复合类型、引用类型和接口类型。基础数据类型包括：基础类型：布尔型、整型、浮点型、复数型、字符型、字符串型、错误类型。复合数据类型包括：指针、数组、切片、字典、通道、结构体、接口。什么是反射在计算机科学领域，反射是指一类应用，它们能够自描述和自控制。在go中，编译时不知道类型的情况下，可更新变量、运行时查看值、调用方法以及直接对他们的布局进行操作的机制，称为反射。场景：无法透视一个未知类型的时候，这时候就需要有反射来帮忙你处理，反射使用TypeOf和ValueOf函数从接口中获取目标对象的信息，轻松完成目的。 rune与byte的区别 byte是uint8、rune为uint32，一个仅限于ascii码的值，一个支持更多的值。rune比byte能表达更多的数。 golang默认使用utf8编码，一个中文占用3字节，一个utf8数字占用1字节，utf8字母占用1字节切片切片的扩容：切片扩容，一般方式：上一次容量的2倍，超过1024字节，每次扩容上一次的1/4 切片的截取：在截取时，capacity 不能超过原slice的 capacity new() 与 make() 的区别 new(T) 和 make(T, args) 是Go语言内建函数，用来分配内存，但适用的类型不用。 new函数用于分配指定类型的零值对象，并返回指向其内存地址的指针。例如，new(int)将分配一个类型为int且值为0的对象，并返回一个指向该地址的指针。可以使用*运算符访问指针指向的值。 make函数用于创建和初始化内置类型（如map、slice、channel）的数据结构，并返回其指针。它比new函数更加复杂很多，因为它需要知道类型的大小和结构，以便为其分配内存并初始化其字段或元素。例如，make(map[string]int)将创建一个空的map。它有一个string类型的键和一个int类型的值。 nil切片和空切片指向的地址一样吗？ nil切片和空切片指向的地址==不一样==。nil空切片引用数组指针地址为0（无指向任何实际地址）空切片的引用数组指针地址是有的，且固定为一个值什么是Receiver Golang的Receiver是绑定function到特定type成为其method的一个参数，即一个function加了receiver就成为一个type的method。构体方法跟结构体指针方法的区别（Receiver和指针Receiver的区别） T 的方法集仅拥有 T Receiver。 *T 方法集则包含全部方法 (Receiver + *Receiver)。 sync.once 是 Golang package 中使方法只执行一次的对象实现，作用与 init 函数类似。但也有所不同 init 函数是在文件包首次被加载的时候执行，且只执行一次 sync.Onc 是在代码运行中需要的时候执行，且只执行一次当一个函数不希望程序在一开始的时候就被执行的时候，我们可以使用 sync.Once 实现：sync.Once 的源码实现非常简单，采用的是双重检测锁机制 (Double-checked Locking)，是并发场景下懒汉式单例模式的一种实现方式首先判断 done 是否等于 0，等于 0 则表示回调函数还未被执行加锁，确保并发安全在执行函数前，二次确认 done 是否等于 0，等于 0 则执行将 done 置 1，同时释放锁疑问一: 为什么不使用乐观锁 CAS 简单的来说就是 f() 的执行结果最终可能是不成功的，所以你会看到现在采用的是双重检测锁机制来实现，同时需要等 f() 执行完成才修改 done 值疑问二: 为什么读取 done 值的方式没有统一比较 done 是否等于 0，为什么有的地方用的是 atomic.

kubernetes面试题收集

Fri, 01 Oct 2021 00:00:00 +0000

Kubernetes概念 Ingress和LoadBalancer的区别 Ingress通常用于将HTTP(S)流量路由到Kubernetes群集内部的服务，支持复杂路径路由和负载均衡算法 LB则是通过提供商提供一种外部流量引入到集群内的组件，通常为2 3层 Ingress本身是基于service的，引入流量时依赖 kube-proxy LB则是独立的组件，最小接入单元也是service，而通过2 3层的广播等功能可以提供多节点的引入功能：Ingress是一个规范，LB则是一种实现实现方式：ingress通过扩展Kubernetes API+controller, 而LB除此外还需要外部设备提供（软硬件，云组件） kubernetes之最小单元 Pod最小可调度单元，最小部署单元容器：容器是最小的执行单元 Namespace：最小隔离单元 Service：最小接入单元 etcd用的什么算法，简单解释一下 raft算法强一致性同一时间只能有一个leader,所有的操作都在leader上。 Pod 的生命周期 Pod 状态始终处于一下几个状态之一: Pending: 部署 Pod 事务已被集群受理，但当前容器镜像还未下载完或现有资源无法满足 Pod 的资源需求 Running: 所有容器已被创建，并被部署到节点上 Successed: Pod 成功退出，并不会被重启 Failed: Pod 中有容器被终止 Unknown: 未知原因，如 kube-apiserver 无法与 Pod 进行通讯 Kubernetes有哪些不同类型的服务？ cluster ip Node Port Load Balancer Extrenal Name 什么是ETCD？ Etcd是用Go编程语言编写的，是一个分布式键值存储，用于协调分布式工作。因此，Etcd存储Kubernetes集群的配置数据，表示在任何给定时间点的集群状态。什么是Ingress网络，它是如何工作的？ Ingress网络是一组规则，充当Kubernetes集群的入口点。这允许入站连接，可以将其配置为通过可访问的URL，负载平衡流量或通过提供基于名称的虚拟主机从外部提供服务。因此，Ingress是一个API对象，通常通过HTTP管理集群中服务的外部访问，是暴露服务的最有效方式。什么是Headless Service？ Headless Service类似于“普通”服务，但没有群集IP。此服务使您可以直接访问pod，而无需通过代理访问它。什么是集群联邦？在联邦集群的帮助下，可以将多个Kubernetes集群作为单个集群进行管理。因此，您可以在数据中心/云中创建多个Kubernetes集群，并使用联邦来在一个位置控制/管理它们。联合集群可以通过执行以下两项操作来实现此目的。请参考下图。 kube-proxy的作用 kube-proxy运行在所有节点上，它监听apiserver中service和endpoint的变化情况，创建路由规则以提供服务IP和负载均衡功能。简单理解此进程是Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。 kube-proxy iptables的原理 Kubernetes从1.

操作系统类面试题收集

Fri, 01 Oct 2021 00:00:00 +0000

Linux 基础进程如何查找特定进程消耗多少内存 bash 1 ps aux --sort=-%mem 按住 ctrl + c 会发生什么按下 Ctrl + C 时，会向当前正在运行的前台进程发送一个信号，具体来说是 SIGINT 信号（Interrupt Signal，中断信号）。这个信号的作用是请求进程中断执行，通常会导致进程终止。信号编号是 2。如果程序有处理信号，那么将不会发生任何事情。守护、僵⼫、孤⼉进程的概念终端【答】守护进程：运⾏在后台的⼀种特殊进程，独⽴于控制终端并周期性地执⾏某些任务。僵⼫进程：⼀个进程 fork ⼦进程，⼦进程退出，⽽⽗进程没有 wait/waitpid⼦进程，那么⼦进程的进程描述符仍保存在系统中，这样的进程称为僵⼫进程。孤⼉进程：⼀个⽗进程退出，⽽它的⼀个或多个⼦进程还在运⾏，这些⼦进程称为孤⼉进程。（孤⼉进程将由 init 进程收养并对它们完成状态收集⼯作）进程间通讯方式有哪些？ Pipe：无名管道，最基本的IPC，单向通信，仅在父/子进程之间，也就是将一个程序的输出直接交给另一个程序的输入。常见使用为 ps -ef|grep xxx FIFO [(First in, First out)] 或有名管道（named pipe）:与Pipe不同，FIFO可以让两个不相关的进程可以使用FIFO。单向。 Socket 和 Unix Domain Socket：socket和Unix套接字，双向。适用于网络通信，但也可以在本地使用。适用于不同的协议。消息队列 Message Queue: SysV 消息队列、POSIX 消息队列。 Signal: 信号，是发送到正在运行的进程通知以触发其事件的特定行为，是IPC的一种有限形式。 Semaphore：信号量，通常用于IPC或同一进程内的线程间通信。他们之间使用队列进行消息传递、控制或内容的传递。（常见SysV 信号量、POSIX 信号量） Shared memory：（常见SysV 共享内存、POSIX 共享内存）。共享内存，是在进程（程序）之间传递数据的有效方式，目的是在其之间提供通信。 BASH和DOS控制台之间的主要区别在于3个方面：答案： BASH命令区分大小写，而DOS命令则不区分; 在BASH下，/ character是目录分隔符，\ 作为转义字符。在DOS下，/ 用作命令参数分隔符，\ 是目录分隔符 DOS遵循命名文件中的约定，即8个字符的文件名后跟一个点，扩展名为3个字符。BASH没有遵循这样的惯例。 Linux 中进程有哪几种状态？在 ps 显示出来的信息中，分别用什么符号表示的？答案：

监控类面试题

Fri, 01 Oct 2021 00:00:00 +0000

Prometheus的四种数据类型 Counter(计数器类型) Counter类型的指标的工作方式和计数器一样，只增不减 Gauge(仪表盘类型) Gauge是可增可减的指标类，通常用于反应当前应用的状态。 Histogram 主要用于表示一段时间范围内对数据进行采样 Summary(摘要类型) Summary类型和Histogram类型相似，主要用于表示一段时间内数据采样结果 Prometheus 的局限 Prometheus 是基于 Metric 的监控，不适用于日志（Logs）、事件(Event)、调用链(Tracing)。 Prometheus 默认是 Pull 模型，合理规划你的网络，尽量不要转发。对于集群化和水平扩展，官方和社区都没有银弹，需要合理选择 Federate、Cortex、Thanos等方案。监控系统一般情况下可用性大于一致性，容忍部分副本数据丢失，保证查询请求成功。这个后面说Thanos 去重的时候会提到。 Prometheus 不一定保证数据准确，这里的不准确一是指 rate、histogram_quantile 等函数会做统计和推断，产生一些反直觉的结果，这个后面会详细展开。二来查询范围过长要做降采样，势必会造成数据精度丢失，不过这是时序数据的特点，也是不同于日志系统的地方采集组件 All IN One Prometheus 体系中 Exporter 都是独立的，每个组件各司其职，如机器资源用 Node-Exporter，Gpu 有Nvidia Exporter等等。但是 Exporter 越多，运维压力越大，尤其是对 Agent做资源控制、版本升级。我们尝试对一些Exporter进行组合，方案有二：通过主进程拉起N个 Exporter 进程，仍然可以跟着社区版本做更新、bug fix。用Telegraf来支持各种类型的 Input，N 合 1。另外，Node-Exporter 不支持进程监控，可以加一个Process-Exporter，也可以用上边提到的Telegraf，使用 procstat 的 input来采集进程指标。合理选择黄金指标采集的指标有很多，我们应该关注哪些？Google 在 “Sre Handbook” 中提出了“四个黄金信号”：延迟、流量、错误数、饱和度。实际操作中可以使用 Use 或 Red 方法作为指导，Use 用于资源，Red 用于服务。 Use 方法：Utilization、Saturation、Errors。如 Cadvisor 数据 Red 方法：Rate、Errors、Duration。如 Apiserver 性能指标 Prometheus 采集中常见的服务分三种：

网络基础面试题收集

Fri, 01 Oct 2021 00:00:00 +0000

域名相关什么是DNS劫持 DNS劫持就是通过劫持了DNS服务器，通过某些手段取得某域名的解析记录控制权，进而修改此域名的解析结果，导致对该域名的访问由原IP地址转入到修改后的指定IP，其结果就是对特定的网址不能访问或访问的是假网址，从而实现窃取资料或者破坏原有正常服务的目的。DNS劫持通过篡改DNS服务器上的数据返回给用户一个错误的查询结果来实现的。通俗来讲：DNS劫持就是指用户访问一个被标记的地址时，DNS服务器故意将此地址指向一个错误的IP地址的行为。范例，网通、电信、铁通的某些用户有时候会发现自己打算访问一个地址，却被转向了各种推送广告等网站，这就是DNS劫持。 DNS劫持症状：在某些地区的用户在成功连接宽带后，首次打开任何页面都指向ISP提供的“电信互联星空”、“网通黄页广告”等内容页面。还有就是曾经出现过用户访问Google域名的时候出现了百度的网站。这些都属于DNS劫持。解决：对于DNS劫持，可以采用使用国外免费公用的DNS服务器解决。例如OpenDNS（208.67.222.222）或GoogleDNS（8.8.8.8）。什么是DNS污染 DNS污染是指在DNS服务器中修改DNS解析结果的过程，以便将用户重定向到恶意网站或欺骗性网站，而不是所期望的目标网站。攻击者可以通过多种方式进行DNS污染攻击。最常见的手段是在用户的网络中添加一个恶意DNS服务器，或者在受感染的计算机上运行一个恶意DNS服务器。当用户试图连接到互联网上的某个网站时，计算机将查询DNS服务器以查找目标网站的IP地址。如果攻击者控制的恶意DNS服务器已将相应的IP地址修改为攻击者的网站，则用户将被重定向到恶意网站或欺骗性网站。 DNS污染发生在用户请求的第一步上，直接从协议上对用户的DNS请求进行干扰。 DNS污染症状：目前一些被禁止访问的网站很多就是通过DNS污染来实现的，例如YouTube、Facebook等网站。解决：可靠的DNS服务器，但这种方式效果不佳手动修改Hosts文件使用VPN或域名远程解析加密通信：VPN可以加密整个通信过程，这意味着攻击者无法窃取UDP数据包中的任何信息，包括DNS查询请求和响应。这样可以避免DNS查询被篡改的风险。虚拟IP地址：VPN会给每个用户分配其所连接的虚拟IP地址，使用户的真实IP地址不会暴露在公共互联网中。这样，DNS服务器只能看到VPN服务器的IP地址，而无法识别用户的IP地址。这意味着攻击者无法跟踪用户的访问历史，从而减少遭受DNS污染攻击的风险。总结： DNS污染，指的是用户访问一个地址，国内的服务器(非DNS)监控到用户访问的已经被标记地址时，服务器伪装成DNS服务器向用户发回错误的地址的行为。范例，访问Youtube、Facebook之类网站等出现的状况。什么是域名被墙这种情况一般出现在解析为国外地址的域名上，假如域名下的网站非法信息多，敏感，又不整改，会直接被G.F.W墙掉，就是通常所说的被封锁、被屏蔽、被和谐，结果就是访问域名是打不开的，但是解析是正常的。此时域名在国内是无法使用的，国外可以访问和使用。主要有以下几种情况： ip 被墙解决：换 ip 。域名被 url 重置（访问时出现ERR_CONNECTION_RESET 或 “连接重置” 换域名做301跳转，(有专门服务商)，域名通过解析到国内301服务商，重定向到真是国外IP，以减少流量和权重的丢失。上 https或域名备案，智能解析分国内，国外。可以使用HTTPS；一般来讲解析到国外的IP的域名，有敏感词会被重置，GFW可以进行敏感词检测（http为明文），使用https加密GFW无法检测数据包内容，（客户端与服务端默认会有公钥私钥，而GFW没有）。域名被国家出口 dns 污染，解决：用国内 dns ，备案回国。域名被省级 dns 污染，解决：能做到这个这里可能为内部或对应运营商被黑（只能进行dns清洗，一般大流量域名了）什么是DNS清洗？ DNS清洗是一项旨在阻止访问特定网站和域名的措施，在该措施中，Internet服务提供商（ISP）通过其服务器筛选特定网站的DNS查询，并将查询重定向到一个错误的IP地址（通常是一个不存在的地址），从而防止用户访问该网站。这种措施通常是由政府、公司或组织实施，旨在防止用户接触到不适当、危险或非法的内容。网络攻击相关什么是TCP的SYN攻击？如何预防？ TCP SYN攻击是一种利用TCP协议三次握手机制的攻击。攻击者发送大量伪造的TCP SYN请求（数据包），然后在TCP三次握手建立连接的第二步时停止（使服务器不断地向攻击者发送SYN-ACK确认，但攻击者不回复ACK确认），从而导致服务器等待客户端的确认信号很长时间，最终占用服务器的资源而无法处理新的请求。为了预防TCP SYN攻击，可以采取以下措施：服务器操作系统的设置：可以设置TCP的连接数和时间等参数，限制每个IP地址的连接数，设置连接超时时间。防火墙设置：可以设置防火墙规则，根据IP地址、端口等信息对连接进行过滤，控制IP地址的访问等。加强网络监测：使用入侵检测系统（IDS）对流量进行实时监控，并对异常流量进行报警处理。使用SYN Cookies：SYN cookies是一种可以防止SYN攻击的技术，它通过特殊的算法对TCP连接进行加密，并保存在服务器端，当客户端发送响应时，服务器端可以对连接进行识别和验证，从而防止SYN攻击。增加硬件设备：可以增加具有流量分析和过滤功能的硬件设备来协助防御SYN攻击，这种设备可以通过分析流量实现精细化的流量分析和识别。 ddos攻击的类型 DDoS攻击（Distributed Denial of Service）是一种利用许多计算机和网络设备构成的“僵尸网络”对一个或多个目标服务器发起攻击，从而占用大量的网络资源，耗尽系统资源，导致服务拒绝的攻击方式。DDoS攻击的类型可以分为以下几种：带宽攻击（Bandwidth-based Attack）：利用大量的数据流或报文，通过消耗目标系统的网络带宽使其服务不能正常传输。应用层攻击（Application-Layer Attack）：利用正常流量模拟合法用户的请求，通过消耗服务器CPU和内存资源使其无法处理合法请求。反射式攻击（Reflection Attack）：使用伪造的IP地址向网络中的一个或多个服务器发起请求，这些服务器会响应请求，但响应信息将被发回目标服务器，从而形成了一次反射式攻击。慢速攻击（Slowloris Attack）：利用HTTP协议的设计漏洞，向目标服务器发送大量不完整请求，从而占用目标服务器处理请求的线程资源。 IoT攻击（IoT Attack）：通过侵入大量的物联网设备，如路由器、摄像头、智能家居等，利用这些设备来发起攻击，构建大规模的“僵尸网络”。 DNS Amplification攻击：攻击者向域名服务器发送请求，利用伪造的IP地址和请求报文，让服务器向目标主机发送大量的DNS解析响应数据包，从而使目标系统在短时间内遭受网络拥塞。 NTP Amplification攻击：攻击者伪造IP地址，向其余互联网上安装有网络时间服务器（Network Time Protocol，NTP）软件的服务器发送请求，从而获取大量NTP响应包，最终将其转发到目标IP地址，从而占用目标系统的网络带宽。 SYN Flood攻击：攻击者向目标服务器发送大量的TCP SYN请求，但却不发送客户端的应答确认，造成服务器长时间处于等待状态，无法接受正常的TCP连接请求。 HTTP Flood攻击：攻击者利用HTTP叠加攻击、HTTP POST攻击等手段，向目标系统发送大量HTTP请求和数据包，造成目标系统资源的耗尽，从而导致服务不可用。 ICMP Flood攻击：攻击者向目标系统发送大量的ICMP数据包，造成目标系统CPU和内存资源的消耗，从而导致系统缓慢或崩溃。什么是反射式攻击反射式攻击（Reflection Attack）是一种利用网络协议的设计缺陷进行攻击的方式。攻击者通常会利用一些可以进行源地址欺骗或反射的协议，例如Domain Name System（DNS），Simple Network Management Protocol（SNMP），和Network Time Protocol（NTP）等。攻击者利用这些协议在网络中进行广播，构造一些请求消息，伪造源IP地址为目标IP地址，将请求消息发送给网络上的服务器，要求其向目标IP地址回送响应。这样攻击者就可以通过伪造的IP地址对目标系统进行攻击，占用它的网络带宽和资源，极大地降低了目标系统的可用性。

运维类面试题收集

Fri, 01 Oct 2021 00:00:00 +0000

如何优化 Linux系统（笼统）不用root，添加普通用户，通过sudo授权管理更改默认的远程连接SSH服务端口及禁止root用户远程连接定时自动更新服务器时间配置国内yum源关闭selinux及iptables（iptables工作场景如果有外网IP一定要打开，高并发除外）调整文件描述符的数量精简开机启动服务（crond rsyslog network sshd）内核参数优化（/etc/sysctl.conf）更改字符集，支持中文，但建议还是用英文字符集，防止乱码锁定关键系统文件清空/etc/issue，去除系统及内核版本登录前的屏幕显示基础命令 ps aux 中的VSZ代表什么意思，RSS代表什么意思 VSZ:虚拟内存集,进程占用的虚拟内存空间 RSS:物理内存集,进程战用实际物理内存空间 shell下32位随机密码生成 text 1 cat /dev/urandom | head -1 | md5sum | head -c 32 >> /pass 将生成的32位随机数保存到/pass文件里了统计出nginx的access.log中访问量最多的5个IP text 1 cat access_log | awk '{print $1}' | sort | uniq -c | sort -n -r | head -5 web与lb 讲述一下LVS三种模式的工作过程 LVS负载的原理，和Nginx负载有啥区别 VS/NAT：（Virtual Server via Network Address Translation）

WSL与Windows环境共享

Wed, 28 Jul 2021 00:00:00 +0000

在使用 wsl 时，总是需要执行 windows 的 cmd，但是windows命令行对于大多数人使用起来还是不习惯，微软提供了在 windows 中Linux与Windows的命令互通，即可以使用cmd shell执行Linux命令，也可以使用bash shell来执行windows命令。 WSL可对 Windows 与 Linux 之间的集成操作：从 Linux shell（如 Ubuntu）运行 Windows 工具（任意 .exe）。从 Windows shell（即 PowerShell or cmd ）运行 Linux 命令（如 cd ls grep）。在 WSL与windows之间共享环境变量。（版本 17063+）满足上述要求，可以很好地使用windows的软件在WSL中畅快的操作，即空WSL环境拥有了python解析器 docker等操作。如何在 WSL和 Windows 之间共享环境变量从Build 17063 开始，可以利用 WSLENV 来增强 Win/WSL 之间的环境变量互操作。什么是WSLENV WSLENV 是一个以冒号分隔的环境变量列表，当从 WSL 启动 WSL进程或 Win进程时包含的变量每个变量都可以以斜杠作为后缀，后跟标识位以指定它的转换方式 WSLENV 可以在 WSL 和 Win32 之间转换的路径 WSLENV。在WSL中，是以冒号分隔的列表。在Win中，是以分号分隔的列表可以在.bashrc或者windows自定义环境变量中设置WSLENV 例如：一个WSLENV应该设置为 text 1 WSLENV=GOPATH/l:USERPROFILE/w:SOMEVAR/wp 在17063之前，WSL访问Windows环境变量唯一方法是使用全路径（可以使用全路径从WSL下启动Win32可执行文件）。但是没有办法在WSL中设置环境变量，调用Win进程，并期望将该变量传送到进程。

windows递归复制指定时间后修改过的文件

Fri, 23 Jul 2021 00:00:00 +0000

因为在拷贝web站点时，也会存在更新，需要定期覆盖新的内容，就是上次覆盖的时间和到这次时间内修改过的文件都复制。实现命令xcopy text 1 2 3 4 5 6 xcopy src dest $ xcopy D:\WWW\back1\* D:\WWW\back4 /D:05-22-2018 /F /E /y D:\WWW\back1\db_qbe.php -> D:\WWW\back4\db_qbe.php D:\WWW\back1\docs.css -> D:\WWW\back4\docs.css D:\WWW\back1\test\changelog.php -> D:\WWW\back4\test\changelog.php 复制了 3 个文件 /D:mm-dd-yyyy /F 打印复制过程 /E 递归复制目录和子目录包括空目录 /Y 禁止提示

python使用虚拟环境venv

Mon, 14 Jun 2021 00:00:00 +0000

venv模块支持使用自己的站点目录创建轻量级“虚拟环境”，可选择与系统站点目录隔离。每个虚拟环境都有自己的Python二进制文件（与用于创建此环境的二进制文件的版本相匹配），并且可以在其站点目录中拥有自己独立的已安装 Python 软件包集。 3.6 版后已移除: pyvenv 是 Python 3.3 和 3.4 中创建虚拟环境的推荐工具，不过在 Python 3.6 中已弃用。在 3.5 版更改: 现在推荐使用 venv 来创建虚拟环境。创建venv虚拟环境如果使用python2，则需要安装virtualenv模块 text 1 2 pip install virtualenv python -m virtualenv {name} python3内置了 venv 模块，可以直接使用 text 1 python3 -m venv {name} 进入虚拟环境 linux text 1 venv\Scripts\activate windows text 1 venv\Scripts\activate.bat 退出环境 text 1 2 venv\Scripts\deactivate.bat venv\Scripts\deactivate 使用venv环境安装软件报错 Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host=‘pypi.

awk常用案例

Wed, 02 Jun 2021 00:00:00 +0000

工具命令集合长期总结 - Linux日志查询命令长期总结 - Linux网络命令合集长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例探索kubectl - 巧用jsonpath提取有用数据探索kubectl - kubectl诊断命令集合 ##AWK运算符运算符说明赋值运算符 = += -= *= /= %= ^= **= 逻辑运算符 || 逻辑或 && 逻辑与正则运算符 ~ !~ 匹配正则表达式和不匹配正则表达式关系运算符 < <= > >= != == 关系运算符算术运算符 + - 加，减 *** / &** 乘，除与求余 + - ! 一元加，减和逻辑非 ^ *** 求幂 ++ – 增加或减少，作为前缀或后缀其他运算符 $ 字段引用空格字符串链接符 ?

P2P打洞技术

Wed, 02 Jun 2021 00:00:00 +0000

P2P 概述相比于 C/S B/S 架构来说， P2P 是由 Peer 组成。每个Peer同时是客户端也是服务器。这意味着，P2P网络中的peer点为每个其他的peer提供服务，所有节点直接相互通信，没有中心节点，并共享资源源相互联系。 P2P有结构化的P2P网络和非结构化P2P网络。如TomP2P (Java的一个框架，一个分布式哈希表，提供去中心化的键/值基础设施）。而Gnutella (第一个分散式P2P文件共享网络)，是非结构化（unstructured）P2P网络的。另外还有两种类型的P2P网络，即集中式（centralized）P2P网络（Napster）和混合（hybrid p2p）peer网络（如Skype）。 NAT网络由于NAT的网络模型，破坏了主机 Peer之间的端到端连接，因此P2P网络需要穿过NAT网络，而穿过NAT网络是目前为P2P技术面临的一个很大的挑战。网络地址转换，NAT （Network Address Translation）是一种模糊指明的机制，可以将两个IP连接在一起，一个NAT设备总是拥有至少两个IP地址，（公网IP，私网IP），NAT就是将数据包上的IP地址在传输时，将私网IP转换为公网IP。每个NAT设备会维护一个NAT表，该表存储了所有活动的连接。在创建网络映射后，NAT将源IP地址和端口更改为外部源IP地址和端口。NAT保留端口，不将新端口分配给外部源。一旦创建了映射，只要映射存在，与之联系的设备就能够发回消息。不存在NAT映射的所有来自外部的通信请求都是无法穿越NAT。因此，在P2P环境中，如果两个peer位于在NAT之后，两者都无法直接联系，因为它们之间不知道外部IP地址和源端口，NAT表中并没有其所维护的映射信息。所以NAT穿越中的主要问题之一是网络地址转换问题。 NAT网络类型一般来讲， NAT网络可以分为四种类型: nat type 全锥型(Full Cone) 受限锥型(Restricted Cone)，或者说是IP受限锥型端口受限锥型(Port Restricted Cone), 或者说是IP + PORT受限锥型对称型(Symmetric) Full Cone NAT 全锥形全锥形网络（Full Cone NAT）的工作原理类似于 IP 地址一对一映射。内部 IP 和端口映射到相同的外部地址和端口。之后，任何外部源都可以通过向外部地址发送数据包来访问内部主机。这意味着，一旦创建了映射，任何外部主机都可以联系内部主机。如下图地址受限形的锥形NAT Address Restricted Cone NAT 地址受限形锥形 NAT是，仅当内部主机先联系外部主机时，受限锥形 NAT 才会为相应的内部主机分配外部IP。外部主机然后能够通过分配的外部地址联系内部主机。对称型 Symmetric nat 对称 NAT 是最难穿过的NAT，因为对称将随机端口分配给映射。如果外部主机首先与内部主机连接，则外部主机只能知道外部映射。在 P2P 场景中，如果两个Peer（主机）位于 NAT 后面，则它们无法互相通信以让另一个对等体知道所使用的映射。此外，对称 NAT 几乎不可能知道分配的端口以通过打孔（hole Punching）建立连接。

python中的signal

Wed, 02 Jun 2021 00:00:00 +0000

什么是信号信号（signal）– 进程间通讯的一种方式，也可作为一种软件中断的方法。一个进程一旦接收到信号就会打断原来的程序执行来按照信号进行处理。简化术语，信号是一个事件，用于中断运行功能的执行。信号始终在主Python线程中执行。对于信号，这里不做详细介绍。 Python封装了操作系统的信号功能的库 singal 的库。singal 库可以使我们在python程序中中实现信号机制。 https://zh.wikipedia.org/wiki/Unix%E4%BF%A1%E5%8F%B7) Python的信号处理首先需要了解Python为什么要提供 signal Library。信号库使我们能够使用信号处理程序，以便当接收信号时都可以执行自定义任务。 Mission：当接收到信号时执行信号处理方法可以通过使用 signal.singal() 函数来实现此功能 Python对信号的处理通常情况下Python 信号处理程序总是会在主 Python 主解析器的主线程中执行，即使信号是在另一个线程中接收的。这意味着信号不能被用作线程间通信的手段。你可以改用 threading 模块中的同步原语。 Python信号处理流程，需要对信号处理程序（signal handling ）简要说明。signal handling 是一个任务或程序，当检测到特定信号时，处理函数需要两个参数，即信号id signal number （Linux 中 1-64），与堆栈帧 frame。通过相应信号启动对应 signal handling ，signal.signal() 将为信号分配处理函数。如：当运行一个脚本时，取消，此时是捕获到一个信号，可以通过捕获信号方式对程序进行异步的优雅处理。通过将信号处理程序注册到应用程序中： py 1 2 3 4 5 6 7 8 9 10 11 import signal import time def handler(a, b): # 定义一个signal handling print("Signal Number:", a, " Frame: ", b) signal.

macos python安装mysqlapi集合

Thu, 29 Apr 2021 00:00:00 +0000

记录一下，接了一个python2 django1.x的项目，很老了导致很多扩展无法安装 os version：macos catalina python version: 2.7.18 而django后端使用sqllite以外需要对应客户端引擎，而安装时编译依赖C客户端即实际mysql组件。使用的数据库后端。内建的数据库后端有： ‘django.db.backends.postgresql’ ‘django.db.backends.mysql’ ‘django.db.backends.sqlite3’ ‘django.db.backends.oracle’ 并且修改配置实例 text 1 2 3 4 5 6 7 8 9 10 DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'USER': 'mydatabaseuser', 'NAME': 'mydatabase', 'TEST': { 'NAME': 'mytestdatabase', }, }, } brew unlink mysql error: command ‘gcc’ failed with exit status 1 text 1 2 3 4 5 6 creating build/temp.macosx-10.9-x86_64-2.7 gcc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -g -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Dversion_info=(1,2,5,'final',1) -D__version__=1.

Linux VMware Tools详解

Wed, 17 Feb 2021 00:00:00 +0000

VMware Tools描述 VMware Tools 中包含一系列服务和模块，可在 VMware 产品中实现多种功能，从而使用户能够更好地管理客户机操作系统，以及与客户机系统进行无缝交互。在Linux虚拟机中安装VMware Tools 安装前准备虚拟机必须打开cd/dvd驱动器，否则安装VMware Tools的选项无法选择 VMware Tools安装程序是使用Perl编写的，必须确认操作系统中安装Perl。安装步骤在虚拟机菜单中右键单击虚拟机，然后单击客户机 > 安装/升级 VMware Tools。要创建一个挂载点 mkdir /mnt/cdrom 要装载 CDROM，mount /dev/cdrom /mnt/cdrom 要将安装文件文件复制到临时目录：cp /mnt/cdrom/VMwareTools*.tar.gz /tmp/；其中，* 部分是 VMware Tools 软件包的版本号，故以替代*。解压文件：cd /tmp && tar -zxvf VMwareTools*.tar.gz 运行PERL脚本以安装VMware Tools：cd vmware-tools-distrib && ./vmware-install.pl，若要求选择，一路回车即可。安装完成后清理 rm -fr {/tmp/VMwareTools*,/tmp/vmware-tools-distrib} ; yum remove perl -y，如不需要perl可以卸载命令集合 bash 1 2 3 4 5 mkdir /mnt/cdrom mount /dev/cdrom /mnt/cdrom cp /mnt/cdrom/VMwareTools*.tar.gz /tmp/ cd /tmp && tar -xf VMwareTools*.

calico网络策略

Mon, 15 Feb 2021 00:00:00 +0000

什么是网络策略在Kubernetes平台中，要实现零信任网络的安全架构，Calico与istio是在Kubernetes集群中构建零信任网络必不可少的组件。而建立和维护整个集群中的“零信任网络”中，网络策略的功能在操作上大致可以总结为使用资源配置模板来管理控制平面数据流。说白了讲网络策略就是用来控制Pod间流量的规则。在Calico中如何编写网络策略要使用网络策略就需要先了解Calico功能**：NetworkPolicy和GlobalNetworkPolicy**。 NetworkPolicy资源，简称np；是命名空间级别资源。规则应用于与标签选择器匹配的endpoint的集合。 GlobalNetworkPolicy资源，简称 gnp/gnps与NetworkPolicy功能一样，是整个集群级别的资源。 GlobalNetworkPolicy 与 NetworkPolicy资源的管理也与calico的部署方式有关，使用etcd作为存储时，资源的管理只能使用 calicoctl进行管理 NetworkPolicy与GlobalNetworkPolicy的构成 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 apiVersion: projectcalico.org/v3 kind: NetworkPolicy metadata: name: allow-tcp-90 spec: selector: app == 'envoy' # 应用此策略的endpoint types: # 应用策略的流量方向 - Ingress - Egress ingress: # 入口的流量规则 - action: Allow # 流量的行为 protocol: ICMP # 流量的协议 notProtocol: TCP # 匹配流量协议不为值的流量 source: # 流量的来源 src与dst的匹配关系为与，所有的都生效即生效 nets: # 有效的来源IP selector: # 标签选择器 namespaceSelector: # 名称空间选择器 ports: # 端口 - 80 # 单独端口 - 6040:6050 # 端口范围 destination: # 流量的目标 egress: # 出口的流量规则 - action: Allow serviceAccountSelector: # 使用与此规则的serviceAccount NetworkPolicy使用实例：允许6379流量可以被 role=frontend的pod访问

基于混合云模式的calico部署

Mon, 15 Feb 2021 00:00:00 +0000

开始前准备确定calico数据存储 Calico同时支持kubernetes api和etcd数据存储。官方给出的建议是在本地部署中使用K8S API，仅支持Kubernetes模式。而官方给出的etcd则是混合部署（Calico作为Kubernetes和OpenStack的网络插件运行）的最佳数据存储。使用etcd作为calico数据存储的好处：允许多平台混用calico，如Kubernetes OpenStack上运行Calico Kubernetes资源与Calico资源分离一个Calico群集，该群集不仅仅包含一个Kubernetes群集，如可与多个kubernetes集群互通。坏处：安装步骤繁琐无法使用Kubernetes RBAC对calico资源的控制无法使用Kubernetes资源对calico进行管理下载calico部署清单 text 1 curl https://docs.projectcalico.org/manifests/calico-etcd.yaml -o calico.yaml 修改Pod CIDR Calico默认的Pod CIDR使用的是192.168.0.0/16，这里一般使用与controller-manager中的--cluster-cidr 保持一,取消资源清单内的 CALICO_IPV4POOL_CIDR变量的注释，并将其设置为与所选Pod CIDR相同的值。 calico的IP分配范围 Calico IPAM从ipPool分配IP地址。修改Pod的默认IP范围则修改清单calico.yaml中的CALICO_IPV4POOL_CIDR 配置Calico的 IP in IP 默认情况下，Calico中的IPIP已经禁用，这里使用的v3.17.2 低版本默认会使用IPIP 要开启IPIP mode则需要修改配置清单内的 CALICO_IPV4POOL_IPIP 环境变量改为 always 修改secret yaml 1 2 3 4 5 6 7 8 9 10 11 # Populate the following with etcd TLS configuration if desired, but leave blank if # not using TLS for etcd.

Linux中169.254.0.0/24的路由来自哪里

Mon, 08 Feb 2021 00:00:00 +0000

在Linux中，发现每次系统启动时，都会将（169.254.0.0/16）路由启动并将其添加到路由表中。但是并不知道这条路由具有什么功能和它到底来自于哪里？ text 1 2 3 4 5 6 $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.0.2 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 要想搞清楚路由（169.254.0.0/16）究竟来自哪里并且它的作用是什么？首先需要搞明白两个概念 zeroconf “zeroconf”或“Zero Configuration Networking” 是一种无需额外配置即可自动创建IP地址网络的技术。也被称为 “Automatic Private IP Addressing”（APIPA）。 zeroconf规范的提出者是Apple公司，其目的是让非专业用户也可以便捷的连接各种网络设备，例如计算机，打印机等。整个搭建网络的过程都是自动实现。如果没有“zeroconf”，用户必须手动，或者利用对应的服务（例如DHCP、DNS）对网络进行配置。这些过程对非技术用户和新用户们来说是很一件难的事情。 zeroconf的出现是问了解决三个问题：为网络设备自动分配可用IP地址解析计算机主机名自动发现网络服务（如打印机等） zeroconf的地址选用对于Link-local address，IPv4使用的特殊保留地址169.254.0.0/16，在RFC3927中所描述。作用是当DHCP客户端在超时和重试后扔找不到对应的DHCP服务器，它将随机从该网络(｀169.254.0.0/16｀)中获取地址。这样可以与无法获取DHCP地址的主机进行通信。如何禁用zeroconf 要在系统引导期间禁用zeroconf路由，需要编辑/etc/sysconfig/network文件，配置以下内容 text 1 2 3 NETWORKING=YES HOSTNAME=localhost.

基于Kubernetes的PaaS平台提供dashboard支持的一种方案

Thu, 28 Jan 2021 00:00:00 +0000

本文转自博客：我的小米粥分你一半我一直在负责维护的PaaS平台引入了Kubernetes作为底层支持, 可以借助Kubernetes的生态做更多的事情, 这篇博客主要介绍如何为用户提供dashboard功能, 以及一些可以扩展的想法. 希望读者有一定的kubernetes使用经验, 并且了解rbac的功能。 Dashboard功能 Kubernetes原生提供了Web界面, 也就是Dashboard, 具体的参考可以见官方文档: 安装完成后, 我们一般是通过token来使用的, 不同的token有着不同的权限. 上面所说的token是Bearer Token, 除了在界面上输入之外, 你可以这么来用, 通过添加header即可. text 1 curl -H "Authorization: Bearer ${TOKEN}" https://{dashboard}/api/myresource PaaS平台使用Dashboard简要讨论需求分析 Dashboard本身的功能是十分强大的, 但是给所有人admin权限显然是不现实的. 对于一个普通用户来讲, PaaS平台的将他的应用(代码)部署好并运行, 他所需要关注的就只有属于他自己的项目, 平台也需要做好权限控制, 避免一个用户操作了另一个用户的应用. 权限系统设计基于以上的需求讨论, 平台需要做的操作就是为每个用户创建属于自己的权限提供, 并限制可以访问到的资源. 考虑这样的情况: 我们有一个用户A, 他拥有自己的一个应用群组(G), 群组中部署了一系列应用程序(a1, a2…). 在Kubernetes中, 这样的群组概念我们将其映射为namespace, 群组(G) <=> 用户空间(NS), 我们需要控制的权限控制策略就变成了用户A在用户空间NS的权限控制. token分发策略拥有了权限控制后, 所需要打就是将token分发给用户, 当然这是一种极度不安全的做法, Kubernetes中的token创建之后一般是不会改变的, 分发这样的token会有很大的安全风险, 有两个方面: 1. 用户A将token保存了下来, 那么他就能不经过平台登录Dashboard, 这样不利于审计工作, 2. token一旦泄露, PaaS平台很难做到反应(因为token脱离了平台的控制, 无法判断究竟是什么时候发生了泄露, 也无法马上吊销这个token), 安全风险比较高.

ARP与ARP Proxy

Wed, 20 Jan 2021 00:00:00 +0000

什么是arp 地址解析协议，Address Resolution Protoco，使用ARP协议可实现通过IP地址获得对应主机的的物理地址（MAC）在TCP/IP的网络环境下，每个互联网的主机都会被分配一个32位的IP地址，这种互联网地址是在网际范围标识主机的一种逻辑地址。为了让报文在物理网路上传输，还补习要知道对方目的主机的物理地址才行。这样就存在把IP地址变换成物理地址的地址转换问题。在以太网环境，为了正确地向目的主机传送报文，必须把目的主机的32为IP地址转换成为目的主机48位以太网地址(MAC),这个就需要在互联层有一个服务或功能将IP地址转换为相应的物理地址(MAC)，这个服务就是ARP协议. 所谓的"地址解析"，就是主机在发送帧之前将目标IP地址转换成目标MAC地址的过程。ARP协议的基本功能就是通过目标设备的IP地址，查询目标设备的MAC地址，以保证主机间互相通信的顺利进行. ARP协议和DNS有相像之处。不同点是：DNS实在域名和IP之间解析，另外ARP协议不需要配置服务，而DNS要配置服务才行。 ARP缓存表在每台安装有TCP/IP协议的设备都会有一个ARP缓存表（windows命令提示符里输入arp -a即可），表里的IP地址与MAC地址是一一对应的。 bash 1 2 3 4 5 6 7 8 9 10 C:\Users\CM>arp -a 接口: 192.168.1.103 --- 0x3 Internet 地址物理地址类型 192.168.1.1 3c-46-d8-5d-53-87 动态 192.168.1.255 ff-ff-ff-ff-ff-ff 静态 224.0.0.22 01-00-5e-00-00-16 静态 224.0.0.251 01-00-5e-00-00-fb 静态 224.0.0.252 01-00-5e-00-00-fc 静态 239.11.20.1 01-00-5e-0b-14-01 静态 239.255.255.250 01-00-5e-7f-ff-fa 静态 arp常用命令 arp -a 查看所有记录 arp -d 清除arp表 arp -s $ip $mac 将绑定IP和MAC arp -n 不解析名称打印arp表 ARP缓存是把双刃剑主机有了arp缓存表，可以加快arp的解析速度，减少局域网内广播风暴。

动态路由- BGP

Wed, 20 Jan 2021 00:00:00 +0000

概述 BGP Border Gateway Protocol 边界网关协议,，是一种运行于TCP上的自治系统AS（Autonomous System）之间的路由可达，并选择最佳路由的距离矢量路由协议。早期发布的三个版本分别是BGP-1、BGP-2和BGP-3，1994年开始使用BGP-4，2006年之后单播IPv4网络使用的版本是BGP-4，其他网络（如IPv6等）使用的版本是MP-BGP。 MP-BGP是对BGP-4进行了扩展，来达到在不同网络中应用的目的，BGP-4原有的消息机制和路由机制并没有改变。MP-BGP在IPv6单播网络上的应用称为BGP4+，在IPv4组播网络上的应用称为MBGP（Multicast BGP）。历史为方便管理规模不断扩大的网络，网络被分成了不同的自治系统。1982年，外部网关协议EGP（Exterior Gateway Protocol）被用于实现在AS之间动态交换路由信息。但是EGP设计得比较简单，只发布网络可达的路由信息，而不对路由信息进行优选，同时也没有考虑环路避免等问题，很快就无法满足网络管理的要求。 BGP是为取代最初的EGP而设计的另一种外部网关协议。不同于最初的EGP，BGP能够进行路由优选、避免路由环路、更高效率的传递路由和维护大量的路由信息。虽然BGP用在AS之间传递路由信息，但并非所有AS之间传递路由信息都要运行BGP。如数据中心上行到Internet的出口上，为了避免Internet海量路由对数据中心内部网络影响，设备采用静态路由代替BGP与外部网络通信。受益 BGP从多方面保证了网络的安全性、灵活性、稳定性、可靠性和高效性： BGP采用认证和GTSM的方式，保证了网络的安全性。 BGP提供了丰富的路由策略，能够灵活的进行路由选路，并且能指导邻居按策略发布路由。 BGP提供了路由聚合和路由衰减功能用于防止路由振荡，有效提高了网络的稳定性。 BGP使用TCP作为其传输层协议（端口号为179），并支持BGP与BFD联动、BGP Tracking和BGP GR和NSR，提高了网络的可靠性。在邻居数目多、路由量大且大多邻居有相同出口策略场景下，BGP用按组打包技术极大提高了BGP打包发包性能。 BGP相关名词说明名词说明 BGP 边界网关协议（Border Gateway Protocol）是互联网上一个核心的去中心化自治路由协议，它通过维护IP路由表或前缀表来实现自治系统（AS）之间的可达性大多数ISP使用BGP来与其他ISP创建路由连接，特大型的私有IP网络也可以使用BGPBGP的通信对端（对等实体，Peer）通过TCP（端口179）会话交换数据，BGP路由器会周期地发送19字节的保活消息来维护连接。在路由协议中，只有BGP使用TCP作为传输层协议 IBGP 内部边界网关协议。同一个AS内部的两个或多个对等实体之间运行的BGP被称为IBGP IGP 内部网关协议。同一AS内部的对等实体（路由器）之间使用的协议，它存在可扩容性问题：1. 一个IGP内部应该仅有数十（最多小几百）个对等实体2. 对于端点数，也存在限制，一般在数百（最多上千）个Endpoint级别IBGP和IGP都是处理AS内部路由的，仍然需要IGP的原因是：1. IBGP之间是TCP连接，也就意味着IBGP邻居采用的是逻辑连接的方式，两个IBGP连接不一定存在实际的物理链路。所以需要有IGP来提供路由，以完成BGP路由的递归查找2. BGP协议本身实际上并不发现路由，BGP将路由发现的工作全部移交给了IGP协议，它本身着重于路由的控制 EBGP 外部边界网关协议。归属不同的AS的对等实体之间运行的BGP称为EBGP AS 自治系统（Autonomous system），一个组织（例如ISP）管辖下的所有IP网络和路由器的整体参与BGP路由的每个AS都被分配一个唯一的自治系统编号（ASN）。对BGP来说ASN是区别整个相互连接的网络中的各个网络的唯一标识。64512到65535之间的ASN编号保留给专用网络使用 RouteReflector 同一AS内如果有多个路由器参与BGP路由，则它们之间必须配置成全连通的网状结构——任意两个路由器之间都必须配置成对等实体。由于所需要TCP连接数是路由器数量的平方，这就导致了巨大的TCP连接数为了缓解这种问题，BGP支持两种方案：Route Reflector、Confederations路由反射器（Route Reflector）是AS内的一台路由器，其它所有路由器都和RR直接连接，作为RR的客户机。RR和客户机之间建立BGP连接，而客户机之间则不需要相互通信RR的工作步骤如下：1. 从非客户机IBGP对等实体学到的路由，发布给此RR的所有客户机2. 从客户机学到的路由，发布给此RR的所有非客户机和客户机3. 从EBGP对等实体学到的路由，发布给所有的非客户机和客户机RR的一个优势是配置方便，因为只需要在反射器上配置工作负载 Workload，即运行在Calico节点上的虚机或容器全互联全互联网络（Full node-to-node Mesh）是指任何两个Calico节点都进行配对的L3连接模式 BGP 应用国内IDC机房需要在 CNNIC (中国互联网信息中心)或 APNIC (亚太网络信息中心)申请自己的IP地址段和AS号，然后将自己的IP地址广播到其它网络运营商的AS中，并通过BGP协议将多个AS进行连接，从而实现可自动跨网访问。此时，当用户发出访问请求后，将根据BGP协议的机制自动在已建立连接的多个AS之间为用户提供最佳路由，从而实现不同网络运营商用户的高速访问同一机房资源。 BGP的运行 BGP使用TCP为传输层协议，TCP端口号179。路由器之间的BGP会话基于TCP连接而建立。运行BGP的路由器被称为BGP发言者（BGP Speaker），或BGP路由器。两个建立BGP会话的路由器互为对等体（或称通信对端/对等实体，peer）。BGP对等体之间交换BGP路由表。 BGP路由器只发送增量的BGP路由更新，或进行触发更新（不会周期性更新）。 BGP具有丰富的路径属性和强大的路由策略工具。

calico network cni网络方案

Mon, 18 Jan 2021 00:00:00 +0000

Calico针对容器、虚拟机的开源网络和网络安全解决方案。是纯三层的数据中心网络方案。 Calico在每一个计算节点利用Linux Kernel实现了一个高效的虚拟路由器vRouter来负责数据转发，而每个vRouter通过BGP协议负责把自己上运行的workload的路由信息向整个Calico网络内传播。（小规模部署可以直接互联 BGP full mesh，大规模下可通过指定的BGP route reflector来完成）。这样保证最终所有的workload之间的数据流量都是通过IP路由的方式完成互联的。Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network。 Calico还基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。 calico组件在Kubernetes平台之上calico/node容器会通过DaemonSet部署到每个节点，并运行三个守护程序： Felix：用于管理路由规则，负责状态上报。 BIRD：BGP的客户端，用于将Felix的路由信息加载到内核中，同时负责路由信息在集群中的分发。 confd：用于监视Calico存储（etcd）中的配置变更并更新BIRD的配置文件。 calicoctl使用问题 text 1 Failed to create Calico API client: invalid configuration: no configuration has been provided 默认情况下，calicoctl 将使用位于的默认KUBECONFIG从 Kubernetes APIServer 读取$(HOME)/.kube/config 。如果默认的 KUBECONFIG 不存在，或者想从指定的存储访问信息，则需要单独配置。 bash 1 2 3 export DATASTORE_TYPE=kubernetes export DATASTORE_TYPE=etcdv3 export KUBECONFIG=~/.kube/config reference for calico 安装配置开始前准备确定calico数据存储 Calico同时支持kubernetes api和etcd数据存储。官方给出的建议是在本地部署中使用K8S API，仅支持Kubernetes模式。而官方给出的etcd则是混合部署（Calico作为Kubernetes和OpenStack的网络插件运行）的最佳数据存储。使用kubernetes api作为数据存储的安装 text 1 2 curl https://docs.projectcalico.org/manifests/calico.yaml -O kubectl apply -f calico.

静态路由

Mon, 18 Jan 2021 00:00:00 +0000

在因特网中，网络连接设备用来控制网络流量和保证网络数据传输质量。常见的网络连接设备有集线器（Hub）、网桥（Bridge）、交换机（Switch）和路由器（Router）。路由器是一种典型的网络连接设备，用来进行路由选择和报文转发。路由器根据收到报文的目的地址选择一条合适的路径（包含一个或多个路由器的网络），然后将报文传送到下一个路由器，路径终端的路由器负责将报文送交目的主机。路由（routing）就是报文从源地址传输到目的地址的活动。路由发生在OSI网络参考模型中的第三层即网络层。当报文从路由器到目的网段有多条路由可达时，路由器可以根据路由表中最佳路由进行转发。最佳路由的选取与发现此路由的路由协议的优先级、路由的度量有关。当多条路由的协议优先级。路由是数据通信网络中最基本的要素。路由信息就是指导报文发送的路径信息，路由的过程就是报文转发的过程。根据路由目的地的不同，路由可划分为：网段路由：目的地为网段，IPv4地址子网掩码长度小于32位或IPv6地址前缀长度小于128位。主机路由：目的地为主机，IPv4地址子网掩码长度为32位或IPv6地址前缀长度为128位。根据目的地与该路由器是否直接相连，路由又可划分为：直连路由：目的地所在网络与路由器直接相连。间接路由：目的地所在网络与路由器非直接相连。根据目的地址类型的不同，路由还可以分为：单播路由：表示将报文转发的目的地址是一个单播地址。组播路由：表示将报文转发的目的地址是一个组播地址。路由的优先级对于相同的目的地，不同的路由协议（包括静态路由）可能会发现不同的路由，但这些路由并不都是最优的。事实上，在某一时刻，到某一目的地的当前路由仅能由唯一的路由协议来决定。为了判断最优路由，各路由协议（包括静态路由）都被赋予了一个优先级，当存在多个路由信息源时，具有较高优先级（取值较小）的路由协议发现的路由将成为最优路由，并将最优路由放入本地路由表中。路由协议优先级 DIRECT 0 OSPF 10 IS-IS IS-IS Level1 15 IS-IS Level 2 由网关加入的路由 50 路由器发现的路由 55 静态路由 60 UNR（User Network Route） DHCP（Dynamic Host Configuration Protocol）：60AAA-Download：60IP Pool：61Frame：62Host：63NAT（Network Address Translation）：64IPSec（IP Security）：65NHRP（Next Hop Resolution Protocol）：65PPPoE（Point-to-Point Protocol over Ethernet）：65 Berkeley RIP 100 点对点接口聚集的路由 110 OSPF的扩展路由 140 OSPF ASE 150 OSPF NSSA 150 BGP 170 EGP 200 IBGP 255 EBGP 255 其中，0表示直接连接的路由，255表示任何来自不可信源端的路由；数值越小表明优先级越高。除直连路由（DIRECT）外，各种路由协议的优先级都可由用户手工进行配置。另外，每条静态路由的优先级都可以不相同。路由器根据路由转发数据包，路由可通过手动配置和使用动态路由算法计算产生，其中手动配置的路由就是静态路由。

深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术

Mon, 18 Jan 2021 00:00:00 +0000

本文是关于深入理解Kubernetes网络原理系列第2章深入理解Kubernetes Pod网络原理 - 网络名称空间深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Overview 本文将介绍Kubernetes中使用的相关虚拟网络功能，目的是为了任何无相关网络背景经历的人都可以了解这些技术在kubernetes中式如何应用的。 VLAN VLAN (Virtual local area networks)是逻辑上的LAN而不受限于同一物理网络交换机上。同样的VLAN也可以将同一台交换机/网桥下的设备/划分为不同的子网。

使用eNSP构建calico BGP网络

Mon, 18 Jan 2021 00:00:00 +0000

实验文件： [calico BGP.zip](https://cdn.jsdelivr.net/gh/cylonchau/blogs@img/img/calico BGP.zip) R1 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 system-view sysname R1 interface l0 ip address 1.1.1.1 32 interface g0/0/0 ip address 10.1.0.1 24 interface g0/0/1 ip address 10.3.0.1 24 bgp 100 router-id 1.1.1.1 peer 10.1.0.2 as-number 123 peer 10.3.0.2 as-number 456 dis this dis ip interface b R2 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 system-view sysname R2 interface l0 ip address 2.

网络隧道技术

Mon, 18 Jan 2021 00:00:00 +0000

隧道技术概要隧道技术（Tunneling）是网络基础设置在网络之间传递数据的方式，使用隧道技术传递可以是不同协议的数据包，隧道协议将这些其他协议的数据包重新封装在新的包头中发送。被封装的数据包在隧道的两个端点之间通过网络进行路由，被封装数据包在网络上传递时所经历的逻辑路径称为隧道。简单来说，隧道技术是一类网络协议，是将一个数据包封装在另一个数据包中进行传输的技术；**使用隧道的原因是在不兼容的网络上传输数据，或在不安全网络上提供一个安全路径。**通过网络隧道技术，可以使隧道两端的网络组成一个更大的内部网络。（把不支持的协议数据包打包成支持的协议数据包之后进行传输）。隧道协议要创建隧道，隧道的客户机和服务器双方必须使用相同的隧道技术，隧道协议有二层隧道协议与三层隧道协议两类。二层隧道协议对应OSI模型中数据链路层，使用帧作为数据交换单位，PPTP、L2TP、L2F都属于二层隧道协议。是将数据封装在点对点协议的帧中通过互联网络发送。三层隧道协议对应OSI模型中网络层，使用包作为数据交换单位，GRE、IPSec 都属于三层隧道协议。都是数据包封装在附加的IP包头中通过IP网络传送。在例如VxLAN，工作在传输层和网络层之间。具体来说，将运行在用户数据报协议 (UDP) 和网络数据报协议 (IP) 之间，以便在网络中建立安全的通信通道。网络隧道技术应用隧道在Linux 中应用 IP隧道是指一种可在两网络间进行通信的通道。在该通道里，会先封装其他网络协议的数据包，之后再传输信息。 Linux原生共支持5种IPIP隧道： ipip: 普通的IPIP隧道，就是在报文的基础上再封装成一个IPv4报文 gre: 通用路由封装（Generic Routing Encapsulation），定义了在任意一种网络层协议上封装其他任意一种网络层协议的机制，所以对于IPv4和IPv6都适用 sit: sit模式主要用于IPv4报文封装IPv6报文，即IPv6 over IPv4 isatap: 站内自动隧道寻址协议（Intra-Site Automatic Tunnel Addressing Protocol），类似于sit也是用于IPv6的隧道封装 vti: 即虚拟隧道接口（Virtual Tunnel Interface），是一种IPsec隧道技术像IPVS/LVS中的 Virtual Server via IP Tunneling，就是使用了IPIP隧道 SSH隧道技术 SSH提供了一个重要功能，称为转发 forwarding 或者称为隧道传输tunneling，它可以通过加密频道将明文流量导入隧道中，在创建SSH隧道时， SSH客户端要设置并转交一个特定本地端口号到远程机器上；一旦SSH隧道创建，用户可以连到指定的本地端口号以访问网络服务。本地端口号不用与远地端口号一样。 SSH隧道主要使用场景一般为规避防火墙、加密网络流量规避防火墙，SSH隧道可以使一个被防火墙阻挡的协议可被包在另一个没被防火墙阻挡的协议里，这技巧可用来逃避防火墙政策。而这种操作符合“数据包封装在另一个数据包中进行传输的技术”，故称为SSH隧道技术。 SSH隧道类型在ssh连接的基础上，指定 ssh client 或 ssh server 的某个端口作为源地址，所有发至该端口的数据包都会透过ssh连接被转发出去；至于转发的目标地址，目标地址既可以指定，也可以不指定，如果指定了目标地址，称为定向转发，如果不指定目标地址则称为动态转发：定向转发定向转发把数据包转发到指定的目标地址。目标地址不限定是ssh client 或 ssh server，既可以是二者之一，也可以是二者以外的其他机器。

长期总结 - Linux网络命令合集

Mon, 18 Jan 2021 00:00:00 +0000

工具命令集合长期总结 - Linux日志查询命令长期总结 - Linux网络命令合集长期总结 - Linux性能分析命令 awk常用案例 bash shell常用示例探索kubectl - 巧用jsonpath提取有用数据探索kubectl - kubectl诊断命令集合理解ldap - OpenLDAP客户端命令行使用 Overview 作为系统管理员或程序员，经常需要诊断分析和解决网络问题，而配置、监控与保护网络有助于发现问题并在事情范围扩大前得意解决，并且网络的性能与安全也是管理与诊断网络的重要部分。本文将总结常用与Linux网络管理的命令与使用示例，保持长期更新与更正。 IP iproute2 包含网络、路由、ARP缓存等的管理与配置的ip命令，用来取代传统的 ifconfig 与 route；ip 使用第二个参数，指定在对象执行的操作（例如，add delete show）。 ip 命令是配置网络接口的强大工具，任何 Linux 系统管理员都应该知道。它用于启动或关闭接口、分配和删除地址和路由、管理 ARP 缓存等等。 ip 常用的子命令有： link (l) 网络接口管理 address (a) IP地址管理 route (r) 路由表管理 neigh (n) arp表管理各系统下的包名与安装 Ubuntu/Debian: iproute2 ；apt install iproute2 CentOS/Fedora: iproute2 ；yum install -y iproute2 Apline：iproute2 ；apk add iproute2 ip link ip link 用于管理和显示网络接口

istio sidecar流量处理机制及配置

Sat, 09 Jan 2021 00:00:00 +0000

sidecar 介绍在istio的流量管理等功能，都需要通过下发的配置应用到应用运行环境执行后生效，负责执行配置规则的组件在service mesh中承载应用代理的实体被称为side-car Istio对流量策略管理等功能无须对应用程序做变动，这种对应用服务完全非侵入的方式完全依赖于Side-car，应用的流量有Sidecar拦截并进行认证、鉴权、策略执行等治理功能。在Kubernetes平台中，Side-car容器于应用容器在同一个Pod中并共享网络名词控件，因此Side-car容易可以通过iptables规则拦截进出流量进行管理。 sidecar的注入 sidecar是service mesh无侵入式架构的应用模式，在使用sidecar部署服务网格时，无需再每个应用节点运行服务代理，但是需要在每个应用程序中部署一个sidecar容器，来接管所有进出流量。 Sidecar会将额外容器注入到 Pod 模板中。Istio中的数据平面组件所需的容器有： istio-init 用于设置容器的iptables规则，目的是为了接管进出流量。在应用容器前启动并运行完成其生命周期，多个init容器按顺序依次完成。 istio-proxy 基于envoy的sidecar的代理。 sidecar被注入的方式手动注入，使用 istioctl 修改容器模板并添加前面提到的两个容器的配置。不论是手动注入还是自动注入，Istio 都从 istio-sidecar-injector 和的 istio 两个 Configmap 对象中获取配置。 refer-istio-sidecar-injector 自动注入，在部署应用是，istio自动将sidecar注入到pod。这是istio推荐的方法，Istio在基于Kubernetes平台之上，需要在部署应用之前，对要标记部署应用程序的名称空间标记 kubectl label namespace default istio-injection=enabled 这个操作是对名称空间级别生效的。而后所部署的Pod中会注入sidecar执行上面sidecar容器的操作。 istio injector 注入原理 Sidecar Injector是Istio中实现自动注入Sidecar的组件，它是以Kubernetes准入控制器 AdmissionController 的形式运行的。Admission Controller 的基本工作原理是拦截Kube-apiserver的请求，在对象持久化之前、认证鉴权之后进行拦截。 Admission Controller有两种：一种是内置的，另一种是用户自定义的。 Kubernetes允许用户以Webhook的方式自定义准入控制器，Sidecar Injector就是这样一种特殊的MutatingAdmissionWebhook。 Sidecar Injector只在创建Pod时进行Sidecar容器注入，在Pod的创建请求到达 Kube-apiserver 后，首先进行认证鉴权，然后在准入控制阶段，Kube-apiserver以REST的方式同步调用Sidecar Injector Webhook服务进行init与istio-proxy容器的注入，最后将Pod对象持久化存储到etcd中。 sidecar容器 sidecar容器内部运行着 pilot-agent 与 envoy Pilot-agent：基于kubernetesAPI资源对象为envoy初始化可用的bootstrap配置进行启动，在运行后管理envoy运行状态，如配置变更，出错重启等。 envoy：数据平面的执行层，由 pilot-agent 所启动的，从xDS API动态获取配置信息。Envoy并通过流量拦截机制处理入栈及出栈的流量。 envoy的listener 在运行在Kubernetes平台之上的istio，Envoy是通过Pilot将Kubernetes CRD资源 DestnationRule VirtualService Gateway等资源提供的配置，生成对应的Envoy配置。

istio部署问题Q&A

Sun, 03 Jan 2021 00:00:00 +0000

端口绑定无权限创建Gateway，提示绑定端口无权限。 text 1 2 3 2020-12-27T12:25:30.974288Z warning envoy config gRPC config for type.googleapis.com/envoy.config.listener.v3.Listener rejected: Error adding/updating listener(s) 0.0.0.0_90: cannot bind '0.0.0.0:90': Permission denied 问题原因：容器内默认权限不能使用非特权端口（<1024 导出部署清单部署失败 bash 1 istioctl manifest generate > generated-manifest.yaml 如果尝试使用来安装和管理Istio istioctl manifest generate，请注意以下警告： Istio名称空间（istio-system默认情况下）必须手动创建。 istioctl install 会从Kubernetes上下文中自动检测特定于环境的设置。如需手动安装需要执行如下步骤： --set values.global.jwtPolicy=third-party-jwt --set values.global.jwtPolicy=first-party-jwt refer token Generate a manifest

动态路由 - OSPF

Sat, 02 Jan 2021 00:00:00 +0000

Open Shortest Path First OSPF，开放的最短路径优先协议，是IETF组织开发的一个基于链路状态的内部网关协议，它的使用不受任何厂商限制，所有人都可以使用，所以称为开放的，而最短路径优先（SPF）只是OSPF的核心思想，其使用的算法是Dijkstra算法，最短路径优先并没有太多特殊的含义，并没有任何一个路由协议是最长路径优先的，所有协议，都会选最短的。 OSPF针对IPv4协议使用的是OSPF Version 2（RFC2328）；针对IPv6协议使用OSPF Version 3（RFC2740）目的：在OSPF出现前，网络上广泛使用RIP（Routing Information Protocol）作为内部网关协议。由于RIP是基于距离矢量算法的路由协议，存在着收敛慢、路由环路、可扩展性差等问题，所以逐渐被OSPF取代。 OSPF作为基于链路状态的协议，能够解决RIP所面临的诸多问题。此外，OSPF还有以下优点： OSPF采用组播形式收发报文，这样可以减少对其它不运行OSPF路由器的影响。 OSPF支持无类型域间选路（CIDR）。 OSPF支持对等价路由进行负载分担。 OSPF支持报文加密。由于OSPF具有以上优势，使得OSPF作为优秀的内部网关协议被快速接收并广泛使用。 OSPF协议特点： OSPF把自治系统AS（Autonomous System）划分成逻辑意义上的一个或多个区域； OSPF通过LSA（Link State Advertisement）的形式发布路由； OSPF依靠在OSPF区域内各设备间交互OSPF报文来达到路由信息的统一； OSPF报文封装在IP报文内，可以采用单播或组播的形式发送。 OSPF工作流程寻找邻居 OSPF协议运行后，先寻找网络中可与自己交互链路状态信息的周边路由器，可以交互链路状态信息的路由器互为邻居建立邻居关系邻接关系可以想象为一条点到点的虚链路，他是在一些邻居路由器之间构成的。只有建立了可靠邻接关系的路由器才相互传递链路状态信息。链路状态信息传递 OSPF路由器将建立描述网络链路状态的LSA Link State Advertisement，链路状态公告，建立邻接关系的OSPF路由器之间将交互LSA，最终形成包含网络完整链路状态的配置信息。计算路由获得了完整的LSBD后，OSPF区域内的每个路由器将会对该区域的网络结构有相同的认识，随后各路由器将依据LSDB的信息用SPF算法独立计算出路由。 Router ID OSPF Router-ID用于在OSPF domain中唯一地表示一台OSPF路由器，从OSPF网络设计的角度，我们要求全OSPF域内，禁止出现两台路由器拥有相同的Router-ID。 OSPF Router-ID的设定可以通过手工配置的方式，或者通过协议自动选取的方式。当然，在实际网络部署中，强烈建议手工配置OSPF的Router-ID，因为这关系到协议的稳定。实验：单区域OSPF配置配置两台路由器 bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 [Huawei]sysname R2 [R2]interface lo0 [R2-LoopBack0]ip add 2.

深入理解Kubernetes Pod网络原理 - 网络名称空间

Sat, 02 Jan 2021 00:00:00 +0000

本文是关于深入理解Kubernetes网络原理系列第1章深入理解Kubernetes Pod网络原理 - 网络名称空间深入理解Kubernetes Pod网络原理 - Linux虚拟网络技术深入理解Kubernetes Pod网络原理 - CNI 深入理解Kubernetes Pod网络原理 - 跟随 flannel 学习CNI原理深入理解Kubernetes Pod网络原理 - 跟随 flannel + multus 剖析 Chained Plugins 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 1 (Shell) 深入理解Kubernetes Pod网络原理 - 从零实现一个 CNI Plugin part 2 (libcni) 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 1 深入理解Kubernetes Pod网络原理 - Kubernetes网络模型 2 深入理解Kubernetes Pod网络原理 - Pod网络排错思路 Linux namespace namespace是Linux内核的一项功能，该功能对内核资源进行分区，以使一组进程看到一组资源，而另一组进程看到另一组资源。该功能通过为一组资源和进程具有相同的名称空间而起作用，但是这些名称空间引用了不同的资源。资源可能存在于多个空间中。 Linux namespaces 是对全局系统资源的一种封装隔离，使得处于不同 namespace 的进程拥有独立的全局系统资源，改变一个namespace中的系统资源只会影响当前 namespace 里的进程，对其他 namespace 中的进程没有影响。

网络实验 - VLAN

Sat, 02 Jan 2021 00:00:00 +0000

虚拟局域网VLAN（Virtual Local Area Network），是将一个物理的LAN在逻辑上划分成多个广播域的通信技术。 VLAN内的主机间可以直接通信，而VLAN间不能直接通信，从而将广播报文限制在一个VLAN内。以太网是一种基于CSMA/CD（Carrier Sense Multiple Access/Collision Detection）的共享通讯介质的数据网络通讯技术。当主机数目较多时会导致冲突严重、广播泛滥、性能显著下降甚至造成网络不可用等问题。通过交换机实现LAN互连虽然可以解决冲突严重的问题，但仍然不能隔离广播报文和提升网络质量。在这种情况下出现了VLAN技术，这种技术可以把一个LAN划分成多个逻辑的VLAN，每个VLAN是一个广播域，VLAN内的主机间通信就和在一个LAN内一样，而VLAN间则不能直接互通，这样，广播报文就被限制在一个VLAN内。 VLAN的作用限制广播域：广播域被限制在一个VLAN内，节省了带宽，提高了网络处理能力。增强局域网的安全性：不同VLAN内的报文在传输时是相互隔离的，即一个VLAN内的用户不能和其它VLAN内的用户直接通信。提高了网络的健壮性：故障被限制在一个VLAN内，本VLAN内的故障不会影响其他VLAN的正常工作。灵活构建虚拟工作组：用VLAN可以划分不同的用户到不同的工作组，同一工作组的用户也不必局限于某一固定的物理范围，网络构建和维护更方便灵活。 VLAN Tag 要使交换机能够分辨不同VLAN的报文，需要在报文中添加标识VLAN信息的字段。IEEE 802.1Q协议规定，在以太网数据帧的目的MAC地址和源MAC地址字段之后、协议类型字段之前加入4个字节的VLAN标签（又称VLAN Tag，简称Tag），用以标识VLAN信息。 VLAN Tag各字段含义：字段长度含义取值 TPID 2Byte Tag Protocol Identifier（标签协议标识符），表示数据帧类型。表示帧类型，取值为0x8100时表示IEEE 802.1Q的VLAN数据帧。如果不支持802.1Q的设备收到这样的帧，会将其丢弃。各设备厂商可以自定义该字段的值。当邻居设备将TPID值配置为非0x8100时，为了能够识别这样的报文，实现互通，必须在本设备上修改TPID值，确保和邻居设备的TPID值配置一致。 PRI 3bit Priority，表示数据帧的802.1p优先级。取值范围为0～7，值越大优先级越高。当网络阻塞时，设备优先发送优先级高的数据帧。 CFI 1bit Canonical Format Indicator（标准格式指示位），表示MAC地址在不同的传输介质中是否以标准格式进行封装，用于兼容以太网和令牌环网。 CFI取值为0表示MAC地址以标准格式进行封装，为1表示以非标准格式封装。在以太网中，CFI的值为0。 VID 12bit VLAN ID，表示该数据帧所属VLAN的编号。 VLAN ID取值范围是0～4095。由于0和4095为协议保留取值，所以VLAN ID的有效取值范围是1～4094。其中，数据帧中的VID（VLAN ID）字段标识了该数据帧所属的VLAN，数据帧只能在其所属VLAN内进行传输。对于交换机来说，其内部处理的数据帧都带有VLAN标签，而现网中交换机连接的设备有些只会收发Untagged帧，要与这些设备交互，就需要接口能够识别Untagged帧并在收发时给帧添加、剥除VLAN标签。同时，现网中属于同一个VLAN的用户可能会被连接在不同的交换机上，且跨越交换机的VLAN可能不止一个，如果需要用户间的互通，就需要交换机间的接口能够同时识别和发送多个VLAN的数据帧。 VLAN PVID 缺省VLAN又称PVID（Port Default VLAN ID）。设备处理的数据帧都带Tag，当设备收到UNTagged帧时，就需要给该帧添加Tag，添加什么Tag，就由接口上的缺省VLAN决定。一个物理端口只能拥有一个PVID，当一个物理端口拥有了一个PVID的时候，必定会拥有和PVID相等的VID，而且在这个VID上，这个物理端口必定是Untagged Port。因此，根据接口连接对象以及对收发数据帧处理的不同，华为定义了4种接口的链路类型：Access、Trunk、Hybrid和QinQ，以适应不同的连接和组网： Access接口：一般用于和不能识别Tag的用户终端（如用户主机、服务器等）相连，或者不需要区分不同VLAN成员时使用。Access接口大部分情况只能收发Untagged帧，且只能为Untagged帧添加唯一的VLAN Tag。 Trunk接口：一般用于连接交换机、路由器、AP以及可同时收发Tagged帧和Untagged帧的语音终端。它可以允许多个VLAN的帧带Tag通过，但只允许一个VLAN的帧从该类接口上发出时不带Tag（即剥除Tag）。 Hybrid接口：既可以用于连接不能识别Tag的用户终端（如用户主机、服务器等）和网络设备（如Hub、傻瓜交换机），也可以用于连接交换机、路由器以及可同时收发Tagged帧和Untagged帧的语音终端、AP。它可以允许多个VLAN的帧带Tag通过，且允许从该类接口发出的帧根据需要配置某些VLAN的帧带Tag（即不剥除Tag）、某些VLAN的帧不带Tag（即剥除Tag）。使用QinQ（802.1Q-in-802.1Q）协议，一般用于私网与公网之间的连接，也被称为Dot1q-tunnel接口。它可以给帧加上双层Tag，即在原来Tag的基础上，给帧加上一个新的Tag，从而可以支持多达4094×4094个VLAN。接口类型对接收不带Tag的报文处理对接收带Tag的报文处理发送帧处理过程 Access接口接收该报文，并打上缺省的VLAN ID。当VLAN ID与缺省VLAN ID相同时，接收该报文。当VLAN ID与缺省VLAN ID不同时，丢弃该报文先剥离帧的PVID Tag，然后再发送。 Trunk接口打上缺省的VLAN ID，当缺省VLAN ID在允许通过的VLAN ID列表里时，接收该报文。打上缺省的VLAN ID，当缺省VLAN ID不在允许通过的VLAN ID列表里时，丢弃该报文。当VLAN ID在接口允许通过的VLAN ID列表里时，接收该报文。当VLAN ID不在接口允许通过的VLAN ID列表里时，丢弃该报文当VLAN ID与缺省VLAN ID相同，且是该接口允许通过的VLAN ID时，去掉Tag，发送该报文。当VLAN ID与缺省VLAN ID不同，且是该接口允许通过的VLAN ID时，保持原有Tag，发送该报文。 Hybrid接口打上缺省的VLAN ID，当缺省VLAN ID在允许通过的VLAN ID列表里时，接收该报文。打上缺省的VLAN ID，当缺省VLAN ID不在允许通过的VLAN ID列表里时，丢弃该报文。当VLAN ID在接口允许通过的VLAN ID列表里时，接收该报文。当VLAN ID不在接口允许通过的VLAN ID列表里时，丢弃该报文。当VLAN ID是该接口允许通过的VLAN ID时，发送该报文。可以通过命令设置发送时是否携带Tag。由上面各类接口添加或剥除VLAN标签的处理过程可见：

网络实验 - VxLAN

Sat, 02 Jan 2021 00:00:00 +0000

vXlan概念实验什么是VxLAN RFC定义了虚拟扩展局域网 VXLAN （Virtual eXtensible Local Area Network，）扩展方案，是对传统VLAN协议的一种扩展。VXLAN采用（MAC in UDP（User Datagram Protocol）封装方式，是NVO3（Network Virtualization over Layer 3）中的一种网络虚拟化技术。VXLAN的特点是将L2的以太帧封装到UDP报文（即L2 over L4）中，并在L3网络中传输。 VXLAN本质上是一种隧道技术，在源网络设备与目的网络设备之间的IP网络上，建立一条逻辑隧道，将用户报文经过特定的封装后通过这条隧道转发。从用户的角度来看，接入网络的服务器就像是连接到了一个虚拟的二层交换机的不同端口上（可把蓝色虚框表示的数据中心VXLAN网络看成一个二层虚拟交换机），可以方便地通信。为什么需要VxLAN 虚拟机规模受网络设备表项规格的限制在传统二层网络环境下，数据报文是通过查询MAC地址表进行二层转发。服务器虚拟化后，VM的数量比原有的物理机发生了数量级的增长，伴随而来的便是VM网卡MAC地址数量的空前增加。而接入侧二层设备的MAC地址表规格较小，无法满足快速增长的VM数量。网络隔离能力有限 VLAN作为当前主流的网络隔离技术，在标准定义中只有12比特，因此可用的VLAN数量仅4096个。对于公有云或其它大型虚拟化云计算服务这种动辄上万甚至更多租户的场景而言，VLAN的隔离能力无法满足。虚拟机迁移范围受限由于服务器资源等问题（如CPU过高，内存不够等），虚拟机迁移已经成为了一个常态性业务。什么是虚拟机动态迁移？所谓虚拟机动态迁移，是指在保证虚拟机上服务正常运行的同时，将一个虚拟机系统从一个物理服务器移动到另一个物理服务器的过程。该过程对于最终用户来说是无感知的，从而使得管理员能够在不影响用户正常使用的情况下，灵活调配服务器资源，或者对物理服务器进行维修和升级。在服务器虚拟化后，虚拟机动态迁移变得常态化，为了保证迁移时业务不中断，就要求在虚拟机迁移时，不仅虚拟机的IP地址、MAC地址等参数保持不变，而且虚拟机的运行状态也必须保持原状（例如TCP会话状态），所以虚拟机的动态迁移只能在同一个二层域中进行，而不能跨二层域迁移。 VxLAN方案为了应对传统数据中心网络对服务器虚拟化技术的限制，VXLAN技术应运而生，其能够很好的解决上述问题。针对虚拟机规模受设备表项规格限制 VXLAN将管理员规划的同一区域内的VM发出的原始报文封装成新的UDP报文，并使用物理网络的IP和MAC地址作为外层头，这样报文对网络中的其他设备只表现为封装后的参数。因此，极大降低了大二层网络对MAC地址规格的需求。针对网络隔离能力限制在传统的VLAN网络中，标准定义所支持的可用VLAN数量只有4000个左右。VXLAN引入了类似VLAN ID的用户标识，称为VXLAN网络标识VNI（VXLAN Network Identifier），由24比特组成，支持多达16M的VXLAN段，有效得解决了云计算中海量租户隔离的问题。针对虚拟机迁移范围受限 VXLAN将VM发出的原始报文进行封装后通过VXLAN隧道进行传输，隧道两端的VM不需感知传输网络的物理架构。这样，对于具有同一网段IP地址的VM而言，即使其物理位置不在同一个二层网络中，但从逻辑上看，相当于处于同一个二层域。即VXLAN技术在三层网络之上，构建出了一个虚拟的大二层网络，只要虚拟机路由可达，就可以将其规划到同一个大二层网络中。这就解决了虚拟机迁移范围受限问题。 VxLAN与VLAN之间的区别 VLAN是传统的网络隔离技术，在标准定义中VLAN的数量只有4096，无法满足大型数据中心的租户间隔离需求。另外，VLAN的二层范围一般较小且固定，无法支持虚拟机大范围的动态迁移。 VXLAN完美地弥补了VLAN的上述不足，一方面通过VXLAN中的24比特VNI字段，提供多达16M租户的标识能力，远大于VLAN的4096；另一方面，VXLAN本质上在两台交换机之间构建了一条穿越数据中心基础IP网络的虚拟隧道，将数据中心网络虚拟成一个巨型“二层交换机”，满足虚拟机大范围动态迁移的需求。 VXLAN Header 增加VXLAN头（8字节），其中包含24比特的VNI字段，用来定义VXLAN网络中不同的租户。此外，还包含VXLAN Flags（8比特，取值为00001000）和两个保留字段（分别为24比特和8比特）。 UDP Header VXLAN头和原始以太帧一起作为UDP的数据。UDP头中，目的端口号（VXLAN Port）固定为4789，源端口号（UDP Src. Port）是原始以太帧通过哈希算法计算后的值。 Outer IP Header 封装外层IP头。其中，源IP地址（Outer Src. IP）为源VM所属VTEP的IP地址，目的IP地址（Outer Dst. IP）为目的VM所属VTEP的IP地址。 Outer MAC Header 封装外层以太头。其中，源MAC地址（Src. MAC Addr.）为源VM所属VTEP的MAC地址，目的MAC地址（Dst. MAC Addr.

istio流量管理：非侵入式流量治理

Wed, 30 Dec 2020 00:00:00 +0000

在服务治理中，流量管理是一个广泛的话题，一般情况下，常用的包括：动态修改服务访问的负载均衡策略，比如根据某个请求特征做会话保持；同一个服务有多版本管理，将一部分流量切到某个版本上；对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等；动态修改服务中的内容，或者模拟一个服务运行故障等。在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。总结Istio流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需关注自己的业务逻辑开发，无须关注服务访问管理。 istio流量治理的核心组件Pilot 在istio1.8中，istio的分为 envoy （数据平面）、istiod （控制平面）、addons（管理插件）及 istioctl （命令行工具，用于安装、配置、诊断分析等操作）组成。 Pilot是Istio控制平面流量管理的核心组件，管理和配置部署在Istio服务网格中的所有Envoy代理实例。 pilot-discovery为envoy sidecar提供服务发现，用于路由及流量的管理。通过kubernetes CRD资源获取网格的配置信息将其转换为xDS接口的标准数据格式后，通过gRPC分发至相关的envoy sidecar Pilot组件包含工作在控制平面中的 pilot-discovery 和工作与数据平面的pilot-agent 与Envoy(istio-proxy) pilot-discovery主要完成如下功能：从service registry中获取服务信息从apiserver中获取配置信息。将服务信息与配置信息适配为xDS接口的标准数据格式，通过xDS api完成配置分发。 pilot-agent 主要完成如下功能基于kubernetes apiserver为envoy初始化可用的boostrap配置文件并启动envoy。管理监控envoy的云兄状态及配置重载。 envoy 每个sidecar中的envoy是由pilot-agent基于生产的bootstrap配置进行启动，并根据指定的pilot地址，通过xDS api动态获取配置。 sidecar形式的envoy通过流量拦截机制为应用程序实现入站和出站的代理功能。 Pilot的实现在istio中的管理策略都是基于Kubernetes CRD的实现，其中有关于流量管理的CRD资源包括 VirtualService EnvoyFilter Gateway ServiceEntry Sidecar DestinationRule WorkloadEntry WorkloadGroup。reference istio-networking-crd-resouces VirtualServices：用于定义路由，可以理解为envoy的 listener => filter => route_config DestinationRule：用于定义集群，可以理解为envoy 的 cluster Gateway：用于定义作用于istio-ingress-gateway ServiceEntry：用于定义出站的路由，作用于istio-egress-gateway EnvoyFilter：为envoy添加过滤器或过滤器链。 Sidecar：用于定义运行在sidecar之上的envoy配置。 Virtual Services和 Destination Rules是Istio流量路由功能的核心组件

goland在mod模式下不从vendor文件夹查找依赖

Sun, 13 Dec 2020 00:00:00 +0000

goland使用vendor作为获取依赖源软件版本： system：windows10 1709 terminal： wsl ubuntu1804 goland：201903 goland 打开项目时使用mod模式，无法识别外部包的依赖根据goland官方提示，开启时，将忽略go.mod依赖描述，所以就找不到相对应的依赖，但是编译时正常的。可以看到下图中，external libraries 并没有加载外部的库导致了无法识别。此时想要正常使用的话，可以按照提示操作将 goland 改为gopath模式，执行go mod vendor 将依赖同步到vendor 。此时正常。当依赖更新时，可以手动添加对应的依赖库，go mod tidy 后。因为vendor中没有新的依赖，需要手动执行下go mod vendor即可正常使用。使用vendor编译在编译时，可以使用 -mod=vendor 标记，使用代码主目录文件夹下vendor目录满足依赖获取，go build -mod=vendor。此时，go build 忽略go.mod 中的依赖，（这里仅使用代码root目录下的vendor其他地方的将忽略） GOFLAGS=-mod=vendor 设置顶级vendor作为依赖 go env -w GOFLAGS="-mod=vendor" 进行设置。取消 go env -w GOFLAGS="-mod="

海信A6/A6L A7Pro/CC A5PRO/A5PRO CC 安装gms google service指南

Mon, 16 Nov 2020 00:00:00 +0000

用过海信双面屏或者eink手机的朋友都知道，海信手机就是死活安装不了谷歌全家桶，因为海信的领导说跟谷歌有协议不能安装谷歌框架（还说后期google审核坚决不给安装，人家其他ov mui都可以安装）。不信的朋友可以去海信论坛求证，杠精走开。海信手机没有安装GSM Google Mobile Service 也没有 youtube，gmail，google map。在国外的朋友们用起来很难受，别说打游戏了，就日常出行也离不开google service，也是找了很久找到一个国外大神对海信A7 Pro下安装的教程，尝试在A6l也可以装，后面 Hisense A5PRO/CC Hisense A7/CC A6/A6L A2/A2Pro 其实都是通用的。不过这个大神的教程并不是root来安装，对于在保的小伙伴们还是依然可以享受保修，系统升级（虽然海信基本百年不更新的），现在开始介绍下如何让海信eink系列获得GMS 安装步骤下载 adb 关闭一堆系統內建的垃圾 Apps 的功能(可以不关闭看自己了) 下载 Aurora Store (这步骤完全没用上，看个人了，国外大神推荐要下载) 先依照順序安裝 4个基础服务 apk，安装完成后可以正常登陆google账号了再按照顺序安裝 3个其他服务 apk（可以不按照顺序，国外大神说的是需要按照顺序）前置步驟：开启开发者模式打开开发者模式步骤1：下载安装 adb 程序 Mac可以直接输入命令：brew install android-platform-tools 具体 brew 是啥自行百度 Windows 平台参考：先从这里下载 adb，然后下一步，下一步就行，到安装完成。安装好后启动 adb，这里只介绍几个命令，对于装个 GAPPS 已经足够了。查看设备：adb devices 看到xxxxxx device即表示连接成功查看手机IP: adb shell ifconfig wlan0 通过IP地址连接手机：adb connect <device-ip-address> 断开连接：adb disconnect <device-ip-address> 设备监听：adb tcpip 5555 这里差不多了，更多可以参考下这里，下面开始介绍如何连接手机

如何将systemd服务的输出重定向到指定文件

Fri, 13 Nov 2020 00:00:00 +0000

有一种更优雅的方法可以解决systemd输出到指定文件而非/var/log/message，需要使用systemd参数与rsyslog过滤器。并指示syslog过滤器按程序名称拆分其输出。 systemd所需参数为 SyslogIdentifier：required，设置日志标识符(发送日志消息时加在行首的字符串)(“syslog tag”)。默认值是进程的名称。此选项仅在 StandardOutput= 或 StandardError= 的值包含 journal(+console), syslog(+console), kmsg(+console) 之一时才有意义，并且仅适用于输出到标准输出或标准错误的日志消息。 StandardOutput：required，设置进程的标准输出(STDOUT)。可设为 inherit, null, tty, journal, syslog, kmsg, journal+console, syslog+console, kmsg+console, file:path, append:path, socket, fd:name 之一。 StandardError：设置进程的标准错误(STDERR)。取值范围及含义与 StandardOutput= 相同。但有如下例外： (1) inherit 表示使用 StandardOutput= 的值。 (2) fd:name 的默认文件描述符名称为 “stderr” rsyslog过滤器设置使用rsyslog条件选择器。如果不改变rsyslog目前工作模式，按照如下操作：新建/etc/rsyslog.d/xx.conf文件。在新建文件内写入内容如下单一条件处理。 text 1 2 3 if $programname == 'programname' then /var/log/programname.log # 停止往其他文件内写入，如果不加此句，会继续往/var/log/message写入。 if $programname == 'programname' then stop 多条件处理会根据不同应用名称将不同的输出日志重定向到不同的文件内。 text 1 2 3 4 5 6 7 8 9 10 11 12 13 if ($programname == 'apiserver') then { action(type="omfile" file="/var/log/apiserver.

awesome git command

Sun, 08 Nov 2020 00:00:00 +0000

Tag command describe git tag 列出所有tag git tag -l v1.* 列出符合条件的tag（筛选作用） git tag [tag_name] 创建轻量tag（无-m标注信息） git push REMOTE TAG 推送一个tag到远端 git push origin –tags* 推送所有本地tag到远程 git push origin :refs/tags/[REMOTE TAG] git push –delete REMOTE TAG 删除远程指定tag git fetch origin [remote_tag_name] 拉取远程指定tag git show [tag_name] 显示指定tag详细信息 git push origin [local_tag_name] 推送指定本地tag到远程 git tag NEW_TAG OLD_TAG git tag -d OLD_TAG 重命名本地tag git tag -d [local_tag_name] 删除本地指定tag git ls-remote –tags origin 查询远程tags git tag -a [tag_name] 创建含注解的tag git fetch origin [remote_tag_name]git checkout [remote_tag_name] git branch checkout远端tag到本地 Checking 检查工作目录与暂存区的状态

适用于windows10 Linux子系统的安装管理配置

Sun, 08 Nov 2020 00:00:00 +0000

什么是WSL Windows Subsystem for Linux 简称WSL，适用于Linux的Windows子系统，可以直接在Windows上运行Linux环境（包括大部分命令行工具） Linux containers与Windows Subsystem for Linux（WSL）区别此处以docker与wsl进行一些比较，主要为个人的理解之处。 docker与wsl同样运行在本机环境中运行，不依赖其他管理程序与虚拟化。 docker与wsl同样为应用容器。安装WSL 在Windows10上，用于Linux的Windows子系，可运行受支持的Linux版本（例如Ubuntu，OpenSuse，Debian等），而无需设置操作系统的复杂性。虚拟机或其他计算机。使用设置为Linux启用Windows子系统打开设置点击“应用”。在“相关设置”部分下，单击“程序和功能”选项单击左窗格中的“打开或关闭Windows功能”选项。检查Windows Subsystem for Linux选项。完成这些步骤后，将配置该环境以下载并运行Windows 10上的Linux版本。使用Microsoft Store安装Linux发行版要在Windows 10上安装Linux发行版，请使用以下步骤：打开Microsoft Store。搜索要安装的Linux发行版。一些可用的发行版包括： Ubuntu OpenSuse Kali Linux Debian Alpine WSL Suse Linux Enterprise 选择要在您的设备上安装的Linux发行版。单击获取（或安装）按钮。 Microsoft Store安装Linux发行版单击启动按钮。为Linux发行版创建一个用户名，然后按Enter键。指定发行版的密码，然后按Enter。重复密码，然后按Enter确认。完成以上步骤后，即完成安装了WSL（没有图形界面），在开始菜单运行 wsl 启动。离线安装WSL 官网指导手册内包含所支持的Linux离线安装包这里下载的为Ubuntu 18.04，下载后，文件格式为appx格式，本次使用的操作系统为，windows1709企业版，并且卸载了所有的 UWP应用。因此只能使用命令行进行安装。非LTSC企业版或卸载windows store的可以直接双击安装管理员打开Powershell 运行以下命令，将路径替换为下载的离线安装包路径。本次安装的 wsl 默认安装到C盘 powershell 1 Add-AppxPackage .\app_name.appx 查看已经安装的子系统

常用加密算法学习总结之散列函数(hash function)

Wed, 04 Nov 2020 00:00:00 +0000

散列函数（Hash function）又称散列算法、哈希函数，散列函数把消息或数据压缩成摘要，使得数据量变小，将数据的格式固定下来。该函数将数据打乱混合，重新创建一个叫做散列值（hash values）的指纹。这种转化是一种压缩映射，也就是散列值的空间通常远小于输入值的空间，不同的输入可能会散列成相同的输出，二不可能从散列值来唯一的确定输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要函数。散列函数性质通过使用单向散列函数，即便是确认几百MB大小的文件的完整性，也只要对比很短的散列值就可以了。那么，单向散列函数必须具备怎样的性质呢？我们来整理一下。根据任意长度的消息计算出固定长度的散列值能够快速计算出散列值计算散列值所花费的时间短。尽管消息越长，计算散列值的时间也会越长，但如果不能在现实的时间内完成计算就没有意义了。消息不同散列值也不同难以发现碰撞的性质称为抗碰撞性（collisionresistance）。密码技术中所使用的单向散列函数，都需要具备抗碰撞性。强抗碰撞性，是指要找到散列值相同的两条不同的消息是非常困难的这一性质。在这里，散列值可以是任意值。密码技术中的单向散列函数必须具备强抗碰撞性。具备单向性单向散列函数必须具备单向性（one-way）。单向性指的是无法通过散列值反算出消息的性质。根据消息计算散列值可以很容易，但这条单行路是无法反过来走的。散列函数的应用散列函数应用具有多样性安全加密：保护资料，散列值可用于唯一地识别机密信息。这需要散列函数是抗碰撞(collision-resistant)的，意味着很难找到产生相同散列值的资料。如数字签名、消息认证码。数据校验：确保传递真实的信息：消息或数据的接受者确认消息是否被篡改的性质叫数据的真实性，也称为完整性。错误校正：使用一个散列函数可以很直观的检测出数据在传输时发生的错误。负载均衡：通过hash算法，对客户端IP进行计算hash值，将取到值与服务器数量进行取模运算。分布式存储：如一致性hash。常用单项散列函数 MD4 MD5 MD5在1996年后被证实存在弱点，可以被加以破解，对于需要高度安全性的资料，专家一般建议改用其他算法，如SHA-2。2004年，证实MD5算法无法防止碰撞攻击，因此不适用于安全性认证，如SSL公开密钥认证或是数字签名等用途。 SHA-1 SHA-2 SHA-1：1995年发布，SHA-1在许多安全协议中广为使用，包括TLS、GnuPG、SSH、S/MIME和IPsec，是MD5的后继者。但SHA-1的安全性在2010年以后已经不被大多数的加密场景所接受。2017年荷兰密码学研究小组CWI和Google正式宣布攻破了SHA-1。 SHA-2：2001年发布，包括SHA-224、SHA-256、SHA-384、SHA-512、SHA-512/224、SHA-512/256。SHA-2目前没有出现明显的弱点。虽然至今尚未出现对SHA-2有效的攻击，但它的算法跟SHA-1基本上仍然相似。比特币使用的sha-256进行的数字签名算法和变体输出散列值长度（bits）中继散列值长度（bits）资料区块长度（bits）最大输入消息长度（bits） MD5 128 128 (4 × 32) 512 无限 SHA-0 160 160 (5 × 32) 512 264 − 1 SHA-1 160 160 (5 × 32) 512 264 − 1 SHA-2 SHA-224 SHA-256 224 256 256 (8 × 32) 512 SHA-384 SHA-512 SHA-512/224 SHA-512/256 384 512 224 256 512 (8 × 64) 1024 2128 − 1 Go语言中使用散列函数 Go语言使用MD5 方式一：

常用加密算法学习总结之数字签名

Tue, 03 Nov 2020 00:00:00 +0000

数字签名（Digital Signature），通俗来讲是基于非对称加密算法，用秘钥对内容进行散列值签名，在对内容与签名一起发送。更详细的解说更详细的解说 - 中文数字签名的生成个验证签名 ⑴ 对数据进行散列值运算。 ⑵ 签名：使用签名者的私钥对数据的散列值进行加密。 ⑶ 数字签名数据：签名与原始数据。图：数字签名 Source：https://cheapsslsecurity.com/blog/digital-signature-vs-digital-certificate-the-difference-explained/ 验证 ⑴ 接收数据：原始数据&数字签名。 ⑵ 使用公钥进行解密得到散列值。 ⑶ 将原始数据的散列值与解密后的散列值进行对比。 Go语言中使用RSA进行数字签名 ⑴ pem解码：使用pem对私钥进行解码, 得到pem.Block结构体 ⑵ 获得私钥：使用GO x509接口pem.Block据解析成私钥结构体 ⑶ 计算hash值：对明文进行散列值计算 ⑷ 使用秘钥对散列值签名 go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 package main import ( "crypto" "crypto/rand" "crypto/rsa" "crypto/sha256" "crypto/x509" "encoding/pem" "fmt" ) var ( private = `-----BEGIN 私钥----- MIICXQIBAAKBgQDc73afIxqYOHg80puDIMYrqUAiTi8EiTVDEiO9YE3+VxRvN0sa pe3zx1UdhgIn3iCPUzyI2vwNADId3LjuIjkdCcdB2fHrBTbcy6u0545HnY42F9aQ 7cAr168bHcqhQoKcna9i9nukO+w7So1J9C6Wr8J4e4923q7+T7z7bZeXywIDAQAB AoGBAItX5KLdywoyo3MJCdgcNaCX8MEyOmlL+HHC4ROxx78gQN0cLJw0Bu33zHEA ch+e8z4yKz3Nj6bLdtBqw6A9qXLBCfWfD/p9YKDZNFP/6+u9teUirOgiBSq7kXWy mtBm0I3pz33EomCuSJzLj/Mj/fkKs+425jPFcZboJdZpCyBhAkEA8mtGUGYuAZwV RKBDkf1bz5EyPBGV+9CyXa6pd6md61APY0j+qhb1w9ADfHKkAzfoilhpucznRhaz kAheqMPAMwJBAOlQEx2Ytc8TxfFqhF8RPTODe2N0jBBvsvJ85k7vNiQ+hnmaAray XS6pCbZdvmGHYKlz3MVGeis/UJKDdSzE0gkCQQCoZijkNPcEmz6S+5m00oFywXRa EgVUdndRaMHEpIlVK7pkyBJQab60Fc42JxUUP0RExoI7VcHbCG4YQhgvuDvNAkBQ CUolcwebe/sBcDrsqetGyqn/WjHaSZcnnDUdiu4VzOUwveaEafeRVCeiydHPfzNn rflkK2MphtTLDhGaRAKRAkASKlhV8aTBzTty/V3XMQfFVIAdHCyEIGMdjDDSzPly shZCn66IyIze8j5Q4ZLcRz6GPglHdrkBnyt4QFuGurpl -----END 私钥-----` public = `-----BEGIN 公钥----- MIGJAoGBANzvdp8jGpg4eDzSm4MgxiupQCJOLwSJNUMSI71gTf5XFG83Sxql7fPH VR2GAifeII9TPIja/A0AMh3cuO4iOR0Jx0HZ8esFNtzLq7TnjkedjjYX1pDtwCvX rxsdyqFCgpydr2L2e6Q77DtKjUn0Lpavwnh7j3berv5PvPttl5fLAgMBAAE= -----END 公钥-----` ) func digitalSign(privateKey, plainText string) (signText []byte, err error) { var ( pemBlock, _ = pem.

prometheus operator使用

Mon, 02 Nov 2020 00:00:00 +0000

什么是 Operator？ Operator是由CoreOS公司开发的，用来扩展kubernetes APi的特定的应用程序控制器，Operator基于Kubernetes的资源和控制器概念之上构建，但同时又包含了对相应应用程序特定的一些专业知识。创建operator的关键是 CRD（CustomResourceDefinition）的设计。 Prometheus Operator Prometheus Operator 是CoreOS公司提供的基于Prometheus及其相关监视组件对Kubernetes集群组件的管理，该Operator目的是简化和自动化针对Kubernetes集群的基于Prometheus的管理及配置。 Prometheus Operator架构组件 Operator：作为Prometheus Operator的核心组件，也即是自定义的控制器，用来监视和部署管理Prometheus Operator CRD资源对象，监控并维持CRD资源状态。 Prometheus Server：Operator 根据自定义资源 Prometheus 类型中定义的内容而部署的Prometheus Cluster Prometheus Operator CRD： Prometheus：以CRD资源提供给Operator的类似于Pod资源清单定位的资源。 ServiceMonitor：声明定义对Kubernetes Services资源进行监控，使用标签选择器来选择所需配置的监控，后端是Service的Endpoint，通过Service标签选择器获取EndPoint对象。 PodMonitor：使用标签选择器，选择对匹配Pod进行监控 Alertmanager：声明定义了Alertmanager在Kubernetes中运行所提供的配置。 PrometheusRule: 声明定义了Prometheus在Kubernetes中运行所需的Rule配置。 reference Prometheus-Operator-design Prometheus Operator监控二进制kubernetes 查看兼容性列表选择对应的版本来下载，此处kubernetes集群为1.8.10 。对应地址为 https://github.com/prometheus-operator/kube-prometheus.git ，可以在域名后添加.cnpmjs.org 访问中国的github加速。 bash 1 git clone https://github.com.cnpmjs.org/prometheus-operator/kube-prometheus.git 资源清单在项目目录 manifests CRD在 manifests/setup 需要先安装CRD 和 Operator 对象 kube-controller-manager 和 kube-scheduler 无监控数据二进制部署的Kubernetes集群中部署Prometheus Operator，会发现在prometheus server的页面上发现kube-controller和kube-schedule的target为0/0。匹配不到节点信息，这是因为serviceMonitor是根据label去选取svc的。此处svc并没有kube-controller和kube-schedule 需要手动创建。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 apiVersion: v1 kind: Service metadata: namespace: kube-system name: kube-controller-manager labels: k8s-app: kube-controller-manager component: kube-controller-manager spec: selector: k8s-app: kube-controller-manager component: kube-controller-manager ports: - name: https-metrics port: 10252 targetPort: 10252 --- apiVersion: v1 kind: Endpoints metadata: namespace: kube-system name: kube-controller-manager labels: k8s-app: kube-controller-manager component: kube-controller-manager subsets: - addresses: - ip: "10.

常用加密算法学习总结之非对称加密

Mon, 02 Nov 2020 00:00:00 +0000

公开密钥密码学（英语：Public-key cryptography）也称非对称式密码学（英语：Asymmetric cryptography）是密码学的一种演算法。常用的非对称加密算法有 RSA DSA ECC 等。公开密钥加密非对称加密算法使用公钥、私钥来加解密。公钥与私钥是成对出现的。多个用户（终端等）使用的密钥交公钥，只有一个用户（终端等）使用的秘钥叫私钥。使用公钥加密的数据只有对应的私钥可以解密；使用私钥加密的数据只有对应的公钥可以解密。非对称加密通信过程下面我们来看一看使用公钥密码的通信流程。假设Alice要给Bob发送一条消息，Alice是发送者，Bob是接收者，而这一次窃听者Eve依然能够窃所到他们之间的通信内容。参考自维基百科 ⑴ Alice与bob事先互不认识，也没有可靠安全的沟通渠道，但Alice现在却要透过不安全的互联网向bob发送信息。 ⑵ Alice撰写好原文，原文在未加密的状态下称之为明文 plainText。 ⑶ bob使用密码学安全伪随机数生成器产生一对密钥，其中一个作为公钥 publicKey，另一个作为私钥 privateKey。 ⑷ bob可以用任何方法传送公钥publicKey 给Alice，即使在中间被窃听到也没问题。 ⑸ Alice用公钥publicKey把明文plainText进行加密，得到密文 cipherText ⑹ Alice可以用任何方法传输密文给bob，即使中间被窃听到密文也没问题。 ⑺ bob收到密文，用私钥对密文进行解密，得到明文 plainText。由于其他人没有私钥，所以无法得知明文；如果Alice，在没有得到bob私钥的情况下，她将重新得到原文。 RSA RSA是一种非对称加密算法，是由罗纳德·李维斯特（Ron Rivest）、阿迪·萨莫尔（Adi Shamir）和伦纳德·阿德曼（Leonard Adleman）在1977年一起提出，并以三人姓氏开头字母拼在一起组成的。 RSA公钥和密钥的获取：随机选择两个大的素数，p q $N = p*q$ RSA加密过程：$cipherText = plainText ^ E mod N$，$(N,e)$为公钥，$(N,d)$为私钥。 RSA解密过程：$plainText = cipherText^ D mod N$ Go语言中RSA的应用在Go语言中生成公钥与私钥生成秘钥流程 ⑴ 使用crypto/rsa中的GenerateKey(random io.Reader, bits int)方法生成私钥（结构体） ⑵ 因为X509证书采用了ASN1描述结构，需要通过Go语言API将的到的私钥（结构体），转换为BER编码规则的字符串。 ⑶ 需要将ASN1 BER 规则转回为PEM数据编码。pem.

常用加密算法学习总结之对称加密

Sat, 31 Oct 2020 00:00:00 +0000

对称加密，又称为共享密钥加密算法，是指加密和解密方使用相同密钥的加密算法。对称加密算法的优点在于加解密的高速度和使用长密钥时的难破解性。对称加密算法 DES DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。1977年被美国联邦政府的国家标准局确定为联邦资料处理标准（FIPS） DES的加密和解密 DES是一种将64bit（8Byte）的明文加密成64bit的密文的对称密码算法，==它的密钥长度是56比特==。从规格上来说，DES的密钥长度是64bit，但由于每隔7bit会设置一个用于==错误检查==的比特，因此实质上其密钥长度是56bit。 DES是以64bit的明文（比特序列）为一个单位来进行加密的，这个64bit的单位称为分组。一般来说，以分组为单位进行处理的密码算法称为分组密码（blockcipher），DES就是分组密码的一种。 DES每次只能加密64比特的数据，如果要加密的明文比较长，就需要对DES加密进行迭代（反复），而迭代的具体方式就称为模式（mode）。 3DES 3DES（Triple DES）：是三重数据加密算法（TDEA，Triple Data Encryption Algorithm）块密码的通称。是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。 3DES是基于计算机的运算能力的增强，基于DES算法，增强秘钥进行多绪加密，而不是一种块密码算法。 AES AES（Advanced Encryption Standard）：高级加密标准，是美国联邦政府采用的一种区块加密标准。分组密码模式 **分组密码（blockcipher）**是每次只能处理特定长度的一块数据的一类密码算法，这里的一块"就称为分组（block）。此外，一个分组的比特数就称为分组长度（blocklength）。例如，DES和3DES的分组长度都是64比特。这些密码算法一次只能加密64比特的明文．并生成64比特的密文。 AES的分组长度可以从128比特、192比特和256比特中进行选择。当选择128比特的分组长度时，AES一次可加密128比特的明文，并生成128比特的密文。分组密码算法只能加密固定长度的分组，但是我们需要加密的明文长度可能会超过分组密码的分组长度，这时就需要对分组密码算法进行迭代，以便将一段很长的明文全部加密。而迭代的方法就称为分组密码的模式（mode）。分组密码的模式有很多种类，分组密码的主要模式有以下5种：明文与密文分组 **明文分组: **是指分组密码算法中作为加密对象的明文。明文分组的长度与分组密码算法的分组长度是相等的。 **密文分组: **是指使用分组密码算法将明文分组加密之后所生成的密文。 ECB模式：Electronic Code Book mode（电子密码本模式） ECB是最简单的加密模式，明文消息被分成固定大小的块（分组），并且每个块被单独加密。每个块的加密和解密都是独立的，且使用相同的方法进行加密，所以可以进行并行计算，但是这种方法一旦有一个块被破解，使用相同的方法可以解密所有的明文数据，安全性比较差。适用于数据较少的情形，加密前需要把明文数据填充到块大小的整倍数。使用ECB模式加密时，相同的明文分组会被转换为相同的密文分组，因此ECB模式也称为电子密码本模式当最后一个明文分组的内容小于分组长度时（如一个分组8bit），需要用一特定的数据进行填充（padding），让值一个分组长度等于分组长度。 ECB模式是所有模式中最简单的一种。ECB模式中，明文分组与密文分组是一一对应的关系，因此，如果明文中存在多个相同的明文分组，则这些明文分组最终都将被转换为相同的密文分组。这样一来，只要观察一下密文，就可以知道明文中存在怎样的重复组合，并可以以此为线索来破译密码，因此ECB模式是存在一定风险的。 CBC模式：Cipher Block Chaining mode（密码分组链接/密码块模式） 1976年，IBM发明了密码分组链接CBC。CBC模式中每一个分组要先和前一个分组加密后的数据进行XOR异或操作，然后再进行加密。这样每个密文块依赖该块之前的所有明文块，为了保持每条消息都具有唯一性，在第一个块进行加密之前需要用初始化向量 IV 进行异或操作。 CBC模式是一种最常用的加密模式，它主要缺点是加密是连续的，不能并行处理，并且与ECB一样消息块必须填充到块大小的整倍数。 **当加密第一个明文分组时，由于不存在 “前一个密文分组"，因此需要事先准备一个长度为一个分组的比特序列来代替“前一个密文分组"，这个比特序列称为初始化向量（initialization vector）**通常缩写为 IV。一般来说，每次加密时都会随机产生一个不同的比特序列来作为初始化向量。 CFB模式：Cipher FeedBack mode（密文反馈模式）密文反馈模式 CFB；在CFB模式中，前一个分组的密文加密后和当前分组的明文XOR异或操作生成当前分组的密文。所谓反馈，这里指的就是返回输入端的意思，即前一个密文分组会被送回到密码算法的输入端。在ECB和CBC中，明文分组都是通过密码算法进行加密的，然而，在CFB模式中，明文分组和密文分组之间并没有经过"加密"这一步骤，明文分和密文分组之间只有一个XOR。 OFB模式：Output FeedBack mode（输出反馈模式）输出反馈模式, OFB。在OFB模式中，上一个分组密码算法的输出是当前分组密码算法的输入（下图） CTR模式：CounTeR mode（计数器模式） CTR是一种通过将逐次累加的计数器进行加密来生成密钥流的流密码；即每个分组对应一个逐次累加的计数器，并通过对计数器进行加密来生成密钥流。也就是说，最终的密文分组是通过将计数器加密得到的比特序列，与明文分组进行XOR而得到的。

将traefik部署为传统web架构模式

Sun, 04 Oct 2020 00:00:00 +0000

traefik概述 traefik-现代反向代理，也可称为现代边缘路由；traefik原声兼容主流集群，Kubernetes，Docker，AWS等。官方的定位traefik是一个让开发人员将时间花费在系统研发与部署功能上，而非配置和维护。并且traefik官方也提供自己的服务网格解决方案作为一个 modern edge router ，traefik拥有与envoy相似的特性基于go语言研发，目的是为了简化开发人员的配置和维护 tcp/udp支持 http L7支持 GRPC支持服务发现和动态配置 front/ edge prory支持可观测性流量管理 … traefik 术语要了解trafik，首先需要先了解一下有关trafik中的一些术语。 EntryPoints 入口点，是可以被下游客户端连接的命名网络位置，类似于envoy 的listener和nginx的listen services 服务，负载均衡，上游主机接收来自traefik的连接和请求并返回响应。类似于nginx upstream envoy的clusters Providers 提供者，提供配置文件的后端，如文件，consul，redis，etcd等，可使traefik自动更新 routers 路由器，分析请求，将下游主机的请求处理转入到services middlewares: 中间件，在将下游主机的请求转入到services时进行的流量调整 traefik部署安装 traefik为go语言开发的，可以直接下载运行即可。此处介绍直接运行二进制程序后端环境准备,此处为docker运行的两个后端。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 version: '3' services: webserver1: image: sealloong/envoy-end:latest ports: - 91:90 networks: envoymesh: aliases: - v1_server - default_server environment: - VERSION=v1 - COLORFUL=blue expose: - 90 webserver2: image: sealloong/envoy-end:latest ports: - 92:90 networks: envoymesh: aliases: - v1_server - default_server environment: - VERSION=v1 - COLORFUL=blue expose: - 90 networks: envoymesh: {} traefik配置说明 Traefik中的配置可以引用两种不同的内容：

windows下Docker Desktop安装管理

Fri, 02 Oct 2020 00:00:00 +0000

检查要求 Windows 10 企业版、专业版或教育版（必须windows10 1903版本以上）版本号 18362.1049+ 或 18363.1049+ ，次版本＃大于.1049。最好是最新版（新版windows可以hype-v wsl2 vmvare共存，但安卓模拟器目前还没稳定的共存版本）。建议使用wsl2，安装包容量会比起hype-v小很多。 Windows开启wsl2，建议 Windows 10 2004（版本号不低于 19041.264），可wsl2与vmvare共存。 CPU 支持并开启虚拟化（Intel VT-c 或 AMD SVM）。最少 4 GB 内存。对于专业版、企业版、教育版可以使用docker desktop wsl2模式，此处无需开启Hype-v 对于Win10 家庭版，Win10 19041.264之前版本，及 Win7 8用户，可以使用docker desktop Hype-v 后端。修改安装盘 Docker Desktop 默认安装到 C:\Program Files\Docker 并不可更改，这样很不友好，可以通过软连接的方式改变Docker Desktop 默认安装盘。 text 1 mklink /J "C:\Program Files\Docker" "D:\Program Files\Docker" 限制wsl2运行最大内存 WSL 是 Microsoft 提供的一项功能，可以使开发人员能够直接在 Windows 上运行 GNU/Linux 环境，无需修改，无需传统虚拟机或双引导设置，减少了开发人员的使用复杂度在 Docker Desktop 使用了 WSL 2 中的动态内存分配特性，极大地提高了资源消耗。这意味着，Docker Desktop 仅使用其所需的 CPU 和内存资源量，同时使 CPU 和内存密集型任务（例如构建容器）运行得更快。

zimbra安装故障记录

Fri, 02 Oct 2020 00:00:00 +0000

启动故障：zimbra postsuper: fatal: scan_dir_push: open directory defer: Permission denied bash 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 Host mail.domain.com Starting ldap...Done. Starting zmconfigd...Done. Starting dnscache...Done. Starting logger...Done. Starting mailbox...Done. Starting memcached...Done. Starting proxy...Done. Starting amavis...Done. Starting antispam...Done. Starting antivirus...Done. Starting opendkim...Done. Starting snmp...Done. Starting spell...Done. Starting mta...Failed. Starting saslauthd...done. postsuper: fatal: scan_dir_push: open directory defer: Permission denied postfix failed to start Starting stats.

Envoy：TLS双向认证

Tue, 29 Sep 2020 00:00:00 +0000

环境准备主机角色数量 front-envoy front envoy 1 service envoy 作为内部后端的envoy 2 end 后端应用程序 2 访问 / front-envoy ==> end * 2 访问 /red/colorful ==> end red 不验证客户端证书单项tls 访问 /gray/colorful ==> end gray 验证客户端证书双项tls docker-compose text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 version: '3' services: front-envoy: image: envoyproxy/envoy-alpine:v1.

Centos7 dbus问题总结

Wed, 23 Sep 2020 00:00:00 +0000

Authorization not available. Check if polkit text 1 2 3 4 Authorization not available. Check if polkit service is running or see debug message for more information. dbus.socket failed to listen on sockets: Address family not supported by protocol Failed to listen on D-Bus System Message Bus Socket. 这个问题是因为dbus.socket状态异常，所有依赖dbus的启动都会去通过systemcall连接 dbus，当服务不可用时，所有服务无法以systemd方式正常启动/关闭。需要检查dbus.socket是否正常。本地使用需保证unix套接字的监听时启动的 Did not receive a reply text 1 Failed to open connection to "system" message bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Envoy开启访问日志 access_log

Tue, 22 Sep 2020 00:00:00 +0000

text 1 2 3 4 5 6 7 access_log: - name: envoy.listener.accesslog typed_config: "@type": type.googleapis.com/envoy.extensions.access_loggers.file.v3.FileAccessLog path: /var/log/envoy.log log_format: text_format: "[%START_TIME%] \"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%\" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% %RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)% \"%REQ(X-FORWARDED-FOR)%\" \"%REQ(USER-AGENT)%\" \"%REQ(X-REQUEST-ID)%\" \"%REQ(:AUTHORITY)%\" \"%UPSTREAM_HOST%\"\n"

记录经过envoy代理后获取客户端真实IP

Tue, 22 Sep 2020 00:00:00 +0000

在envoy作为前端代理时，用户ip的获取很重要，一般获取ip的方式。都是通过Header中的 X-Forward-For、 X-Real-IP或 Remote addr 等属性获取，但是如果确保Envoy可以获取到的ip是真实的用户ip呢？本篇继续解密！概念说明 Remote Address 是nginx与客户端进行TCP连接过程中，获得的客户端真实地址。Remote Address 无法伪造，因为建立 TCP 连接需要三次握手，如果伪造了源 IP，无法建立 TCP 连接，更不会有后面的 HTTP 请求。一般情况下，在Envoy作为最外层代理时，此IP为真实的IP客户端IP X-Real-IP 是一个自定义头。X-Real-Ip 通常被 HTTP 代理用来表示与它产生 TCP 连接的设备 IP，这个设备可能是其他代理，也可能是真正的请求端。X-Real-Ip 目前并不属于任何标准，代理和 Web 应用之间可以约定用任何自定义头来传递这个信息。 X-Forwarded-For X-Forwarded-For 是一个扩展头。HTTP/1.1（RFC 2616）协议并没有对它的定义，它最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP，现在已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。通常，X-Forwarded-For可被伪造，并且使用CDN会被重写 Envoy中如何获取真实IP 在Envoy中，涉及到客户端IP的配置如下： use_remote_address：默认值false，设置为true，使用客户端连接的真实远程地址，false是使用x-forwarded-for skip_xff_append：设置为true，则不会将远程地址附加到x-forwarded-for中 request_headers_to_add 添加请求头 request_headers_to_remove 删除一个请求头实验环境配置准备 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 admin: access_log_path: /dev/null address: socket_address: { address: 0.

使用alpine为基础镜像Q&A

Sun, 20 Sep 2020 00:00:00 +0000

作为go应用存在二进制文件却不能执行明明镜像中有对应的二进制文件，但是执行时却提示 not found 或 no such file 或 standard_init_linux.go:211: exec user process caused "no such file or directory" 网上常说都是因为windows换行符编码问题。此处实际问题是该二进制文件是使用动态链接方式编译. 解决方法： text 1 CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build --ldflags "-extldflags -static" 注意：CGO_ENABLED=0 GOOS=linux GOARCH=amd64 和 cgo_enabled=0 goos=linux goarch=amd64 是有区别的。保存信息诸如此类信息都是上述问题 text 1 2 3 4 standard_init_linux.go:211: exec user process caused "no such file or directory" /tmp # ./envoy_end /bin/sh: ./envoy_end: not found 替换为国内源 text 1 RUN sed -i 's@http://dl-cdn.alpinelinux.org/@https://mirrors.aliyun.com/@g' /etc/apk/repositories 基于alpine制作PHP镜像 alpine包搜索 https://pkgs.

centos配置

Thu, 17 Sep 2020 00:00:00 +0000

CentOS7 / CentOS8 设置终端屏幕分辨率 Centos7 修改文件 /boot/grub2/grub.cfg 搜索 linux16 text 1 2 vmlinuz-3.10.0-123.el7.x86_64 root=UUID=881ac4e6-4a55-47b1-b864-555de7051763 ro rd.lvm.lv=centos/swap vconsole.font=latarcyrheb-sun16 rd.lvm.lv=centos/root crashkernel=auto vconsole.keymap=us rhgb quiet LANG=en_US.UTF-8 添加如下,???具体看下表 text 1 2 3 vga=0x??? vga=0x340 CentOS 8 CentOS8 使用了 blsgcfg来解析文件生成菜单项。菜单项配置文件在/boot/loader/entries/下，每一个文件表示一个启动项。这里需要修改启动项的参数，这里修改options，实际上是修改了 /boot/grub2/grubenv对应的值。 text 1 options $kernelopts $tuned_params 可以直接修改/etc/sysconfig/grub中的GRUB_CMDLINE_LINUX值后增加=加vga=0x??? （对照分辨率表修改???）。修改完成后执行 grub2-mkconfig -o /boot/grub2/grub.cfg 重启即修改了/boot/grub2/grubenv对应的值。 centos7 启动引导顺序查看默认启动项 grub2-editenv list 查看启动项列表 awk -F\' '$1=="menuentry " {print $2}' /etc/grub2.cfg 设置默认引导 grub2-set-default 'Windows 10' 设置默认启动项 grub2-set-default 2 需要按照启动项列表顺序重新生成grub2.

Envoy 离群检测

Tue, 15 Sep 2020 00:00:00 +0000

outlier detection 在异常检测领域中，常常需要决定新观察的点是否属于与现有观察点相同的分布（则它称为inlier），或者被认为是不同的（称为outlier）。离群是异常的数据，但是不一定是错误的数据点。在Envoy中，离群点检测是动态确定上游集群中是否有某些主机表现不正常，然后将它们从正常的负载均衡集群中删除的过程。outlier detection可以与healthy check同时/独立启用，并构成整个上游运行状况检查解决方案的基础。此处概念不做过多的说明，具体可以参考官方文档与自行google 监测类型连续的5xx 连续的网关错误连续的本地来源错误更多介绍参考官方文档 outlier detection 离群检测测试说明，此处只能在单机环境测试更多还的参考与实际环境环境准备 docker-compose 模拟后端5个节点 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 version: '3' services: envoy: image: envoyproxy/envoy-alpine:v1.

Envoy的主动健康监测

Mon, 14 Sep 2020 00:00:00 +0000

实验文件 docker-compose yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 version: '3' services: envoy: image: envoyproxy/envoy-alpine:v1.15-latest environment: - ENVOY_UID=0 - HEALTHY=ok ports: - 80:80 - 443:443 - 82:9901 volumes: - .

Envoy V3APi 开启 TLS

Sun, 13 Sep 2020 00:00:00 +0000

方案架构本次实例与官方Envoy front_proxy Example相似，首先会有一个Envoy单独运行。ingress的工作是给其他地方提供一个入口。来自外部的传入连接请求到这里，前端代理将会决定他们在内部的转发路径。图源自Envoy官网文档 front_proxy 生成证书 text 1 openssl req -nodes -new -x509 -keyout certs/server.key -out certs/server.crt -days 365 -subj "/C=CN/ST=Guangdong/L=Guangzhou/O=studyenvoy/OU=studyenvoy/CN=*.studyenvoy.cn" envoy配置说明 v3 api中envoy去掉了tls_context的配置，配置tls首先需要熟悉envoy的如下两个术语 Downstream：下游主机连接到 Envoy，发送请求并或获得响应。 Upstream：上游主机获取来自 Envoy 的链接请求和响应。本次使用的是ingress的代理，需要配置的即为 Downstream v3api中使用的是transport_socket，transport_socket为 listeners 当中某一个 filter_chains 中上线文中的配置。 transport_socket 官方说明为： (config.core.v3.TransportSocket) Optional custom transport socket implementation to use for downstream connections. To setup TLS, set a transport socket with name tls and DownstreamTlsContext in the typed_config. If no transport socket configuration is specified, new connections will be set up with plaintext.

envoy官方example运行失败问题处理

Sat, 12 Sep 2020 00:00:00 +0000

镜像内安装包失败处理方法一：修改Dockerfile，在Dockerfile中增加如下 ubuntu示例 text 1 2 RUN sed -i 's/archive.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list RUN sed -i 's/security.ubuntu.com/mirrors.aliyun.com/g' /etc/apt/sources.list apline示例 text 1 RUN sed -i 's@http://dl-cdn.alpinelinux.org/@https://mirrors.aliyun.com/@g' /etc/apk/repositories 方法二：使用http代理， ubuntu 参考命令行使用代理下载镜像失败处理方法一：docker宿主机使用ss，开启局域网可连接。同局域网中的都可直接连此代理方法二： docker systemd的 service文件中增加http代理可看到已经可以成功运行envoy example示例 cannot bind ‘0.0.0.0:80’: Permission denied docker-compose文件 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 version: '3' services: envoy: image: envoyproxy/envoy-alpine:v1.15-latest volumes: - .

Envoy TLS 配置

Wed, 02 Sep 2020 00:00:00 +0000

official front proxy 在一个Services Mash内部中，都会存在一到多个微服务，为了将南北向流量统一引入网格内部管理，通常存在单独运行的envoy实例。 Envoy的listener支持面向下游客户端一侧的TLS会话，并可选地支持验正客户端证书； listener中用到的数字证书可于配置中静态提供，也可借助于SDS动态获取; tls_context 是 listeners 当中某一个 filter_chains 中上线文中的配置，tls_context 配置在哪个 listeners当中就隶属于哪个listeners。 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 listeners: ... filter_chains: - filters: .. tls_context: common_tls_context: {} # 常规证书相关设置； tls_params: {} # TLS协议版本，加密套件等； tls_certifcates: [] # 用到的证书和私钥文件； - certifcate_chain: {} filename: # 证书文件路径; private_key: {} # 私钥; filename: # 私钥文件路径; password: {} # 私钥口令； filename: # 口令文件路径； tls_certifcate_sds_secret_configs: [] # 要基于SDS API获取TLS会话的相关信息时的配置； require_client_certifcate: # 是否验证客户端证书；例如，下面示例将前面的Ingress示例中的Envoy配置为通过TLS提供服务，并将所有基于http协议的请求重定向至https；

Envoy部署

Wed, 02 Sep 2020 00:00:00 +0000

常用的构建方法 https://skyao.io/learning-envoy/ 手动配置构建环境，手动构建Envoy。使用Envoy提供的预制于Docker中的构建环境进行手动构建二进制Envoy 使用Envoy提供的预制于Docker中的构建环境进行手动构建二进制Envoy，并直接将Envoy程序打包成Docker镜像提供Bootstrap配置文件，存在使用xDS的动态资源时，还需要基于文件或管理服务器向其提供必须的配置信息也可使用Envoy的配置生成器生成示例性配置基于Bootstrap配置文件启动Envoy实例直接启动二进制Envoy 于Kubernetes平台基于Sidecar的形式运行Envoy，或运行单独的Envoy Pod（Edge Proxy）启动Envoy 启动Envoy时，需要通过（-c 选项为其指定初始配置文件以提供引导配置（Bootstrap configuration），这也是使用v2APl的必然要求； text 1 envoy -c <path to config>.{json,yaml,pb,pb_text} 扩展名代表了配置信息的组织格式；引导配置是Envoy配置信息的基点，用于承载Envoy的初始配置，它可能包括静态资源和动态资源的定义静态资源（static_resources）于启动直接加载动态资源（dynamic_resources）则需要通过配置的xDS服务获取并生成通常，Listener 和 Cluster 是Envoy得以运行的基础，而二者的配置可以全部为静态格式，也可以混合使用动态及静态方式提供，或者全部配置为动态；一个yaml格式纯静态的基础配置框架类似如下所示： yaml 1 2 3 4 5 6 7 8 9 10 11 static_resources: linteners: - name: ... address: {} filter_chains: [] clusters: - name: ... type: ... connect_timeout: {} lb_policy: ... load_assignment: {} Listener 简易静态配置侦听器主要用于定义Envoy监听的用于接收Down streams请求的套接字、用于处理请求时调用的过滤器链及相关的其它配置属性;目前envoy仅支持tcp的协议 yaml 1 2 3 4 listeners: - name: address: socket_address: { address: .

Envoy管理

Wed, 02 Sep 2020 00:00:00 +0000

envoy内建了一个管理接口，它支持查询和修改操作，甚至有可能暴露私有数据（例如统计数据、集群名称和证书信息等）因此非常有必要精心编排期访问控制机制，以避免非授权访问。 administration interface 属于 bootstrap 配置文件中的==顶级配置字段==使用。 administration interface offical document yaml 1 2 3 4 5 6 7 8 admin: access_log_path: .. # 管理接口的访问日志文件路径，无须记录访问日志使用/dev/null profile_path: ... # cpu_profile的输出路径，默认为/var/log/envoy/envoy.prof; address: socket_address: # 监听的套接字 protocol: .. address: ... prot_value: ... 下面是一个简单的配置示例 yaml 1 2 3 4 admin: access_log_path: /tmp/admin_access.log address: socket_address: { address: 127.0.0.1, port_value: 9901 } admin接口内置了多个 /path ，不同的path可能会分别接受不同的GET或POST请求 GET /help ：打印所有可用选项； / : Admin home page /certs : GET 列出在的所有TLS相关的信息； /clusters : upstream cluster status GET，格外支持使用 /clusters?

Envoy基础

Wed, 02 Sep 2020 00:00:00 +0000

服务网格的基本功能控制服务间通信：熔断、重试、超时、故障注入、负载均衡和故障转移等。服务发现：通过专用的服务总监发现服务端点。可观测：指标数据采集、监控、分布式日志记录和分布式追踪。安全性：TLS/SSL通信和秘钥管理。身份认证和授权检查：身份认证，以及基于黑白名单或RBAC的访问控制功能。部署：对容器技术的原生支持，例如Docker和Kubernetes等。服务间的通信协议：HTTP1.1 HTTP2.0和gRPC等。健康状态监测：监测上游服务的健康状态。 …. 服务网格的部署模式有两种：主机共享代理和Sidecar容器主机共享代理适用于同一主机存在许多容器的场景，并且还可以利用连接池来提高吞吐量。带一个代理进程故障将终止其所在主机上的整个容器队列，受影响的不仅仅是单个服务。实现方式中，常见的是允许为Kubernetes之上的 DaemonSet。 Sidecar容器代理进程注入每个Pod定义以与住容器一同运行。 Sidecar进程应该尽可能轻量且功能完善。实现方案：Linkerd、Envoy和Conduit。 What IS Enovy Enovy是工作与OSI模型的7层代理在实现上，数据平面的主流解决方案有Linkerd、Nginx、Envoy、HAProxy和Traefik等，而控制平面的实现主要有Istio、Nelson和SmartStack等几种口Linkerd ●由Buoyant公司于2016年率先创建的开源高性能网络代理程序（数据平面），是业界第一款Service Mesh产品，引领并促进了相关技术的快速发展 ·Linkerd使用Namerd提供控制平面，实现中心化管理和存储路由规则、服务发现配置、支持运行时动态路由等功能 Envoy 核心功能在于数据平面，于2016年由Lyft公司创建并开源，目标是成为通用的数据平面云原生应用，既可用作前端代理，亦可实现Service Mesh中的服务间通信 Envoy常被用于实现APIGateway（如Ambassador）以及Kubernetes的Ingress Controller（例如gloo等），不过，基于Envoy实现的Service Mesh产品Istio有着更广泛的用户基础 Istio ·相比前两者来说，lstio发布时间稍晚，它于2017年5月方才面世，但却是目前最火热的Service Mesh解决方案，得到了Google、IBM、Lyt及Redhat等公司的大力推广及支持 ·目前仅支持部署在Kubernetes之上，其数据平而由Envoy实现 envoy适用于现代大型面向服务架构的动态组织应用程序的7层代理应用程序，其典型特性：运行在架构进程之外支持3/4层过滤器支持HTTP协议7层过滤器支持HTTP协议7层高级路由功能 envoy在现代服务体系架构当中的适用位置既可以为一组服务提供代理，作为整个服务统一的api网关来进行接入，同时也可以对每一个微服务单独实现作为代理，此时需要以sidecar的形式运行在应用程序前端。进而与最前端的apigateway组织成所谓的服务网格（Sevice Mesh）。而在每一个Envoy实例内部都要接受请求。这个请求可能是来自互联网或服务网格之外的客户端，称之为南北流量；也可能是来自网格当中的其他服务的请求，称之为东西流量。在Envoy当中类似于Nginx或者haproxy的功能术语： listeners ：面向客户端一侧提供监听并接受客户端请求的组件。类似于nginx的server或haproxy的frontend 。 cluster：面向后端测，将多个被代理的实例分成组，统一进行负载均衡调度的组。 cluster definltions：cluster的归类。 filter chains：过滤器链，可以将多个链以流水线方式依次进行处理。面向客户端提供服务/监听的套接字，lintener内部包含一到多个filter组成filter chains，称之为过滤器链。过滤器是lintener内部的子组件。envoy支持4层过滤器和7层过滤器。 envoy 术语主机（Host）：能够进行网络通信的实体（如手机，服务器等上的应用程序）。在这个文档中，主机是一个逻辑网络应用程序。一个物理硬件可能有多个主机上运行，只要他们可以独立寻址。下游（Downstream）：下游主机连接到Envoy，发送请求并接收响应。上游（Upstream）：上游主机接收来自Envoy的连接和请求并返回响应。监听器（Listener）：侦听器是可以被下游客户端连接的命名网络位置（例如，端口，unix域套接字等）。Envoy公开一个或多个下游主机连接的侦听器。 filters chains，过滤器链L4/L7 route：完成对客户请求进行分类群集（Cluster）：群集是指Envoy连接到的一组逻辑上相似的上游主机。Envoy通过服务发现发现一个集群的成员。它可以通过主动健康检查来确定集群成员的健康度，从而Envoy通过负载均衡策略将请求路由到相应的集群成员。网格（Mesh）：协调一致以提供一致的网络拓扑的一组主机。在本文档中，“Envoy mesh”是一组Envoy代理，它们构成了由多种不同服务和应用程序平台组成的分布式系统的消息传递基础。

Envoy健康状态监测

Wed, 02 Sep 2020 00:00:00 +0000

官方文档 healthy_check Envoy的服务发现并未采用完全一致的机制，而是假设主机以最终一致的方式加入或离开网格，它结合主动健康状态检查机制来判定集群的健康状态；健康与否的决策机制以完全分布式的方式进行，因此可以很好地应对网络分区；为集群启用主机健康状态检查机制后，Envoy基于如下方式判定是否路由请求到一个主机；发现失败，单健康检查正常，此时，无法添加新主机，但现有主机将继续正常运行。 Discovery Status Health Check OK Health Check Failed Discovered Route Dont’t Route Absent Route Don’t Route / Delete 故障处理机制 Envoy提供了一系列开箱即用的故障处理机制：超时（timeout）有限次数的重试，并支持可变的重试延迟主动健康检查与异常探测连接池断路器所有这些特性，都可以在运行时动态配置；结合流量管理机制，用户可为每个服务/版本定制所需的故障恢复机制；健康状态监测健康状态检测用于确保代理服务器不会将下游客户端的请求代理至工作异常的上游主机； Envoy支持两种类型的健康状态检测，二者均基于集群进行定义：主动检测（Active Health Checking）：Envoy周期性地发送探测报文至上游主机，并根据其响应判断其健康状态；Envoy目前支持三种类型的主动检测： HTTP：向上游主机发送HTTP请求报文 L3/L4：向上游主机发送L3/L4请求报文，基于响应的结果判定其健康状态，或仅通过连接状态进行判定； Redis：向上游的redis服务器发送Redis PING；被动检测（Passive Health Checking）：Envoy通过异常检测（Outlier Detection）机制进行被动模式的健康状态检测；目前，仅htp router、tcp proxy和redis proxy三个过滤器支持异常值检测； Envoy支持以下类型的异常检测：连续5XX：意指所有类型的错误，非htp router过滤器生成的错误也会在内部映射为5xx错误代码；连续网关故障：连续5XX的子集，单纯用于http的502、503或504错误，即网关故障；连续的本地原因故障：Envoy无法连接到上游主机或与上游主机的通信被反复中断；成功率：主机的聚合成功率数据阀值；主动健康状态监测集群的主机健康状态检测机制需要显式定义，否则，发现的所有上游主机即被视为可用；定义语法 yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 clusters: - name: .

envoy流量管理

Wed, 02 Sep 2020 00:00:00 +0000

灰度发布概述新版本上线时，无论是出于产品稳定性还是用户接受程度等方面因素的考虑，直接以新代旧都充满风险；于是，通行做法是新老版本同时在线，且一开始仅分出较小比例的流量至新版本，待确认新版本没问题后再逐级加大流量切换。灰度发布是迭代的软件产品在生产环境安全上线的一种重要手段，对于Envoy来说，灰度发布仅是流量治理的一种典型应用；以下是几种常见的场景口金丝雀发布 - 蓝绿发布 - A/B测试 - 流量镜像灰度策略需要在生产环境发布一个新的待上线版本时，需要事先添加一个灰度版本，而后将原有的生产环境的默认版本的流量引流一部分至此灰度版本，配置的引流机制即为灰度策略，经过评估稳定后，即可配置此灰度版本接管所有流量，并下线老版本。常用的策略类型大体可分为 “基于请求内容发布”和“基于流量比例发布”两种类型基于请求内容发布：配置相应的请求内容规则，满足相应规则服务流量会路由到灰度版本；例如对于http请求，通过匹配特定的Cookie标头值完成引流 Cookie内容：完全匹配：当且仅当表达式完全符合此情况时，流量才会走到这个版本；正则匹配：此处需要您使用正则表达式来匹配相应的规则；自定义Header：完全匹配：当且仅当表达式完全符合此情况时，流量才会走到这个版本；正则匹配：此处需要您使用正则表达式来匹配相应的规则；可以自定义请求头的key和value，value支持完全匹配和正则匹配；基于流量比例发布：对灰度版本配置期望的流量权重，将服务流量以指定权重比例引流到灰度版本；例如10%的流量分配为新版本，90%的流量保持在老版本。这种灰度策略也可以称为AB测试；注：所有版本的权重之和为100；灰度发布的实现方式基于负载均衡器进行灰度发布在服务入口的支持流量策略的负载均衡器上配置流量分布机制仅支持对入口服务进行灰度，无法支撑后端服务需求基于Kubernetes进行灰度发布根据新旧版本应用所在的Pod数量比例进行流量分配，不断滚动更新旧版本Pod到新版本（先增后减、先减后增、又增又减）；服务入口通常是Service或Ingress。基于服务网格进行灰度发布对于Envoy或lstio来说，灰度发布仅是流量治理机制的一种典型应用。通过控制平面，将流量配置策略分发至对目标服务的请求发起方的envoy sidecar上即可。支持基于请求内容的流量分配机制，例如浏览器类型、cookie等。服务访问入口通常是一个单独部署的Envoy Gateway。 Envoy中流量转移新版本上线时，为兼顾到产品的稳定性及用户的接受程度，让新老版本同时在线，将流量按需要分派至不同的版本；蓝绿发布 A/B测试金丝雀发布流量镜像 …. HTTP路由器能够将流量按比例分成两个或多个上游集群中虚拟主机中的路由，从而产生两种常见用例：版本升级：路由时将流量逐渐从一个集群迁移至另一个集群，实现灰度发布；通过在路由中定义路由相关流量的百分比进行； A/B测试或多变量测试：同时测试多个相同的服务，路由的流量必须在相同服务的不同版本的集群之间分配；通过在路由中使用基于权重的集群路由完成；另外，匹配条件中，结合指定标头或也能够完成基于内容的流量管理；流量迁移是指，通过在路由中配置运行时对象选择特定路由以及相应集群的概率的变动，从而实现将虚拟主机中特定路由的流量逐渐从一个集群迁移到另一个集群。 runtime_fraction yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 route: - match: prefix|path|regex: runtime_faction: # 额外匹配指定的运行时键值，每次评估匹配路径时，必须低于此字段指示的百分比，支持渐进式修改。 default_value: # 运行时键值不可用时，则使用此默认值。 numerator: # 指定分子，默认0 denominator: # 指定分母，小于分母时，最终百分比为1，分母可使用 HUNDRED（默认） TEN_THOUSAND和MILLION， runtime_key: routing.

Envoy路由管理

Wed, 02 Sep 2020 00:00:00 +0000

HTTP 链接管理 envoy处理用户请求逻辑 ① 用户请求报文到达七层过滤器链处理机制后，首先根据请求HTTP报文中的 Host 首部来完成虚拟主机的选择；② 由此虚拟机主机内部的 Route 表项进行处理。③ 后由 match 进行匹配; Match 是与请求URL的 PATH 组成部分或请求报文的标头部分 header 。④ 最后才可到达 Route 进行 direct_response 、redirect 等。官方手册 Envoy通过内置的L4过滤器HTTP连接管理器将原始字节转换为HTTP应用层协议级别的消息和事件，例如接收到的标头和主体等，以及处理所有HTTP连接和请求共有的功能，包括访问日志、生成和跟踪请求ID，请求/响应头处理、路由表管理和统计信息等；支持HTTP/1.1、WebSockets和HTTP/2，但不支持SPDY; 关联的路由表可静态配置，亦可经由 xDS API 中的 RDS 动态生成；内建重试插件，可用于配置重试行为; Host Predicates Priority Predicates 内建支持302重定向，它可以捕获302重定向响应，合成新请求后将其发送到新的路由匹配（match）所指定的上游端点，并将收到的响应作为对原始请求的响应返回客户端支持适用于HTTP连接及其组成流（constituent streams）的多种可配置超时机制连接级别：空闲超时和排空超时（GOAWAY）；流级别：空闲超时、每路由相关的上游端点超时和每路由相关的 gRPC 最大超时时长；基于自定义集群的动态转发代理； HTTP协议相关的功能通过各HTTP过滤器实现，这些过滤器大体可分为编码器、解码器和编/解码器三类； router envoy.router 是最常的过滤器之一，它基于路由表完成请求的转发或重定向，以及处理重试操作和生成统计信息等； HTTP 路由 Envoy基于HTTP router过滤器基于路由表完成多种高级路由机制，例如: 将域名映射到虚拟主机； path的前级 prefix 匹配、精确匹配或正则表达式匹配；虚拟主机级别的TLS重定向； path级别的 path/host 重定向； direct_response ，由Envoy直接生成响应报文；显式 host rewrite； prefix rewrite；基于HTTP标头或路由配置的请求重试与请求超时；基于运行时参数的流量迁移；基于权重或百分比的跨集群流量分割；基于任意标头匹配路由规则；基于优先级的路由；基于hash策略的路由；路由配置和虚拟主机路由配置中的顶级元素是虚拟主机

服务网格安全体系

Wed, 02 Sep 2020 00:00:00 +0000

服务网格安全框架 Microservice Security Basics 零信任安全 | 什么是零信任网络？零信任是一种安全模型，其基础是维护严格的访问控制并且默认不信任任何人，即便是已在网络边界内的人。零信任安全 IAAA (Identification and Authentication, Authorization and Accountability Identification: 必须支持多个身份和属性 Your name, username, ID number, employee number, SSN etc. “I am Thor”. Authentication: 必须支持多种认证方式以及委托认证方式 Authorization: 对于单个请求的授权可以在请求路径中的多个点确认 Accountability: 从API中捕获相关安全数据或元数据服务网格常见安全解决方案网络级别控制 Network Level Contros local isolation 主机隔离 Network segementation 网络分割意味着新人底层的服务器及网络设施，信任隔离机制及实现过程且信任网段内的所有组件； SSL/TLS mTLS、spiffe/spire 应用级别控制 Network Level Contros 传统网络令牌认证 Traditional Web Tokens API-oriented Tokens OAuth 2.0 OpenID Connect JWT TokenTypes Opaque tokens Transparent tokens 基于cookie的会话 cookie based sessions SAML Security Assertion Markup Language 一种基于XML开源标准的数据格式，它在当事方之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。 Envoy的身份认证机制传输认证传输认证：即服务组件的认证，它基于双向TLS实现传输认证（即mTLS），包括双向认证、信道安全和证书自动管理；每个服务都需要有其用于服务间双向认证的标识，以实现此种认证机制；

istio安装

Thu, 20 Aug 2020 00:00:00 +0000

Istio用于提供统一方式来集成微服务的开放平台，管理微服务之间的流量，执行策略和汇总遥测数据。Istio的控制平面在基础集群管理平台（例如Kubernetes）上提供了一个抽象层。 Istio组成：在Istio1.8中，istio由以下组件组成：istio-component istio服务网格分为数据平面和控制平面数据平面：数据平面是由一组代理组成 envoy：Sidecar Proxy 每个微服务代理来处理入口/出口业务服务之间的集群中，并从外部服务的服务。代理形成一个*安全的微服务网格，*提供了丰富的功能集合控制平面：管理与配置代理的流量规则。 istiod：istio的控制平面，提供了服务发现，配置和证书管理，包含如下组件： Pilot ：负责运行时配置，（服务发现，智能路由） Citadel：负责证书的颁发与轮替 Galley：负责配置的管理（验证，提取，分发等功能） istio卸载 bookinfo卸载 text 1 kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml istio卸载 text 1 istioctl manifest generate|kubectl delete -f - addons text 1 2 3 4 kubectl delete -f samples/addons/prometheus.yaml kubectl delete -f samples/addons/jaeger.yaml kubectl delete -f samples/addons/kiali.yaml kubectl delete -f samples/addons/grafana.yaml

istio命令

Thu, 20 Aug 2020 00:00:00 +0000

显示配置文件中的差异 istioctl profile diff default demo 显示对应配置的profile istioctl profile dump demo 显示可用的配置 istioctl profile list 安装指定配置的istio istioctl install --set profile=demo 生成配置清单 istioctl manifest generate istioctl验证安装: istioctl manifest generate --set profile=demo |istioctl verify-install - istio的非侵入式流量治理流量治理是一个非常宽泛的话题，例如： ◎ 动态修改服务间访问的负载均衡策略，比如根据某个请求特征做会话保持； ◎ 同一个服务有两个版本在线，将一部分流量切到某个版本上； ◎ 对服务进行保护，例如限制并发连接数、限制请求数、隔离故障服务实例等； ◎ 动态修改服务中的内容，或者模拟一个服务运行故障等。在Istio中实现这些服务治理功能时无须修改任何应用的代码。较之微服务的SDK方式，Istio以一种更轻便、透明的方式向用户提供了这些功能。用户可以用自己喜欢的任意语言和框架进行开发，专注于自己的业务，完全不用嵌入任何治理逻辑。只要应用运行在Istio的基础设施上，就可以使用这些治理能力。一句话总结 Istio 流量治理的目标：以基础设施的方式提供给用户非侵入的流量治理能力，用户只需关注自己的业务逻辑开发，无须关注服务访问管理。 istio服务架构在istio1.8中，istio的分为 envoy （数据平面）、istiod （控制平面）、addons（管理插件）及 istioctl （命令行工具，用于安装、配置、诊断分析等操作）组成。 Pilot Pilot是Istio控制平面流量管理的核心组件，管理和配置部署在Istio服务网格中的所有Envoy代理实例。 pilot-discovery为envoy sidecar提供服务发现，用于路由及流量的管理。通过kubernetes CRD资源获取网格的配置信息将其转换为xDS接口的标准数据格式后，通过gRPC分发至相关的envoy sidecar Pilot组件包含工作在控制平面中的 pilot-discovery 和工作与数据平面的pilot-agent 与Envoy(istio-proxy) pilot-discovery主要完成如下功能：从service registry中获取服务信息从apiserver中获取配置信息。将服务信息与配置信息适配为xDS接口的标准数据格式，通过xDS api完成配置分发。 pilot-agent 主要完成如下功能

常用加密算法之数字证书与TLS/SSL

Sun, 02 Aug 2020 00:00:00 +0000

数字证书互联网上任意双方之间实现通信时，证书的目的有两种，主机证书，主要实现主机与主机之间进程间通信的。个人证书，主要用作个人通信的，主要用作加密的数据的发送。主机类证书所拥有的标识主要为主机名，主机证书名称一定要与互联网之上访问名称一致，否则此证书为不可信证书。对于一个安全的通信，应该有以下特征：完整性：消息在传输过程中未被篡改身份验证：确认消息发送者的身份不可否认：消息的发送者无法否认自己发送了信息显然，数字签名和消息认证码是不符合要求的，这里就需要数字证书来解决其弊端。数字证书（digital certificate）又称公开密钥认证 PKC（英语：Public key certificate）。是在互联网通信中，方式数字签名的秘钥被篡改，是用来证明公开密钥拥有者的身份。此文件包含了公钥信息、拥有者身份信息（主体）、以及数字证书认证机构（发行者）对这份文件的数字签名，以保证这个文件的整体内容正确无误。数字证书认证机构 CA (Certificate Authority)：是负责发放和管理数字证书的权威机构。公钥证书的格式标准 X.509是密码学中公钥明证PKC的格式标准，所有的证书都符合ITU-T X.509国际标准。X.509证书的结构是用ASN1 (Abstract Syntax Notation One)进行描述数据结构，并使用ASN.1语法进行编码。证书规范 X.509指的是ITU和ISO联合制定的（RFC5280）里定义的的 X.509 v3 前使用最广泛的标准为X.509的 v3版本规范 (RFC5280）, 一般遵从X.509格式规范的证书，会有以下的内容：证书组成结构结构说明版本现行通用版本是 V3，序号用来识别每一张证书，用来追踪和撤销证书。只要拥有签发者信息和序列号，就可以唯一标识一个证书，最大不能过20个字节；由CA来维护主体拥有此证书的法人或自然人身份或机器，包括：国家（C，Country）州/省（S，State）** 地域/城市（L，Location）组织/单位（O，Organization）通用名称（CN，Common Name）：在TLS应用上，此字段一般是域名发行者以数字签名形式签署此证书的数字证书认证机构有效期(Validity) 此证书的有效开始时间，在此前该证书并未生效；此证书的有效结束时间，在此后该证书作废。公开密钥用途指定证书上公钥的用途，例如数字签名、服务器验证、客户端验证等公开密钥公开密钥指纹数字签名使用信任的CA对内容进行主体别名例如一个网站可能会有多个域名（www.jd.com www.360buy.com..）一个组织可能会有多个网站（*.baidu.com tieba.baidu.com），不同的网域可以一并使用同一张证书，方便实现应用及管理。互联网上任意双方之间实现通信时，证书的目的有两种，主机证书，主要实现主机与主机之间进程间通信的。个人证书，主要用作个人通信的，主要用作加密的数据的发送。主机类证书所拥有的标识主要为主机名，主机证书名称一定要与互联网之上访问名称一致，否则此证书为不可信证书。数字证书文件格式 X.

脚本在公网的加密执行

Mon, 18 May 2020 00:00:00 +0000

openssl 可以加密解密，当然也可以为文件加密解密 bash 1 sudo openssl des3 -e -k d36b6b41f36c87963676005ddfb931c7 -in /data/init_app.sh -out /data/rpm/init_app 解密 bash 1 curl http://47.244.200.140:8181/init_app|openssl des3 -d -k d36b6b41f36c87963676005ddfb931c7|sudo bash -s jdk8

Powershell阻止确认

Sun, 19 Apr 2020 00:00:00 +0000

要阻止弹出确认提示，需要设置-Confirm为false, text 1 new-VM -Name $hostname -Template $template -VMHost 10.11.31.5 -OSCustomizationspec TestLinux -Confirm:$false 获得当前确认级别 text 1 $ConfirmPreference 查看确认级别（$ConfirmPreference）支持的选项，类型为枚举 text 1 [ENUM]::GetNames($ConfirmPreference.GetType()) 设置确认级别 text 1 $ConfirmPreference="None"

named主从部署

Mon, 17 Feb 2020 00:00:00 +0000

text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 // // named.

zimbra安装三方颁发的证书

Thu, 09 Jan 2020 00:00:00 +0000

步骤1：取得SSL凭证证书需要取的从根证书每一级的证书步骤2：合成SSL证书将中级、根证书合成为一个证书顺序：按照从后到前合成为一个证书如，三级 ==》二级 ==》根合成后的格式如下 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 -----BEGIN CERTIFICATE----- 你的crt內容 -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/ MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw 7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69 ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5 JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ -----END CERTIFICATE----- 步骤3：验证你的商业证书复制生成的所有证书到目录 /opt/zimbra/ssl/zimbra/commercial 下，（合成后的根证书、证书、与秘钥）切換到 zimbra 用戶 text 1 2 3 4 5 6 7 8 $ zmcertmgr verifycrt comm {{privkey.

zimbra启用SMTP认证

Wed, 08 Jan 2020 00:00:00 +0000

text 1 2 zmprov modifyServer {{ you domain }} zimbraMtaTlsAuthOnly FALSE zmcontrol restart 查看对应配置 text 1 zmprov getServer {{ you domain }} | grep Auth 查看SMTP是否开启成功 text 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 $ telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 xxxx ESMTP Postfix ehlo xxxx 250-xxxxx 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH LOGIN PLAIN #SMTP认证相关参数 250-AUTH=LOGIN PLAIN #SMTP认证相关参数 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN

使用ldap客户端创建zimbra ldap用户的格式

Mon, 16 Dec 2019 00:00:00 +0000

命令如下 ldif cat << EOF | ldapadd -x -W -H ldap://:389 -D "uid=zimbra,cn=admins,cn=zimbra" dn: uid=jak1,ou=people,dc=mail,dc=xxxxx2021,dc=com zimbraAccountStatus: active displayName: jak1 givenName: jak1 sn: jak1 zimbraMailStatus: enabled objectClass: inetOrgPerson objectClass: zimbraAccount objectClass: amavisAccount zimbraId: e2214a66-3ga2-4241-9223-44f222ce0522 zimbraCreateTimestamp: 20191102062818.876Z zimbraMailHost: mail.xxxx2021.com zimbraMailTransport: lmtp:mail.xxxx2021.com:7025 zimbraMailDeliveryAddress: scott8@mail.xxxx2021.com mail: jak1@mail.xxxx2021.com cn: jak1 uid: jak1 userPassword:: e1NTSEE1MTJ9ZzBzZGlXRlBjbDQxa2xmZ200YXc1ZkJzSGQzVXNBdVBydUlKRnZ LTExYby9HWXBoUkNTMzZYMEx5VnpCZUJPMGJNTCtTV2IwSnhkaHdudTViR0c1bTJabFVhU3R1N1J3 EOF zimbraAccountStatus 为账户设置中的状态 zimbraId 唯一的值 givenName 姓 displayName 显示名字 bash 1 ldapsearch -LLL -w 99tJFkhVfn -H ldap://172.31.110.115:389 -D "uid=zimbra,cn=admins,cn=zimbra"|less

Kubernetes包管理 - Helm

Wed, 27 Nov 2019 00:00:00 +0000

什么是 Helm Helm 是一个用于管理 Kubernetes 应用程序的包管理工具。它允许您定义、安装和升级 Kubernetes 应用程序，以简化应用程序部署和管理的过程。在 Kubernetes 中，应用程序被打包为一个或多个称为 “Charts” 的 Helm 资源。一个 Chart 是一个预定义的目录结构，包含了用于部署应用程序的 Kubernetes 资源清单模板。Chart 可以包含 Deployment、Service、ConfigMap、Ingress 等 Kubernetes 资源的定义。使用 Helm，您可以将应用程序打包为一个 Chart，并使用 Helm 客户端来安装和管理 Chart。这使得应用程序的部署过程更加简单、可重复和可扩展。您可以根据需要部署多个实例，轻松地进行升级和回滚操作，并使用 Helm 提供的值覆盖机制来自定义每个实例的配置。最重要的是，Helm 支持使用 Helm 仓库来共享和发布 Charts。Helm 仓库是一个集中存储 Charts 的地方，供用户从中搜索和安装 Charts。Helm 仓库可以是公共的，也可以是私有的，您可以自己搭建私有仓库来管理自己的 Charts。 Helm 所作的事情 Helm 管理名为 chart 的Kubernetes包的工具。故 Helm 可以做以下的事情：创建一个新的 chart 将 chart 打包成归档 (tgz) 文件与存储 chart 的仓库进行交互在现有的 Kubernetes 集群中安装和卸载 chart 管理与Helm一起安装的 chart 的发布周期 Helm中的术语 chart：类似于rpm包，deb包，包含Kubernetes资源所需要的必要信息。 repo：chart仓库，类似于yum的仓库，chart仓库是一个简单的HTTP服务。 values：提供了自定义信息用来覆盖模板中的默认值。 release ：chart安装后的版本记录。 Helm 与 YAML 资源清单比有什么优势？模板化和参数化: Helm 使用 Go 的模板引擎来创建 Kubernetes 资源清单。这使得您可以在 Chart 中使用模板来定义资源配置的部分内容，例如标签、名称、端口等。同时，Helm 还支持使用参数化的值，允许您根据不同的环境或需求来自定义 Chart 的配置。这样一来，您可以根据需要生成不同的 Kubernetes 资源清单，而无需手动编辑每个清单文件。可重用性: Helm 提供了一种将应用程序打包为 Chart 的方式，可以将 Chart 存储在 Helm 仓库中进行共享和重用。这样，您可以使用其他人创建的 Charts 来快速部署常见的应用程序，避免从头开始编写和管理 Kubernetes 资源清单。同时，您也可以将自己的应用程序打包为 Chart，方便自己和团队在不同环境中部署和管理。版本管理和升级: 使用 Helm，您可以对已安装的 Chart 进行版本管理和升级。当应用程序的配置或代码发生变化时，您可以通过升级 Chart 来自动应用这些更改，而无需手动修改和重新部署 Kubernetes 资源清单。Helm 还提供了回滚功能，允许您在升级出现问题时快速回退到之前的版本。依赖管理: Helm 允许您在 Chart 中定义和管理依赖关系。这意味着您可以在部署应用程序时自动解析和安装它所依赖的其他 Charts。这样，您可以轻松地管理应用程序所需的其他资源，减少手动处理依赖关系的工作。部署的一致性和标准化: Helm 提供了一种标准的部署方式，使得不同团队或开发者之间可以使用相同的工具和流程来管理应用程序的部署。这样可以确保在不同环境中的一致性，并降低由于不同部署方式导致的错误和配置差异。可管理的 Charts: Helm Charts 是可管理的，您可以在 Chart 中定义预先配置的模板、默认值、钩子和配置验证。这使得管理应用程序的配置和部署过程更加灵活和可控。社区支持和生态系统: Helm 是一个活跃的开源项目，拥有庞大的用户社区和丰富的生态系统。这意味着您可以轻松地找到文档、示例、教程和问题解答，并从社区中获取支持和贡献。可扩展性和插件支持: Helm 提供了插件机制，允许您扩展 Helm 的功能。您可以使用插件来添加自定义的命令、功能和工作流程，以满足特定需求或自动化常见的任务。可视化界面和用户友好性: Helm 可以与各种第三方工具和平台集成，提供可视化界面和用户友好的操作方式。这使得非技术人员或不熟悉命令行的开发人员也能够方便地部署和管理应用程序。安装helm Helm 安装主要官方提供了几种安装方式

Ceph集群安装 - ceph-deploy

Mon, 18 Nov 2019 00:00:00 +0000

本文是Ceph集群部署系列第3章使用cephadm纯离线安装Ceph集群使用cephadm纯离线安装Ceph集群 2 Ceph集群安装 - ceph-deploy Ceph集群安装 - ceph-deploy下线rgw 环境配置 Ceph 是一个开源去中心化存储平台，专为满足现代存储需求而设计。 Ceph可扩展至 EB 级，并且设计为无单点故障，使其成为需要高度可用的灵活存储的应用程序的理想选择。下图显示了具有 Ceph 存储的示例 3 节点集群的布局。两个网络接口可用于增加带宽和冗余，这有助于保持足够的带宽来满足存储要求，而不影响客户端应用程序。图：Ceph存储集群 Source：https://www.jamescoyle.net/how-to/1244-create-a-3-node-ceph-storage-cluster 图中架构表示了一个无单点故障的 3 节点 Ceph 集群，以提供高度冗余的存储。每个节点都配置了两个磁盘；一台运行 Linux 操作系统，另一台将用于 Ceph 存储。下面的输出显示了可用的存储空间，每个主机上的存储空间完全相同。 /dev/sda 是包含操作系统安装的根分区， /dev/sdb 是一个未触及的分区，将用于部署 Ceph 集群，对应的硬件信息如下表所示。主机名 public IP cluster IP 数据盘 ceph-nautilus01 10.0.0.50 10.0.0.50 /dev/sda /dev/sdb ceph-nautilus02 10.0.0.51 10.0.0.51 /dev/sda/dev/sdb ceph-nautilus03 10.0.0.52 10.0.0.52 /dev/sda/dev/sdb ceph-control 10.0.0.49 10.0.0.49 /dev/sda 部署工具 ceph-deploy 工具是在 “管理节点” (ceph-admin) 上的目录中运行。

ch1 VPN与OpenVPN应用场景分析

Mon, 18 Nov 2019 00:00:00 +0000

什么是VPN VPN ( Virtual Private Network) 虚拟专用网络，是依靠ISP和其他的NSP，在公共网络中建立专用的数据通信网络的技术，可以为企业与企业之间或者个人与企业之间提供安全的数据传输隧道服务。在VPN中任意两点之间的连接并没有传统专网所需的端到端的物理链路，而是利用公共网络资源动态组成的，可以理解为通过私有的隧道技术在公共数据网络上模拟出来的和专网有同样功能的点到点的专线技术，所谓虚拟是指不需要去拉实际的长途物理线路，而是借用了公共Internet网络实现。 vpn直观的形象图： VPN Server/Client <---------------------------------> VPN Server/Client VPN的作用 VPN功能可以帮助公司里的远程用户(出差，家里)、公司的分支机构、商业合作伙伴及供应商等公司和自己的公司内部网络之间建立可信的安全连接或者是局域网连接，确保数据的加密安全传输和业务访问，对至运维工程师来说，还可以连接不同的机房为局域网，处理相关的业务流。我们可以通过一张网络逻辑图来描述VPN的作用。图：OpenVPN架构 Source：https://www.slideteam.net/vpn-tunnel-architecture-connecting-corporate-and-branch-office.html VPN的分类我们根据VPN的常见企业应用，将VPN分为以下4类应用远程访问VPN服务即通过个人电脑远程拨号到企业办公网络。一般为企业内部员工出差、休假或特殊情况下在远离办公室的时候，又有需求访问公司的内部网络获取相关资源，就可以通过VPN拨号到公司内部.此时远程拨号的员工和办公室内的员工以及其他拨号的员工之间都相当于一个局域网络内。例如:访问内部的域控制器，文件服务器，OA系统，ERP, HTTP服务，内网聊天工具等局域网服务应用。对于运维人且就是需要个人电脑远程拨号到企业网站IDC机房，远程维护内网服务器（一般无外网IP）。此点是技术人员特别是运维人且在工作中会经常用这个方法维护大量的机房内无外网的服务器及网络设备。企业内部网络之间VPN服务在公司的分支机构的局域网和公司总部LAN之间的VPN连接。通过公网Internet建立VPN将公司在各地的分支机构的LAN连接到公司总部的LAN。例如:各大超市之间业务结算等。这是由于地域的原因而产生的VPN的需求，通过VPN让不同地域内的机器可以互相访问，就好像是一个局域网一样。例如：办公室互联协同办公，机房互联数据同步及业务访问等。互联网公司多IDC机房之间VPN服务此处是运维架构人员需要考虑的问题。不同机房之间业务管理和业务访问，数据流动。企业外部VPN服务在供应商、合作伙伴的LAN和本公司的LAN之间建立的VPN服务。访问外国网站翻墙的应用常贝隧道协议介绍 PPTP 点对点隧道协议(PPTP)是由包括微软和3Com等公司组成的PPTP论坛开发的一种点对点隧道协议，基于拨号使用的PPP协议，使用PAP或CHAP之类的加密算法，或者使用Microsoft的点对点加密算法MPPE。其通过跨越基于TCP/IP的数据网络创建VPN。实现了从远程客户端到专用企业服务器之间数据的安全传输。PPTP支持通过公共网络(例如Internet)建立按需的、多协议的、虚拟专用网络。PPTP允许加密IP通讯，然后在要跨越公司IP网络或公共IP网络(如Internet)发送的IP头中对其进行封装。典型的linux平台的开源软件为pptp。 PPTP属于点对点方式的应用，比较适合远程的企业用户拨号到企业进行办公等的应用。 L2TP L2TP第2层隧道协议(L2TP)是IETF基于L2F (Cisco的第二层转发协议)开发的PPTP的后续版本。是一种工业标准Internet隧道协议，其可以为跨越面向数据包的媒体发送点到点协议(PPP)框架提供封装。PPTP和L2TP都使用PPP协议对数据进行封装，然后添加附加包头用于数据在互联网络上的传输。PPTP只能在两端点间建立单一隧道。L2TP支持在两端点间使用多隧道，用户可以针对不同的服务质量创建不同的隧道。L2TP可以提供隧道验证，而PPTP则不支持隧道验证。但是当L2TP或PPTP 与 IPSEC 共同使用时，可以由IPSEC提供隧道验证，不需要在第2层协议上验证隧道使用L2TP。PPTP要求互联网络为IP网络。L2TP只要求隧道媒介提供面向数据包的点对点的连接，L2TP可以在IP(使用UDP)，帧中继永久虚拟电路(PVCs)，X.25虚拟电路(VCs)或ATM VCs网络上使用。 L2TP (Layer 2 Tunneling Protocol) 在计算机网络中，第2层隧道协议（L2TP）是一种隧道协议，用于支持虚拟专用网络（VPN）或作为ISP提供服务的一部分。它本身不提供任何加密或机密性。相反，它依靠它在隧道内传递的加密协议来提供隐私。由于L2TP协议缺乏固有的机密性，因此通常与IPsec一起实施。这被称为L2TP / IPsec，并在IETF RFC 3193中进行了标准化。 Reference L2TP IPSec IP安全协议(IPSec: IP Security)实际上是一套协议包而不是一个独立的协议。从1995年开始IPSec的研究以来，IETF IPSec工作组在它的主页上发布了几十个Internet草案文献和12个RFC文件。其中，比较重要的有RFC2409 IKE(互连网密钥交换)、RFC2401 IPSec协议、RFC2402 AH验证包头、RFC2406 ESP加密数据等文件。 IPSec隧道模式隧道是封装、路由与解封装的整个过程。隧道将原始数据包隐藏(或封装)在新的数据包内部。该新的数据包可能会有新的寻址与路由信息，从而使其能够通过网络传输。隧道与数据保密性结合使用时，在网络上窃听通讯的人将无法获取原始数据包数据(以及原始的源和目标)。封装的数据包到达目的地后，会删除封装，原始数据包头用于将数据包路由到最终目的地。隧道本身是封装数据经过的逻辑数据路径，对原始的源和目的端，隧道是不可见的，而只能看到网络路径中的点对点连接。连接双方并不关心隧道起点和终点之间的任何路由器、交换机、代理服务器或其他安全网关。将隧道和数据保密性结合使用时，可用于提供VPN。

ch2 从零开始安装OpenVPN

Mon, 18 Nov 2019 00:00:00 +0000

OpenVPN安装环境需求设备 IP 笔记本或PC (adsl上网) 10.0.0.0/24 办公室（DHCP） OpenVPN Server双网卡 eth0:10.0.0.4/24（外网） eth1:192.168.100.4（内网） IDC机房内部局域网服务器 192.168.100.0/24 IDC机房内网服务器无外网IP，又希望ADSL上网笔记本（运维人员），在不同的网络能够直接访问实现需求：在远端通过VPN客户端(笔记本)拨号到VPN，然后在笔记本电脑上可以直接访问vpnserver所在局域网内的多个servers，进行维护管理环境 VPN-Server eth0:10.0.0.4(外网IP)。GW:10.0.0.1, dns:10.0.0.1。 eth1:172.0.0.1(内网IP)。GW:不配提示：检查是否可以ping通client eth0 IP。 App client Server:ethO:172.0.0.2。GW:路由器。提示：检查是否可以ping通VPN-Server eth1 IP。 OpenVPN 解决方案图解部署OpenVPN Server Reference download lzo installing-openvpn openvpn offical releases openvpn github 安装前准备 openvpn支持的平台： Linux kernel 2.6+ OpenBSD 5.1+ Mac OS X Darwin 10.5+ FreeBSD 7.4+ Windows (WinXP and higher) 下载地址： openvpn-releases openvpn github 安装openvpn的依赖项： 0.9.8版或更高版本的OpenSSL库，对于加密是必需的 PolarSSL库，是加密的替代版本1.1或更高版本 LZO实时压缩库，连接压缩所需 bash 1 yum install openssl-devel lzo-devel pam-devel -y bash 1 2 3 4 5 6 .

ch3 OpenVPN的高可用配置

Mon, 18 Nov 2019 00:00:00 +0000

方案1：在Vpn 客户端使用多个配置文件实现（由用户选择拨号）类方案1：需求分析与操作过程讲解。基本说明：生产场景中比较规范的做法是让所有的VPN SERVER尽可能共享同一套 server，ca证书或者连接同一个认证系统（即使是跨机房）。这样只需要一份客户端认证和文件和多份指定不同vpn client的配置文件即可实现vpn的负载均衡了。总结结论： 1）该负载均衡方案操作简单，不引入多余服务（后面的方案都会引入服务），因此不会增加多余的单点故障，当用户连接的vpn不能使用时，用户就可以人工选择拨号其他的VPN服务器。 2）如果使用者为公司内部工作人员，此种方案是值得推荐的。老男孩老师推荐。 3）从广义上讲这是在用户端实现的负载均衡方案，类似早期的华军下载站一样，由用户选择下载站点，而不是用什么智能DNS等复杂的业务模式。缺点：当一个vpnserver不能使用时，不能自动连上别的vpn server。方案2：通过在客户端配置文件实现负载均衡（客户端文件里随机连接服务器）提示：同方案1，所有VPN SERVER 需要共享同一套 server，ca证书。openvpn 服务器一套keys的多份拷贝方式式。 text 1 2 3 4 remote 10.0.0.28 52115 remote 10.0.0.552115 remote-random resolv-retry 20 implementing-a-load-balancing-failover-configuration 总结结论： 1）该负载均衡方案操作简单，不引入多余服务（后面的方案都会引入服务），因此不会增加多余的单点故障，，当用户连接的vpn不能使用时，电脑可以重新再次自动拨号连接VPN服务器。 2）如果使用者为公司内部工作人员，此种方案是值得推荐的。-老男孩老师推荐。如果是使用者为外部人员，那么这个方案依然是可以的。 3）本方案是比较标准的在VPN用户端，由客户端配置参数实现的负载均衡的方案，是非常值得推荐的方案。 4）和方案1对比，方案2的配置更简单，仅需一个配置文件多个remote参数，拨号时客户端会随机自动选择拨号，方案1则需要手动选择不同的配置文件拨号。当正在连接的VPN服务端右机时，那么此时方案2不需要人工干预，客户端的VPN会自动判断并且自动重新连接其他的可用vpn服务器。. 方案3：通过域名加DNS轮询的方式实现负载均衡（由DNS自动分配vpn）总结结论： 1）通过dns轮询实现VPN负载均衡方案操作比较复杂，引入了DNS服务，因此增加了单点故障及维护成本，当用户连接的vpn不能使用时，用户也需要重新人工再次拨号。 2）如果使用者为公司内部工作人员，此种方案是不推荐的。如果是外部的用户可以考虑用这种方式，但是复杂度比方案1大了很多（如果存在DNS服务器加配置还可以）。 3）当机房多，配置文件多时，无需用户选择服务器，只需拨号即可。如果多个VPN在一个机房还好一些，如果多个VPN服务器不在一个机房，还需要通过IPSEC进行连接。总之，此法很麻烦，中小型公司老男孩老师极不推荐。 4）DNS轮询会遭遇到客户端DNS缓存问题，从而导致服务切换失效。。 one-network-interface-on-a-public-network

ch4 OpenVPN的统一身份认证方案及实现方法

Mon, 18 Nov 2019 00:00:00 +0000

OpenVPN 2.0与更高版本允许OpenVPN服务器从客户端安全地获取用户名和密码，并将该信息用作认证基础。方法1：通过本地证书密钥认证。默认不配置，openvpn即使用证书进行身份认证。（1）编辑主服务器配置文件/etc/openldap/slapd.conf，取消如下行的注释：方法2：本地文件认证在使用身份验证时，需要将 auth-user-pass 指令添加到客户端配置文件中，设置后OpenVPN客户端向用户索要用户名/密码，并将其通过安全的TLS通道传递给服务器进行验证。服务端配置文件需要增加配置指令 auth-user-pass-verify auth-pam.pl via-file 使用脚本插件。auth-pam.pl 在源码包 sample/sample-script 路径下。 text 1 plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so login 生产环境下官方推荐使用 openvpn-auth-pam 插件进行验证，相比于 auth-pam.pl，openvpn-auth-pam 插件具有多个优点： openvpn-auth-pam 使用拆分权限执行模型来提高安全性。 C编译的插件比脚本运行速度更快。 OpenVPN可以通过虚拟内存（而不是通过文件或环境）将用户名/密码传递给插件，这对于服务器上的本地安全性更好。获取openvpn-auth-pam插件 openvpn-auth-pam插件在openvpn代码目录src/plugins/auth-pam 下，运行 make && make install 进行安装，会自动复制到openvpn安装好的 lib/openvpn/plugins 目录下。开启密码认证默认情况下，在服务器上使用 auth-user-pass-verify 或用户名/密码插件将启用双重身份验证，要求客户端证书和用户名/密码身份验证都必须成功，才能对客户端进行身份验证。可以选择关闭客户端证书认证。 text 1 2 client-cert-not-required username-as-common-name # 用户名作为通用名称开启后需要在客户端注释 cert 和 key的配置方法3：数据库认证法2：利用的脚本程序（shell，php等）本地文件去读数据库。法1：用pam_mysql 方法:4：ldap统一用户认证 openvpn-auth-ldap 利用第一个文件认证的思路，去LDAP查询，还可以和本地文件比较。如 ldap认证原理图配置openvpn服务端通过ldap进行身份验证配置OpenVPN基 LDAP的身份验证，需要安装用于LDAP身份验证的OpenVPN插件。openvpn-auth-ldap，它通过LDAP为OpenVPN实现身份认证。 CentOS中 openvpn-auth-ldap 插件在EPEL中 ubuntu与Centos都可以通过对应的包管理工具进行插件安装。

kubernetes应用 - Traefik Ingress Controller

Wed, 23 Oct 2019 00:00:00 +0000

Kubernetes Ingress Kubernetes Ingress是路由规则的集合，这些规则控制外部用户如何访问Kubernetes集群中运行的服务。在Kubernetes中，有三种方式可以使内部Pod公开访问。 NodePort：使用Kubernetes Pod的NodePort，将Pod内应用程序公开到每个节点上的端口上。 Service LoadBalancer：使用Kubernetes Service，改功能会创建一个外部负载均衡器，使流量转向集群中的Kubernetes Pod。 Ingress Controller： Node Port是在Kubernetes集群中每个节点（Node）上开放端口，Kubernetes直接将流量转向集群中Pod。Kubernetes集群中使用NodePort，则需要编辑防火墙规则，但是NodePort是范围在Kubernetes集群中默认设置的范围为 30000–32767，最终导致流量端口暴露在非标准端口之上。 LoadBalancer一般应用于云厂商提供的Kubernetes服务，如果自行在机器上部署Kubernetes集群，则需要自行配置LoadBalancer的实现， Kubernetes Ingress，为Kubernetes中的抽象概念，实现为第三方代理实现，这种三方实现集合统称为Ingress Controller。Ingress Controller负责引入外部流量并将流量处理并转向对应的服务。 Kubernetes IngressController功能实现上面只是说道，在Kubernetes集群中，如何将外部流量引入到Kubernetes集群服务中。负载均衡无论在Kubernetes集群中，无论采用什么方式进行流量引入，都需要在外部负载均衡完成，而后负载均衡将流量引入Kubernetes集群入口或内部中，通常情况下，NodePort方式管理繁琐，一般不用于生产环境。服务的Ingress选择 Kubernetes Ingress是选择正确的方法来管理引入外部流量到服务内部。一般选择也是具有多样性的。 Nginx Ingress Controller，Kubernetes默认推荐的Ingress，弊端①最终配置加载依赖config reload，②定制化开发较难，配置基本来源于config file。 Envoy & traefik api网关，支持tcp/udp/grpc/ws等多协议，支持流量控制，可观测性，多配置提供者。云厂商提供的Ingress。AWS ALB，GCP GLBG/GCE，Azure AGIC Traefik介绍 traefik-现代反向代理，也可称为现代边缘路由；traefik原声兼容主流集群，Kubernetes，Docker，AWS等。官方的定位traefik是一个让开发人员将时间花费在系统研发与部署功能上，而非配置和维护。并且traefik官方也提供自己的服务网格解决方案作为一个 modern edge router ，traefik拥有与envoy相似的特性基于go语言研发，目的是为了简化开发人员的配置和维护 tcp/udp支持 http L7支持 GRPC支持服务发现和动态配置 front/ edge prory支持可观测性流量管理 … traefik 术语要了解trafik，首先需要先了解一下有关trafik中的一些术语。 EntryPoints 入口点，是可以被下游客户端连接的命名网络位置，类似于envoy 的listener和nginx的listen services 服务，负载均衡，上游主机接收来自traefik的连接和请求并返回响应。类似于nginx upstream envoy的clusters Providers 提供者，提供配置文件的后端，如file，kubernetes，consul，redis，etcd等，可使traefik自动更新 routers 路由器，承上启下，分析请求，将下游主机的请求处理转入到services middlewares: 中间件，在将下游主机的请求转入到services时进行的流量调整在Kubernetes中使用traefik网关作为Ingress Traefik于2019年9月发布2.

centos安装powershell和powercli