[2024/11/05 16:58:39.301 GMT+08:00] abc3a19a1358: Verifying Checksum[2024/11/05 16:58:39.301 GMT+08:00] abc3a19a1358: Download complete[2024/11/05 16:58:42.790 GMT+08:00] abc3a19a1358: Pull complete[2024/11/05 16:58:45.368 GMT+08:00] 5046bd3dbdb4: Pull complete[2024/11/05 16:58:45.368 GMT+08:00] Digest: sha256:49abd03aa63ce2e929564d858e18830eee7e577f3313d39b5cd91be763b3a3b6[2024/11/05 16:58:45.368 GMT+08:00] Status: Downloaded newer image for************[2024/11/05 16:58:49.694 GMT+08:00] + pip config set global.index-url http://mirrors.tools.huawei.com/pypi/simple[2024/11/05 16:58:49.699 GMT+08:00] starting check in ***/@tmp/durable-2c6c6cbc[2024/11/05 16:58:49.954 GMT+08:00] Writing to /home/build/.config/pip/pip.conf[2024/11/05 16:58:50.225 GMT+08:00] + pip config set global.trusted-host mirrors.tools.huawei.com[2024/11/05 16:58:50.510 GMT+08:00] Writing to /home/build/.config/pip/pip.conf[2024/11/05 16:58:50.510 GMT+08:00] + pip install -r requirements.txt --target=target[2024/11/05 16:58:51.089 GMT+08:00] Looking in indexes: http://mirrors.tools.huawei.com/pypi/simple[2024/11/05 16:58:51.089 GMT+08:00] WARNING: Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPConnection object at 0x7f9de550abe0>: Failed to establish a new connection: [Errno -2] Name or service not known',)': /pypi/simple/requests/[2024/11/05 16:58:51.660 GMT+08:00] WARNING: Retrying (Retry(total=3, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPConnection object at 0x7f9de550a9e8>: Failed to establish a new connection: [Errno -2] Name or service not known',)': /pypi/simple/requests/[2024/11/05 16:58:52.634 GMT+08:00] WARNING: Retrying (Retry(total=2, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPConnection object at 0x7f9de54aa5f8>: Failed to establish a new connection: [Errno -2] Name or service not known',)': /pypi/simple/requests/[2024/11/05 16:58:54.772 GMT+08:00] WARNING: Retrying (Retry(total=1, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPConnection object at 0x7f9de54aa7f0>: Failed to establish a new connection: [Errno -2] Name or service not known',)': /pypi/simple/requests/[2024/11/05 16:58:58.990 GMT+08:00] WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPConnection object at 0x7f9de54aa9e8>: Failed to establish a new connection: [Errno -2] Name or service not known',)': /pypi/simple/requests/[2024/11/05 16:58:58.990 GMT+08:00] ERROR: Could not find a version that satisfies the requirement requests (from versions: none)[2024/11/05 16:58:58.990 GMT+08:00] ERROR: No matching distribution found for requests[2024/11/05 16:58:59.008 GMT+08:00] [ERROR]  : script returned exit code 1, exitMessage is: command run failed[2024/11/05 16:59:00.601 GMT+08:00] dockerindocker18.09-1.3.3: Pulling from *****构建过程中，用的docker自动构建容器，指定requirements.txt，代码一直找http://mirrors.tools.huawei.com/pypi/simple下载requests模块，里边没有requests，封装就一直过不去...把模块一起上传可以正常封装，这个pip源的问题怎么解决？折腾了好几天，难道只能连模块一起上传么？

1 安装docker desktop 配置镜像源2 国内镜像源"registry-mirrors": [ "https://ccr.ccs.tencentyun.com", "https://docker.rainbond.cc", "https://elastic.m.daocloud.io", "https://elastic.m.daocloud.io", "https://docker.m.daocloud.io", "https://gcr.m.daocloud.io", "https://ghcr.m.daocloud.io", "https://k8s-gcr.m.daocloud.io", "https://k8s.m.daocloud.io", "https://mcr.m.daocloud.io", "https://nvcr.m.daocloud.io", "https://quay.m.daocloud.io" ]

