根据更新的比特币价格数据和计算，如果每年元旦买入BTC，次年元旦卖出，直到2024年，每年的投资回报率（ROI）如下：

• 2013年买入，2014年卖出的ROI：约 5390.75%
• 2014年买入，2015年卖出的ROI：约 -57.01%
• 2015年买入，2016年卖出的ROI：约 37.21%
• 2016年买入，2017年卖出的ROI：约 131.78%
• 2017年买入，2018年卖出的ROI：约 1243.49%
• 2018年买入，2019年卖出的ROI：约 -72.10%
• 2019年买入，2020年卖出的ROI：约 92.07%
• 2020年买入，2021年卖出的ROI：约 308.63%
• 2021年买入，2022年卖出的ROI：约 62.51%
• 2022年买入，2023年卖出的ROI：约 -58.27%
• 2023年买入，2024年卖出的ROI：约 166.06%

环境信息

• aws-cli/2.9.15

aws cli 安装更新说明

aws cli 基础配置及说明

常见用法

查看 aws 帮助信息

aws help

查看子命令帮助信息

aws ec2 help

配置认证信息时指定鉴权信息对应的 Profile

aws configure --profile source-account

aws 命令常用选项

开户链接

环境信息

• Kubernetes 1.29

kubeadm 初始化集群

Network setup

组件的 advertise IP 地址选择

Kubernetes 中的组件（如 Kubeadm、Kube-apiserver 等）在初始化启动时，都需要在节点（主机）上找到一个合适的 IP 作为组件的 advertising/listening 的地址。^[1]

默认情况下，此 IP 是主机上默认路由对应的网卡所在的 IP。

# ip route show
default via 172.31.16.1 dev eth0 
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 
10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.31.16.0/20 dev eth0 proto kernel scope link src 172.31.26.11

如果系统上有多个默认路由，组件会尝试使用第一个默认路由对应的网卡所在的 IP。如果系统上没有默认路由，并且未明确为组件配置 IP，组件会初始化失败并退出

组件选择的 IP 地址将会作为 X.509 证书的 SAN(Subject Alternative Name) 的一部分。因此在系统初始化运行之后修改 IP 需要重新签发证书并重启相关组件。

Pod 网段选择

Pod 的网段必须不能和主机网络重叠，如果选用的网络插件的网络和主机的网段重叠，必须为网络插件选择合适的和主机不同的网段，在集群初始化时通过参数 --pod-network-cidr 配置，并在安装网络插件时在其 YAML 文件中修改为对应的网段。 ^[4]

control-plane-endpoint 参数说明

--control-plane-endpoint 选项用来配置 api-server 的共享地址，可以是域名或者负载均衡器的 IP。 ^[2]

如果是单主节点的 Kubernetes 集群，想要扩展成为多个 Master 节点（高可用），初始化时没有 --control-plane-endpoint，是不被支持的。

因此为了后期可以由单个 Master 节点扩展为多个 Master 节点，即高可用，初始化节点时，建议加上此选项配置 api-server 的负载均衡地址。

<– more –>

admin.conf 的重要性

kubeadm init 初始化集群成功后，会产生一个 kubeconfig 文件 /etc/kubernetes/admin.conf，此配置中包含了一个绑定到 cluster-admin 的 ClusterRole 的组，其拥有对整个集群的控制权，不要将其共享给任何人。^[3]

kubeadm init 初始化集群成功后，同时会生成一个名为 super-admin.conf 的 kubeconfig 文件，其中配置的超级用户可以跳过 authorization layer，比如 RBAC。不要将其共享给任何人。建议将其保存在一个安全的位置。

Node

节点名称

在 Kubernetes 集群中，节点名称（Node Name）唯一的标识一个节点。在一个集群中，不能有多个名称一样的节点，Kubernetes 系统默认同一个 节点名（Node Name） 的实例将具有同样的一个状态和属性 ^[7]

配置节点为不可调度

将节点标记为 不可调度（unschedulable ） 会阻止系统调度新的 Pod 到节点上，但是不会影响节点上已有的 Pod。

Labels Selectors Annotations

Label 主要用来给 Kubernetes 中的对象添加 可识别属性。 Label 可以提供高效的查询和匹配以选择 Kubernetes 中的对象，Lables 可以在对象创建时或者运行过程中随时做变更。

不具有识别属性的信息 不建议用作 Labels，而是应该写入 Annotations 中。^[5]

Label Key 由 2 部分构成：

• （可选的）前缀。系统组件（如 kube-scheduler, kube-controller-manager, kube-apiserver, kubectl） 或者第三方自动化组件为对象添加 labels 时必须带有前缀（prefix）。kubernetes.io/ and k8s.io/ 是为 Kubernetes 核心系统保留的前缀
• （必须的）名字。

  Annotations 的 Key 命名规则和 Label Key 基本一致 ^[6]

Label select 用法说明

集群间通讯流量说明

API Server 到 kubelet

API Server 请求 kubelet 的主要目的包括： ^[8]

• 获取到 Pods 的日志
• （比如使用 kubectl） Attach 到 Pods 中的容器
• 提供 kubelet 的端口转发功能。

默认情况下，API 服务器不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击， 在非受信网络或公开网络上运行也是 不安全的。
为了对这个连接进行认证，使用 --kubelet-certificate-authority 标志给 API 服务器提供一个根证书包，用于 kubelet 的服务证书。

API Server 到 nodes, pods 和 services

从 API 服务器到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 https: 来运行在安全的 HTTPS 连接上。 不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。 因此，虽然连接是加密的，仍无法提供任何完整性保证。 这些连接 目前还不能安全地 在非受信网络或公共网络上运行。 ^[8]

