分词操作个人理解就是在做一个表来记录term和id的关系，可能会再存储一大段信息的时候会出现一定时间的延迟创建。

优化，先按字典序排序通过二分查找来找到词项。

Term dictionary过大所以不可能会放在内存里面，但是放在磁盘里面，搜索过程又会很慢。

优化

每一个词项会有相似的地方，那么把这些相似的地方拎出来进行复用，然后就能构建出一个目录树的结构，进行偏移量的辅助指向后续拼接的term。感觉有一点像计算机的存储方式结构。

term index（上面优化出来的目录树结构就是index）

通过index能够找到term的大概位置，通过少量的检索找到target.

Stored Fields

存放完整文档内容，行式存储结构

Doc Values

空间换时间，把形同的字段归纳在一起，列式存储结构。

segment

具备完整搜索功能的最小单元

Lucene

• 因为segment结构特殊，若是有数据写入，则需要刷新整个segment架构的所有信息。这样读取和写入若是并行的话，性能会大量降低。因此为了规避这个风险，所以不允许新的信息写入segment，所以只能生成新的segment，那么问题就来了，我怎么知道我要取的信息在哪个Segment里面呢。
• 为了解决上面的问题，所以需要程序进行并发读取，但是随着数据量过大，并发读取的任务就会变得很重。导致文件句柄耗尽。
• 为了解决句柄消耗严重的问题引出了段合并，segment merging，这个功能就是解决了segment过多的问题，是用来把小一点的segment合并成一个大的segment。和前面的不允许新的信息写入是不冲突的。

到这里都还没有解释到lucene，综合上面多个segment组成的一个单机文本检索库，这个就是一个有名的开源基础搜索库Lucene

Lucene高性能

其实和kafka的原理基本都是一样的，为了用多用户并发读取，所以就回用topic来继续区分，在Lucene中我们叫index name，继续topic里面可能存在的问题，所以会把这个topic区分片，形成partition，我们这里叫作shard。其实每一个shard就是一个独立Lucene库。

Lucene高扩展

• 为了避免多个分片shard过多导致性能过高，存在宕机隐患。我们可以把它们不定的shard放在不同的node里面，来防止性能过高。

Lucene高可用

• 为了避免node换了，到时分片shard不能服务，保证高可用，添加副本，分词主分片和负分片，主分片会同步到副分片，副本分片不仅能够提供读操作也能够保证主分片挂了时候顶上

node分化

• 为了避免某个集群压力过大，若是每个node都需要集群管理，存储数据，和处理请求的功能，这会导致node的压力还是会变大。所以会进行角色分化的一个操作，每一个node负责不一样的功能。

去中心化

总图 这就是ES

写入流程

搜索流程

查询阶段

搜索内容：跳过。

转发：是通过index name了解信息在哪个分片和哪个node上面，让后Lucene会并发搜索segment来获取倒排索引的文档id和docvalues获取排序信息。

返回：聚合返回协调节点，然后排序聚合。

获取阶段

找寻分片：通过文档id，在Stored Fields获取完整文档，然后返回给协调节点，然后返回给客户。

实践策划

1. 目标设定：
   • 在Kubernetes中使用ConfigMap和Secret存储重要的配置数据和敏感信息。
   • 将这些数据以卷的形式挂载到Pod中，使其在容器内可用。
   • 通过实际操作掌握如何管理和使用ConfigMap和Secret，并了解它们的权限控制和安全性。
   • 验证在容器内的读取和修改操作，以及了解ConfigMap和Secret的更新机制对Pod的影响。
2. 内容规划：
   • 创建ConfigMap和Secret资源。
   • 使用ConfigMap和Secret挂载卷到Pod中。
   • 验证挂载成功以及在容器内读取数据。
   • 测试ConfigMap和Secret的更新机制。
   • 讨论ConfigMap和Secret的最佳实践与安全管理。

创建命名空间

kubectl create namespace config-secret-practice

创建ConfigMap

apiVersion: v1                # 指定Kubernetes API版本为v1
kind: ConfigMap               # 定义资源类型为ConfigMap
metadata:
  name: app-config            # ConfigMap的名称
  namespace: config-secret-practice  # ConfigMap所在的命名空间
data:
  config.json: |              # 使用多行文本格式存储名为config.json的配置信息
    {
      "setting1": "value1",   # JSON格式的配置，包含多个键值对
      "setting2": "value2",
      "setting3": "value3"
    }
  database_url: "mongodb://mongo-svc:27017"  # 另一个键值对，存储数据库URL

创建Secret

apiVersion: v1                # 指定Kubernetes API版本为v1
kind: Secret                  # 定义资源类型为Secret
metadata:
  name: db-secret             # Secret的名称
  namespace: config-secret-practice  # Secret所在的命名空间
type: Opaque                  # Secret的类型为Opaque，用于存储任意二进制数据或字符串
data:
  db-password: bXlwYXNzd29yZA==  # Base64编码的敏感信息，这里是数据库密码'mypassword'的编码形式

创建deploy

apiVersion: apps/v1           # 定义API版本为apps/v1，这是Deployment的API组
kind: Deployment              # 资源类型为Deployment
metadata:
  name: app-deployment        # Deployment的名称
  namespace: config-secret-practice  # Deployment所在的命名空间
spec:
  replicas: 2                 # 定义Pod副本的数量，设为2个
  selector:
    matchLabels:              # 用于选择标签匹配的Pod
      app: my-app             # 这里定义标签app=my-app
  template:
    metadata:
      labels:
        app: my-app           # Pod模板的标签，与selector中的标签匹配
    spec:
      containers:
      - name: my-app-container # 容器名称
        image: docker.m.daocloud.io/library/busybox # 容器使用的镜像，这里是busybox适合进行简单的命令执行
        command: ["/bin/sh", "-c", "while true; do sleep 3600; done"] # 让容器保持运行，方便测试
        volumeMounts:          # 定义容器内的卷挂载
        - name: config-volume  # ConfigMap卷挂载的名称
          mountPath: /etc/config  # 挂载路径，容器内的文件系统路径
        - name: secret-volume  # Secret卷挂载的名称
          mountPath: /etc/secret  # 挂载路径，容器内的文件系统路径
        env:
        - name: DB_PASSWORD    # 定义一个环境变量
          valueFrom:
            secretKeyRef:      # 从Secret引用获取值
              name: db-secret  # Secret名称
              key: db-password # Secret中的键，指向数据库密码
      volumes:
      - name: config-volume    # 定义一个卷，来源于ConfigMap
        configMap:
          name: app-config     # 关联的ConfigMap的名称
      - name: secret-volume    # 定义一个卷，来源于Secret
        secret:
          secretName: db-secret # 关联的Secret的名称

验证卷挂载

查看环境变量

修改configmap测试是否实时更新

更新secret:

echo -n 'newpassword' | base64   # 使用echo命令和base64编码工具对新密码进行编码
kubectl apply -f db-secret.yaml  # 重新应用Secret，以测试其在Pod中的更新

这里为什么没有被修改到,因为secret作为环境变量时候需要重新启动pod

启动自动滚动更新

我们在deploy选项下面添加serect的optinal为true

apply后直接

kubectl rollout status deployment/app-deployment -n config-secret-practice

使用RBAC,限制对ConfigMap和Secret的访问