华为云容器镜像docker登陆后push时仍然提示未登录 docker login -u cn-north-4@XXXXXXXXXX-p XXXXXXXXXXXX swr.cn-north-4.myhuaweicloud.com WARNING! Using --password via the CLI is insecure. Use --password-stdin. WARNING! Your password will be stored unencrypted in /home/crf/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credential-stores  Login Succeeded  sudo docker push swr.cn-north-4.myhuaweicloud.com/crf/mynginx:1.0 The push refers to repository [swr.cn-north-4.myhuaweicloud.com/xxxx/mynginx] 825fb68b6033: Preparing  7619c0ba3c92: Preparing  1c1f11fd65d6: Preparing  6b133b4de5e6: Preparing  3d07a4a7eb2a: Preparing  756474215d29: Waiting  8d853c8add5d: Waiting  denied: You may not login yet 

 前言 在日常生产环境中，我们通常会使用Docker来做容器化管理，通过运行容器来执行任务。但是，随着业务量的不断扩大，容器的不断启动，往往会出现磁盘空间不足的情况。  1、查看当前磁盘使用情况         df -h  其中Use%过大的目录需要排查 2、进入目录，查看当前目录下的文件大小         du -sh *  发现containers目录、overlayer2目录、volumes目录占用空间比较大 containers目录 进入某个容器目录，发现里面是Docker的日志文件  查看同级目录下的所有-json.log du -ha /home/docker/containers/ | grep "json.log" | sort -rh volumes目录         进入volumes目录中，查看大小         du -sh * 进入某个volume，查看其中内容，发现是数据卷内容，可以看情况清理 overlayer2目录 查看其中目录占用空间大小 发现其中部分目录占用空间较大，进入里面看看都由哪些东西 merged 和 diff 占磁盘空间比较大，work 目录可以不用管。 这两个文件夹内容开始是一样的 ，merged会多一些由容器本身产出的写文件，进merged继续往下找 进入./csp目录，发现其中有很多的日志文件  我这里是sentinel的日志，个人项目视情况是否删除，或者通过配置限制文件个数和大小。  3、解决方法 1、docker 镜像占用磁盘 Docker 中查询磁盘占用情况命令： docker system df   可通过执行docker system prune 命令可用于清理磁盘，删除关闭的容器、无用的数据卷和网络，以及dangling镜像（即无tag的镜像） 【慎用】 docker system prune -a 命令清理更干净、彻底，可以将没有容器使用的Docker镜像都删掉。  2、containers目录 Docker 容器的日志文件可能会增长并占用大量的磁盘空间。可以检查并删除不再需要的容器日志文件。  (1)临时方案：这个命令将删除 /home/docker/containers/ 目录下的容器日志文件。  sudo find /home/docker/containers/ -name "*-json.log" -type f -delete  (2)稳定方案：设置容器服务的日志大小上线  方式一：每个容器都可以单独设置  logging:   driver: "json-file"   options:     max-size: "256m"     max-file: "3"     方式二：全局设置   方式三：contab定时执行清理脚本  echo "======== start clean docker containers logs ========" logs=$(find /home/docker/containers/ -name *-json.log) for log in $logs         do                 echo "clean containers logs : $log"                 cat /dev/null > $log         done echo "======== end clean docker containers logs ========"    3、volumes目录   可通过命令删除  find /var/lib/docker/volumes -type f -name "*.log" -delete  3、overlayer2目录 通过排查overlayer2下merged目录中的占用空间较大的目录排查是否需要删除 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/weixin_44012070/article/details/139067735 

 一、引言 1、Elasticsearch简介 Elasticsearch是一个开源的、基于Lucene的分布式搜索和分析引擎，设计用于云计算环境中，能够实现实时的、可扩展的搜索、分析和探索全文和结构化数据。  1. 核心特性：  分布式：Elasticsearch是分布式的，可以在多个服务器上运行，并且能够自动将数据在服务器之间进行负载均衡。 可扩展性：Elasticsearch提供了可扩展的架构，无论是存储、节点还是查询吞吐量，都可以随着业务需求的变化而增加资源。它可以扩展到上百台服务器，处理PB级别的数据。 实时性：Elasticsearch能够实时地处理数据，提供了近实时的搜索和分析功能。 全文检索：Elasticsearch提供了全文检索功能，支持对大量数据进行复杂的搜索和分析。 分析性：Elasticsearch提供了强大的分析功能，包括聚合、统计和排序等。 多租户能力：Elasticsearch可以配置为多租户环境，允许不同的用户和应用共享相同的集群资源。 监控和警报：Elasticsearch提供了内置的监控和警报功能，使得用户可以实时了解系统的运行状态，并在出现异常时得到通知。    2. 数据支持：  Elasticsearch为所有类型的数据提供近乎实时的搜索和分析。无论您拥有结构化或非结构化文本、数字数据还是地理空间数据，Elasticsearch都能以支持快速搜索的方式高效地存储和索引它。  3. 技术实现：  Elasticsearch使用Java开发，并基于Lucene作为其核心来实现所有索引和搜索的功能。但其目的是通过简单的RESTful API来隐藏Lucene的复杂性，通过面向文档从而让全文搜索变得简单。 Elasticsearch支持多种数据类型，包括字符串、数字、日期等。 Elasticsearch的水平可扩展性允许通过增加节点来扩展其处理能力。 在硬件故障或节点故障的情况下，Elasticsearch具有容错能力，能够保持数据的完整性和服务的可用性。  4. 应用场景：  Elasticsearch在众多场景下都有广泛的应用，如企业搜索、日志和事件数据分析、安全监控等。  5. 集成方案：  Elasticsearch与名为Logstash的数据收集和日志解析引擎以及名为Kibana的分析和可视化平台一起开发的。这三个产品被设计成一个集成解决方案，称为“Elastic Stack”（以前称为“ELK stack”）。     2、为什么在k8s中部署elasticsearch 1. 自动化和编排  自动化部署和管理:  Kubernetes 提供了自动化的部署、扩展和管理功能，可以简化 Elasticsearch 集群的配置、启动和监控。 自愈能力:  Kubernetes 能够自动检测并重新调度失败的 Pod，确保 Elasticsearch 集群的高可用性和稳定性。  2. 可扩展性  水平扩展:  Elasticsearch 的节点可以在 Kubernetes 中水平扩展，通过增加或减少节点数目来应对数据量和查询量的变化。 弹性资源分配:  Kubernetes 允许为不同的 Elasticsearch 节点（如数据节点、主节点、协调节点）分配不同的资源配额，确保资源的合理利用和优化。  3. 高可用性  多副本管理:  Kubernetes 能够通过其副本控制器和 StatefulSets 管理 Elasticsearch 的数据副本和分片，确保在节点失败时数据不会丢失，并且服务能迅速恢复。 跨可用区分布:  Kubernetes 可以将 Elasticsearch 节点分布在不同的可用区（Availability Zones），提高容灾能力。  4. 容器化优势  一致的环境:  使用容器化的 Elasticsearch 可以确保在开发、测试和生产环境中运行的一致性，减少环境差异带来的问题。 依赖管理:  容器化可以简化依赖管理，确保 Elasticsearch 及其依赖组件能够在独立的环境中运行，不会相互干扰。 二、k8s基础 1、k8s简介 K8s，全称Kubernetes，是一个开源的容器编排系统，旨在自动化容器化应用程序的部署、扩展和管理。 1. 定义与概念： K8s是一个用于管理容器的开源平台，允许用户方便地部署、扩展和管理容器化应用程序。 它通过自动化的方式实现负载均衡、服务发现和自动弹性伸缩等功能。 Kubernetes将应用程序打包成容器，并将这些容器部署到一个集群中，自动处理容器的生命周期管理、自动扩容等操作。 2. 主要特点： 自动化管理：自动化管理容器应用程序的部署、扩展、运维等一系列操作，减少了人工干预，提高了效率。 弹性伸缩：根据应用负载情况自动进行扩容或缩容，保证应用的性能和稳定性。 高可用性：当某个节点故障时，K8s会自动将应用迁移至其他健康节点，保证应用的正常运行。 自愈能力：能够监测应用状态并进行自动修复，如自动重启或迁移故障应用。  3. 架构与组件： K8s集群由多个节点（Node）组成，包括Master节点和Worker节点。 Master节点作为整个集群的控制中心，负责集群的管理和调度工作，包括API服务器、调度器、控制器管理器等核心组件。 Worker节点是集群的工作节点，负责运行Pod（容器组）并提供应用程序的运行环境。 2、Pods、Services、StatefulSet等基本概念 2.1 Pods Pods 是Kubernetes中最小的可部署计算单元。一个Pod可以包含一个或多个容器，这些容器共享网络命名空间和存储资源，并总是共同调度在同一个节点上。  单容器Pod: 最常见的情况，一个Pod包含一个容器。 多容器Pod: 包含多个需要紧密协作的容器，例如共享存储或网络的协同进程。 特点：  共享相同的存储卷和网络命名空间。 作为一个整体被调度到同一个节点上。 2.2 Services Services 是一种抽象，它定义了一组逻辑上相同的Pods，并且提供一个稳定的访问入口（IP地址和端口）。Services实现了负载均衡，并且允许Pod进行自动发现和通信。 类型： ClusterIP: 默认类型，仅在集群内部可访问。 NodePort: 在每个节点上开放一个静态端口，使得服务可以通过<NodeIP>:<NodePort>访问。 LoadBalancer: 使用云提供商的负载均衡器，公开服务到外部网络。 ExternalName: 将服务映射到外部名称，比如DNS名称。 功能： 提供Pod的负载均衡。 稳定的网络接口，不会因为Pod的创建和销毁而变化。 2.3 StatefulSets  StatefulSets 专门用于管理有状态应用，确保Pod有固定的标识符和稳定的存储。适用于数据库、分布式文件系统等需要持久化存储的应用。 特点： 稳定的网络标识: 每个Pod有一个固定的DNS名，例如pod-0.service.namespace.svc.cluster.local。 有序部署和更新: Pod按顺序进行创建、删除和更新（例如从pod-0到pod-N）。 稳定的存储: 每个Pod可以有一个独立的PersistentVolume，与Pod的生命周期无关。 三、Elasticsearch集群架构 1、Elasticsearch集群的组成 一Elasticsearch集群主要由以下几个部分组成： 1. 节点（Node）: 节点是Elasticsearch集群中的一个单独运行实例，每个节点都存储数据并参与集群的索引和搜索功能。 2. 主节点（Master Node）: 负责集群范围内的管理任务，如创建或删除索引、跟踪集群中各个节点的状态，并选择主分片和副本分片的位置。 一个集群中只有一个主节点是活动的，但可以配置多个候选主节点以提高容错性。 3. 数据节点（Data Node）: 负责存储数据和处理CRUD（创建、读取、更新、删除）操作以及搜索请求。数据节点需要较多的内存和存储资源。 4. 协调节点（Coordinating Node）: 处理来自客户端的请求，将请求分发到合适的数据节点，并汇总结果后返回给客户端。 任何节点都可以作为协调节点，但可以专门配置一些节点只作为协调节点。 5. 主节点候选节点（Master-Eligible Node）: 可以被选举为主节点的节点。通常，集群会配置多个候选主节点，以防止单点故障。 6. 专用节点（Dedicated Node）: 可以配置专门的节点来处理特定任务，如专用的主节点、数据节点或协调节点，以优化集群性能。 2、Elasticsearch工作原理 1. 索引和分片（Shards）: 数据在存储时被划分为多个分片。每个索引（类似于关系数据库中的表）可以被分成一个或多个主分片（Primary Shard），每个主分片可以有多个副本分片（Replica Shard）。 主分片负责处理数据写入，副本分片用于数据冗余和读取操作，以提高查询性能和数据安全性。 2. 数据分布:  Elasticsearch使用一致性哈希算法将分片分布到集群中的各个节点上。主节点负责跟踪分片的位置，并在节点故障时重新分配分片。 3. 查询和搜索: 当客户端发送查询请求时，协调节点会解析请求并将其分发到相关的分片上。每个分片在本地执行查询，并返回结果给协调节点，协调节点汇总结果后返回给客户端。 查询可以并行执行，从而提高性能。  4. 数据写入:  当客户端发送数据写入请求时，协调节点将数据发送到相关的主分片。主分片处理写入后，将数据同步到所有副本分片。确保所有副本分片都成功写入数据后，协调节点才会向客户端确认写入成功。 3、集群高可用设计 本次部署的elasticsearch设计为5节点，一主多从的高可用方式，如果一个主节点意外宕掉，其他节点自主选举出新的Master节点接管任务，从而保证集群的高可用性 四、部署环境准备 1、准备k8s集群 这里我们使用的k8s集群版本为 1.23，也可以使用其他的版本，只是镜像导入命令不通，如果还未搭建k8s集群，请参考《在Centos中搭建 K8s 1.23 集群超详细讲解》这篇文章 2、准备StorageClass  因为我们要对Elasticsearch中的数据进行持久化，避免Pod漂移后数据丢失，保证数据的完整性与可用性 如果还未创建存储类，请参考《k8s 存储类（StorageClass）创建与动态生成PV解析，（附带镜像）》这篇文件。 五、部署Elasticsearch集群  1、编写部署Elasticsearch的YAML文件 apiVersion: v1 kind: Namespace metadata:   name: es --- #创建ConfigMap用于挂载配置文件 apiVersion: v1 kind: ConfigMap metadata:   name: sirc-elasticsearch-config   namespace: es   labels:     app: elasticsearch data:             #具体挂载的配置文件   elasticsearch.yml: |+          cluster.name: "es-cluster"     network.host: 0.0.0.0     http.cors.enabled: true     http.cors.allow-origin: "*"     http.cors.allow-headers: "*"     bootstrap.system_call_filter: false     xpack.security.enabled: false     index.number_of_shards: 5     index.number_of_replicas: 1 #创建StatefulSet，ES属于数据库类型的应用，此类应用适合StatefulSet类型 --- apiVersion: apps/v1 kind: StatefulSet metadata:   name: elasticsearch   namespace: es spec:   serviceName: "elasticsearch-cluster"   #填写无头服务的名称   replicas: 5   selector:      matchLabels:        app: elasticsearch   template:     metadata:       labels:         app: elasticsearch     spec:       initContainers:       - name: fix-permissions         image: busybox         imagePullPolicy: IfNotPresent         command: ["sh", "-c", "chown -R 1000:1000 /usr/share/elasticsearch/data"]         securityContext:           privileged: true         volumeMounts:         - name: es-data           mountPath: /usr/share/elasticsearch/data       - name: increase-vm-max-map         image: busybox         imagePullPolicy: IfNotPresent         command: ["sysctl", "-w", "vm.max_map_count=262144"]         securityContext:           privileged: true       - name: increase-fd-ulimit         image: busybox         imagePullPolicy: IfNotPresent         command: ["sh", "-c", "ulimit -n 65536"]         securityContext:           privileged: true       containers:       - name: elasticsearch         image: elasticsearch:7.17.18         imagePullPolicy: Never         resources:           requests:             memory: "1000Mi"             cpu: "1000m"           limits:             memory: "2000Mi"             cpu: "2000m"         ports:         - containerPort: 9200           name: elasticsearch         env:         - name: node.name           valueFrom:             fieldRef:               fieldPath: metadata.name  #metadata.name获取自己pod名称添加到变量MY_POD_NAME，status.hostIP获取自己ip等等可以自己去百度         - name: discovery.type           value: zen         - name: cluster.name           value: elasticsearch         - name: cluster.initial_master_nodes           value: "elasticsearch-0,elasticsearch-1,elasticsearch-2,elasticsearch-3,elasticsearch-4"         - name: discovery.zen.minimum_master_nodes           value: "3"         - name: discovery.seed_hosts           value: "elasticsearch-0.elasticsearch-cluster.es,elasticsearch-1.elasticsearch-cluster.es,elasticsearch-2.elasticsearch-cluster.es,elasticsearch-3.elasticsearch-cluster.es,elasticsearch-4.elasticsearch-cluster.es"         - name: network.host           value: "0.0.0.0"         - name: "http.cors.allow-origin"           value: "*"         - name: "http.cors.enabled"           value: "true"         - name: "number_of_shards"           value: "5"         - name: "number_of_replicas"           value: "1"         - name: path.data           value:  /usr/share/elasticsearch/data         volumeMounts:                                      - name: es-data                  #挂载数据             mountPath: /usr/share/elasticsearch/data        volumes:       - name: elasticsearch-config         configMap:                                #configMap挂载           name: sirc-elasticsearch-config   volumeClaimTemplates:                     #这步自动创建pvc，并挂载动态pv     - metadata:         name: es-data       spec:         accessModes: ["ReadWriteMany"]         storageClassName: nfs         resources:           requests:             storage: 10Gi #创建Service --- apiVersion: v1 kind: Service metadata:   name: elasticsearch-cluster  #无头服务的名称，需要通过这个获取ip，与主机的对应关系   namespace: es   labels:     app: elasticsearch spec:   ports:     - port: 9200       name: elasticsearch   clusterIP: None   selector:     app: elasticsearch   --- apiVersion: v1 kind: Service metadata:   name: elasticsearch   #service服务的名称，向外暴露端口   namespace: es   labels:     app: elasticsearch spec:   ports:     - port: 9200       name: elasticsearch   type: NodePort   selector:     app: elasticsearch --- apiVersion: v1 kind: Service metadata:   name: my-nodeport-service-0   namespace: es spec:   type: NodePort   selector:     statefulset.kubernetes.io/pod-name: elasticsearch-0   ports:     - protocol: TCP       port: 80        # Service 暴露的端口       targetPort: 9200   # Pod 中容器的端口       nodePort: 30000    # NodePort 类型的端口范围为 30000-32767，可以根据需要调整 --- apiVersion: v1 kind: Service metadata:   name: my-nodeport-service-1   namespace: es spec:   type: NodePort   selector:     statefulset.kubernetes.io/pod-name: elasticsearch-1   ports:     - protocol: TCP       port: 80        # Service 暴露的端口       targetPort: 9200   # Pod 中容器的端口       nodePort: 30001    # NodePort 类型的端口范围为 30000-32767，可以根据需要调整 --- apiVersion: v1 kind: Service metadata:   name: my-nodeport-service-2   namespace: es spec:   type: NodePort   selector:     statefulset.kubernetes.io/pod-name: elasticsearch-2   ports:     - protocol: TCP       port: 80        # Service 暴露的端口       targetPort: 9200   # Pod 中容器的端口       nodePort: 30002    # NodePort 类型的端口范围为 30000-32767，可以根据需要调整 --- apiVersion: v1 kind: Service metadata:   name: my-nodeport-service-3   namespace: es spec:   type: NodePort   selector:     statefulset.kubernetes.io/pod-name: elasticsearch-3   ports:     - protocol: TCP       port: 80        # Service 暴露的端口       targetPort: 9200   # Pod 中容器的端口       nodePort: 30003    # NodePort 类型的端口范围为 30000-32767，可以根据需要调整 --- apiVersion: v1 kind: Service metadata:   name: my-nodeport-service-4   namespace: es spec:   type: NodePort   selector:     statefulset.kubernetes.io/pod-name: elasticsearch-4   ports:     - protocol: TCP       port: 80        # Service 暴露的端口       targetPort: 9200   # Pod 中容器的端口       nodePort: 30004    # NodePort 类型的端口范围为 30000-32767，可以根据需要调整 --- apiVersion: apps/v1 kind: Deployment metadata:   name: elasticsearchhead   namespace: es spec:   replicas: 1   selector:     matchLabels:       app: elasticsearchhead   template:     metadata:       labels:         app: elasticsearchhead     spec:       containers:       - name: elasticsearchhead         image: mobz/elasticsearch-head:5         ports:         - containerPort: 9100 --- apiVersion: v1 kind: Service metadata:   name: elasticsearchhead-service   namespace: es spec:   type: NodePort   ports:   - port: 9100     targetPort: 9100     nodePort: 30910  # 可根据需要选择合适的端口号   selector:     app: elasticsearchhead  上述Kubernetes配置文件定义了Elasticsearch集群的部署，使用StatefulSet来管理其有状态的Pod。  配置说明  1. 命名空间 (Namespace)  创建一个命名空间es，用于组织和隔离Elasticsearch资源。 2. ConfigMap  创建一个ConfigMap，用于存储Elasticsearch的配置文件elasticsearch.yml。 3. StatefulSet  StatefulSet 用于部署和管理有状态应用。 包含5个副本（replicas），每个副本都有唯一的标识符（如elasticsearch-0）。 使用初始化容器（initContainers）来处理权限、系统参数和文件描述符的设置。 定义了主容器elasticsearch，并指定了环境变量、资源请求和限制，以及挂载数据卷。 4. Services  创建了一个无头服务elasticsearch-cluster，用于Pod之间的内部通信。 创建了一个NodePort服务elasticsearch，暴露9200端口到集群外部。 为每个StatefulSet的Pod创建单独的NodePort服务，分别暴露在不同的端口（30000-30004），用于直接访问特定的Pod。 5. Elasticsearch Head 部署和服务  部署Elasticsearch Head插件，用于图形化管理和浏览Elasticsearch集群。 暴露Elasticsearch Head的9100端口，使用NodePort类型服务，端口号为30910。 2、部署 Elasticsearch 执行下面的命令  kubectl get pod -n es 3、查看Pod状态 执行下面的命令 kubectl get svc -n es 4、访问测试  查看svc的nodeport端口  在浏览器输入Node的IP加30910端口  在连接窗口输入 Node的IP加30001端口，点击连接  如果能显示下面的结果，则集群部署成功    💕💕💕每一次的分享都是一次成长的旅程，感谢您的陪伴和关注。希望这些关于Elasticsearch的文章能陪伴您走过技术的一段旅程，共同见证成长和进步！😺😺😺  🧨🧨🧨让我们一起在技术的海洋中探索前行，共同书写美好的未来！！！  ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/weixin_53269650/article/details/139632433 

 概述 nvidia-docker 和 nvidia-container-runtime 是用于在 NVIDIA GPU 上运行 Docker 容器的两个相关工具。它们的作用是提供 Docker 容器与 GPU 加速硬件的集成支持，使容器中的应用程序能够充分利用 GPU 资源。  nvidia-docker 为了提高 Nvidia GPU 在 docker 中的易用性， Nvidia 通过对原生 docker 的封装提供了 nvidia-docker 工具 nvidia-docker 是一个 Docker 插件，用于在 Docker 容器中启用 NVIDIA GPU 支持。 该工具提供了一个命令行界面，允许在运行容器时通过简单的命令来指定容器是否应该访问主机上的 NVIDIA GPU 资源。 当在容器中运行需要 GPU 加速的应用程序时，可以使用 nvidia-docker 来确保容器能够访问 GPU。 # 示例命令 nvidia-docker run -it --rm nvidia/cuda:11.0-base nvidia-smi 上述命令使用 nvidia-docker 在容器中运行 NVIDIA 的 CUDA 基础镜像，并在容器中执行 nvidia-smi 命令以查看 GPU 信息  nvidia-container-runtime  nvidia-container-runtime 是 NVIDIA 的容器运行时，它与 Docker 和其他容器运行时（如 containerd）集成，以便容器可以透明地访问 NVIDIA GPU 资源。  与 nvidia-docker 不同，nvidia-container-runtime 不是 Docker 插件，而是一种更通用的容器运行时，可与多个容器管理工具集成。  nvidia-docker 和 nvidia-container-runtime 都是用于使 Docker 容器能够访问 NVIDIA GPU 资源的工具。可以根据自己的需求选择其中一个来配置容器以利用 GPU 加速。  需要注意的是，最新的 NVIDIA Docker 支持通常建议使用 nvidia-container-runtime，因为它提供了更灵活和通用的 GPU 支持，而不仅仅是为 Docker 定制的解决方案。  # 示例命令 docker run --runtime=nvidia -it --rm nvidia/cuda:11.0-base nvidia-smi 上述命令使用 Docker 运行容器，通过 --runtime=nvidia 参数指定使用 nvidia-container-runtime 运行时，并在容器中执行 nvidia-smi 命令。 原生 docker 通过设备挂载和磁盘挂载的方式支持访问 GPU 资源  docker 本身并不原生支持 GPU，但使用 docker 的现有功能可以对 GPU 的使用进行支持  # 示例命令 docker run \ --device /dev/nvidia0:/dev/nvidia0 \ --device /dev/nvidiactl:/dev/nvidiactl \ --device /dev/nvidia-uvm:/dev/nvidia-uvm \ -v /usr/local/nvidia:/usr/local/nvidia \ -it --privileged nvidia/cuda 通过 --device 来指定挂载的 GPU 设备，通过 -v 来将宿主机上的 nvidia gpu 的命令行工具和相关的依赖库挂载到容器。这样，在容器中就可以看到和使用宿主机上的 GPU 设备了。 注意：这种方式对于 GPU 的可用性（哪些 GPU 是空闲的等）需要人为的判断，效率很低  nvidia-docker 详解 结构图及各组件说明 nvidia-docker 对于使用 GPU 资源的 docker 容器支持的层次关系： Nvidia-docker的原理图以及各个部分的作用解析： **libnvidia-container：**提供了一个库和简单的 CLI 工具，以实现在容器当中支持使用 GPU 设备的目标。  nvidia-container-toolkit：  是一个实现了 runC 的 prestart hook 接口的脚本，该脚本在 runC 创建一个容器之后，启动该容器之前调用，其主要作用就是修改与容器相关联的 config.json，注入一些在容器中使用 NVIDIA GPU 设备所需要的一些信息（比如：需要挂载哪些 GPU 设备到容器当中）。  nvidia-container-runtime：  主要用于将容器 runC spec 作为输入，然后将 nvidia-container-toolkit 脚本作为一个 prestart hook 加入到 runC spec 中，再用修改后的 runC spec 调 runc 的 Exec 接口运行容器。  所以在容器启动之前会调用 pre-start hook（nvidia-container-toolkit），这个 hook 会通过 nvidia-container-cli 文件，来调用libnvidia-container 库，最终映射挂载宿主机上的 GPU 设备、nvid 驱动的 so 文件、可执行文件到容器内部。  nvidia-container-runtime 才是真正的核心部分，它在原有的 docker 容器运行时 runc 的基础上增加一个 prestart hook，用于调用 libnvidia-container 库 RunC：  RunC 是一个轻量级的工具，它是用来运行容器的，只用来做这一件事。  可以认为它就是个命令行小工具，可以不用通过 docker 引擎，直接运行容器。也是 docker 默认的容器运行方式。  事实上，runC 是标准化的产物，它根据 OCI 标准来创建和运行容器。而 OCI（Open Container Initiative）组织，旨在围绕容器格式和运行时制定一个开放的工业化标准。  直接使用 RunC 的命令行即可以完成创建一个容器，并提供了简单的交互能力。  容器创建过程 创建一个正常容器（不支持 GPU）的流程：  docker --> dockerd --> containerd–> containerd-shim -->runc --> container-process 1 docker 客户端将创建容器的请求发送给 dockerd，当 dockerd 收到请求任务之后将请求发送给 containerd，containerd 经过查看校验启动 containerd-shim 或者自己来启动容器进程。  创建一个支持 GPU 的容器的流程：  docker–> dockerd --> containerd --> containerd-shim–> nvidia-container-runtime --> nvidia-container-runtime-hook --> libnvidia-container --> runc – > container-process 1 基本流程和不支持 GPU 的容器差不多，只是把 docker 默认的运行时替换成了 NVIDIA 封装的 nvidia-container-runtime  这样当 nvidia-container-runtime 创建容器时，先执行 nvidia-container-runtime-hook，这个 hook 去检查容器是否需要使用GPU（通过环境变 NVIDIA_VISIBLE_DEVICES 来判断)。如果需要则调用 libnvidia-container 来暴露 GPU 给容器使用。否则走默认的 runc 逻辑。  NVIDIA Docker 整体工作架构 软硬件基础 硬件，服务器上安装了英伟达 GPU  宿主机，安装了操作系统和 Cuda Driver，以及 Docker 引擎  容器，包含容器 OS 用户空间，Cuda Toolkit，以及用户应用程序  注意：  宿主机上需要安装 cuda driver，容器内需要安装 cuda toolkit。容器内无需安装 cuda driver NVIDIA 提供了一些官方镜像，其中已经安装好了 cuda toolkit，但还是需要在宿主机安装 cuda driver。 API 结构 NVIDIA 提供了三层 API：  CUDA Driver API：  GPU 设备的抽象层，通过提供一系列接口来操作 GPU 设备，性能最好，但编程难度高，一般不会使用该方式开发应用程序  CUDA Runtime API：  对 CUDA Driver API 进行了一定的封装，调用该类 API 可简化编程过程，降低开发难度  CUDA Libraries：  是对 CUDA Runtime API 更高一层的封装，通常是一些成熟的高效函数库，开发者也可以自己封装一些函数库便于使用  应用程序可调用 CUDA Libraries 或者 CUDA Runtime API 来实现功能，当调用 CUDA Libraries 时，CUDA Libraries 会调用相应的 CUDA Runtime API，CUDA Runtime API 再调用 CUDA Driver API，CUDA Driver API 再操作 GPU 设备。  CUDA 的容器化 目标：让应用程序可以在容器内调用 CUDA API 来操作 GPU  因此需要实现：  在容器内应用程序可调用 CUDA Runtime API 和 CUDA Libraries  在容器内能使用 CUDA Driver 相关库。因为 CUDA Runtime API 其实就是 CUDA Driver API 的封装，底层还是要调用到 CUDA Driver API  在容器内可操作 GPU 设备  因此容器中访问 GPU 资源过程为：  要在容器内操作 GPU 设备，需要将 GPU 设备挂载到容器里  Docker 可通过 --device 挂载需要操作的设备，或者直接使用特权模式（不推荐）。  NVIDIA Docker 是通过注入一个 prestart 的 hook 到容器中，在容器自定义命令启动前就将GPU设备挂载到容器中。  至于要挂载哪些GPU，可通过 NVIDIA_VISIBLE_DEVICES 环境变量控制。  挂载 GPU 设备到容器后，还要在容器内可调用 CUDA API  CUDA Runtime API 和 CUDA Libraries 通常跟应用程序一起打包到镜像里  CUDA Driver API 是在宿主机里，需要将其挂载到容器里才能被使用。  NVIDIA Docker 挂载 CUDA Driver 库文件到容器的方式和挂载 GPU 设备一样，都是在 runtime hook 里实现的。  注意：  该方案也有一些问题，即容器内的 CUDA Runtime 同宿主机的 CUDA driver 可能存在版本不兼容的问题。  CUDA Libraries 和 CUDA Runtime API 是和应用程序一起打包到镜像中的，而 Driver 库是在创建容器时从宿主机挂载到容器中的，需要保证 CUDA Driver 的版本不低于 CUDA Runtime 版本。  ，  NVIDIA Docker 2.0（nvidia-container-runtime） 实现机制 nvidia-docker2.0 是一个简单的包，它主要通过修改 docker 的配置文件 /etc/docker/daemon.json，将默认的 Runtime 修改为 nvidia-container-runtime，可实现将 GPU 设备，CUDA Driver 库挂载到容器中。  cat /etc/docker/daemon.json  {     "default-runtime": "nvidia",     "runtimes": {         "nvidia": {             "path": "/usr/bin/nvidia-container-runtime",             "runtimeArgs": []         }     } } Debug日志 修改 nvidia runc 的默认配置文件 /etc/nvidia-container-runtime/config.toml ，打开 hook 的 debug 日志选项，可以看到宿主机挂载 nvidia 驱动、设备到容器内部的详细过程。 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/footless_bird/article/details/136291344 