Kubernetes 支持使用 SSH tunnels 来加密从 API 到 nodes 的链接（目前已经处于废弃状态，推荐使用 Konnectivity service 替代）。

Leases

Kubernetes 使用 Lease API 来更新 kubelet 发送到 Kubernetes API Server 的心跳信息。Kubernetes 中的每一个节点在 kube-node-lease Namespace 中都有一个 Lease Object。kubelet 向系统上报心跳的过程，就是在更新对应的 Lease Object 的 spec.renewTime 字段，Kubernetes 控制平面会使用这个上报的时间戳来决定节点是否可用 ^[9]

# kubectl describe lease -n kube-node-lease k8s-admin
Name:         k8s-node1
Namespace:    kube-node-lease
Labels:       <none>
Annotations:  <none>
API Version:  coordination.k8s.io/v1
Kind:         Lease
Metadata:
  Creation Timestamp:  2023-09-07T09:54:15Z
  Managed Fields:
    API Version:  coordination.k8s.io/v1
    Fields Type:  FieldsV1
	...
  Owner References:
    API Version:     v1
    Kind:            Node
    Name:            k8s-node1
    UID:             db3dafee-1232-4c07-a1c6-524f86a96fbe
  Resource Version:  46696081
  UID:               053d9b79-81be-4f3f-801e-09192012c822
Spec:
  Holder Identity:         k8s-node1
  Lease Duration Seconds:  40
  Renew Time:              2024-02-03T02:30:11.760176Z
Events:                    <none>

Leases 也被用来确保 HA 的组件（类似 kube-controller-manager 和 kube-scheduler）在同一时刻只有一个实例提供服务，其他实例处于备用状态 ^[9]

kubelet

串行和并行拉取镜像

Kubelet 默认（同一个节点）串行的拉取镜像，即同一时间只发送一个拉取镜像的请求到 Registry Server，其他的拉取镜像的请求保持等待，直到当前请求处理完成。多个节点上的镜像拉取请求是隔离的，即不同的节点在同一时间是并行的拉取镜像的。 ^[10]

如果要配置一个节点上的 Kubelet 并行的拉取镜像，可以在 kubelet 的配置中配置 serializeImagePulls 为 false，前提是 Registry Server 和 CRI 支持并行拉取镜像。

Pod

Pod 状态

Pod 的状态字段（status） 是一个 PodStatus Object。其中包含 phase 字段。phase 字段描述/记录了 Pod 在其整个生命周期中所处的阶段 ^[11]

phase 字段可以有以下值：

Pod 中的容器的状态

Kubernetes 会跟踪 Pod 中每个容器的状态。一旦通过 Scheduler 将 Pod 分配到某个 Node，Kubernetes 会通过 CRI 创建 Pod 中的容器。

在 Kubernetes 中，容器可以有以下 3 种状态 ^[11]

QoS

Kubernetes 会根据 Pod 定义中的 resource requests and limits 将 Pod 划归到某一个 QoS 类中，Kubernetes 将会根据 QoS 类来决定在节点资源不足的情况下，哪些 Pod 将会被优先驱逐（Evict）。目前存在的 QoS 类主要有以下三个 ^[12]

Memory QoS 基于系统内核的 cgroup v2 实现 ^[12]

Pod 中如果有个容器因为 Limit 被 kill，系统只会 kill 掉这一个容器并重启之，不会影响其他容器

脚注

环境信息

• Centos7 5.4.212-1
• Docker 20.10.18
• containerd.io-1.6.8
• kubectl-1.25.0
• kubeadm-1.25.0
• kubelet-1.25.0

几乎所有的 Kubernetes 对象都包含两个嵌套的对象字段：

• spec - 对象的期望状态（desired state）的描述信息
• status - 对象当前的状态（current state）

Kubernetes 系统的目标就是不停的调整对象的当前状态（current state）直到和期望状态（desired state）匹配。

常用字段说明

必需字段

在想要创建的 Kubernetes 对象所对应的 .yaml 文件中，必须配置的字段如下：^[1]

• apiVersion - 创建该对象所使用的 Kubernetes API 的版本
• kind - 想要创建的对象的类别
• metadata - 帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace
• spec - 你所期望的该对象的状态

metadata

帮助唯一标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace

集群中的每一个对象都有一个 名称（name）来标识在同类资源中的唯一性。name 也用来作为 url 中的资源名称 ^[2]

每个 Kubernetes 对象也有一个 UID（uid）来标识在整个集群中的唯一性。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels: 
    app: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

标签和选择算符

标签（labels） 是附加到 Kubernetes 对象（比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。^[3]

通过 标签选择算符，客户端/用户可以识别一组对象。标签选择算符 是 Kubernetes 中的核心分组原语。

对于某些 API 类别（例如 ReplicaSet）而言，两个实例的标签选择算符不得在命名空间内重叠， 否则它们的控制器将互相冲突，无法确定应该存在的副本个数。

比较新的资源，例如 Job、 Deployment、 ReplicaSet 和 DaemonSet， 也支持基于集合的需求。

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels 是由 {key,value} 对组成的映射。 matchLabels 映射中的单个 {key,value} 等同于 matchExpressions 的元素， 其 key 字段为 key，operator 为 In，而 values 数组仅包含 value。 matchExpressions 是 Pod 选择算符需求的列表。 有效的运算符包括 In、NotIn、Exists 和 DoesNotExist。 在 In 和 NotIn 的情况下，设置的值必须是非空的。 来自 matchLabels 和 matchExpressions 的所有要求都按 逻辑与 的关系组合到一起 – 它们必须都满足才能匹配。

字段选择器

