俞兆鹏的博客

【代码】根据运行的容器获取docker-compose.yml的位置。

首先遇到的问题是安装docker desktop后，启动引擎时报错可以看到是wsl更新时报错，由于后面是乱码，不知道具体是什么错误，所以接下来打开管理员终端，输入wsl --list测试一下，果然，报错了这时候，显然报错原因找到了，没有权限写入注册表，不得不吐槽一下微软，这个bug就是不更新。

Windows 上使用 Docker GPU需要进行一系列的配置和步骤。这是因为 Docker 在 Windows 上的运行环境与 Linux 有所不同，需要借助 WSL 2（Windows Subsystem for Linux 2）和 NVIDIA Container Toolkit 来实现 GPU 的支持。

在Docker中使用GPU可以大大提升计算密集型任务的性能，特别是在深度学习和高性能计算领域。通过正确安装NVIDIA Container Toolkit并合理配置Docker容器，你可以充分利用GPU的计算能力。希望本文能够帮助你更好地在Docker中使用GPU，加速你的开发和部署过程！

文章目录基础概念Elasticsearch概述Elasticsearch用途文档&类型&索引数据类型查询DSL查询过滤器查询结果高亮分析数据分析器字符过滤器（Character filter）分词器（Tokenizer）分词过滤器（Token filter）使用相关性进行搜索词频-逆文档频率（TF-IDF）function_score 定制得分使用聚集来搜索数据度量聚集多桶型聚集ES集群管理集群扩展集群选举主节点基础概念Elasticsearch概述Elasticsearch 是一个分

k8s 更新证书

问题描述是最近在使用k8s的过程中出现的一个问题，我在deployment 的yaml文件中，给pod配置了env环境变量，类似的如下：apiVersion: apps/v1kind: Deploymentmetadata: name: test-deploy namespace: testspec: template: spec: containers: - env: - name: test-key

概述在 k8s 中我们暴露服务通常需要借助Service来实现，当我们创建了service后，可以看到会分配一个ClusterIP ，本文主要是一个示例介绍ClusterIP 的网络原理 。这个示例中会创建一个svc ， 然后深入的跟踪一下这个svc的网络实现。ClusterIP是通过kube-proxy来维护的，在示例中 kube-proxy 是使用的iptables ，这个方便后续实验观察。创建service并验证创建一个nginx的deployment# 创建 deploymentku

通过openvpn等，解决mac电脑里无法访问minikube的service问题。

最近做镜像分析扫描工作，需要扫描镜像的安全漏洞，评估镜像安全性，调研了几款漏洞扫描工具，最后决定使用Trivy工具，Trivy是一家以色列安全公司开源的一个漏洞扫描工具，支持容器镜像、虚机镜像、文件系统的安全扫描。

是google出的一个容器差异比较工具，通过这个工具可以比较两个镜像之间存在的文件差异、RPM包差异、apt包差异、pip包差异和node包差异。也包括了对单个镜像分析能力，像文件分析啊、apt包、rpm包分析等功能。在日常工作中，如果我们想知道一个镜像的新旧版本之间有哪些变更，或者面对两个类似的镜像不知道该用哪一个的时候，就可以使用这个工具来分析比较一下差异，我们就能更加深入得了解镜像内部。

dive是一个容器镜像分析工具，可以直观的看到容器每一层变动了哪些文件，每一层占用的磁盘空间，这样也就可以看到镜像的历史构建过程；同时也可以看到镜像的磁盘空间使用率，面对特别大的镜像文件是，可以分析是否有优化的空间。其实镜像每一层的文件信息、文件大小、层的信息，都是存储在镜像的元数据中，dive就是帮我们将这些信息，已更好的方式组装展示出来了，方便我们分析镜像。

介绍Knative Eventing组件是一个实现了事件驱动的一个组件，通过事件发布/订阅的机制，使事件的生产者和消费者充分解耦。当一个事件产生时，事件的发出者并不用关心该事件是否被消费，或者被哪个消费者消费。事件消费者也不依赖与生产者，各自都具有独立性。核心资源Source（源）Souce是Knative Eventing组件中的消息生产者，负责产生事件然后发出，接收事件的对象可以是Knative Service、K8s Service、Channel或者Broker。示例中是将一个消息发送到

介绍Knative Serving 组件是负责Knative框架中的容器的生命周期管理，从容器的创建、容器的弹性伸缩到容器结束运行，另外Knative Serving组件还会调用服务网格istio的功能来实现服务的治理。核心资源Knative使用CRD来实现自定义的资源，核心的资源类型包括Configuration、Route、Service。Configuration&RevisionKnative Serving 始于 Configuration。 Configuration 中为

介绍Knative Build组件是负责Knative生态中执行构建任务的，在Knative新版本中是由Tekton Pipelines来实现流水线构建功能，Tekton Pipelines是扩展K8s（CRD）来实现的，Knative Build组件是开放式的设计，各个组件之间是解耦的，在Knative中也可以使用Tekton Piplines的替代品等。安装Tekton Piplines本身不依赖istio，可以再k8s集群中直接安装，通过编写好的yaml文件可以一键安装。kubectl app

概述Knative是由谷歌开源的一款基于k8s的Serverless项目，该项目的目标是致力于以容器为核心的serverless标准化，加速Serverless生态发展。Knative定义了serverless的构建、服务管理和事件驱动。该项目与2018年7月正式发布，目前还处在快速发展阶段。Knative使用应用模板和统一的运行环境来标准化服务的构建、部署和管理。Kubernetes作为基础设施，解决应用编排和运行环境，Isito作为通信基础设施层，提供服务治理相关能力。解决的问题K8s使用门

技术背景Service Mesh即服务网格，服务网格被看作为下一代的微服务技术。服务网格概念的提出者对于服务网格定义如下：服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。初期的微服务系统通常都是选择一种语言技术框架来实现，常见的比如Spring Cloud、Dubbo等，以Spring Cloud 为例，该框架集成了微服务的套件