【docker】centos7配置docker镜像加速-转载鲲鹏发表于 13 小时前4查看国内从 DockerHub 拉取镜像有时会遇到困难，由于网络原因，下载一个Docker官方镜像可能会需要很长的时间，甚至下载失败。此时可以配置镜像加速器。Docker 官方和国内很多云服务商都提供了国内加速器服务。 国内常见镜像仓库 docker官方地址仓库国外地址：    https://download.docker.com/linux/centos/docker-ce.repo 阿里云 ：            http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo 华为云：    https://<your accelerate address>.mirror.swr.myhuaweicloud.com 腾讯云：   https://mirror.ccs.tencentyun.com 科大镜像：    https://docker.mirrors.ustc.edu.cn/ 七牛云加速器：   https://reg-mirror.qiniu.com docker中国：   https://registry.docker-cn.com 网易：   http://hub-mirror.c.163.com daocloud：   http://f1361db2.m.daocloud.io 【注意】云服务的话要根据自己购买的服务器获取自己服务器对应的镜像加速地址，这样可以比公开的镜像地址速度更快。推荐阿里云和华为云的。 确认操作系统版本 uname  -r 查看信息（配置镜像加速前） docker info  没有看到 Registry Mirrors: https:// XXXXXXXXXXXXX 说明没有配置镜像加速。 创建文件夹 mkdir -pv /etc/docker  创建daemon.json cd /etc/docker/   touch daemon.json  编辑 daemon.json vim daemon.json  增加内容： {"registry-mirrors":["https://hub-mirror.c.163.com/"]}  重新启动服务 systemctl daemon-reload   systemctl restart docker   再次查看信息（配置镜像加速后） docker info  ————————————————                             版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/wochunyang/article/details/134894410 