字段选择器（Field selectors） 允许你根据一个或多个资源字段的值 筛选 Kubernetes 资源

下面是一些使用字段选择器查询的例子：

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

下面这个 kubectl 命令将筛选出 status.phase 字段值为 Running 的所有 Pod：

kubectl get pods --field-selector status.phase=Running

不同的 Kubernetes 资源类型支持不同的字段选择器。 所有资源类型都支持 metadata.name 和 metadata.namespace 字段。 使用不被支持的字段选择器会产生错误

你可在字段选择器中使用 =、== 和 != （= 和 == 的意义是相同的）操作符。 例如，下面这个 kubectl 命令将筛选所有不属于 default 命名空间的 Kubernetes 服务：

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

同标签和其他选择器一样， 字段选择器可以通过使用逗号分隔的列表组成一个选择链。 下面这个 kubectl 命令将筛选 status.phase 字段不等于 Running 同时 spec.restartPolicy 字段等于 Always 的所有 Pod：

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

你能够跨多种资源类型来使用字段选择器。 下面这个 kubectl 命令将筛选出所有不在 default 命名空间中的 StatefulSet 和 Service：

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default

English Word !

环境信息

• Filebeat 8.8

Filebeat 启动之后，会根据配置文件中配置的数据收集路径启动 1 个或者多个 inputs。针对匹配到的每个文件，Filebeat 都会启动一个对应的 harvester，每个 harvester 读取一个单独的文件内容，并将其中的新内容发送到 libbeat，libbeat 会整合数据并将其发送到配置的 output ^[1]

如果 input 类型为 log，input 会负责找到配置中匹配到的文件，并为每个文件启动一个 harvester。每个 input 都运行在自己独立的 Go routine (例程) 中。 ^[4]

Filebeat 工作原理

Filebeat 会将收割(harvest) 的每个文件的状态存储到 registry。因此如果要让 Filebeat 从头开始收集数据，只需要删除 registry 文件即可。可以使用命令 filebeat export config 找到 data 目录，registry 位于其中。

安装

Filebeat 官方安装文档

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.8.2-x86_64.rpm
rpm -vi filebeat-8.8.2-x86_64.rpm

systemctl enable --now filebeat

filebeat command-line interface

filebeat 命令常用功能 ^[3]

和田玉的分类

山料和籽料

按照矿产分类，主要分为籽料与山料两种。

山料，是籽料的前身。

山料

和田玉山料 产自昆仑山脉之中，属于原生矿，被称为 璞玉

从质地上说，有的山料的结构较为粗糙，颗粒比较明显或带石性，不带皮色，油性差，有的山料靠近外部有红糖的颜色。也有结构细密，油润度极好的优质山料。

山料因为没有受到河流的冲刷，自始至终都深藏在岩体中，缺乏外力的打磨，看起来比较干涩，所以外形大多平淡无奇，有棱有角，表面也比较干涩，绺裂现象明显。

籽料

和田玉籽料 是采自河床或者河床泥土中，经过几十万年的侵蚀打磨而得到的玉石。有时又被称为 水籽

籽料是由山料在地质活动时冲刷或滚落到河里，由河水冲刷（还有风化、风干等物理反应一起作用）形成的。籽料产自 河流中下游，是次生矿。产自河流上游的被称为 山流水料。籽料因为长久受到河流的冲刷，一般为卵石形状，表面很光滑圆润，带皮色。

和山料的存在环境不同，导致籽料有了以下特性：

• 籽料常年在河水中浸泡，水流的压力使它的肉质变得更加紧密，水流的冲刷使它变的更加温润油腻，形成了它独特的质地和油润感；
• 河水中存在很多的矿物质和微量元素，长时间的水流冲刷和加压过程中，部分矿物质会沉淀到籽料中，形成各种颜色的籽料皮子。带有皮子的籽料，价格有大大提升

籽料开采出来，外观上看就与鹅卵石一般无二，各个颜色都有，只不过他是和田玉再形成的鹅卵石。仔细观察籽料表面会发现上面密密麻麻都是一些小孔，因为这些小孔跟我们皮肤上的毛孔相似被称之为毛孔或者皮孔。和田玉籽料一般有皮色和皮孔，就算没有皮色，籽料上还是能够找到均匀的毛细孔，这是籽料独有的标志。而山料则没有皮色皮孔。

一般情况下，籽料都会拥有或深或浅的皮色，表面还会有明显的小凹坑（也就是俗称的皮孔），这是玉石长时间在水中冲刷、浸泡和磕碰造成的。而山料由于生长环境固定，不存在皮色和皮孔。

同时，由于籽料长年累月泡在水中，水里的微生物和微量元素会渗入到玉石中，所以会造成局部呈现或黄或红或黑的颜色，也就是 沁色。而这一点在山料身上，就非常不明显。

籽料的水润度是明显高于山料的，如果比较籽料和山料制作的成品，会很容易发现籽料表面质地非常润泽、光滑、细腻。而山料作品，即使经过抛光处理，表面仍会干涩，缺乏光滑的油润感，这一点用手触摸时尤为明显。

由于 和田玉籽料的密度比山料大，所以同等体积的情况下，籽料相对山料比较重

山料也有很多可以跟顶级籽料相媲美的。比如 1995 年于田县开采的 8 吨和田玉山料，白度细度等各个方面都是顶级。因品质极佳，入市后引起了轰动，后被称之位“95于田料”。时至今日，“95于田料” 在业内也是传说中的料子，被很多业内人士公认为 羊脂级。著名的和氏璧就是一块山料。

和田玉器的市场价格中羊脂玉最高、籽料高、山流水次之、山料更次之。