kubectl create serviceaccount app-user -n config-secret-practice

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: config-secret-practice
  name: config-secret-role
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  resourceNames: ["app-config", "db-secret"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: config-secret-rolebinding
  namespace: config-secret-practice
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: config-secret-role
subjects:
- kind: ServiceAccount
  name: app-user
  namespace: config-secret-practice

kubectl auth can-i get configmap/app-config --as=system:serviceaccount:config-secret-practice:app-user -n config-secret-practice

使用一个带有serviceAccount的pod验证

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: config-secret-practice
spec:
  serviceAccountName: app-user  # 指定使用的ServiceAccount
  containers:
  - name: test-container
    image: docker.m.daocloud.io/library/busybox
    command: ["/bin/sh", "-c", "sleep 3600"]  # 让容器保持运行

• 添加干净的空磁盘

手动添盘

1. 编写ldc

   cat <<\EOF > ldc.yaml apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskClaim metadata: name: hostname-ld-name spec: nodeName: g-master # 获取节点名字。 owner: local-storage description: localDiskNames: - localdisk-0cfade4286bfce385512af7244265e0d # kubectl get ld 获取绑定的ld名字 EOF

   或

   # 获取所有可用磁盘信息 AVAILABLE_DISKS=$(kubectl get ld -o wide | grep Available | awk '{print $1}') # 定义节点名称 NODE_NAME="g-master" # 遍历每一个可用磁盘，生成对应的ldc.yaml文件 for DISK_NAME in $AVAILABLE_DISKS; do # 提取磁盘ID DISK_ID=$(echo $DISK_NAME | cut -d'-' -f2) # 替换模板并生成对应的ldc.yaml cat <<EOF > ldc-$DISK_ID.yaml apiVersion: hwameistor.io/v1alpha1 kind: LocalDiskClaim metadata: name: ${NODE_NAME}-ld-$DISK_ID spec: nodeName: $NODE_NAME owner: local-storage description: localDiskNames: - $DISK_NAME EOF echo "Generated ldc-$DISK_ID.yaml for disk: $DISK_NAME" done

2. 应用

应用ldc.yamlkubectl apply -f ldc.yaml

3. 查询磁盘状态

kubectl get ld

4. 查询ldc状态

kubectl get ldc

5. 一般能看到有ldc的话都是没有成功的，基本上都是在pending

6. 修改对应的localdisk是否处于保留政策

# 获取处于 pending 状态的 LDC 名称
PENDING_LDC=$(kubectl get ldc --no-headers | awk '$3=="Pending" {print $1}')

# 遍历每一个处于 pending 状态的 LDC
for LDC in $PENDING_LDC; do
  echo "Checking LDC: $LDC"

  # 获取对应的 LD 名称
  LD_NAME=$(kubectl get ldc $LDC -o jsonpath='{.spec.description.localDiskNames[0]}')

  # 检查 LD 的 reserved 字段状态
  RESERVED_STATUS=$(kubectl get ld $LD_NAME -o jsonpath='{.spec.reserved}')

  # 如果 reserved 为 true，则修改为 false
  if [ "$RESERVED_STATUS" == "true" ]; then
    echo "Modifying reserved status of LD: $LD_NAME from true to false"
    
    # 修改 reserved 字段为 false
    kubectl patch ld $LD_NAME --type=json -p='[{"op": "replace", "path": "/spec/reserved", "value": false}]'
    
    echo "LD $LD_NAME reserved status set to false."
  else
    echo "LD $LD_NAME reserved status is already false."
  fi
done

在资源紧缺或者无法添盘操作时候，可以进行清盘

# 查看清理盘的设备信息,看不需要哪个目录
mount | grep xxxx
# 查看清理设备的具体信息UUID，LABEL
blkid
# 编辑fstab，解除挂载
vim /etc/fstab
# 重新挂载，进行解除
mount -a
# 检查挂载情况
mount | grep /mnt/data
# 移除所有对应设备的lv和vg,pv
lvremove xxxxx
vgremove xxxx
# 查看分区，解除分区
fdisk xxxx(d,w)
pvremove xxxxx
blkid | grep xxxx
# 擦除设备签名
wipefs -a xxxxx
# 解除挂载
mount -a
# 检查hwameistor资源
kubectl api-resources | grep hwamei
# 查看hwameistor存储节点状态
kubectl get lsn
# 查看sc
kubectl get sc

1. 创建一个命名空间

首先，我们可以创建一个专门用于Prometheus的命名空间，以便管理和隔离资源。

kubectl create namespace monitoring

2. 配置Prometheus的ConfigMap

为了配置Prometheus的抓取目标（scrape targets），我们需要创建一个ConfigMap，用于存储prometheus.yml配置文件。

apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s

    scrape_configs:
      - job_name: 'kubernetes-nodes'
        kubernetes_sd_configs:
          - role: node
        scheme: https
        tls_config:
          ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
          insecure_skip_verify: false
        bearer_token_file: /var/run/secrets/kubernetes.io/serviceaccount/token
        relabel_configs:
          - action: labelmap
            regex: __meta_kubernetes_node_label_(.+)
          - target_label: __address__
            replacement: kubernetes.default.svc:443
          - source_labels: [__meta_kubernetes_node_name]
            regex: (.+)
            target_label: __metrics_path__
            replacement: /api/v1/nodes/${1}/proxy/metrics

      - job_name: 'kubernetes-pods'
        kubernetes_sd_configs:
          - role: pod
        relabel_configs:
          - action: labelmap
            regex: __meta_kubernetes_pod_label_(.+)
          - action: replace
            source_labels: [__meta_kubernetes_namespace]
            target_label: kubernetes_namespace
          - action: replace
            source_labels: [__meta_kubernetes_pod_name]
            target_label: kubernetes_pod_name

将上述配置保存为prometheus-config.yaml文件，并应用它：

kubectl apply -f prometheus-config.yaml

3. 创建Prometheus Pod和Service

接下来，创建一个Pod来运行Prometheus，并通过NodePort暴露它的服务。

apiVersion: v1
kind: Pod
metadata:
  name: prometheus-pod
  namespace: monitoring
  labels:
    app: prometheus
spec:
  containers:
  - name: prometheus
    image: quay.io/prometheus/prometheus:v2.44.0
    args:
      - --config.file=/etc/prometheus/prometheus.yml
      - --storage.tsdb.path=/prometheus/
    ports:
      - containerPort: 9090
    volumeMounts:
      - name: prometheus-config-volume
        mountPath: /etc/prometheus/
      - name: prometheus-data-volume
        mountPath: /prometheus/
  volumes:
    - name: prometheus-config-volume
      configMap:
        name: prometheus-config
    - name: prometheus-data-volume
      emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus-service
  namespace: monitoring
spec:
  type: NodePort
  ports:
    - port: 9090
      targetPort: 9090
      nodePort: 30000
  selector:
    app: prometheus

将上述配置保存为prometheus-pod-service.yaml文件，并应用它：

kubectl apply -f prometheus-pod-service.yaml

4. 设置适当的权限

确保Prometheus有足够的权限访问Kubernetes API。创建一个ClusterRole和ClusterRoleBinding。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus
rules:
- apiGroups: [""]
  resources:
  - nodes
  - nodes/proxy
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups:
  - extensions
  - apps
  resources:
  - deployments
  verbs: ["get", "list", "watch"]

---
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: monitoring

将上述配置保存为prometheus-rbac.yaml文件，并应用它：

kubectl apply -f prometheus-rbac.yaml

5. 访问Prometheus

你现在可以通过NodePort访问Prometheus的Web界面。假设你的集群中的节点IP为<Node-IP>，你可以通过以下URL访问Prometheus：

http://<Node-IP>:30000

6. 验证抓取目标

访问Prometheus Web界面后，在“Status” -> “Targets”页面查看Prometheus是否正确发现并抓取了Kubernetes节点和Pod的监控数据。

• 需要提前把前提步骤完成，可以参考集群创建前置
• 把每个节点进行kubelet,kubeadm,containerd以及一些环境配置好即可，先不需要进行初始化
• 可以通过克隆加快速度，3master/3work/3etcd模式，资源消耗可能有点多。

创建高可用的ETCD外部集群

节点准备

• 按照之前，可以把所有环境都准备好备用。
• 然后保持系统时钟同步

使用chrony进行同步

# 每台ETCD节点安装chrony
apt update && apt install chrony

# 修改 /etc/chrony/chrony.conf,添加或者修改NTP服务器配置,自己可以添加主机或者用公共NTP
server 192.168.154.20 iburst

# 重启
systemctl restart chronyd

# 验证同步
chronyc tracking
chronyc sources -v
root@etcd3:/etc/chrony# chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^? 192.168.154.20                0   7     0     -     +0ns[   +0ns] +/-    0ns

安装ETCD，整机跑

ps：个人建议可以在每个节点准备Go环境，虽然不需要严格和Kubernetes版本进行对应，但是还是需要注意版本兼容问题。

# golang
apt update && apt search golang
apt info golang
apt install golang
# 注意版本，这里是使用3.12.0，自己斟酌
# ps: https://mirrors.huaweicloud.com/etcd/v3.5.12/ wget 不到这里可以获取。
wget https://github.com/etcd-io/etcd/releases/download/v3.12.0/etcd-v3.12.0-linux-amd64.tar.gz
tar -xvf etcd-v3.12.0-linux-amd64.tar.gz
sudo mv etcd-v3.12.0-linux-amd64/etcd* /usr/local/bin/

创建etcd.conf.yml

# 一般在/etc/etcd/ 下面
mkdir -p /etc/etcd
touch /etc/etcd/etcd.conf.yaml

# 每一个etcd节点都需要进行配置

# etcd 配置文件示例
name: 'etcd1'  # 当前节点的名称
data-dir: /var/lib/etcd  # 数据存储路径
wal-dir:  # 日志文件存储路径，通常省略
snapshot-count: 10000  # 多少事务后进行一次快照

# 与其他 etcd 节点的通信设置
initial-advertise-peer-urls: https://<etcd1-cluster-ip>:2380  # 当前节点的 peer URL
listen-peer-urls: https://<etcd1-cluster-ip>:2380  # 当前节点监听的 peer URL
listen-client-urls: https://<etcd1-cluster-ip>:2379,http://127.0.0.1:2379  # 当前节点监听的 client URL
advertise-client-urls: https://<etcd1-cluster-ip>:2379  # 广播给其他服务的 client URL

# 初始化集群信息
initial-cluster: 'etcd1=https://<etcd1-cluster-ip>:2380,etcd2=https://<etcd2-cluster-ip>:2380,etcd3=https://<etcd3-cluster-ip>:2380'
initial-cluster-state: 'new'  # 'new' 用于初始引导，'existing' 用于已有集群加入新节点
initial-cluster-token: 'etcd-cluster-1'  # 集群标识

# 安全性设置
client-transport-security:
  cert-file: /etc/etcd/etcd-client.crt  # 客户端证书路径
  key-file: /etc/etcd/etcd-client.key  # 客户端密钥路径
  client-cert-auth: true  # 启用客户端认证
  trusted-ca-file: /etc/etcd/ca.crt  # 可信 CA 证书路径

peer-transport-security:
  cert-file: /etc/etcd/etcd-peer.crt  # 节点间通信证书路径
  key-file: /etc/etcd/etcd-peer.key  # 节点间通信密钥路径
  peer-client-cert-auth: true  # 启用节点间认证
  trusted-ca-file: /etc/etcd/ca.crt  # 可信 CA 证书路径

创建etcd.service

[Unit]
Description=etcd key-value store  # 描述该服务的用途
Documentation=https://github.com/etcd-io/etcd  # 提供服务相关的文档链接
After=network.target  # 确保网络服务启动后再启动 etcd

[Service]
Type=notify  # 服务类型为 notify，表示 etcd 会在准备好后通知 systemd
ExecStart=/usr/local/bin/etcd \  # 指定 etcd 二进制文件的路径及命令行参数
  --name {NODE_NAME} \  # 设置节点名称，需替换为实际节点名称，如 etcd1, etcd2
  --data-dir=/var/lib/etcd \  # 数据存储目录，指定 etcd 数据存放的路径
  --initial-advertise-peer-urls http://{NODE_IP}:2380 \  # 通告给集群其他节点的 URL，替换 {NODE_IP} 为实际节点 IP
  --listen-peer-urls http://{NODE_IP}:2380 \  # 当前节点监听其他节点连接的 URL
  --listen-client-urls http://{NODE_IP}:2379,http://127.0.0.1:2379 \  # 客户端访问的 URL，包括本地回环地址
  --advertise-client-urls http://{NODE_IP}:2379 \  # 通告给客户端的访问 URL
  --initial-cluster-token etcd-cluster-1 \  # 集群标识符，用于区分不同的 etcd 集群
  --initial-cluster etcd1=http://192.168.154.16:2380,etcd2=http://192.168.154.17:2380,etcd3=http://192.168.154.18:2380 \  # 定义集群中所有节点及其 IP 地址
  --initial-cluster-state new  # 集群的初始状态，"new" 表示新建集群，已有集群用 "existing"
Restart=always  # 服务退出时自动重启
RestartSec=5  # 重启前等待 5 秒
LimitNOFILE=40000  # 设置服务进程可打开文件的最大数量，通常设为较高值以避免资源限制

[Install]
WantedBy=multi-user.target  # 在多用户模式下启动服务

启动etcd.service

systemctl daemon-reload
systemctl restart etcd
systemctl enable etcd
systemctl status etcd

签发证书

# 目录可以任意
mkdir -p /etc/etcd/pki/pki-json
cd /etc/etcd/pki
touch ca-config.json
touch ca-csr.json
touch etcd-csr.json

# ca-config.json

常见问题

• 有时候进行一些服务变更之后呢，这个etcd的服务可能会进入一个长时间的阻塞，他会不断的进行节点查询和选举过程。这是一直既是正常又是不正常的状态，这个时候你可以：

# 停止etcd服务
systemctl stop etcd
# 清理数据目录
rm -rf /var/lib/etcd/*
# 再次确认配置文件没有问题之后，进行重启服务
systemctl daemon-reload
systemctl start etcd
systemctl status etcd 
# 检查集群健康
etcdctl --endpoints=http://192.168.154.11:2379,http://192.168.154.13:2379,http://192.168.154.14:2379 endpoint health

• 有时候你的集群节点数量在某种场合中很庞大，所以每次查询集群状态时候会显得吃力，所以你可以：

  # 本来你是需要这样子，<endpoints>里面需要填写所有节点的监听地址 etcdctl --endpoints=<endpoints> member list # 你可以使用环境变量进行export nano ~/.bashrc # 在最后一行你需要添加，需要注意的是ETCDCTL_ENDPOINTS这个字段是必须的，etcd才能够意识到 export ETCDCTL_ENDPOINTS="http://192.168.154.11:2379,http://192.168.154.13:2379,http://192.168.154.14:2379" # 进行配置生效。 source ~/.bashrc # 然后再进行查询 etcdctl member list # 还有另外一种方式就是，能够使用etcd专用的etcdctl.config.yaml endpoints: - http://192.168.154.11:2379 - http://192.168.154.13:2379 - http://192.168.154.14:2379 # 然后可以进行环境变量的指定 export ETCDCTL_CONFIG_FILE=~/.etcdctl.config.yml

• 还有其他的集群情况查询命令（已经设置环境变量的情况，未设置的话请添加–endpoint）

# 查看集群成员信息
etcdctl member list
# 查看集群状况
etcdctl endpoint status --write-out=table
# 查看每个节点的健康情况
etcdctl endpoint health
# 查看当前集群的leader
etcdctl endpoint status --write-out=table | grep true
# 查看集群报警情况
etcdctl alarm list
# 查看当前的节点和角色的投票情况
etcdctl endpoint status --write-out=table | grep -E 'ID|IS LEADER'
# Raft leader
etcdctl endpoint status --write-out=json | jq .

• etcdctl endpoint status --write-out=table字段解释

1. Raft Term:
   • 当前节点所在的 Raft 任期编号。
   • 常见排查：能够通过这个值判断这个ETCD是否稳定。
2. Raft Index：
   • 表示当前节点上已经应用的日志索引号，Raft日志中最新提交位置，证明有东西写入ETCD中
   • 若是不同节点的这个值相差较大，证明可能存在网络延迟或者节点不健康的情况
3. Raft Applied Index：

• 表示当前节点已经应用的日志条目索引号，已经应用于状态机。
• 如果此值明显小于上一个值证明，应用日志存在延迟问题，会产生一些性能瓶颈。

4. Errors：
   • 节点存在故障异常

如何让K8S集群使用到这个外部ETCD集群

再补充一些正式的的一些注意事项

• 需要注意的是，etcd集群的每一个节点都需要一个统一的ca进行签发，不然不统一后面kubernetes集群连接的时候可能会出现问题。其次在所有的pem进行移动到其他节点的操作，可能会存在pem过于暴露的提示，这个时候就需要进行一定的授权。

ps:证书公私钥的拷贝移动个人是觉得比较危险的行为，但是好像我暂时没有发现什么新的办法去解决。

1. 这里的意思是说，先在一个节点创建一个ca-config和ca-csr的json然后签发统一的cd然后拷贝分发到其他的节点，其他节点再用这个分发来的ca进行etcd的证书创建。

2. 所以你可以为了方便，在克隆之前先颁发ca.pem,ca-key.pem和定义ca-config.json和ca-csr.json等操作

3. 理论上在kubernentes使用外部etcd的时候只需要进行用统一ca证书配置的pem即可。

常见问题

证书配置

• 证书最好由统一的ca根证书颁发，然后用统一的json进行签发。

配置文件格式问题

• 最好注意service的排版格式以及配置config的排版格式，以及证书的路径位置

• 这里需要非常注意到是，证书签发后，上面涉及到的环境变量问题需要改成https并且在查看集群情况的时候你需要带上你的证书参书

靠谱的证书签发过程,（个人过程，不要直接黏贴）

# 这里是有准备ansible工具,删除集群信息。
ansible etcd -m shell -a 'rm -rf /var/lib/etcd/member'
# 签发证书，参考下面,其次你需要把之前的环境变量清楚掉改成https，然后把目录上的证书也expost到环境中。然后就可以了。

提供环境变量的名字

export ETCDCTL_ENDPOINTS="https://192.168.154.11:2379,https://192.168.154.13:2379,https://192.168.154.14:2379"
export ETCDCTL_CACERT="/etc/etcd/pki/ca/pem"
export ETCDCTL_CERT="/etc/etcd/pki/etcd-client.pem"
export ETCDCTL_KEY="/etc/etcd/pki/etcd-client-key.pem"
export ETCDCTL_SKIP_TLS_VERIFY=true
# 清除环境变量
unset xxx
# 搜寻环境变量
env | grep ETCDCTL

证书生成

根据你的命令记录，以下是生成 etcd 集群所需证书的完整步骤。这个过程包括创建自签名的 CA 证书，以及为 etcd 服务器、客户端、和 peer 节点生成相关证书。

生产证书的步骤

首先，为 etcd 集群生成一个自签名的 CA 证书，用于签署其他的 etcd 组件证书。

• 创建 CA 配置文件 ca-config.cnf（可以包含基本配置信息）。

• 生成 CA 的私钥 ca-key.pem：

  openssl genrsa -out ca-key.pem 4096

• 使用 CA 私钥生成自签名的 CA 证书 ca.pem：

  openssl req -x509 -new -nodes -key ca-key.pem -sha256 -days 3650 -out ca.pem -config ca-config.cnf

2. 为 etcd Peer 节点生成证书

Peer 证书用于 etcd 节点之间的通信。

• 创建 Peer CSR 配置文件 etcd-peer-csr.cnf。

• 生成 Peer 节点的私钥 etcd-peer-key.pem：

  openssl genrsa -out etcd-peer-key.pem 2048

• 创建 Peer 节点的证书签名请求 etcd-peer.csr：

  openssl req -new -key etcd-peer-key.pem -out etcd-peer.csr -config etcd-peer-csr.cnf

• 使用 CA 证书和私钥签署 Peer 证书 etcd-peer.pem：

  openssl x509 -req -in etcd-peer.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out etcd-peer.pem -days 365 -extensions req_ext -extfile etcd-peer-csr.cnf

3. 为 etcd 服务器生成证书

服务器证书用于 etcd 节点与客户端的通信。

• 创建服务器 CSR 配置文件 etcd-server-csr.cnf。

• 生成服务器的私钥 etcd-server-key.pem：

  openssl genrsa -out etcd-server-key.pem 2048

• 创建服务器证书签名请求 etcd-server.csr：

  openssl req -new -key etcd-server-key.pem -out etcd-server.csr -config etcd-server-csr.cnf

• 使用 CA 证书和私钥签署服务器证书 etcd-server.pem：

  openssl x509 -req -in etcd-server.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out etcd-server.pem -days 365 -extensions req_ext -extfile etcd-server-csr.cnf

4. 为 etcd 客户端生成证书

客户端证书用于 etcdctl 等客户端工具与 etcd 集群的安全通信。

• 创建客户端 CSR 配置文件 etcd-client-csr.cnf。

• 生成客户端的私钥 etcd-client-key.pem：

  openssl genrsa -out etcd-client-key.pem 2048

• 创建客户端证书签名请求 etcd-client.csr：

  openssl req -new -key etcd-client-key.pem -out etcd-client.csr -config etcd-client-csr.cnf

• 使用 CA 证书和私钥签署客户端证书 etcd-client.pem：

  openssl x509 -req -in etcd-client.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out etcd-client.pem -days 365 -extensions req_ext -extfile etcd-client-csr.cnf

• 都是为了高可用以及高扩展而存在的模式。

共识算法Paxos

• 分布式系统领域经典的共识算法有很多，如Raft和paxos，这一次我们先详细了解Paxox

Paoxs解决的问题

• Paxos主要解决在一个由多个节点（或服务器）组成的分布式系统中，如何确保这些节点在面对网络延迟、节点故障或分区等不确定性情况下，能够对某一个值达成一致。

Paxos基本原理

• Paxos算法分为基本Paxos和多Paxos两种变体。

基本Paxos

• 提议者 (Proposer) 发起提案，提出一个编号和值，希望获得多数接受者的同意。
• 接受者 (Acceptor) 对提案进行投票，并根据之前已经接受的提案决定是否同意新的提案。
• 学习者 (Learner) 观察已经被多数接受者接受的提案，最终学习到共识值

基本Paxos阶段

Prepare 阶段：
提议者选择一个提案编号 n，向所有接受者发送 Prepare(n) 请求。
每个接受者在收到 Prepare(n) 请求后，如果 n 大于其之前响应过的所有提案编号，则承诺不再接受编号小于 n 的提案，并返回其已经接受的提案及其编号。

Accept 阶段：
提议者在收到多数接受者的响应后，选择最高编号的提案值（如果有），并发送 Accept(n, v) 请求，其中 v 是被选择的提案值或提议者自己的新值。
接受者在收到 Accept(n, v) 请求后，如果尚未承诺接受比 n 更大的编号，则接受该提

Multi-Paxos

多Paxos是Paxos协议的一个扩展和优化，用于在分布式系统中处理多个值的共识问题。它通过将多个共识实例串联在一起，提高了效率，使得在一组节点中可以连续不断地达成多个值的共识。

• 在多Paxos中，提议者通常是固定的，这个固定的提议者称为领导（Leader）。领导者负责发起提案，并在一段时间内主导多个共识实例。

• 多Paxos的每一个提案编号 n 对应于一个特定的共识实例。这样，领导者只需要在初次选举时进行Prepare阶段的操作，后续的提案就可以直接进入Accept阶段，大幅减少了通信轮次。

具体优化

• 领导者选举：在多Paxos中，系统首先通过Paxos协议选出一个领导者。领导者负责在它的任期内发起多个提案。在每个共识实例中，领导者只需进行Accept阶段操作。
• 省略Prepare阶段：一旦领导者被选定且多数接受者同意，它可以直接在每个共识实例中发起
• Accept请求，而无需每次都从Prepare阶段开始。管道化：多Paxos可以支持管道化操作，即允许多个提案同时进行，以提高吞吐量。

MySQL Group Replication

原理

• 多主架构： MGR是一个多主复制解决方案，允许多个节点同时接收和处理写操作。每个节点都可以处理读写请求，这样系统可以实现高可用性和负载均衡。

• 一致性协议： MGR使用Paxos或Raft等一致性协议来确保多个节点之间的数据一致性。每次事务提交时，都会在组内传播，并通过一致性协议来决定事务是否提交成功。

• 自动故障转移： 如果一个节点出现故障，MGR可以自动检测并将其从组中移除，同时其他节点继续提供服务。系统可以自动将新节点加入到复制组中，实现自动化管理。

• 读写分离： 由于每个节点都可以接受写操作，因此在实现高可用性的同时，也具备一定的扩展能力。不过，通常建议设置部分节点为读专用，以分散负载。

流程架构

1. Execute (执行)
   Master 1: 开始执行某个事务。这个操作是在本地节点上执行的，但尚未传播到其他节点。
2. Certify (认证)
   所有参与共识的节点（Master 1、Master 2、Master 3）都会对事务进行认证。认证的目的是确保当前事务不会与其他事务产生冲突。这一步是基于全局事务顺序（GTS）来实现的。
   Master 1: 在本地节点上执行完事务后，会将其传递给其他节点进行认证。其他节点在收到这个事务后也会进行认证。
3. Relay Log (中继日志)
   Master 2 和 Master 3: 在认证通过后，将事务记录到中继日志中。这一步是为了确保即使发生故障，也能够在恢复时继续执行未完成的事务。
4. Apply (应用)
   Master 2 和 Master 3: 将中继日志中的事务应用到本地数据库中。这个步骤是将接收到的事务内容真正写入到数据库，从而保持与其他节点的数据一致性。
5. Binlog (二进制日志)
   所有的 Master 节点在成功应用事务后，会将事务记录到二进制日志中（Binlog）。二进制日志记录了所有数据更改，通常用于数据恢复、复制等场景。
6. Commit (提交)
   最后，所有 Master 节点都会将事务提交，正式结束这次事务处理。事务在所有节点上达成一致后，才会进行最终提交，这样可以确保整个集群的一致性。

使用限制

1. 事务一致性
   MySQL MGR 强制要求使用 InnoDB 存储引擎，因为它支持事务和行级锁。
   不支持非事务性存储引擎（如 MyISAM），使用这些引擎的表不会被复制，从而导致数据不一致。
2. 全局事务标识符（GTID）
   MySQL MGR 依赖 GTID 进行复制，因此在配置时必须启用 GTID（gtid_mode=ON）。
   不能在同一个实例上同时使用 MGR 和传统的基于二进制日志的复制。
3. 表的主键
   表中必须有主键或唯一索引，MGR 依赖这些来确保数据一致性和避免冲突。
   没有主键的表可能导致冲突检测机制失效，进而造成数据不一致。
4. 写入冲突
   多主模式下，多个节点可以同时写入数据，可能会产生写入冲突。MGR 通过冲突检测机制解决这些冲突，但在高并发情况下，可能影响性能或导致事务回滚。
5. 网络延迟和分区
   MGR 对网络延迟敏感，延迟较高时可能会影响复制的性能。
   在网络分区的情况下，MGR 可能会分裂为多个子组，这可能会导致服务不可用或数据不一致。
6. 兼容性限制
   MGR 不支持部分 MySQL 特性，例如：
   不支持外部锁（例如 LOCK TABLES 和 FLUSH TABLES WITH READ LOCK）。
   不支持临时表的跨节点复制。
   不支持在不同模式下（READ_WRITE, READ_ONLY, OFF）进行组内成员角色的动态切换。
7. 资源消耗
   由于 MGR 需要维护组内成员的一致性，尤其在多主模式下，资源消耗（如 CPU 和内存）比传统主从复制要高。
   在大数据量高并发写入的场景下，可能会影响性能，必须注意容量规划。

MySQL Master-Slave

原理：

1. 单主多从架构： 在Master-Slave模式中，一个数据库作为主库（Master），其他数据库作为从库（Slave）。所有写操作都由主库处理，而从库只接收来自主库的复制日志进行更新。
2. 异步复制： 通常情况下，从库以异步方式从主库获取更新。主库完成写操作后，立即返回给客户端，从库稍后复制这些更新。这种模式下，从库的数据可能会有短暂的延迟。异步复制是mysql默认的复制方式，主库写入binlog即可成功后返回给客户端，不等待binlog日志传递的过程，如果主库宕机，就有可能会出现丢失数据的情况。
3. 半同步复制：加了数据的安全性。因为主库在提交事务前确保至少一个从库已经接收并应用了该事务，从而降低了主库故障时数据丢失的风险。坏处也有由于主库在提交事务之前需要等待从库的 ACK，增加了事务的等待时间，这可能会对性能产生一定影响。如果从库的响应速度较慢，或者网络延迟较大，都会导致主库提交事务的时间延长。
4. 手动故障切换： 当主库故障时，需要手动将其中一个从库提升为主库，并重新配置其他从库指向新的主库。这通常需要借助外部工具或手动操作来完成。
5. 读写分离： 通过配置读写分离，客户端可以将读请求发送到从库，而写请求发送到主库，从而减轻主库的负载。

流程架构之异步复制

Master 端的操作

Binlog（Binary Log）：
主服务器（Master）在处理写操作（如 INSERT、UPDATE、DELETE 等）时，会将这些操作记录在二进制日志（Binlog）中。二进制日志是一个顺序写入的文件，记录了所有对数据库进行更改的 SQL 语句，这些语句将用于在从服务器上重放。

Dump：
在主服务器上，Dump 线程负责从 Binlog 中读取这些变化，并将其发送给请求同步数据的从服务器（Slave）。这个线程会持续运行

Slave 端的操作

IO Thread（IO 线程）：
从服务器上有一个 IO 线程，它向主服务器发送请求，要求主服务器发送新的 Binlog 数据。IO 线程接收到主服务器发送的二进制日志更新后，会将其写入到本地的中继日志（Relay Log）中。

Relay Log（中继日志）：
中继日志是从服务器上的一个临时存储区域，用于保存从主服务器接收到的二进制日志数据。这个日志可以被视为主服务器 Binlog 的本地副本。

SQL Thread（SQL 线程）：
从服务器上的 SQL 线程负责从中继日志中读取 SQL 语句并在从服务器上执行这些语句。这些 SQL 语句是从主服务器同步过来的，执行这些语句的目的是让从服务器的数据库状态与主服务器保持一致。

流程架构之半同步复制

MySQL 半同步复制工作原理

1. **主库执行事务 (Execute)**：

• 当主库（Master）接收到一个写操作时，首先会在主库上执行这个事务。此时，事务被记录在主库的二进制日志（Binlog）中。

2. **生成 Binlog 并发送给从库 (Binlog)**：

• 主库在执行事务后，会将该事务生成的二进制日志（Binlog）发送给所有配置了半同步复制的从库（Slave）。

3. **从库接收并写入中继日志 (Relay Log)**：

• 从库接收到主库发送的 Binlog 后，将其写入到中继日志（Relay Log）中。

4. **从库应用日志 (Apply)**：

• 从库将中继日志中的内容应用到本地数据库，完成对数据的更新。

5. 从库返回 ACK：

• 在从库成功应用完日志后，会发送一个确认信号（ACK）给主库。这个步骤确保了主库知道至少有一个从库已经成功应用了该事务。

6. **主库提交事务 (Commit)**：

• 主库在收到至少一个从库的 ACK 后，才会正式提交该事务。这就是“半同步”复制的关键点：主库确保至少有一个从库成功接收并应用了事务后，才认为事务提交成功。

7. 主库继续处理其他事务：

• 在事务提交之后，主库可以继续处理后续的事务操作。

• 为什么有了Kafka还是会有其他的的消息队列中间件呢，是因为KafKa不好用吗，并不是的，其实RocketMQ是有参考KafKa进行开发的，总的一句话说就是在架构上做减法，在功能上做加法

减法

• RcketMQ在KafKa的架构上除去了过重的Zookeeper分布式协调服务的组件，选择使用了更轻量级的nameserver。为什么要舍弃Zookeeper呢，主要是Zookeeper的功能多样而且强大，在KafKa中使用太过了。后续KafKa的新版本中也舍弃了Zookeeper选择使用了Raft一致性算法进行数据的统一协调。为什么新版本后还是有很多人选择使用RocketMQ呢，第一是新的东西总是有坑，第二就是RocketMQ还有不同KafKa的过人之处。

相似

• RocketMQ还是和KafKa一样，在不同topic上分不同的Partition，接着就是Broker进行高可用和高扩展，只是不一样的是RocketMQ把partition改名成了Queue

不同

消息体的存储位置

• 和KafKa不同的是，KafKa在partition中存储的是完整的消息题，而RocketMQ则是在Queue中只存储简要的信息，用来堆消息进行导向，比如offset。而实际的消息体会放在一个commitLog上面进行存储，通过offset来堆消息体进行定位获取。

@ 小白debug

持久化磁盘的区别

因为RocketMQ的消息体是放在一个commitLog里面，自然在写入磁盘时候也是顺序写入，非常通畅

备份简化

• RocketMQ为了不拆分commitLog干脆把主从副本升级成为了broker的级别，这样就不需要再多个Broker维护主从副本，直接改成了主从Broker。

加法

细分类

RocketMQ做的加法其实就是再Queue再进行细分类上打上tag的标签，比如，我在Queue中的索引某个消息打上vip的标签这样消费者就能够直接获取标签上的offset来获取vip标签。而KafKa则需要再一个partition里面进行筛选最终选出消息体给出消息。

加入延时队列

• RocketMQ能够使用延时队列，顾名思义就是能够延迟被消费者进行消费的队列消息。

加入死信队列

• RockerMQ会对重复失败处理的消息放入，专门处理失败的独立Queue队列也就是死信队列。

附上总图 @ 小白debug

sum

看似RocketMQ在KafKa的基础上做了如此多的优化，其实性能却远不及KafKa这又是为什么呢？？？

假设你有两台服务器，服务器A不断地发送需要处理的消息给服务器B，但是处理的速度赶不上发送的速度，就会导致消息堆积以至于是服务器B负载升高。要是服务B宕机了存储在内存里面的需要处理的消息就消失了，服务A又不知道导致各种消息没有得到处理后的回应，于是就有了消息队列kafka的诞生，没有什么是不能增加一个中间件解决不了的。

什么是KafKa

一种分布式流处理平台，主要用途是构建实时数据流应用和数据管道。

KafKa的架构

• 首先既然是一个中间件，它要是单独的跑一个消息队列进行消息的存储，当消息过多也会造成中间件的崩溃，所以需要一个高性能，高可用，有备份的中间件是必要的。

KafKa是怎么实现高性能的。

• 我们把对参与消息的分为Producer和Consumer，意思就是生产者和消费者，更简单点就是发布消息者和订阅消息者。按自己理解来。
• KafKa是通过消息的分类和分组的方式来区分不同类型的消息，我们管它叫Topic
• 在每一个Topic它又会分为多个Partition，每个Partition能过够被Consumer独立消费

ps：到以上能够解决了KafKa的性能问题，那么这多的partition在一节点上，要是节点炸了，那么消息一样全没了，所以又引导出高扩展的问题

KafKa是怎么实现高扩展的

• 大佬们是这么解决的，是通过服务器节点，我们把它叫Broker，Broker里面可以放不同数量的Partition，所以能够通过添加Broker节点来达到增加Partition，从何提高Topic的性能情况下，减少所有Partition放在同一个节点的方式的高负荷问题，那么要是就算某一个Broker还是因为高负荷坏了，该怎么解决，那么又能引发出高可用的问题

KafKa是怎么实现高可用

• KafKa是通过子不同的Borker里面存放副本进行高可用的实现，这些副本分为主从，若是主副本的Broker宕机了，那么从副本就会升级为主副本被Consumer消费。现在问题又来了，怎么保证他们每一个Broker之间的通信呢。

KafKa怎么解决组件之间通信的

• KafKa最后处理组件一致性和通信问题是用了Zookeeper，Zookeeper有着服务发现的功能，能够很好的协调KafKa集群的分布式服务。通信问题解决了。要是在很极端的情况下，所有的高性能高可用以及高扩展出来的东西，还是因为负载过高而全部宕机呢。那么就需要考虑到持久化存储，既然放在内存里面的消息如此不稳定。那么我们就持久化到磁盘里面。

KafKa的底层存储

• KafKa是对每一个Partiton分区进行顺序写入的操作，Partiton分区下面是实际上是一堆堆segment，顺序写入Partition实际上是顺序把消息写入segment里面。然后再随机写入磁盘中，这里为什么要注意随机呢。

KafKa的持久化存储为什么最终是随机写入磁盘

• 众所周知顺序写入磁盘会比随机写入要快很多，那么为什么KafKa明明是对segment顺序写入的，最终还是成为随机呢。
• 因为每一堆segment是partition下面的，既然你那么多的partition，所以就会有很多份segment，对于sgement本身虽然是顺序写入，但是对于每一份segment确实随机写入。

最终附上up：小白debug的总图

最近在集群中遇到了很多containerd的问题，所以不禁思考我真的懂containerd吗？？?

前提

本文假设你熟悉了

1. CRI的概念 && gRPC && socket 参考：https://blog.kalyan.life/2024/07/04/CRI/
2. shim垫片概念

containerd是什么就不说啦

架构（理解就好，主要在于如何使用，想要研究可以去看源码）

1. API 层

• gRPC API: 提供给客户端的 gRPC API，支持包括容器管理、镜像管理、存储管理等操作。
• CRI: 容器运行时接口，允许 Kubernetes 通过 gRPC API 与 containerd 交互。
• Prometheus: 用于监控的指标接口，收集和暴露 containerd 的运行时数据。

2. 核心层 (Core)

• Services

  : 包含多种服务，每种服务负责不同的功能模块。

  • Containers Service: 管理容器的生命周期。
  • Content Service: 负责内容管理，处理镜像层的数据。
  • Diff Service: 负责镜像层之间的差异计算。
  • Images Service: 负责镜像的管理。
  • Leases Service: 管理临时资源。
  • Namespaces Service: 提供命名空间支持，隔离不同的容器组。
  • Snapshots Service: 管理快照。
  • Tasks Service: 管理任务的运行。

• Metadata

  : 提供命名空间支持和元数据管理。

  • Containers, Content, Images, Leases, Namespaces, Snapshots: 各种元数据的管理模块。

3. 后端层 (Backend)

• Content Store: 负责存储内容，可以通过插件和本地存储实现。

• Snapshotter

  : 管理文件系统的快照。

  • overlay, btrfs, devmapper, native, windows, plugin: 支持多种文件系统和快照技术。

• Runtime

  : 支持容器运行时。

  • runc, runhcs, kata, Firecracker, gVisor, shim: 支持多种运行时，包括 runc、runhcs、kata containers、Firecracker 和 gVisor。
  • v2 shim client: 每个容器都有一个 shim 进程，隔离容器的生命周期管理，确保容器的独立运行。

4. 系统层 (System)

• 支持多种硬件架构和操作系统，包括 ARM、Intel、Windows、Linux。

简化版

• 分为三⼤块：Storage 管理镜像⽂件的存储；Metadata 管理镜像和容器的元数据；另外由 Task
  触发运⾏时。对外提供 GRPC ⽅式的 API 以及 Metrics 接⼝。

然后我们讲一下重要的配置文件

config.toml

version = 2
# 配置文件版本

root = "/var/lib/containerd"
# containerd 数据存储的根目录

state = "/run/containerd"
# containerd 状态信息存储目录

oom_score = 0
# OOM（Out of Memory）分数调整值，用于内存不足时的优先级

[grpc]
# gRPC 配置部分

  max_recv_message_size = 16777216
  # gRPC 最大接收消息大小

  max_send_message_size = 16777216
  # gRPC 最大发送消息大小

[debug]
# 调试配置部分

  level = "info"
  # 日志级别，info 表示信息级别日志

[metrics]
# 指标配置部分

  address = ""
  # 指标服务监听地址，空表示不启用

  grpc_histogram = false
  # 是否启用 gRPC 直方图

[plugins]
# 插件配置部分

  [plugins."io.containerd.grpc.v1.cri"]
  # CRI 插件配置部分

    sandbox_image = "192.168.154.2/registry.k8s.io/pause:3.9"
    # 沙箱镜像，用于 Pod 的基础镜像

    max_container_log_line_size = -1
    # 容器日志行的最大长度，-1 表示不限制

    enable_unprivileged_ports = false
    # 是否启用非特权端口

    enable_unprivileged_icmp = false
    # 是否启用非特权 ICMP

    [plugins."io.containerd.grpc.v1.cri".containerd]
    # containerd 相关配置

      default_runtime_name = "runc"
      # 默认运行时名称

      snapshotter = "overlayfs"
      # 默认使用的快照器类型

      discard_unpacked_layers = true
      # 是否丢弃解包的层

    [plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
    # 容器运行时配置部分

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
      # runc 运行时配置部分

        runtime_type = "io.containerd.runc.v2"
        # 运行时类型

        runtime_engine = ""
        # 运行时引擎

        runtime_root = ""
        # 运行时根目录

        base_runtime_spec = "/etc/containerd/cri-base.json"
        # 基础运行时规格文件

      [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
      # runc 运行时选项配置部分

        SystemdCgroup = true
        # 是否启用 systemd cgroup

        BinaryName = "/usr/local/bin/runc"
        # runc 二进制文件路径

    [plugins."io.containerd.grpc.v1.cri".registry]
    # 镜像仓库配置部分

      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
      # 镜像仓库镜像配置部分

        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."192.168.154.2"]
        # 指定的镜像仓库
          endpoint = ["https://192.168.154.2"]
          # 镜像仓库的端点 URL

      [plugins."io.containerd.grpc.v1.cri".registry.configs."192.168.154.2".tls]
      # 镜像仓库 TLS 配置部分

        insecure_skip_verify = true
        # 是否跳过 TLS 证书验证

值得注意的是这里的镜像仓库有两种加载方式,到了2.0版本就可以用

[plugins."io.containerd.grpc.v1.cri".registry]
config_path= "/etc/containerd/certs.d"

# 然后再certs.d目录下面添加你的镜像仓库就好了.

/run/containerd/里面的是什么

1. containerd.sock:

• 这是 containerd 的主 Unix socket 文件，用于与 containerd 守护进程进行通信。客户端（例如 Docker 或 Kubernetes）通过这个 socket 文件发送管理指令。

2. containerd.sock.ttrpc:

• 这是 containerd 用于 ttrpc（Tiny Transport RPC）通信的 socket 文件。ttrpc 是一种轻量级的 RPC 框架，用于在性能敏感的环境中提供高效的进程间通信。

3. io.containerd.grpc.v1.cri:

• 这个目录包含与 Kubernetes CRI（Container Runtime Interface）集成相关的 socket 文件和配置。containerd 支持 CRI，使得 Kubernetes 可以直接通过 containerd 来管理容器。

4. io.containerd.runtime.v1.linux:

• 这个目录包含与 v1 版本的 containerd 运行时相关的文件和配置，主要用于 Linux 系统上的容器管理。

5. io.containerd.runtime.v2.task:

• 这个目录包含与 v2 版本的 containerd 任务管理相关的文件和配置。v2 版本引入了一些新的特性和改进，用于更高效地管理容器任务。

6. runc:

• 这是 runc 运行时的目录。runc 是一个 CLI 工具，用于根据 OCI（Open Container Initiative）规范创建和运行容器。containerd 使用 runc 作为默认的容器运行时。

7. s:

• 这个目录的具体用途可能需要根据系统的实际配置来确定。它可能是用于存储临时文件、状态文件或特定插件的目录。

/var/lib/containerd 里面的是什么

1. io.containerd.content.v1.content:

• 存储镜像和容器层的内容，包括所有下载的镜像数据。这里的文件通常以内容地址（例如 SHA256 哈希）进行命名和存储。

2. io.containerd.snapshotter.v1.overlayfs:

• 这是一个与文件系统快照相关的目录，特别是使用 OverlayFS 作为存储后端时。这个目录包含快照和层的数据，用于构建和管理容器的文件系统层。

3. io.containerd.snapshotter.v1.btrfs:

• 类似于 overlayfs 目录，但用于 Btrfs 文件系统。它存储使用 Btrfs 作为存储后端时的快照和层的数据。

4. io.containerd.snapshotter.v1.devmapper:

• 用于 Device Mapper 存储后端的快照数据，存储容器层的信息。

5. io.containerd.grpc.v1.cri:

• 包含与 Kubernetes CRI 集成相关的数据和配置。Kubernetes 通过这个目录与 containerd 进行通信和数据交换。

6. tmpmounts:

• 临时挂载点目录，用于存储容器运行时的临时文件和挂载点信息。

命令工具

常用命令

其他命令

Containerd 如何存储镜像和容器。⽬录结构是什么样的。是否⽀持 容量限制

Containerd 是⼀个容器运⾏时管理程序，它使⽤ OCI（Open Container Initiative）标准来定义容器和镜像。镜像通常被存储在⼀个容器镜像存储库（Container Image Store）中，例如 Docker Hub，或者本地的 OCI 镜像存储库。Containerd 会从存储库中下载镜像，并在本地存储。容器则是使⽤镜像创建的运⾏实例。Containerd 将容器的元数据存储在称为 “snapshots” 的⽬录中。每个容器都有⼀个独⽴的快照⽬录，其中包含容器的根⽂件系统和元数据。Containerd 还⽀持将容器存储在可移动的磁盘上，这种⽅式称为 “offline snapshots”。Containerd ⽀持容器资源限制，可以设置 CPU 和内存的限制，也可以设置 I/O 和⽹络带宽等限制。这些限制是通过使⽤ Linux 内核的 cgroup 和 namespace 功能来实现的。

Containerd 如何处理⽇志，是否⽀持轮滚

Containerd 本身并不负责处理容器的⽇志，⽽是将⽇志处理交给容器运⾏时，如 runc 或 CRI- O。这些容器运⾏时⽀持使⽤各种不同的⽅式来处理容器的⽇志，如直接输出到控制台、将⽇志写⼊⽂件或使⽤⽇志聚合⼯具，如 Fluentd 或ELK Stack。对于容器的⽇志轮滚，⼀般是由容器运⾏时负责实现。例如，runc 可以通过指定 –log-opt max-size 和 –log-opt max-file 参数来控制容器⽇志的⼤⼩和轮滚。当容器⽇志⽂件⼤⼩达到指定的⼤⼩时，runc 会⾃动创建⼀个新的⽇志⽂件，并将旧的⽇志⽂件压缩和删除。类似地，CRI- O 也⽀持使⽤ –log-max-file 和 –log-max-size 参数来控制容器⽇志的轮滚。

Containerd 重启，是否会导致容器重启

当 Containerd 重启时，已经在运⾏的容器不会⽴即停⽌或重启。这是因为容器本身是由容器运⾏时（例如 runc 或CRI- O）管理的，⽽不是由 Containerd 直接控制。因此，Containerd 重启不会直接影响容器的运⾏状态。当 Containerd 重启后，容器运⾏时会重新连接到新的 Containerd 进程，以便继续管理容器。在此过程中，容器运⾏时可能会暂停⼀段时间，导致容器内的应⽤程序暂时⽆法访问，但通常这个时间⾮常短暂，只会影响到容器内正在进⾏的临时操作。需要注意的是，如果 Containerd 重启导致容器存储被破坏或不可⽤，那么容器本身可能会受到影响，因为容器的根⽂
件系统和元数据存储在 Containerd 的快照⽬录中。在这种情况下，容器运⾏时可能会⽆法连接到 Containerd，导致容器⽆法正常运⾏。因此，在重启 Containerd 之前，需要确保容器存储的完整性和可⽤性。

Containerd 的⽹络命名空间是什么样的，⽆ CNI 下的容器，是否⽀持⽹络

Containerd 使⽤ Linux 内核的⽹络命名空间（network namespace）来隔离容器的⽹络栈和⽹络配置，以便容器可以拥有⾃⼰独⽴的⽹络栈和⽹络环境。每个容器都有⾃⼰的⽹络命名空间，并且容器之间默认是隔离的，不能相互访问。在没有 CNI（Container Networking Interface）插件的情况下，Containerd 本身并不提供⽹络功能，需要⼿动配置容器的⽹络。可以使⽤ Linux 的⽹络⼯具，如 ip 和 iptables，来⼿动配置容器的⽹络，例如分配 IP 地址、设置路由和防⽕墙规则等。这种⽅式需要⼿动配置和管理，⽐较繁琐。不过，Containerd 可以与 CNI 插件配合使⽤，以便⾃动化配置容器的⽹络。CNI 插件可以在容器创建时⾃动配置⽹络，例如分配 IP 地址、设置⽹络接⼝和路由等。常⻅的 CNI 插件包括 Flannel、Calico、Weave Net 等，它们可以与Containerd 集成，以提供⾃动化的⽹络配置和管理。

Containerd 有没有 KMEM 泄露 的问题

在早期版本的 Containerd 中曾经存在⼀些 KMEM 泄漏的问题。具体来说，这些问题通常与 Containerd 在处理⾼负载情况下使⽤了⼤量的内核内存（KMEM），导致内存泄漏和系统不稳定。不过，Containerd 的开发团队已经在后续版本中修复了这些问题，并采取了⼀些措施来避免 KMEM 泄漏。例如，Containerd 1.4.0 版本中引⼊了 KMEM 限制和监控功能，以便在 Containerd 使⽤⼤量 KMEM 时⾃动降低容器的资源配额，从⽽避免 KMEM 泄漏和系统不稳定。总的来说，如果您使⽤的是较新版本的 Containerd，并且在运⾏期间遇到了 KMEM 泄漏的问题，建议升级到最新版本并检查您的系统配置，以确保已经正确配置了 KMEM 限制和监控。同时，如果您的系统遇到了 KMEM 泄漏等其他问题，也可以向 Containerd 的开发团队报告问题并寻求技术⽀持。

Containerd-shim-runc-v1与v2的区别

containerd-shim-runc-v1 和 containerd-shim-runc-v2 是 containerd 中使⽤的两个 shim 实现。这两个 shim 实现都是使⽤ runc 来启动和管理容器的。containerd-shim-runc-v1 是 containerd 中旧的 shim 实现，它使⽤进程间通信 (IPC) 来与 containerd 守护进程进⾏通信，通常会使⽤ UNIX 域套接字或 FIFO 进⾏通信。它是在 containerd 1.0 中引⼊的，主要⽤于运⾏ Docker 容器，但现在已经被 containerd-shim-runc-v2 替代。containerd-shim-runc-v2 是 containerd 中新的 shim 实现，它使⽤ gRPC 来与 containerd 守护进程进⾏通信。它是在 containerd 1.1 中引⼊的，其⽬标是提供更好的性能和可靠性，并为后续的扩展提供更好的基础设施。与containerd-shim-runc-v1 相⽐，它更加轻量级，并且可以通过 API 配置各种容器和执⾏参数。总的来说，containerd-shim-runc-v2 是 containerd 中更加现代和⾼效的 shim 实现，它⽐ containerd-shimrunc-v1 更具扩展性和可维护性，因此在使⽤ containerd 时应该尽可能地使⽤ containerd-shim-runc-v2。

Containerd的grpc⽅法是如何注册的？

containerd 的 gRPC ⽅法是通过⽣成的 protobuf ⽂件和相应的代码实现的。protobuf ⽂件描述了 containerd ⽀持的API ⽅法和数据结构，然后使⽤这个⽂件⽣成对应的代码（包括客户端和服务器端代码）。这些⾃动⽣成的代码提供了实现⽅法的框架，开发⼈员可以在其中添加⾃⼰的代码以实现具体功能。在 containerd 中，服务器端的 gRPC ⽅法是在 services ⽬录下实现的。每个服务都实现了⼀个接⼝（在 protobuf⽂件中定义），并提供了⼀些⽅法来处理请求。这些⽅法通常采⽤ context 参数来获取请求上下⽂和取消信号，然后使⽤⾃动⽣成的代码处理 protobuf 消息。在这些⽅法中，使⽤的核⼼实现代码通常在 containers、images 或content 等核⼼ package 中实现。服务注册是通过 init 函数实现的，每个服务都在其对应的包中实现了⼀个名为 Register 的函数，该函数在包被导⼊时⾃动运⾏，将⾃⼰注册到 containerd 的 gRPC 服务器上。在 Register 函数中，使⽤
server.RegisterService 函数将⾃⼰的服务实现注册到 containerd 的 gRPC 服务器上，以便客户端可以调⽤。

Containerd与containerd-shim是如何交互的？

在 Containerd 中，containerd-shim 是负责启动容器进程并与 Containerd API 通信的组件。Containerd 通过 gRPC接⼝与 containerd-shim 通信，以便进⾏容器的创建、启动、停⽌、删除等操作。具体⽽⾔，Containerd 与containerd-shim 之间的交互过程如下：

1. Containerd 使⽤ gRPC 接⼝向 containerd-shim 发送创建容器的请求，包括容器的 ID、镜像、⽂件系统等参数。
2. containerd-shim 接收到创建容器的请求后，会根据请求中的参数启动⼀个新的容器进程，并创建⼀个对应的Linux namespace。
3. containerd-shim 将容器的 PID、Stdin、Stdout 和 Stderr 等信息发送回给 Containerd，以便后者能够管理和监控容器的运⾏状态。
4. 在容器运⾏过程中，Containerd 可以通过 gRPC 接⼝向 containerd-shim 发送信号以启动、停⽌、暂停或恢复容器的运⾏。
5. 当容器进程退出后，containerd-shim 会向 Containerd 发送容器的退出状态和退出码，Containerd 在接收到这些信息后，会更新容器的状态并删除对应的容器对象。需要注意的是，Containerd 和 containerd-shim 都是独⽴的进程，它们之间通过 gRPC 接⼝通信，因此 Containerd和 containerd-shim 可以在不同的计算机上运⾏，这也为 Containerd 的分布式部署提供了便利。

Containerd-shim与runc是如何交互的？

在容器技术中，runc 是⼀个⽤于启动和管理容器的轻量级⼯具，⽽ containerd-shim 是 containerd ⽤于管理容器⽣命周期的代理。在容器启动的过程中，runc 和 containerd-shim 之间会进⾏以下交互：

1. Containerd-shim 通过 Containerd API 向 Containerd 发送创建容器的请求。
2. Containerd 接收到请求后，将请求转发给 runc 来创建容器。runc 将通过 system call 创建新的容器进程，并设置容器的隔离环境（⽐如 namespace、cgroups、rootfs）等参数。
3. runc 启动新的容器进程并返回 PID 给 Containerd-shim。
4. Containerd-shim 接收到容器进程的 PID 后，会将 PID 发送回给 Containerd。Containerd 会继续管理和监控容器的⽣命周期。
5. 在容器运⾏期间，Containerd 可以通过 Containerd API 向 Containerd-shim 发送命令，⽐如停⽌、暂停、恢复、删除容器等操作。
6. 当容器进程退出后，runc 将容器的退出状态和退出码发送给 Containerd-shim。Containerd-shim 将这些信息发送回给 Containerd，Containerd 将更新容器的状态并删除对应的容器对象。需要注意的是，runc 是⼀个独⽴的⼯具，它与 containerd-shim 的交互是在容器启动时发⽣的。在容器启动成功后，runc 将直接与容器进程交互，⽽ containerd-shim 的作⽤将逐渐变⼩。

你需要提前了解，hwameistor的组件生命周期管理：

1. LocalDiskManager

作用: LocalDiskManager 负责管理节点上的物理磁盘资源。它发现、监控和维护节点的本地磁盘信息，确保系统对可用磁盘资源的了解是最新的。

生命周期管理:

• 启动: 当 LocalDiskManager 启动时，它扫描节点上的所有可用磁盘，收集磁盘的元数据（例如大小、型号、状态等）。
• 运行中: 持续监控磁盘状态变化，更新磁盘元数据信息，并根据需要调整磁盘的可用性状态。
• 停止: 在组件停止时，需要确保停止对磁盘的监控，并正确释放资源。

2. LocalStorage

作用: LocalStorage 提供节点级别的存储资源管理。它负责将物理磁盘抽象为可用的存储卷，并执行卷的创建、删除、扩展等操作。

生命周期管理:

• 启动: 初始化本地存储卷的管理逻辑，确保节点上的物理磁盘可以被正确识别和使用。
• 运行中: 管理存储卷的生命周期，包括创建、删除、扩展、快照等操作，监控卷的健康状态。
• 停止: 停止管理存储卷，确保所有资源被安全释放。

3. Scheduler

作用: Scheduler 是一个自定义调度器插件，用于优化工作负载调度到具有特定存储要求的节点上。

生命周期管理:

• 启动: 注册自定义调度逻辑，将其集成到 Kubernetes 调度流程中。
• 运行中: 根据工作负载的存储需求和节点的存储资源情况，执行优化调度。
• 停止: 取消注册自定义调度逻辑，从 Kubernetes 调度器中安全移除。

4. AdmissionController

作用: AdmissionController 在工作负载被提交到 Kubernetes 集群时，对其进行预处理，确保其符合存储策略和要求。

生命周期管理:

• 启动: 注册到 Kubernetes 的准入控制器链中，准备对即将创建的资源进行预处理。
• 运行中: 拦截工作负载请求，根据存储策略进行验证和调整。
• 停止: 从准入控制器链中移除，停止对新请求的拦截和处理。

5. VolumeEvictor

作用: VolumeEvictor 负责在节点维护或失败时，将存储卷从受影响的节点上安全地迁移到其他节点。

生命周期管理:

• 启动: 初始化卷迁移逻辑，确保在节点发生问题时，卷可以被安全转移。
• 运行中: 持续监控节点状态和卷的健康状况，执行必要的迁移操作。
• 停止: 停止监控和迁移操作，确保当前迁移过程安全完成。

6. Exporter

作用: Exporter 收集和导出存储系统的监控指标，供外部监控系统（如 Prometheus）使用。

生命周期管理:

• 启动: 初始化监控指标的收集和导出逻辑。
• 运行中: 持续收集系统指标，提供给监控系统进行实时监控和分析。
• 停止: 停止指标的收集和导出，释放相关资源。

7. Apiserver

作用: Apiserver 提供对 HwameiStor 的管理接口，使用户能够通过 RESTful API 进行操作。

生命周期管理:

• 启动: 初始化 API 服务，注册可用的接口端点。
• 运行中: 处理用户请求，执行存储管理操作。
• 停止: 停止 API 服务，确保当前请求被正确处理完成。

目标

手速StorageClass用hwameistor的方式进行pvc申领动态制备PV

简要步骤

1. 保证helm存在
2. 添加 hwameistor-operator Helm Repo
3. 通过hwameistor-operator部署HwameiStor

@&^%!*&@$实战开始

检查是否有空盘，至于hwameistor是否能再无空盘情况下中断安装后续再尝试

添加源

其实这个步骤是挺简单的，全都是自动创建，所以建议就是最后需要了解一下改csi驱动的特点。比如分布式以及自动搜盘。

helm repo add hwameistor-operator https://hwameistor.io/hwameistor-operator
helm repo update hwameistor-operator

通过hwameistor-operator进行部署HwameiStor

helm install hwameistor-operator hwameistor-operator/hwameistor-operator -n hwameistor --create-namespace

ps:HwameiStor默认会把所有干净的磁盘纳入到LSD的存储池里面，但是也可以预留，通过helm的values来设置

--set diskReserve\[0\].nodeName=node1 \
--set diskReserve\[0\].devices={/dev/sdc\,/dev/sdd} \
--set diskReserve\[1\].nodeName=node2 \
--set diskReserve\[1\].devices={/dev/sdc\,/dev/sde}

# -f diskReserve.yaml
# diskReserve.yaml 如下
diskReserve:
- nodeName: node1
  devices:
  - /dev/sdc
  - /dev/sdd
- nodeName: node2
  devices:
  - /dev/sdc
  - /dev/sde

结束

理论来说，镜像拉取没有问题的话，就基本都可以了，HwameiStor就是这么的nb，可以自己做完所有事情。

该实战基于假设了解并清楚，ServiceAccount，ClusterRole，ClusterRoleBinding等
以下是简要介绍：

1. ServiceAccount：为Pod提供了一个身份，允许Pod与Kubernetes API进行安全交互。Local Path Provisioner需要访问和管理PV、PVC、Nodes等资源
2. ClusterRole：定义了一组权限，允许某个身份（如ServiceAccount）对Kubernetes集群中的资源执行特定操作。
3. ClusterRoleBinding：ClusterRoleBinding将ClusterRole与一个或多个主体（如ServiceAccount）绑定，以便这些主体获得ClusterRole定义的权限

   目标

   手撕StorageClass用rancher的local-path的方式进行PVC申领动态制备PV

简要步骤

1. 建立命名空间进行资源隔离
2. 创建ServiceAccount、ClusterRole和ClusterRoleBinding（前提解释）
3. 创建deploy，控制pod副本数量
4. 创建configMap，存储不含机密信息的配置数据。（参考：存储基础）
5. 创建StorageClass（参考第4条）

废话不多说@#￥%……&*实战开始

namespace

# 好的，已经成功一半了
kubectl create namespace(ns) local-path-storage

ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: local-path-provisioner-service-account
  namespace: local-path-storage 

ClusterRole，直接拿官方的

apiVersion: rbac.authorization.k8s.io/v1 # 指定API版本，这里是rbac.authorization.k8s.io/v1
kind: ClusterRole # 资源类型，这里是ClusterRole，表示集群级别的权限定义
metadata:
  name: local-path-provisioner-role # ClusterRole的名称，这里是local-path-provisioner-role
rules: # 定义该角色的权限规则列表
- apiGroups: [""] # 指定API组，空字符串表示核心API组
  resources: ["nodes", "persistentvolumeclaims", "persistentvolumes"] # 资源类型列表，包括nodes、persistentvolumeclaims和persistentvolumes
  verbs: ["get", "list", "watch", "create", "delete"] # 允许的操作，包括获取、列出、监视、创建和删除
- apiGroups: [""] # 再次指定核心API组
  resources: ["pods"] # 资源类型是pods
  verbs: ["get", "list", "watch"] # 允许的操作，包括获取、列出和监视
- apiGroups: ["storage.k8s.io"] # 指定API组storage.k8s.io
  resources: ["storageclasses"] # 资源类型是storageclasses
  verbs: ["get", "list", "watch"] # 允许的操作，包括获取、列出和监视
- apiGroups: ["batch", "extensions"] # 指定API组batch和extensions
  resources: ["jobs"] # 资源类型是jobs
  verbs: ["get", "list", "watch", "create", "delete"] # 允许的操作，包括获取、列出、监视、创建和删除

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1 # 指定API版本，这里是rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding # 资源类型，这里是ClusterRoleBinding，表示集群级别的角色绑定
metadata:
  name: local-path-provisioner-bindings # ClusterRoleBinding的名称，这里是local-path-provisioner-bindings
roleRef: # 指定要绑定的角色
  apiGroup: rbac.authorization.k8s.io # 角色所属的API组，这里是rbac.authorization.k8s.io
  kind: ClusterRole # 角色类型，这里是ClusterRole
  name: local-path-provisioner-role # 角色名称，这里是local-path-provisioner-role
subjects: # 定义该角色绑定的主体列表
- kind: ServiceAccount # 主体类型，这里是ServiceAccount（服务账户）
  name: local-path-provisioner-service-account # 服务账户的名称，这里是local-path-provisioner-service-account
  namespace: local-path-storage # 服务账户所属的命名空间，这里是local-path-storage

Deploy

apiVersion: apps/v1 # 指定API版本，这里是apps/v1
kind: Deployment # 资源类型，这里是Deployment，表示部署一个应用
metadata:
  name: local-path-provisioner # Deployment的名称，这里是local-path-provisioner
  namespace: local-path-storage # Deployment所属的命名空间，这里是local-path-storage
spec: # Deployment的规格定义
  replicas: 1 # 副本数，这里是1，表示只部署一个副本
  selector: # 用于选择要部署的Pod
    matchLabels:
    # 标签选择器，选择标签为app: local-path-provisioner的Pod
      app: local-path-provisioner 
  template: # Pod模板定义
    metadata:
      labels:
        app: local-path-provisioner # 为Pod设置的标签，这里是app: local-path-provisioner
    spec: # Pod的规格定义
    # 使用的服务账户名称，这里是local-path-provisioner-service-account
      serviceAccountName: local-path-provisioner-service-account 
      containers: # 容器列表
      - name: provisioner # 容器名称，这里是provisioner
      # 容器镜像，这里是rancher/local-path-provisioner:latest
        image: rancher/local-path-provisioner:master-head # 换加速啊啊啊啊啊啊啊啊叼毛
        imagePullPolicy: Always # 镜像拉取策略，总是拉取最新的镜像
        volumeMounts: # 挂载的卷列表
        - name: config-volume # 卷名称，这里是config-volume
          mountPath: /etc/config # 挂载路径，这里是/etc/config
        - name: local-path-storage # 卷名称，这里是local-path-storage
          mountPath: /opt/local-path-storage # 挂载路径，这里是/opt/local-path-storage
      volumes: # 定义Pod中使用的卷
      - name: config-volume # 卷名称，这里是config-volume
        configMap: # 使用ConfigMap作为卷
          name: local-path-config # ConfigMap的名称，这里是local-path-config
      - name: local-path-storage # 卷名称，这里是local-path-storage
        hostPath: # 使用主机路径作为卷
          path: /opt/local-path-storage # 主机路径，这里是/opt/local-path-storage

config

apiVersion: v1 # 指定API版本，这里是v1
kind: ConfigMap # 资源类型，这里是ConfigMap，用于存储配置信息
metadata:
  name: local-path-config # ConfigMap的名称，这里是local-path-config
  namespace: local-path-storage # ConfigMap所属的命名空间，这里是local-path-storage
data: # 配置数据
  config.json: | # 配置文件的名称，这里是config.json，使用多行字符串格式
    {
      "nodePathMap":[
        {
          "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES", # 节点名称，表示未列出的节点的默认路径
          "paths":["/opt/local-path-storage"] # 路径列表，这里是/opt/local-path-storage
        }
        ]
    }

StorageClass

apiVersion: storage.k8s.io/v1 # 指定API版本，这里是storage.k8s.io/v1
kind: StorageClass # 资源类型，这里是StorageClass，表示存储类
metadata:
  name: local-path # StorageClass的名称，这里是local-path
provisioner: rancher.io/local-path # 指定的provisioner，这里是rancher.io/local-path
reclaimPolicy: Delete # 回收策略，这里是Delete，表示当持久卷被释放时删除它
# 卷绑定模式，这里是WaitForFirstConsumer，表示延迟绑定，直到Pod被调度到节点上
volumeBindingMode: WaitForFirstConsumer 

验证

创建pvc yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-local-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: local-path

因为设计的是WaitForFirstConsumer，所以需要设计一个pod

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: m.daocloud.io/docker.io/library/nginx
    volumeMounts:
    - mountPath: "/usr/share/nginx/html"
      name: my-local-storage
  volumes:
  - name: my-local-storage
    persistentVolumeClaim:
      claimName: my-local-pvc

总结

以上的配置文件只是一个参考，实际的可以用官方的配置文件,需要注意的是换加速镜像地址时候要换全哦，带image的都换。配置不正确多半进入cashloopbackoff的问题。

apiVersion: v1
kind: Namespace
metadata:
  name: local-path-storage

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: local-path-provisioner-service-account
  namespace: local-path-storage

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: local-path-provisioner-role
  namespace: local-path-storage
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: local-path-provisioner-role
rules:
  - apiGroups: [""]
    resources: ["nodes", "persistentvolumeclaims", "configmaps", "pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "patch", "update", "delete"]
  - apiGroups: [""]
    resources: ["events"]
    verbs: ["create", "patch"]
  - apiGroups: ["storage.k8s.io"]
    resources: ["storageclasses"]
    verbs: ["get", "list", "watch"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: local-path-provisioner-bind
  namespace: local-path-storage
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: local-path-provisioner-role
subjects:
  - kind: ServiceAccount
    name: local-path-provisioner-service-account
    namespace: local-path-storage

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: local-path-provisioner-bind
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: local-path-provisioner-role
subjects:
  - kind: ServiceAccount
    name: local-path-provisioner-service-account
    namespace: local-path-storage

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: local-path-provisioner
  namespace: local-path-storage
spec:
  replicas: 1
  selector:
    matchLabels:
app: local-path-provisioner
  template:
    metadata:
      labels:
        app: local-path-provisioner
    spec:
      serviceAccountName: local-path-provisioner-service-account
      containers:
        - name: local-path-provisioner
          image: docker.m.daocloud.io/rancher/local-path-provisioner:master-head  # ps：换
          imagePullPolicy: IfNotPresent
          command:
            - local-path-provisioner
            - --debug
            - start
            - --config
            - /etc/config/config.json
          volumeMounts:
            - name: config-volume
              mountPath: /etc/config/
          env:
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            - name: CONFIG_MOUNT_PATH
              value: /etc/config/
      volumes:
        - name: config-volume
          configMap:
            name: local-path-config

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-path
provisioner: rancher.io/local-path
volumeBindingMode: Immediate
reclaimPolicy: Delete

---
kind: ConfigMap
apiVersion: v1
metadata:
  name: local-path-config
  namespace: local-path-storage
data:
  config.json: |-
    {
            "nodePathMap":[
            {
                    "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
                    "paths":["/opt/local-path-provisioner"]
            }
            ]
    }
  setup: |-
    #!/bin/sh
    set -eu
    mkdir -m 0777 -p "$VOL_DIR"
  teardown: |-
    #!/bin/sh
    set -eu
    rm -rf "$VOL_DIR"
  helperPod.yaml: |-
    apiVersion: v1
    kind: Pod
    metadata:
      name: helper-pod
    spec:
      priorityClassName: system-node-critical
      tolerations:
        - key: node.kubernetes.io/disk-pressure
          operator: Exists
          effect: NoSchedule
      containers:
      - name: helper-pod
        image: m.daocloud.io/docker.io/library/busybox # ps：换
        imagePullPolicy: IfNotPresent

kubernetes是需要PKI才能执行多数操作:

1. kubelet的客户端证书:用于API服务器身份验证
2. kubelet服务证书:用于API服务器与Kubelet的会话
3. API服务器端点证书:用于HTTPS加密，确保通信加密
4. 集群管理员的客户端证书：管理员（我）的工作证明
5. API 服务器的客户端证书：用于和 Kubelet 的会话
6. API 服务器的客户端证书：用于和 etcd 的会话
7. 控制器管理器的客户端证书或 kubeconfig：用于和 API 服务器的会话
8. 调度器的客户端证书或 kubeconfig：用于和 API 服务器的会话
9. 前端代理的客户端及服务端证书

自定义证书

• 首先用kubeadm创建的kubernetes会生成集群所需地全部证书。
• 其次你可以自定义，通过--cert-dir来指定不同的目录
• 默认位置/etc/kubernetes/pki里面
• kubeadm init --cert-dir /自定义目录/或者在kubeadm自定义的config的certificatesDir字段进行目录指定

外部CA

指在 Kubernetes 集群中使用由外部证书颁发机构（CA）签发的证书，而不是由 kubeadm 自行生成和管理 CA 证书。这种模式下，所有的证书和密钥都是由外部的 CA 签发的，提供更高的安全性和信任度，尤其在有严格合规性要求的环境中。

使用外部 CA 模式配置 Kubernetes 集群

1. 准备外部 CA 签发的证书和密钥

   • 你需要从外部 CA 获取以下证书和密钥：
     • CA 证书 (ca.crt)
     • kube-apiserver 证书及其密钥 (apiserver.crt 和 apiserver.key)
     • kube-controller-manager 证书及其密钥（可选，如果需要）
     • kube-scheduler 证书及其密钥（可选，如果需要）
     • 其他组件所需的证书及其密钥（如 etcd 等）

2. 创建并配置 Kubernetes 配置文件

   • 创建一个 kubeadm 配置文件，如 kubeadm-config.yaml，并在其中指定 certificatesDir 和 ClusterConfiguration。示例如下：

     apiVersion: kubeadm.k8s.io/v1beta2 kind: ClusterConfiguration kubernetesVersion: stable-1.21 certificatesDir: /etc/kubernetes/pki apiServer: certSANs: - "your.domain.com" extraArgs: "tls-cert-file": "/etc/kubernetes/pki/apiserver.crt" "tls-private-key-file": "/etc/kubernetes/pki/apiserver.key"

3. 将外部 CA 签发的证书和密钥放置在指定目录

   • 复制外部 CA 签发的证书和密钥到 /etc/kubernetes/pki 目录或你在配置文件中指定

sudo cp /path/to/ca.crt /etc/kubernetes/pki/ca.crt
sudo cp /path/to/apiserver.crt /etc/kubernetes/pki/apiserver.crt
sudo cp /path/to/apiserver.key /etc/kubernetes/pki/apiserver.key

4. 运行 kubeadm 初始化命令

• 使用 kubeadm 初始化命令并指定配置文件来初始化 Kubernetes 集群：

  sudo kubeadm init --config kubeadm-config.yaml

检查证书

kubeadm certs check-expiration

ps:

1. kubeadm不能管理外部ca

2. 没有kubelet.conf的原因是kubeadm会将kubelet配置为自动更新证书，轮换在/var/lib/kubelet/pki

• 轮询失败暂时参考：https://kubernetes.io/zh-cn/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert

自动更新证书

kubeadm 提供了一种机制，在集群控制面（control plane）升级时自动更新所有证书。这种方式简化了证书管理，并确保在定期升级 Kubernetes 版本时保持集群的安全性。下面是详细的操作步骤和相关说明。

自动更新证书的机制

当你使用 kubeadm upgrade apply 命令升级控制面节点时，kubeadm 会自动更新所有的证书。

进。

禁用自动证书更新

如果你有更复杂的证书管理需求，可以选择在升级时禁用自动证书更新。可以通过传递 --certificate-renewal=false 参数来实现。

1. 升级控制面节点时禁用证书更新：

   sudo kubeadm upgrade apply v1.xx.x --certificate-renewal=false

   其中 v1.xx.x 为目标 Kubernetes 版本。

2. 升级 worker 节点时禁用证书更新：

   sudo kubeadm upgrade node --certificate-renewal=false

手动启用证书更新

在 Kubernetes 1.17 版本之前，kubeadm upgrade node 命令的 --certificate-renewal 参数默认值为 false，需要显式地设置为 true。

显式启用证书更新的操作步骤

1. 升级控制面节点时显式启用证书更新：

   sudo kubeadm upgrade apply v1.xx.x --certificate-renewal=true

2. 升级 worker 节点时显式启用证书更新：

   sudo kubeadm upgrade node --certificate-renewal=true

手动更新证书

# 执行完此命令之后你需要重启控制面 Pod,运行了一个 HA 集群，这个命令需要在所有控制面板节点上执行。
kubeadm certs renew (all)

ps:kubeadm通常会把admin.conf 证书复制到 $HOME/.kube/config 中，在这样的系统中，为了在更新 admin.conf 后更新 $HOME/.kube/config 的内容， 你必须运行以下命令：

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

PVC

• 用于请求和绑定持久化存储卷pv,PVC 独立于具体的存储实现，可以通过存储类（StorageClass）来动态配置和管理存储资源。

yaml参考

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gih 

K.os

• 应该是可以理解为通过pvc进行申请后，StorageClass会根据pvc来动态创建pv

  configMap

• 于在集群中管理非机密数据配置，将配置信息从代码中分离出来，注入配置数据的方法，便于管理和更新。

K.os

• 可以用键值得形式存储重要数据

secret

可以参考：

持久卷

为Pod提供独立于Pod生命周期的持久存储。

PV

• 一块存储资源。它是集群级别的资源，与Pod的生命周期分离。PV可以由管理员预先创建，也可以通过存储类动态创建。

静态

• 写完直接apply

  apiVersion: v1 kind: PersistentVolumeClaim metadata: name: my-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi

  动态

• 需要一个存储类StorageClass进行动态申领，就是想定义好StorageClass，再进行pvc进行获取

绑定

• Kubernetes会根据PVC的需求自动寻找和绑定合适的PV。

回收

• 当PVC被删除后，PV的回收策略决定了PV的处理方式。回收策略有三种：Retain、Recycle和Delete。

1. Retain：保留数据，管理员可以手动处理数据。
2. Recycle：清空数据后重新供PVC使用（已弃用）。
3. Delete：删除PV和存储数据。

K.os

• 可以理解成物理卷一样，都是可以当作一块存储。但是后续的操作不一样，this.pv是能够通过StorageClass动态创建。

投射卷

• 将多种不同类型的数据源投射到 Pod 内的单个卷中。这些数据源包括 Secret、ConfigMap、Downward API 和 ServiceAccount Token 等。投射卷的一个主要优势是，它可以将多个来源的数据整合到一个挂载点，从而简化了数据管理和使用。

apiVersion: v1
kind: Pod
metadata:
  name: projected-volume-pod
spec:
  containers:
  - name: my-container
    image: nginx
    volumeMounts:
    - name: my-projected-volume
      mountPath: /etc/projected-volume
  volumes:
  - name: my-projected-volume
# 这里11111
    projected:
      sources:
      - configMap:
          name: my-config
      - secret:
          name: my-secret
      - downwardAPI:
          items:
          - path: "labels"
            fieldRef:
              fieldPath: metadata.labels
      - serviceAccountToken:
          path: "token"
          expirationSeconds: 3600
          audience: "api"

存储类

用来定义PV的资源对象

属性

Provisioner：定义由谁负责提供存储资源。不同的 Provisioner 对应不同的存储系统，如 kubernetes.io/aws-ebs 对应 AWS 的 EBS 存储，kubernetes.io/gce-pd 对应 Google Cloud 的 Persistent Disk，等等。

Parameters：提供给存储系统的参数。例如，对于 AWS EBS，可以指定卷类型（如 gp2、io1 等）、IOPS 等参数。

ReclaimPolicy：定义 PV 被释放后如何处理。有两种策略：

Retain：保留存储资源供管理员手动回收。
Delete：自动删除存储资源。
AllowVolumeExpansion：指示是否允许动态扩展存储卷大小。

MountOptions：提供给挂载卷的选项，这些选项会应用于挂载存储卷时。

VolumeBindingMode：定义 PV 的绑定模式，主要有两种：

Immediate：PV 会立即绑定到 PVC。
WaitForFirstConsumer：PV 会等待第一个消费者（Pod）出现后再绑定，以便更好地优化存储资源分配。

apiVersion: storage.k8s.io/v1  # 指定API版本
kind: StorageClass            # 声明资源类型为StorageClass
metadata:
  name: fast                  # StorageClass的名称，用户定义的标识
provisioner: kubernetes.io/aws-ebs  # 指定Provisioner类型，这里使用AWS EBS作为存储提供者
parameters:
  type: io1                   # 指定AWS EBS卷的类型，这里使用io1类型
  iopsPerGB: "10"             # 指定每GB卷的IOPS（仅对io1类型有效）
  fsType: ext4                # 指定文件系统类型，默认为ext4
reclaimPolicy: Retain         # 设置回收策略，Retain表示保留PV供管理员手动回收
allowVolumeExpansion: true    # 允许动态扩展存储卷大小
mountOptions:
  - debug                     # 挂载卷时的选项，这里使用debug模式
volumeBindingMode: WaitForFirstConsumer  # 设置卷绑定模式，WaitForFirstConsumer表示等待第一个消费者出现再绑定

节点资源规划（仅学习）

资源规划：一个master，两个work（非测试不建议这种模式，无高可用）
master： 16c,32g,200G,200G(空)
work : 16c,32g,200G,200G(空)

选择安装工具

1. 首先DNS更正223.5.5.5，223.6.6.6
2. 选择后国内清华源的K8s软件库：

• https://mirrors.tuna.tsinghua.edu.cn/help/kubernetes/

3. 选择containerd运行时
4. 安装ipvs

个人理解：环境主要在三节点上有kubelet，kubectl，主节点多一个初始化的kubeadm。然后主节点用kubeadm进行初始化主节点，然后进行containerd运行时进行组件的拉取和运行。组成一个集群。

设置

各种安装过程我们跳过哈,然后我们深度聊一聊一些环境的设置

环境设置

内核参数调整

什么是内核参数呢，会影响什么

内核参数是配置Linux内核行为的设置。这些参数控制系统的各种功能，如内存管理、网络设置、文件系统行为等。内核参数通常通过/etc/sysctl.conf文件进行配置，并通过sysctl命令加载和应用。常用的内核参数请看
Linux从核心到边缘 | Kalyan的小书房 (zitiu.top)

需要调整的内核参数

vm.swappiness = 0  # 减少swap分区使用
net.ipv4.ip_forward = 1 # 允许linux内核将网络流量从一个网络接口转发到另一个网络接口
net.bridge.bridge-nf-call-iptables=1 # 启用 bridge-nf-call-iptables
net.ipv4.ip_forward=1 # 启用 IP 转发

这里通常会有一个问题，当你sysctl -p采用的时候可能会报错

sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-iptables: No such file or directory
sysctl: cannot stat /proc/sys/net/bridge/bridge-nf-call-ip6tables: No such file or directory

这个时候你可以

# 启用 bridge-nf-call-iptables
sudo modprobe br_netfilter
echo 1 | sudo tee /proc/sys/net/bridge/bridge-nf-call-iptables
echo "net.bridge.bridge-nf-call-iptables=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

# 启用 IP 转发
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

最后进行微调

# 创建一个文件，将需要的内核模块写入其中，以便在系统启动时自动加载这些模块
tee /etc/modules-load.d/k8s.conf <<'EOF'
# netfilter 模块，允许 iptables 检查桥接流量
br_netfilter
# containerd 文件系统支持
overlay
# IPVS (IP Virtual Server) 模块，用于负载均衡
ip_vs
# 轮叫调度算法
ip_vs_rr
# 加权轮叫调度算法
ip_vs_wrr
# 源地址散列调度算法
ip_vs_sh
# 连接跟踪模块，用于跟踪网络连接状态
nf_conntrack
EOF

# 创建目录以存放模块加载脚本
mkdir -vp /etc/modules.d/

# 创建一个脚本文件，立即加载所需的内核模块
cat > /etc/modules.d/k8s.modules <<EOF
#!/bin/bash
# 允许 iptables 检查桥接流量
modprobe -- br_netfilter
# containerd 文件系统支持
modprobe -- overlay
# IPVS 模块，用于负载均衡
modprobe -- ip_vs
# 轮叫调度算法
modprobe -- ip_vs_rr
# 加权轮叫调度算法
modprobe -- ip_vs_wrr
# 源地址散列调度算法
modprobe -- ip_vs_sh
# 连接跟踪模块，用于跟踪网络连接状态
modprobe -- nf_conntrack
EOF

# 给脚本文件赋予执行权限
chmod 755 /etc/modules.d/k8s.modules

# 运行脚本，立即加载所需的内核模块
bash /etc/modules.d/k8s.modules

# 验证内核模块是否加载成功，查看加载的模块列表中是否包含 ip_vs 和 nf_conntrack 模块
lsmod | grep -e ip_vs -e nf_conntrack

# 应用 sysctl 配置，确保所有内核参数设置立即生效
sysctl --system

# 重启系统，确保所有配置在系统重启后自动生效
reboot

什么是swap分区,为什么要删除.

• 你可以把swap分区简单理解成是为了分担RAM的负担的这么一个作用,你可以想象一下你有一个书桌,你工作的时候,为了快速获取资料,你会在书桌上堆满书本,这个时候swap就像书架一样,在书架取书会有点慢,但是你起码有位置放书.

• 那么为什么我们要在kubernetes中要删除呢,继续刚刚的比喻,现在一个研究馆内,有很多书桌(节点),管理人员(k8s调度器)会根据每个人的书桌的容量进行任务的合理分配.如果启动了书架(swap),管理人员可能不知道,你书桌上的实际容量,要是书桌(RAM)把大量资源放到了书架(swap)上,管理人员(调度器)看你的书桌(RAM)空闲,把大量的资源工作丢给你,可能会导致书桌(RAM)的坍塌

• 一句话:k8s调度器无法知道swap分区里面的情况.

防火墙

这个就不说了,主要是为了更好的后续node以及pod会有自己的网络体系,为了适配关掉最好.

ufw disable && systemctl disable ufw
swapoff -a && sed -i 's|^/swap.img|#/swap.ing|g' /etc/fstab

加入清华源后安装系列工具

apt install containerd -y 
# 启动
systemctl daemon-reload
systemctl enable containerd
systemctl restart containerd

containerd设置-配置runtime-endpoint

# containerd - 运行时设置,这一步不能出错
crictl config runtime-endpoint /run/containerd/containerd.sock

要是出现无法连接的情况就检查三个地方

# 是否有/etc/containerd/config.toml 用于配置管理containerd容器运行时守护进程的行为。
mkdir -vp /etc/containerd/
containerd config default > /etc/containerd/config.toml
# 将配置文件中所有出现的 k8s.gcr.io 替换为 registry.cn-hangzhou.aliyuncs.com/google_containers
sed -i "s#k8s.gcr.io#registry.cn-hangzhou.aliyuncs.com/google_containers#g"  /etc/containerd/config.toml
# 这里有点问题，需要提前把SystemdCgroup = false删除掉，否则会有重复定义的错误。
sed -i '/containerd.runtimes.runc.options/a\ \ \ \ \ \ \ \ \ \ \ \ SystemdCgroup = true' /etc/containerd/config.toml
# 修改版
CONFIG_FILE="/etc/containerd/config.toml"; grep -q 'SystemdCgroup' "$CONFIG_FILE" && sed -i 's/SystemdCgroup =.*/SystemdCgroup = true/' "$CONFIG_FILE" || sed -i '/containerd.runtimes.runc.options/a\ \ \ \ \ \ \ \ \ \ \ \ SystemdCgroup = true' "$CONFIG_FILE"
# 将配置文件中所有出现的 https://registry-1.docker.io 替换为 https://xlx9erfu.mirror.aliyuncs.com。
sed -i "s#https://registry-1.docker.io#https://xlx9erfu.mirror.aliyuncs.com#g"  /etc/containerd/config.toml
# 是否有/etc/crictl.yaml
runtime-endpoint: "unix:///run/containerd/containerd.sock"
image-endpoint: ""
timeout: 0
debug: false
pull-image-on-create: false
disable-pull-on-run: false
# 是否有/run/containerd/containerd.sock

验证containerd的情况

# 能看这个套接字sock是否有正常连接到crictl工具
crictl info 
# 能够查询失败部署容器
crictl ps -a | grep kube | grep -v pause
# 能够查看日志
crictl  logs CONTAINERID

初始化主节点

# 生产配置模板，自己把imageRepository改成自己加速的镜像源。
kubeadm config print init-defaults > kubeadm.yaml
#初始化
kubeadm init --config=kubeadm.yaml --v=5
# 查看镜像列表
kubeadm config images list
# 然后进行拉取
crictl pull

ps:一定要仔细配置kubeadm。

要是containerd有问题的话，修改过config.toml，记得restart一下然后记得

kubeadm reset -f --cri-socket unix:///run/containerd/containerd.sock

ps:修改镜像源后记得修改一下containerd里面的pause的镜像源。

给个样板在这里：

apiVersion: kubeadm.k8s.io/v1beta3
bootstrapTokens:
- groups:
  - system:bootstrappers:kubeadm:default-node-token
  token: abcdef.0123456789abcdef
  ttl: 24h0m0s
  usages:
  - signing
  - authentication
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 10.70.49.131 # 必填
  bindPort: 6443
nodeRegistration:
  criSocket: unix:///run/containerd/containerd.sock #最好加上unix://
  imagePullPolicy: IfNotPresent # 可以忽略镜像拉取，后续可以手动拉
  name: masternode-1 # 必填
  taints: null
---
apiServer:
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta3
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns: # dns有点ex，注意镜像源
  type: CoreDNS
  imageRepository: k8s.m.daocloud.io/coredns
  imageTag: v1.10.1
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: k8s.m.daocloud.io
kind: ClusterConfiguration
kubernetesVersion: 1.28.0
networking:
  dnsDomain: cluster.local
  serviceSubnet: 10.96.0.0/12
  podSubnet: 10.244.0.0/16
scheduler: {}
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: ipvs # 开启ipvs模式
---
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
cgroupDriver: systemd

calico

wget https://docs.projectcalico.org/v3.18/manifests/calico.yaml

然后自己配置一下

然后apply一下。等待跑起来

哪个拉不起来就去对应的controlby，或者直接deploy上修改image。然后正常来说的话就基本node全部ready

起因是拉起某个pod的时候持续不断的错误边拉边寄，显示的不是image问题。

尝试describe一下，发现调度，拉取，创建，启动似乎都正常

这个时候就得去看日志kubectl log一下，

？？？timeout？？？kubectl 正常能get不至于访问不到api，api是包正常的。

那就是网络问题，先看一下插件，插件也正常。

再看DNS，似乎有点问题，丢了master3的conredns？？？

但是查询后这个pod的是属于master1的pod所以不是dns的问题，缺一个的问题后面再解决。
按着尝试手动再吃连接api服务器,草pod fail了，所以用不了，先标记

kubectl exec -it kcollie-pre-hook-install-crds-bdb4g -n kcollie-system -- /bin/sh
curl -k https://10.233.0.1:433

再check一下kube-system的pod

md草了，有屎啊，节点二怎么就timeout了，相继的节点一三也爆屎了。

看一下节点情况，感觉可以rollout整个kube-system，完蛋，怎么查个pod状态，查到整个kube崩了

直接rollout所有

# 重启所有 Deployments
for deployment in $(kubectl get deployments -n kube-system -o jsonpath='{.items[*].metadata.name}'); do
  kubectl rollout restart deployment $deployment -n kube-system
done

# 重启所有 StatefulSets
for statefulset in $(kubectl get statefulsets -n kube-system -o jsonpath='{.items[*].metadata.name}'); do
  kubectl rollout restart statefulset $statefulset -n kube-system
done

# 重启所有 DaemonSets
for daemonset in $(kubectl get daemonsets -n kube-system -o jsonpath='{.items[*].metadata.name}'); do
  kubectl rollout restart daemonset $daemonset -n kube-system
done

总算是起来了，然后有一个node还是not ready，估计是node3的某些pod还没好，但是报错还是

不懂，node1的apiserver明明好好的，coredns也没问题。

又死了，草啊啊啊啊啊啊啊啊啊啊。节点不知道为什么十分的不稳定，似乎不断崩溃重启，直接停机加内存。

估计上面的Error是不怎么影响的。。。。。。。。重启然后就没事了。

介绍

KIND，全称“Kubernetes IN Docker”，是一个开源工具，用于在本地开发和测试 Kubernetes 集群。KIND 允许在 Docker 容器中运行 Kubernetes 集群，从而便于开发者快速创建和销毁 Kubernetes 集群，提升开发效率。

安装和配置

前置条件

在使用 KIND 之前，你需要确保以下软件已经正确安装：
Docker
kubectl
确保 Docker 已经启动，并且你的用户在 docker 组中，以便能够运行 Docker 命令而无需 sudo。

安装 KIND

在 Linux 环境中，可以通过以下命令获取和安装 KIND：

curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.11.1/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

检查安装

验证 KIND 是否安装成功：

kind –version
你应该看到类似 kind v0.11.1 的输出。

创建 Kubernetes 集群

简单创建一个集群

使用以下命令创建一个默认的 Kubernetes 集群：

kind create cluster
成功创建后，你会看到与集群相关的信息输出。

自定义配置创建集群

为了更具定制化，可以使用 YAML 文件：

创建 kind-config.yaml 文件：

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:

• role: control-plane
• role: worker
• role: worker
  使用以下命令创建集群：

kind create cluster –config kind-config.yaml

查看集群状态

验证集群状态：

kubectl cluster-info –context kind-kind

实战操作

部署应用到 KIND 集群

创建一个名为 nginx-deployment.yaml 的文件：

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
使用 kubectl 部署：

kubectl apply -f nginx-deployment.yaml

验证部署

查看部署的状态：

kubectl get deployments
查看 Pods 状态：

kubectl get pods

暴露服务

创建一个名为 nginx-service.yaml 的文件：

kind: Service
apiVersion: v1
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:

• protocol: TCP
  port: 80
  targetPort: 80
  type: LoadBalancer
  使用 kubectl 暴露服务：

kubectl apply -f nginx-service.yaml

KIND的应用场景和作用

开发和测试环境

在本地开发和测试 Kubernetes 应用，KIND 的特性让开发者可以快速创建和删除集群，大大提高了开发效率。

CI/CD管道

在 CI/CD 管道中，KIND 可以在每次代码变更时快速创建一个新的 Kubernetes 集群用于测试，确保代码的稳定性和一致性。

学习和培训

KIND 非常适合用于学习和培训，可以在本地快速搭建 Kubernetes 环境，使学习者掌握 Kubernetes 基本操作和概念。

注意事项

KIND 是基于 Docker 容器的，因此某些 Kubernetes 高级功能可能不完全支持。
偶尔你可能需要手动清理 Docker 容器和网络设置，特别是在多次创建和删除集群后。
不建议在生产环境中使用 KIND，它更适用于开发和测试用途。

结论

KIND 是一个非常方便的工具，可以帮助我们在本地快速搭建和管理 Kubernetes 集群。无论是开发测试、CI/CD 还是学习培训，KIND 都能发挥其巨大的作用。

一个开源的监控和告警系统

特点

多维数据模型

• 使用时间序列数据，每个序列有一个度量指标（metricname）和一组键值对（labels）标识，这样可以灵活对同一类进行细分。

  度量指标

• counter：计数器，用于记录累计值，例如请求次数。
• gauge：测量值，可增可减，例如当前内存使用量。
• histogram：直方图，用于记录值分布，例如请求延迟。
• summary：摘要，用于统计分位数和总和，例如响应时间的分位数。

标签

• 一组键值对，用于对时间序列进行细分和区分。例如，监控一个 HTTP 请求的计数器可以通过标签区分不同的请求路径和状态码

http_requests_total{method="POST", handler="/api/v1", status="200"}
http_requests_total{method="GET", handler="/api/v1", status="500"}

例子

假设我们有一个 Web 服务，它记录了每个请求的数量和响应时间。我们可以定义以下指标：

1. 记录请求数量的计数器：
   • Metric Name: http_requests_total
   • Labels: method, handler, status
2. 记录响应时间的直方图：
   • Metric Name: http_request_duration_seconds
   • Labels: method, handler

每次有新的请求进来，计数器和直方图都会更新。例如：

http_requests_total{method="POST", handler="/api/v1", status="200"} 1234
http_requests_total{method="GET", handler="/api/v1", status="500"} 56
http_request_duration_seconds_bucket{method="POST", handler="/api/v1", le="0.1"} 5
http_request_duration_seconds_bucket{method="POST", handler="/api/v1", le="0.5"} 50

支持PromQL

查询所有 POST 请求的数量：

promql
复制代码
sum(http_requests_total{method="POST"})

查询 /api/v1 接口的所有请求数量：

promql
复制代码
sum(http_requests_total{handler="/api/v1"})

查询状态码为 200 的请求数量：

promql
复制代码
sum(http_requests_total{status="200"})

优化使用标签

• 标签数目不要过多：过多的标签会导致时间序列爆炸，影响性能。
• 标签值尽量稳定：标签值变化太频繁会增加存储和查询负担。
• 合理设计标签：确保标签的选择能够满足查询需求，同时不过度细化。

时间序列数据库

TSDB Prometheus自带时序数据库

特点

高效写入：Prometheus 的 TSDB 能够每秒写入数百万个样本，适合高频数据采集。
高效查询：针对时间序列数据优化的查询性能。
数据压缩：使用差分编码和 Gorilla 压缩算法减少存储空间。
局部存储：数据默认存储在本地磁盘上，可以通过远程存储扩展。

数据结构

样本 (Sample)：包含一个时间戳和一个值。
时间序列 (Time Series)：由一个度量名和一组标签唯一标识的一组样本。
块 (Block)：TSDB 中的数据以块的形式存储，每个块通常覆盖 2 小时的数据。
WAL (Write-Ahead Log)：在写入到块之前，数据先写入 WAL，以确保数据持久化。

数据存储和管理

1. 数据存储路径：默认存储路径为 /var/lib/prometheus，可以在 Prometheus 配置文件中通过 storage.tsdb.path 参数修改。
2. 数据保留策略：默认保留 15 天的数据，可以通过 –storage.tsdb.retention.time 参数设置。
3. 数据压缩和删除：Prometheus 会自动压缩和删除过期数据。

   独立抓取模型：

基本概念

1. Scrape：Prometheus 从目标处获取监控数据的过程。
2. Target：被监控的对象，可以是服务器、应用程序、数据库等。
3. Job：一组相似目标的集合。
4. Exporter：用于将目标的数据暴露给 Prometheus 的组件，通常是 HTTP 端点

配置文件’prometheus.yml’

global:
  scrape_interval: 15s     # 每15秒抓取一次数据
  evaluation_interval: 15s # 每15秒评估一次规则

抓取配置

抓取配置定义了 Prometheus 如何发现和抓取目标数据。

scrape_configs:
  - job_name: 'prometheus'
    static_configs:
      - targets: ['localhost:9090']

动态服务发现

Prometheus 支持多种服务发现机制，允许动态发现目标。例如，可以使用 Kubernetes、Consul、Etcd 等进行服务发现。

####### Exporter
Exporter 是将监控数据暴露给 Prometheus 的组件，不同的应用和系统有不同的 Exporter。例如：

• Node Exporter：用于监控操作系统的资源使用情况。
• Blackbox Exporter：用于进行探测和检查（如 HTTP、HTTPS、TCP）。
• MySQL Exporter：用于监控 MySQL 数据库。

多种数据支持：

支持包括通过导出器（exporters）收集第三方系统的数据，支持服务发现（Service Discovery），如 Kubernetes、Consul、Etcd 等

告警：

内置了 Alertmanager，用于处理告警通知和管理告警规则。

结构

1. Prometheus Server：
   存储：使用基于时间序列数据库（TSDB）的本地存储来存储监控数据。
   抓取（Scrape）：定期从目标端点（如应用程序、数据库等）拉取指标数据。
   PromQL 查询引擎：允许用户通过 PromQL 查询存储的数据。
2. 数据导出器（Exporters）：
   节点导出器（Node Exporter）：收集系统级别的指标，如 CPU、内存、磁盘使用等。
   应用程序导出器：如 MySQL Exporter、Redis Exporter，专门用于从特定应用中收集指标。
3. 服务发现（Service Discovery）：
   支持多种服务发现机制，如 Kubernetes、Consul、DNS 等，自动发现并监控动态变化的服务和主机。
4. Alertmanager：
   告警规则：定义告警规则，当满足条件时触发告警。
   告警通知：管理告警的路由和发送，支持多种通知方式，如电子邮件、Slack、PagerDuty 等。
   告警抑制和分组：可以配置告警抑制规则和告警分组，避免告警风暴。
5. Pushgateway：
   用于接收临时性任务（如批处理任务）的指标数据，这些任务无法被 Prometheus 定期拉取。

工作流程

1. 配置和服务发现：通过配置文件或服务发现机制，Prometheus 确定需要监控的目标。
2. 抓取数据：Prometheus 定期从目标端点拉取指标数据。
3. 存储数据：将拉取到的指标数据存储在本地的时间序列数据库中。
4. 查询和可视化：通过 PromQL 查询数据，结合 Grafana 等可视化工具展示监控结果。
5. 告警处理：根据定义的告警规则，Prometheus 触发告警并通过 Alertmanager 发送通知。

用于配置管理、应用程序部署、任务自动化

ansible主机清单

定义组

[webservers] # 定义组
xxx.xxx.com
xxx.xxx.com

[dbserver] # 定义组
xxx.xxx.com
xxx.xxx.com

[dce5_nodes]
10.70.49.17[2:4]

[all:vars] # 定义全局变量适用于全部主机

# Ansible SSH 用户名，用于连接到目标主机
ansible_ssh_user: guest2admin

# Ansible SSH 密码，用于连接到目标主机
ansible_ssh_pass: @users

# Ansible 使用的 Python 解释器路径
ansible_python_interpreter: /usr/bin/python

# SSH 连接的通用参数，这里指定了加密算法为 AES-256-CBC
ansible_ssh_common_args: -c aes256-cbc

# 指定 Ansible 连接到主机的方式，这里使用 SSH
ansible_connection: ssh

# 提权操作时使用的密码（例如切换到 root 用户时的密码）
ansible_become_password: root@root@su

# 提权方法，这里使用 su 命令切换用户
ansible_become_method: su

# 提权执行命令，这里指定了使用 sudo su - 命令来切换到超级用户
ansible_become_exe: sudo su -

# 还可以组别变量
[webserver:vars]

o打

1. Ping 模块

   ansible all -m ping

   通过 Ping 模块测试所有主机是否可达。

2. Shell 模块

   ansible all -m shell -a 'uptime'

   在所有主机上执行 uptime 命令。

3. Command 模块

   ansible all -m command -a 'ls /tmp'

   使用 command 模块列出 /tmp 目录下的文件。

4. Copy 模块

   ansible all -m copy -a 'src=/path/to/source dest=/path/to/destination'

   将本地文件复制到远程主机。

5. File 模块

   ansible all -m file -a 'path=/tmp/testfile state=touch'

   在远程主机上创建一个空文件。

6. Service 模块

   ansible all -m service -a 'name=httpd state=started'

   启动所有主机上的 httpd 服务。

7. User 模块

   ansible all -m user -a 'name=johndoe state=present'

   创建一个名为 johndoe 的用户。

常用选项

• -i <inventory>：指定主机清单文件。例如 -i hosts。
• --list-hosts：列出将运行任务的主机。
• -l <subset>：指定要执行任务的主机子集。例如 -l webservers。
• -u <user>：指定远程主机用户。例如 -u root。
• -k：提示输入 SSH 密码。
• --ask-become-pass：提示输入 sudo 密码。
• -e <extra_vars>：传递额外变量。例如 -e "var1=value1 var2=value2"。

示例详解

1. 列出主机

   ansible all --list-hosts

   列出所有在清单中的主机。

2. 指定用户和密码执行命令

   ansible all -m shell -a 'df -h' -u root -k

   使用 root 用户执行 df -h 命令，并提示输入密码。

3. 传递额外变量

   ansible all -m shell -a 'echo {{ var_name }}' -e 'var_name=HelloWorld'

   传递变量 var_name，并在命令中使用。

高级用法

1. 使用标签

   ansible all -m shell -a 'systemctl restart httpd' --tags "restart"

   使用标签来组织和执行特定的任务。

2. 检查主机连通性

   ansible all -m ping -i inventory/hosts

   使用指定的主机清单文件检查连通性。

是一种架构，为了解决服务和服务之间的通信。

服务网格接口（打算理解）

SMI

用于定义服务网格标准化接口的规范，旨在提供一个通用的接口，让不同的服务网格实现可以互操作。SMI的主要目的是简化服务网格的使用和集成，使用户可以使用统一的API管理不同的服务网格实现，如Istio、Linkerd、Consul Connect等。

CRD

是Kubernetes中的一种机制，用于扩展Kubernetes API，使用户可以定义自己的资源类型。通过CRD，用户可以创建自定义资源（CR），这些资源可以与Kubernetes内置资源（如Pod、Service）一样进行管理和操作。

数据平面代理

负责处理和管理服务间流量的代理组件。

核心职责:
流量转发：代理组件负责接收、转发和负载均衡服务之间的流量。这包括 HTTP、gRPC、TCP 等多种协议。
服务发现：代理可以自动发现 Kubernetes 中的服务，根据服务的配置进行相应的流量路由。
流量管理：包括流量控制、重试策略、断路器、故障注入等功能，以保证服务间通信的可靠性和稳定性。
安全：提供 mTLS（双向 TLS）加密来确保服务间通信的安全性，支持认证和授权策略。
监控和可观测性：代理会收集并上报各种流量指标和日志，帮助管理员监控和诊断服务间的通信问题。

数据平面架构

代理附件

一般部署在工作负载的pod上，后续会拦截进出服务的所有通信，但是在一些升级上，代理附件不能保证在不重建Pod的条件下进行升级

代理节点

由代理节点来处理运行服务的所有流量。但是会存在很大的网络瓶颈。

Envoy

一个高性能的开源边缘和服务代理，主要用于微服务架构中的通信管理

场景

API网关：

Envoy可以作为API网关，处理外部请求并将其路由到内部服务，同时提供认证、限流、缓存等功能。

边车代理：

• 是一种设计模式，在这种模式下，一个代理程序（如Envoy）被部署在每个服务实例的旁边，这样每个服务实例都有一个独立的代理来处理进出流量。
• 在服务网格架构中，Envoy通常以边车代理的形式部署在每个服务实例旁，拦截和处理所有入站和出站流量。
• 边车注入是将边车代理自动注入到服务实例的Pod中，以便在微服务架构中实现服务网格功能的过程。分为手动与自动，自动注入似乎能够用istio来进行自动注入。
• Sidecar 模式：Envoy 通常以 sidecar 容器的形式部署在每个微服务 Pod 内，与应用容器共享网络命名空间。所有进出微服务的流量都会通过 Envoy 代理。

中介层代理：

Envoy可以部署在不同的服务层之间，作为中介层代理，处理跨服务的流量和策略管理。

模块化架构

Listener：
作用：Listener是Envoy用于监听网络端口的组件，负责接受客户端的连接请求。每个Listener都绑定到一个特定的IP地址和端口，并根据配置将流量传递给相应的处理模块。
配置：Listener的配置包括监听的地址和端口、使用的协议（如HTTP、TCP）、以及关联的过滤器链。

Filter：
作用：Filter是Envoy用于处理请求和响应的中间处理模块。Filter可以用于修改请求、添加日志、执行身份验证、路由选择等。Envoy的Filter分为多种类型，包括网络过滤器、HTTP过滤器和TCP过滤器。
类型：
网络过滤器：处理TCP连接层面的流量，如TLS终止、连接限速等。
HTTP过滤器：处理HTTP请求和响应，如修改头部信息、执行认证和授权、负载均衡等。
TCP过滤器：处理TCP层流量，如TCP代理、流量镜像等。

Cluster：
作用：Cluster是Envoy用于表示一组上游服务实例的组件。Cluster负责服务发现、负载均衡、健康检查等。每个Cluster包含多个主机（即上游服务实例），并定义了如何将流量分配到这些主机上。
配置：Cluster的配置包括服务发现类型（静态、DNS、EDS等）、负载均衡策略（如轮询、随机、加权轮询等）、健康检查配置等。

Route：
作用：Route组件定义了Envoy如何将请求路由到不同的Cluster。Route规则基于请求的属性（如路径、头部信息、方法等）来决定具体的路由目标。
配置：Route的配置包括匹配规则、路由目标Cluster、重试策略、超时设置等。

Admin：
作用：Admin组件提供了管理和监控Envoy的接口。通过Admin接口，用户可以查看Envoy的运行状态、统计信息、配置详情，并进行管理操作。
配置：Admin接口通常通过HTTP API暴露，可以在Envoy配置中指定Admin的监听地址和端口。

配置管理

配置管理
Envoy的配置管理可以通过静态文件配置，也可以通过动态配置API（xDS）实现。xDS（Envoy Dynamic Configuration API）包括以下几个部分：
ADS（Aggregated Discovery Service）：聚合配置服务，统一管理其他xDS服务。
CDS（Cluster Discovery Service）：动态管理Cluster的配置。
EDS（Endpoint Discovery Service）：动态管理Cluster中上游服务实例的配置。
LDS（Listener Discovery Service）：动态管理Listener的配置。
RDS（Route Discovery Service）：动态管理路由配置。
SDS（Secret Discovery Service）：动态管理密钥和证书。

控制平面

负责管理和协调数据平面代理

配置管理：提供统一的配置接口，管理服务网格中所有代理的配置，包括路由规则、负载均衡策略、故障恢复策略等。
服务发现：集成服务发现机制，实时感知集群中服务的变化，并通知数据平面代理更新其配置。
安全管理：实现服务间的认证和授权，管理 TLS 证书的分发和轮换，确保服务间通信的安全性。
流量管理：提供流量路由、灰度发布、A/B 测试等高级流量控制功能，帮助开发和运维人员灵活管理服务间的流量。
可观测性：收集和聚合数据平面代理的监控指标、日志和分布式追踪数据，提供全局的可观测性视图，帮助排查和诊断问题。

istio

istiod为基于envoy的服务网络提供控制平面，他包括三个核心组件，Galley，Pilot，Citidel

Pilot：一个Envoy的配置服务器，实现 xDS API，并将配置流向与应用程序一起运行的Envoy代理。

Citadel：负责网格内的证书管理，建立服务器身份和相互TLS。

Galley：与外部系统互动，Kubernetes等。

webhook

用于在 Kubernetes 集群中实现动态配置和策略控制的关键组件。 Istio 中的主要用途包括服务网格控制、资源变更管理和策略执行等。

• 自动注入 Sidecar 容器:Istio 使用一个变异（Mutating）Webhook 自动将 Envoy 代理（Sidecar）注入到新创建的 Kubernetes Pod 中。这个过程确保每个服务都能被 Istio 管理和监控。当你为集群启用了自动注入，Webhook 会拦截 Pod 创建请求，在 Pod 完成调度之前往其定义中添加 Envoy 容器以及必要的配置信息。
• 配置验证（Validating Webhook）:验证（Validating）Webhook 用于在新的 Istio 配置资源（如 VirtualService、DestinationRule 等）创建或更新时执行验证过程，确保这些配置符合要求，避免因错误配置导致服务故障。这个 Webhook 会在配置提交到 etcd 之前进行执行，起到一个“守门人”的作用，阻止不符合标准的配置生效。
• 动态配置和策略控制:Webhook 还可以用于执行动态配置和策略决策。例如，通过 Webhook，可以向运行时注入配置参数或更新策略以应对瞬时需求或安全要求。

通过iptable达到工作负载通过Envoy发送流量。

Istio的iptables规则是通过init-containner来进行安装，拦截pod网络流量路由到Envoy。

initContainers:
”argS:
- istio-iptables
- --envoy-port #捕获出站的所有流量，并且发送到Envoy这个端口
- "15001"
- --inbound-capture-port #捕获入站的所有流量，并且发送Envoy这个端口1
- "15006"
- --proxy-uid
- "1337”
- --istio-inbound-interception-mode
- REDIRECT
--istio-service-cidr 
- '*'
--istio-inbound-ports 
- '*'
- --istio-local-exclude-ports
- 15090,15021,15020
image: docker.io/istio/proxyv2:1.6.7
imagePullPolicy: Always
name: istio-init