0、报错内容1、环境win10 子系统  wls2  Ubuntu20.04 2、docker ce 信息Docker version 27.1.1, build 6312585

1、环境win10  子系统wsl2 Ubuntu20.4  安装了docker ce 版本 Docker version 27.1.1, build 63125852、问题运行build_sdk_base.sh报错，错误内容如下如何解决

如指导书截图所示，正常执行③，将成功创建，但实际执行中报错，经重启无效，求大佬指点。报错信息如下：ERROR: failed to solve: process "/bin/sh -c yum install -y httpd vi && yum clean all" did not complete successfully: exit code: 1

Docker容器绑定外部IP和端口的方法主要依赖于Docker的端口映射功能。Docker允许通过外部访问容器或者容器之间互联的方式来提供网络服务。以下是具体的步骤和方法：1. 使用-p或-P参数进行端口映射-p（小写）参数：可以指定要映射的端口，并且在一个指定端口上只可以绑定一个容器。-p参数支持多种格式，如ip:hostport:containerport、ip::containerport、hostport:containerport。如果不指定IP，则默认映射到宿主机的所有IP上。示例：将宿主机的5000端口映射到容器的5000端口上，可以使用以下命令：docker run -d -p 5000:5000 training/webapp python app.py如果希望只将宿主机的某个特定IP（如192.168.1.100）的5000端口映射到容器的5000端口上，可以使用：docker run -d -p 192.168.1.100:5000:5000 training/webapp python app.py-P（大写）参数：Docker会随机选择一个端口映射到容器内部开放的网络端口上。这种方式适用于不需要固定端口的情况。示例：启动容器并随机映射端口：docker run -d -P training/webapp python app.py之后，可以使用docker ps命令查看容器运行信息，包括Docker随机分配的端口号。2. 查看容器绑定和映射的端口及IP地址使用docker port命令可以查看容器的端口映射情况。例如，查看某个容器（通过容器ID或名称指定）的端口映射，可以使用：docker port 容器ID或名称这将列出容器内部端口与宿主机端口的映射关系。3. 注意事项默认情况下，Docker容器使用的是内部网络，无法直接访问公网。如果需要通过公网访问容器，需要在宿主机上配置相应的网络设置（如NAT转发、防火墙规则等）。在生产环境中，为了避免端口冲突和方便管理，建议明确指定要映射的端口号。容器名称的指定（通过--name参数）有助于记忆和管理容器，特别是在运行多个容器时。容器间的互联（通过--link参数，但注意--link在新版本的Docker中已不推荐使用，建议使用Docker网络功能）可以实现容器间的安全交互。综上所述，Docker容器绑定外部IP和端口主要通过-p或-P参数实现，同时需要注意网络配置和端口管理的问题。

 出现 Cannot connect to the Docker daemon at unix:///Users/dragonplus/.docker/run/docker.sock. Is the docker daemon running? 错误的原因通常是由于 Docker 守护进程未运行或者无法连接到 Docker 守护进程。以下是一些可能的解决方法：  1. 确保 Docker 服务在运行 在 Linux 上 你可以通过以下命令查看 Docker 服务是否正在运行，并启动它： sudo systemctl status docker 如果 Docker 未运行，可以使用以下命令启动它：  sudo systemctl start docker 在 macOS 和 Windows 上 对于 macOS 和 Windows 用户，Docker 通常以 Docker Desktop 的形式运行。请确保 Docker Desktop 应用已经启动。  2. 检查 Docker Socket 权限 有时，用户没有正确的权限访问 Docker Socket 文件。在 Linux 系统上，你可以尝试将当前用户添加到 docker 组来解决这个问题：  # 将当前用户添加到 docker 组 sudo usermod -aG docker $USER  # 重新登录 shell 或者重启系统以使更改生效 newgrp docker 3. 检查 Docker 安装和配置 确保 Docker 已正确安装，并且配置文件没有问题。可以通过以下命令检查 Docker 的版本信息：  docker --version 如果命令返回了 Docker 的版本信息，则说明 Docker 已成功安装。  4. 重启 Docker 服务或计算机 有时候简单地重启 Docker 服务或整个计算机会解决问题。  重启 Docker 服务（Linux） sudo systemctl restart docker 重启 Docker Desktop（macOS/Windows） 退出并重新启动 Docker Desktop 应用。 5. 查看日志和错误信息 如果上述步骤都没有解决问题，可以查看 Docker 日志获取更多信息：  在 Linux 上 sudo journalctl -u docker.service 在 macOS 上 Docker Desktop 会记录日志，你可以通过 Docker Desktop 的 UI 来查看这些日志。  6. 检查 Docker 配置文件 确保 Docker 的配置文件 /etc/docker/daemon.json 没有语法错误或不正确的配置。如果有任何修改，请重启 Docker 服务以应用更改。  示例：修复 Docker 守护进程未运行的问题 步骤 1: 启动 Docker 服务 sudo systemctl start docker 步骤 2: 添加用户到 docker 组 sudo usermod -aG docker $USER newgrp docker 步骤 3: 验证 Docker 是否正常运行 docker ps 如果执行以上步骤后依然无法解决问题，请提供更多错误信息或者具体环境设置，以便进行进一步诊断。 