和田玉结构

和田玉籽料内部结构致密，用肉眼几乎看不到内部结构；而再好的山料，还是能看到其松软质地的结构。

籽料由于有外力的挤压、打磨，所以密度要明显高过山料。籽料的话，无论是青籽还是白籽，内部结构都是致密的，用肉眼几乎看不到内部结构。而山料，无论结构多致密，在强光手电筒下，总是能看到松软的质地结构。

广义的籽料

今天的籽料已不是传统意义上的和田籽料了。在广义和田玉的范围内，籽料也有了更多种类。

新疆产的岫玉籽料

新疆除了有和田玉籽料，还出产一种颜色或绿或黑绿色等，里面也有黑点存在的岫玉。岫玉中品质好的，外观与和田玉籽料很相似，并且在市场上的和田籽料中也能看到相当数量的岫玉籽料，大家要留意。

来自俄罗斯的“籽料”

俄罗斯玉，近年来随着和田料的减少而逐渐成为软玉舞台的有力竞争者。

从玉材来看，俄料95%都是山料，但也有籽料，只是俄料中的“籽料”并未达到籽料定义的产状玉料：籽料由于长期的冲刷搬运碰撞，玉质形态韧性都达到了特别的质感，而俄料中的“籽料”其实没有这个长期的过程，严格意义上只能算和田玉的山流水料。

辽宁产的河磨料

河磨料是国内确切命名的两种籽料之一，另一种是和田籽料。“河磨”，从河里磨出来的玉，名字起得很传神，可能因为河水的冲击力较小，河磨料多见厚皮料。

另外，近几年贵州罗甸也出产白度尚可的软玉，透闪石含量达95%，也是广义和田玉中的一种。罗甸玉石性很重，料子干涩，缺乏油性，其实所谓的“籽料”也只能用来骗骗小白玩友；广西大化玉则是这几年才出现的玉种，也是广义和田玉中的一种，大化玉里有籽料，质地也很细腻，有兴趣的宝友可以玩一玩。

环境信息

• Centos-7 3.10.0-1062.9.1
• Docker 19.03.15
• containerd.io-1.4.13
• kubectl-1.25.0
• kubeadm-1.25.0
• kubelet-1.25.0

kubeadm 常用命令

kubeadm 命令官方参考文档

创建集群

kubeadm init --pod-network-cidr=10.244.0.0/16 --cri-socket=unix:///var/run/cri-dockerd.sock

添加节点到集群

kubeadm join 172.31.10.19:6443 --token 8ca35s.butdpihinkdczvqb --discovery-token-ca-cert-hash sha256:b2793f9a6bea44a64640f99042f11c4ff6 \ 
        --cri-socket=unix:///var/run/cri-dockerd.sock

其中的 token 可以在 master 上使用以下命令查看

$ kubeadm token list
TOKEN                     TTL         EXPIRES                USAGES                   DESCRIPTION                                                EXTRA GROUPS
8ca35s.butdpihinkdczvqb   19h         2022-09-14T02:54:55Z   authentication,signing   The default bootstrap token generated by 'kubeadm init'.   system:bootstrappers:kubeadm:default-node-token

默认情况下，令牌会在 24 小时后过期。如果要在当前令牌过期后将节点加入集群， 则可以通过在控制平面节点上运行以下命令来创建新令牌：

kubeadm token create

如果你没有 --discovery-token-ca-cert-hash 的值，则可以通过在控制平面节点上执行以下命令链来获取它^[1]：

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'

filebeat 上传数据到 elasticsearch 问题汇总

filebeat 上传数据到 elasticsearch 报错

适用版本信息说明

• filebeat 7
• elasticsearch 7

filebeat 7.5.2 上传数据到 Elasticsearch 报错：

# journalctl -f -u filebeat
{"type":"illegal_argument_exception","reason":"Validation Failed: 1: this action would add [2] total shards, but this cluster currently has [6924]/[3000] maximum shards open;"}

此错误原因是由于 Elasticsearch 的集群中打开的分片数量超过了集群的最大分片限制。在 Elasticsearch 中，每个索引由多个分片组成，而集群有一个设置的最大分片数限制。这个限制是为了防止分片数过多导致性能问题。

错误消息 {"type":"illegal_argument_exception","reason":"Validation Failed: 1: this action would add [2] total shards, but this cluster currently has [6924]/[3000] maximum shards open;"} 显示当前集群已有 6924 个分片，超过了 3000 个的限制。

要解决这个问题，可以考虑以下几个选项：

1. 调整 Elasticsearch 集群设置，增加最大分片数限制

   可以通过更改 Elasticsearch 配置来增加最大分片数的限制。但请注意，这可能会导致性能问题，尤其是如果硬件资源有限的话。

   这可以通过修改 cluster.max_shards_per_node 设置来实现

   PUT /_cluster/settings { "persistent": { "cluster.max_shards_per_node": "新的分片数限制" } }

   获取 Elasticsearch 集群的最大分片数限制

   curl -X GET "http://[your_elasticsearch_host]:9200/_cluster/settings?include_defaults=true&pretty"

2. 删除一些不必要的索引 :如果有些索引不再需要，可以删除它们来减少分片数。

   curl -X DELETE "localhost:9200/my_index" curl -X DELETE "localhost:9200/logstash-2021.11.*"

3. 合并一些小索引：如果有很多小的索引，可以考虑将它们合并为更大的索引，以减少总分片数。

4. 优化现有索引的分片策略：可以优化索引的分片数量，例如，通过减少每个索引的主分片数量。

filebeat 错误

filebeat 配置上传数据到 elasticsearch 报错

适用版本信息说明