在 docker-compose.yml 文件中，restart 选项用于指定 Docker 容器的重启策略，以便在容器退出或失败时自动重启它。这个选项非常有用，特别是在生产环境中，可以提高服务的可用性和可靠性。重启策略选项Docker 支持以下几种重启策略：no：默认值，不会自动重启容器。always：总是重启容器，无论退出状态如何。on-failure：仅当容器以非零退出代码停止时才重启。unless-stopped：总是重启容器，除非容器被手动停止或 Docker 服务被停止。基本语法在 docker-compose.yml 文件中，restart 选项位于服务定义下。例如：version: '3.8'services: web: image: nginx:latest ports: - "80:80" restart: always app: build: ./app ports: - "5000:5000" restart: on-failure db: image: postgres:13 volumes: - db-data:/var/lib/postgresql/data environment: - POSTGRES_DB=mydatabase - POSTGRES_USER=user - POSTGRES_PASSWORD=secret restart: unless-stoppedvolumes: db-data:示例使用restart: no这是默认设置，即使未显式设置 restart 选项，容器也不会自动重新启动。services: example-no-restart: image: someimage restart: norestart: always无论容器的退出状态如何，总是自动重启容器。services: example-always-restart: image: someimage restart: alwaysrestart: on-failure仅在容器因错误而退出时重新启动（退出代码不为 0）。services: example-on-failure: image: someimage restart: on-failure你还可以指定最大重启次数，例如最多重试 5 次：services: example-on-failure-with-max-retries: image: someimage restart: on-failure deploy: restart_policy: condition: on-failure max_attempts: 5restart: unless-stopped容器将始终重启，除非它们被手动停止或 Docker 服务被停止。services: example-unless-stopped: image: someimage restart: unless-stopped使用场景开发环境：在开发环境中，你可能希望手动控制容器的生命周期，因此可以使用 restart: no。测试/预生产环境：在这些环境中，当某些服务需要高可用性时，可以使用 restart: on-failure，以确保在服务崩溃后自动重启。生产环境：在生产环境中，通常会使用 restart: always 或 restart: unless-stopped 来确保服务的持续可用性。结合其他选项在一些复杂场景中，你可能希望与其他选项结合使用，例如健康检查和重启策略：services: app: image: myapp:latest restart: on-failure healthcheck: test: ["CMD", "curl", "-f", "http://localhost"] interval: 1m30s timeout: 10s retries: 3 deploy: restart_policy: condition: on-failure delay: 5s max_attempts: 3 window: 120s总结restart 选项用于设置 Docker 容器的重启策略，以提高服务的可用性和可靠性。常用的重启策略包括 no, always, on-failure, 和 unless-stopped。不同的策略适用于不同的环境和使用场景，如开发、测试、预生产、和生产环境。可以结合其他选项如健康检查和部署策略来实现更复杂的配置。通过正确配置重启策略，你可以显著提高应用的稳定性和可用性。

我的昇腾服务器无法登录昇腾镜像仓库，每次使用如下命令都会报错docker login -u xxxxxxx ascendhub.huawei.com错误信息：Error response from daemon: Get "https://ascendhub.huawei.cn/v2/": received unexpected HTTP status: 500 Internal Server Error我可以ping通ascendhub.huawei.cn

仅个人工作时对操作步骤进行记录，无任何安全、可行性保证，转载请标注出处！  配置IP地址，使其可正常上网。  2.配置yum源  #安装yum工具  yum -y install yum-utils  #下载配置阿里的yum源  wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-vault-8.5.2111.repo  #下载配置docker的yum源  yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo  3.安装docker  yum -y install docker-ce.x86_64 docker-ce-cli.x86_64 containerd.io.x86_64  会报错提示有安装包冲突，输入—allowerasing  yum -y install docker-ce.x86_64 docker-ce-cli.x86_64 containerd.io.x86_64 --allowerasing  4.docker安装完成后，配置docker镜像加速，使docker从国内网站下载镜像   sudo mkdir -p /etc/docker  sudo tee /etc/docker/daemon.json <<-'EOF'  {    "registry-mirrors": ["https://fw80gpy5.mirror.aliyuncs.com"]  }  EOF  sudo systemctl daemon-reload  sudo systemctl restart docker  5.下载网上已配置好的kms镜像  docker pull luodaoyi/kms-server   6.运行该镜像并配置开机自启，使本地1688端口对应镜像中1688端口，运行后docker ps -a 可看见镜像已正常拉起  docker run -itd -p 1688:1688 --name kms --restart always luodaoyi/kms-server   7.测试能否正常激活windows和office  7.1先添加DNS，或直接使用IP也可以   7.2测试1688端口已正常放通   7.3Windows已激活成功，注意当前只测试了server和win10企业版可激活   slmgr /skms 服务器IP  slmgr /ato  slmgr /ipk 输入序列号  7.4 激活office  激活office需进入office文件ospp.vbs的存放路径运行命令  cd C:\Program Files (x86)\Microsoft Office\Office16  cscript ospp.vbs /sethst:kms.botsing.com  cscript ospp.vbs /act  或者直接带路径进行激活，注意 每个office版本的ospp文件路径可能不一样  cscript "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" /sethst:kms.botsing.com  cscript "C:\Program Files (x86)\Microsoft Office\Office16\OSPP.VBS" /act   此时office已提示激活成功  8.配置加域自动激活，在域控DNS服务器正向查找区域中中添加SRV    完成后，单击确定，然后单击完成。  在域内的电脑只要是批量版(VL)的系统或office即可自动激活 ————————————————                              版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。                          原文链接：https://blog.csdn.net/u011387552/article/details/133810235