• filebeat 7
• elasticsearch 7

使用以下 filebeat 配置文件

filebeat.inputs:
- type: log
  paths:
    - /home/logs/laravel-2023*
  tags: ["admin-log"]
  close_timeout: 3h
  clean_inactive: 72h
  ignore_older: 70h
  close_inactive: 5m

output.elasticsearch:
  hosts: ["1.56.219.122:9200", "1.57.115.214:9200", "1.52.53.31:9200"]
  username: "elastic"
  password: "passwd"
  index: "logstash-admin-%{+yyyy.MM.dd}"
setup.template.enabled: true
setup.template.name: "logstash-admin"
setup.template.pattern: "logstash-admin-*"

filebeat 启动后报错，elasticsearch 上未创建相应的索引，关键错误信息 Failed to connect to backoff(elasticsearch(http://1.57.115.214:9200)): Connection marked as failed because the onConnect callback failed: resource 'filebeat-7.5.2' exists, but it is not an alias

journalctl -f -u filebeat
INFO        [index-management]        idxmgmt/std.go:269        ILM policy successfully loaded.
ERROR        pipeline/output.go:100        Failed to connect to backoff(elasticsearch(http://1.57.115.214:9200)): Connection marked as failed because the onConnect callback failed: resource 'filebeat-7.5.2' exists, but it is not an alias
INFO        pipeline/output.go:93        Attempting to reconnect to backoff(elasticsearch(http://1.57.115.214:9200)) with 3 reconnect attempt(s)
INFO        elasticsearch/client.go:753        Attempting to connect to Elasticsearch version 7.6.2
INFO        [index-management]        idxmgmt/std.go:256        Auto ILM enable success.
INFO        [index-management.ilm]        ilm/std.go:138        do not generate ilm policy: exists=true, overwrite=false
INFO        [index-management]        idxmgmt/std.go:269        ILM policy successfully loaded.
ERROR        pipeline/output.go:100        Failed to connect to backoff(elasticsearch(http://1.56.219.122:9200)): Connection marked as failed because the onConnect callback failed: resource 'filebeat-7.5.2' exists, but it is not an alias
INFO        pipeline/output.go:93        Attempting to reconnect to backoff(elasticsearch(http://1.56.219.122:9200)) with 3 reconnect attempt(s)

这表明 Filebeat 无法正常连接到 Elasticsearch 集群。出现这个问题的主要原因可能为：

• 索引/别名冲突: Filebeat 试图创建或使用一个名为 filebeat-7.5.2 的索引或别名，但这个资源在 Elasticsearch 中已存在且不是一个别名。解决方法为 删除或重命名冲突索引

• ILM 配置问题

  使用此配置文件，解决 索引/别名冲突 问题后，filebeat 运行正常，但是 Elasticsearch 上未创建配置中的索引 logstash-admin-*，而是将数据上传到了索引 filebeat-7.5.2-*。这个问题是由 ILM 导致，可以禁用 ILM。参考以下配置，禁用 ILM (setup.ilm.enabled: false)

  filebeat.inputs: - type: log paths: - /home/logs/laravel-2023* tags: ["admin-log"] close_timeout: 3h clean_inactive: 72h ignore_older: 70h close_inactive: 5m output.elasticsearch: hosts: ["1.56.219.122:9200", "1.57.115.214:9200", "1.52.53.31:9200"] username: "elastic" password: "passwd" index: "logstash-admin-%{+yyyy.MM.dd}" setup.ilm.enabled: false setup.template.enabled: true setup.template.name: "logstash-admin" setup.template.pattern: "logstash-admin-*"

环境信息

• Centos 7 3.10.0-1062

curl 命令示例

常见选项

Dockerfile 是一个文本文件，其内包含了一条条的 指令(Instruction)，每一条指令构建一层，因此每一条指令的内容，就是描述该层应当如何构建。

nc

安装

Centos 下安装

yum install -y nc

Windows 下安装

Windows 下需要 下载 netcat 运行程序

下载后直接解压，将 nc.exe 复制到 C:\Windows\System32 目录或将 nc.exe 添加到系统 path 环境变量中

使用示例

注意事项：客户端测试使用 localhost 作为主机名时，会优先被解析为 IPv6 地址，如果端口监听在 IPv4 地址，会导致测试结果不可达

测试 udp 端口连通性

以下输出表示端口可达

# nc -vuz ip/domain 8472
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to ip:8472.
Ncat: UDP packet sent successfully
Ncat: 1 bytes sent, 0 bytes received in 2.01 seconds.

以下输出表示端口不可达

# nc -vuz 127.0.0.1 8473
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 127.0.0.1:8473.
Ncat: Connection refused.

版本信息

• Centos 7
• Kubernetes 1.24
• Prometheus 2.44.0
• AlertManager 0.24.0

Prometheus 部署步骤

为 Prometheus 创建专用的 Namespace，此处创建 prometheus

kubectl create namespace prometheus

创建集群角色

Prometheus 使用 Kubernetes API 从 Nodes、Pods、Deployments 等等中读取所有可用的指标。因此，我们需要创建一个包含读取所需 API 组的 RBAC 策略，并将该策略绑定到新建的 prometheus 命名空间。^[1]

1. 创建一个名为 prometheusClusterRole.yaml的文件，并复制以下 RBAC 角色。

   在下面给出的角色中，可以看到，我们已经往 nodes, services endpoints, pods 和 ingresses 中添加了 get，list 以及 watch 权限。角色绑定被绑定到监控命名空间。如果有任何要从其他对象中检索指标的用例，则需要将其添加到此集群角色中。

   apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prometheus rules: - apiGroups: [""] resources: - nodes - nodes/proxy - nodes/metrics - services - endpoints - pods verbs: ["get", "list", "watch"] - apiGroups: - extensions resources: - ingresses verbs: ["get", "list", "watch"] - nonResourceURLs: ["/metrics"] verbs: ["get"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prometheus roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prometheus subjects: - kind: ServiceAccount name: default namespace: prometheus

2. 使用下面的命令创建角色

   kubectl apply -f prometheusClusterRole.yaml

要将 Python 脚本打包为 Windows 可运行程序，一种常用的方法是使用 PyInstaller。

安装 PyInstaller

pip install pyinstaller

打包

在命令行中，导航到脚本所在的文件夹并运行以下命令

pyinstaller --onefile test_file.py

这会生成一个 dist 目录，里面包含一个名为 test_file.exe 的可执行文件。参数 --onefile 确保所有必要的文件都被包含在单一的可执行文件中。

以上方法打包后的文件点击运行后，桌面会弹窗一个 cmd 窗口，如果关闭了此 cmd 窗口，与其关联的程序也会被关闭。为了阻止这个命令行窗口的出现，并让程序在关闭窗口后仍然运行，你需要在使用 PyInstaller 打包时使用 --noconsole 选项。此外，为了使程序在没有任何可视窗口的情况下静默运行（例如，仅在系统托盘中），你还需要使用 --windowed 选项。

pyinstaller --onefile --noconsole --windowed test_file.py

如果你想要程序在系统托盘中静默运行，并通过系统托盘图标进行交互，那么你需要使用其他库，如 pystray，来创建系统托盘应用。

环境信息

• centos7 3.10.0
• kubernetes Server Version: v1.21.2
• Helm 3.10.0
• Rancher 2.6

安装

官方安装文档

安装 Helm

安装文档官网参考

安装 Ingress-nginx-controller

安装文档官网参考

添加 Helm Chart 仓库

添加最新版本，生产环境建议使用稳定版本

helm repo add rancher-latest https://releases.rancher.com/server-charts/latest

为 Rancher 创建命名空间

你需要定义一个 Kubernetes 命名空间，用于安装由 Chart 创建的资源。这个命名空间的名称为 cattle-system：

kubectl create namespace cattle-system

安装 cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.7.1/cert-manager.crds.yaml

# 添加 Jetstack Helm 仓库
helm repo add jetstack https://charts.jetstack.io

# 更新本地 Helm Chart 仓库缓存
helm repo update

# 安装 cert-manager Helm Chart
helm install cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --create-namespace \
  --version v1.7.1

安装完 cert-manager 后，你可以通过检查 cert-manager 命名空间中正在运行的 Pod 来验证它是否已正确部署：

$ kubectl get pods -n cert-manager
NAME                                      READY   STATUS    RESTARTS   AGE
cert-manager-5b97785fbd-vvscn             1/1     Running   0          77s
cert-manager-cainjector-c8657d84f-6b8qr   1/1     Running   0          77s
cert-manager-webhook-8564679744-hjgkx     1/1     Running   0          77s

通过 Helm 安装 Rancher

helm install rancher rancher-stable/rancher --namespace cattle-system \
     --set hostname=rancher.my.com --set bootstrapPassword=admin \
     --set ingress.ingressClassName=nginx

安装成功后，输出结果如下

NAME: rancher
LAST DEPLOYED: Wed Oct 12 10:22:25 2022
NAMESPACE: cattle-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Rancher Server has been installed.

NOTE: Rancher may take several minutes to fully initialize. Please standby while Certificates are being issued, Containers are started and the Ingress rule comes up.

Check out our docs at https://rancher.com/docs/

If you provided your own bootstrap password during installation, browse to https://rancher.my.com to get started.

If this is the first time you installed Rancher, get started by running this command and clicking the URL it generates:

```
echo https://rancher.my.com/dashboard/?setup=$(kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}')
```

To get just the bootstrap password on its own, run:

```
kubectl get secret --namespace cattle-system bootstrap-secret -o go-template='{{.data.bootstrapPassword|base64decode}}{{ "\n" }}'
```


Happy Containering!

根据提示，浏览器中访问 https://rancher.my.com/dashboard/?setup=admin，正常情况下，显示如下页面

根据页面提示，保持密码，登陆。

blackbox_exporter 是一个由 Prometheus 社区维护的项目，它允许用户通过 HTTP、HTTPS、DNS、TCP 和 ICMP 协议对服务进行“黑盒”方式的探测，以检测和监控网络协议的可用性和响应时间。

本文档以在 Kubernetes 中部署 blackbox_exporter 为例，演示其使用方法。

为了能够监控到 Kubernetes 集群内部的部分信息（如 api-server 的证书等），建议 参考文档为其配置 RBAC 策略 以使其能读取 kube-apiserver 相关资源，本文档中的配置示例基于此权限配置。Namespace 为 prometheus

Kubernetes 中部署 blackbox_export

创建 ConfigMap 以外部化 blackbox_export 配置

blackbox_export 基于配置文件运行，将其配置文件通过 Kubernetes 的 ConfiMap 存储，分离运行环境和配置，方便管理。

参考以下配置，创建 ConfigMap

apiVersion: v1
data:
  blackbox.yml: |-
    modules:
      http_2xx:
        prober: http
        timeout: 10s
        http:
          preferred_ip_protocol: "ip4" ##如果http监测是使用ipv4 ,需要配置。默认使用 IPv6
      tcp_connect:
        prober: tcp
kind: ConfigMap
metadata:
  name: blackbox-export-config
  namespace: prometheus

部署 blackbox_export

参考以下内容，创建 Deployment 和 Service，在此配置中，使用上面创建的 ConfigMap 作为 blackbox_export 的配置文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus-blackbox-export
  namespace: prometheus
  labels:
    app: prometheus-blackbox-export
spec:
  replicas: 1
  selector:
    matchLabels:
      app: prometheus-blackbox-export
  template:
    metadata:
      labels:
        app: prometheus-blackbox-export
    spec:
      containers:
        - name: prometheus-blackbox-export
          image: bitnami/blackbox-exporter
          args:
            - "--config.file=/etc/blackbox/blackbox.yml"
          ports:
            - containerPort: 9115
          resources:
            requests:
              cpu: 500m
              memory: 500M
            limits:
              cpu: 1
              memory: 1Gi
          volumeMounts:
            - name: blackbox-config-volume
              mountPath: /etc/blackbox/
      volumes:
        - name: blackbox-config-volume
          configMap:
            defaultMode: 420
            name: blackbox-export-config
---
apiVersion: v1
kind: Service
metadata:
  name: blackbox-service
  namespace: prometheus
spec:
  ports:
    - name: blackbox-port
      port: 9115
      protocol: TCP
      targetPort: 9115
  selector:
    app: prometheus-blackbox-export            

部署成功后，从 prometheus 的 Namespace 中测试访问 blackbox_export 的 Endpoint blackbox-service:9115，如果是在其他 Namespace，可以使用 Endpoint blackbox-service.prometheus.svc.cluster.local:9115。如果集群的域名不是 cluster.local，修改为实际值。

prometheus-7589d5bbdd-xdjwt:~# curl -v blackbox-service:9115
*   Trying 10.111.137.0:9115...
* Connected to blackbox-service (10.111.137.0) port 9115 (#0)
> GET / HTTP/1.1
> Host: blackbox-service:9115
> User-Agent: curl/8.0.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html
< Date: Tue, 26 Sep 2023 09:11:25 GMT
< Content-Length: 544
< 
<html>
    <head><title>Blackbox Exporter</title></head>
    <body>
    <h1>Blackbox Exporter</h1>
    <p><a href="probe?target=prometheus.io&module=http_2xx">Probe prometheus.io for http_2xx</a></p>
    <p><a href="probe?target=prometheus.io&module=http_2xx&debug=true">Debug probe prometheus.io for http_2xx</a></p>
    <p><a href="metrics">Metrics</a></p>
    <p><a href="config">Configuration</a></p>
    <h2>Recent Probes</h2>
    <table border='1'><tr><th>Module</th><th>Target</th><th>Result</th><th>Debug</th></table></body>
* Connection #0 to host blackbox-service left intact
    </html>

Prometheus 读取 blackbox_exporter 数据

在 Prometheus 配置中添加以下内容，使 Prometheus 抓取 black_exporter 的监控数据

- job_name: 'blackbox_http_2xx'
    scrape_interval: 60s
    metrics_path: /probe
    params:
      module: [http_2xx]  # Look for a HTTP 200 response.
    static_configs:
        - targets:
          - http://www.google.com:5000/
    relabel_configs:
        - source_labels: [__address__]
          target_label: __param_target
        - source_labels: [__param_target]
          target_label: instance
        - target_label: __address__
          replacement: blackbox-service.prometheus.svc.cluster.local:9115

部署完成后，观察过 Prometheus 的 Target，正常情况下可以看到监控目标的状态。

在 SUSE Linux（无论是 openSUSE 还是 SUSE Linux Enterprise Server）中，可以使用 zypper 命令行工具来管理和安装软件包。

更新软件包数据库

在安装任何新的软件包之前，建议首先更新你的软件包数据库，以确保你拥有最新的软件包信息。

sudo zypper refresh

搜索软件包

如果你不确定软件包的确切名称，可以使用 zypper search 来查找它

zypper search <package-name>

安装软件包

sudo zypper install <package-name>

查询软件包信息

要查看关于特定软件包的详细信息，包括描述、版本和依赖关系等，可以使用

zypper info <package-name>

卸载软件包

sudo zypper remove <package-name>

升级系统

要升级所有已安装的软件包到其最新版本，可以使用以下命令

sudo zypper update

常用软件包安装

以下示例安装常用工具包

• net-tools，提供 netstat 命令
• iproute2 提供 ip、ss 等命令
• iputils 提供 ping 命令

  sudo zypper refresh sudo zypper install net-tools zypper install iproute2 sudo zypper install iputils

环境信息

• Python 3.10
• huaweicloudsdk 3.1.23

常用方法

华为云 Python SDK 安装方法官网说明

ECS

获取云服务器 (ECS) 实例信息

通过华为云提供的 Python SDK 获取云服务器实例信息 ^[1]

>>> from huaweicloudsdkcore.auth.credentials import BasicCredentials
>>> from huaweicloudsdkecs.v2.region.ecs_region import EcsRegion
>>> from huaweicloudsdkcore.exceptions import exceptions
>>> from huaweicloudsdkecs.v2 import *

>>> ak = 'QONOKCeljdngdsEGSAM'
>>> sk = 'uD4ndlLqP5xDGSrgRRRPJGF8hg^HGkGl2'

>>> credentials = BasicCredentials(ak, sk)

>>> client = EcsClient.new_builder().with_credentials(credentials).with_region(EcsRegion.value_of("cn-east-2")).build()

>>> request = ListServersDetailsRequest()
>>> response = client.list_servers_details(request)

response 返回一个 huaweicloudsdkecs.v2.model.list_servers_details_response.ListServersDetailsResponse 对象，其中包含了服务器数量和服务器详情列表，要转换为 Python 字典对象，可以通过以下方法

>>> import json

>>> server_info = json.loads(str(response))

>>> type(server_info)
<class 'dict'>

### 获取查询出的机器数量
>>> server_info['count']
2

### 云服务器列表 list[dict]
>>> server_info['servers']

### 获取云服务器的名称及 id
>>> server_info['servers'][0]['name']
>>> server_info['servers'][0]['id']

### 获取云服务器的配置规格信息
>>> server_info['servers'][0]['flavor']
{'id': 'c3.xlarge.2', 'name': 'c3.xlarge.2', 'disk': '0', 'vcpus': '4', 'ram': '8192'}

### 获取云服务器挂载的磁盘id
>>> server_info['servers'][0]['os-extended-volumes:volumes_attached']
[{'id': '1fd566f2-82bb-49d3-95d1-7452a5868f80', 'delete_on_termination': 'false', 'device': '/dev/vdb'}, {'id': '2deefa5c-e92b-4ec5-9914-10af9919c121', 'delete_on_termination': 'false', 'bootIndex': '0', 'device': '/dev/vda'}]

### 获取云服务器 IP 信息
### 首先在 'metadata' 中获取云服务器的 VPC id 信息，根据 VPC id 获取对应的 ip 信息
>>> server_info['servers'][0]['metadata']
{'lockScene': '', 'charging_mode': '1', 'vpc_id': '6827d6f5-4614-42a5-9762-15d3d173411c', 'metering.product_id': '00301-15033-0--0', 'lockSource': '', 'lockSourceId': '', 'metering.imagetype': 'gold', 'metering.order_id': 'CS23010203413KRGB', 'image_name': 'Windows Server 2016 Standard 64bit', 'metering.resourcespeccode': 'c3.xlarge.2.win', 'os_type': 'Windows', 'metering.resourcetype': '1', 'metering.image_id': 'dd714f2c-f470-43b6-afc8-34d8ec689516', 'os_bit': '64', 'EcmResStatus': '', 'lockCheckEndpoint': '', 'cascaded.instance_extrainfo': 'clock_adjustment:28800,pcibridge:1'}

>>> server_info['servers'][0]['metadata']['vpc_id']
'6827d6f5-4614-42a5-9762-15d3d173411c'

### 其中 {'OS-EXT-IPS:type': 'floating'} 表示公网 IP
>>> server_info['servers'][0]['addresses']['6827d6f5-4614-42a5-9762-15d3d173411c']
[{'version': '4', 'addr': '192.168.0.65', 'OS-EXT-IPS:type': 'fixed', 'OS-EXT-IPS-MAC:mac_addr': 'fa:16:3e:00:76:2a', 'OS-EXT-IPS:port_id': 'c1ec2783-6d3c-4d8a-9c55-abb59c2c648d'}, {'version': '4', 'addr': '159.138.38.203', 'OS-EXT-IPS:type': 'floating', 'OS-EXT-IPS-MAC:mac_addr': 'fa:16:3e:00:76:2a', 'OS-EXT-IPS:port_id': 'c1ec2783-6d3c-4d8a-9c55-abb59c2c648d'}]

根据云服务器 id，查询云服务器挂载的磁盘信息 ^[2]

>>> request = ListServerBlockDevicesRequest(server_id='a7dd4502-cb3e-4754-b7b7-73bcb5696a1c')

>>> response = client.list_server_block_devices(request)

>>> response
{"attachableQuantity": {"free_scsi": 58, "free_blk": 22, "free_disk": 58}, \
 "volumeAttachments": [{"bootIndex": 0, "pciAddress": "0000:02:01.0", "volumeId": "2deefa5c-e92b-4ec5-9914-10af9919c121", "device": "/dev/vda", "serverId": "a7dd4502-cb3e-4754-b7b7-73bcb5696a1c", \
                        "id": "2deefa5c-e92b-4ec5-9914-10af9919c121", "size": 100, "bus": "virtio"}, \
                        {"pciAddress": "0000:02:02.0", "volumeId": "1fd566f2-82bb-49d3-95d1-7452a5868f80", \
                        "device": "/dev/vdb", "serverId": "a7dd4502-cb3e-4754-b7b7-73bcb5696a1c", "id": "1fd566f2-82bb-49d3-95d1-7452a5868f80", "size": 100, "bus": "virtio"}]}

Akamai CDN API 说明文档，调用 API 之前需要先根据官方文档说明 Create API Client

Python SDK 使用

根据官方文档说明安装 edgegrid-python，并配置 Create API Client Key 信息 ^[1]。

pip install edgegrid-python

Python SDK 使用官方示例

Akamai API 列表

获取账号信息

大多数 API 使用都需要提供 groupId，accountId，contractIds，通过以下接口获取这些信息 ^[2]

>>> import requests
>>> from akamai.edgegrid import EdgeGridAuth, EdgeRc
>>> from urllib.parse import urljoin

>>> edgerc = EdgeRc('~/.edgerc')
>>> section = 'default'
>>> baseurl = 'https://%s' % edgerc.get(section, 'host')

>>> s = requests.Session()
>>> s.auth = EdgeGridAuth.from_edgerc(edgerc, section)

>>> result = s.get(urljoin(baseurl, '/papi/v1/groups'))

>>> result.json()
{'accountId': 'act_F-AC-488298736', 'accountName': 'Guangzhou kl Network Technology Co., Ltd', 'groups': {'items': [{'groupName': 'Guangzhou extreme-G-8HGkt-DSA', 'groupId': 'grp_186987767', 'contractIds': ['ctr_G-3JDoujhh']}]}}

如果 Property 中存在分组，每个分组都有一个独立的 groupId