爱死亡机器人

VNC技术是由Olivetti和Oracle在英国剑桥的研究实验室创建的。它有助于使用远程帧缓冲协议 （RFB） 访问/控制远程系统。VNC 使用客户端-服务器模型，其中 VNC 服务器安装在远程系统上，VNC 客户端安装在本地系统上。一旦获得权限，VNC 服务器就会将远程计算机屏幕的副本传输到客户端。提供 VNC 的软件包括;TigerVNC、VNC4server、Vino 等。本指南旨在说明如何在 Rocky Linux 8|AlmaLinux 8 上设置 RealVNC 服务器和客户端。

文章目录1. 容器发展2. KataContainers原理3. gVisor原理4. 对比1. 容器发展使用虚拟化技术来做一个像 Docker 一样的容器项目，并不是一个新鲜的主意。早在 Docker 项目发布之后，Google 公司就开源了一个实验性的项目，叫作 novm。这，可以算是试图使用常规的虚拟化技术来运行 Docker 镜像的第一次尝试。不过，novm 在开源后不久，就被放弃了，这对于 Google 公司来说或许不算是什么新鲜事，但是 novm 的昙花一现，还是激发出了很多内核开发者的灵

背景Prometheus 项目与 Kubernetes 项目一样，也来自于 Google 的 Borg 体系，它的原型系统，叫作 BorgMon，是一个几乎与 Borg 同时诞生的内部监控系统。而 Prometheus 项目的发起原因也跟 Kubernetes 很类似，都是希望通过对用户更友好的方式，将 Google 内部系统的设计理念，传递给用户和开发者。简介作为一个监控系统，Prometheus 项目的作用和工作方式，其实可以用如下所示的一张官方示意图来解释。可以看到，Prometheus 项

文章目录1. custom metrics2. 实例3. 总结kubernetes快速学习手册promethues快速学习手册1. custom metrics在上一篇文章中，我为你详细讲述了 Kubernetes 里的核心监控体系的架构。不难看到，Prometheus 项目在其中占据了最为核心的位置。实际上，借助上述监控体系，Kubernetes 就可以为你提供一种非常有用的能力，那就是 Custom Metrics，自定义监控指标。在过去的很多 PaaS 项目中，其实都有一种叫作 Auto

功能创建新的 chartchart 打包成 tgz 格式上传 chart 到 chart 仓库或从仓库中下载 chart在Kubernetes集群中安装或卸载 chart管理用Helm安装的 chart 的发布周期概念Helm 有三个重要概念：chart：包含了创建Kubernetes的一个应用实例的必要信息config：包含了应用发布配置信息release：是一个 chart 及其配置的一个运行实例Helm组件Helm 有以下两个组成部分：Helm Client 是用户

文章目录1. 模板函数2. 管道3.default 函数参考链接：阳明1. 模板函数比如我们需要从.Values中读取的值变成字符串的时候就可以通过调用quote模板函数来实现：(templates/configmap.yaml)apiVersion: v1kind: ConfigMapmetadata: name: {{ .Release.Name }}-configmapdata: myvalue: "Hello World" k8s: {{ quote .Values.co

文章目录1. if/else 条件2. 空格控制3. 使用 with 修改范围4. range 循环5. 变量参考链接：阳明模板函数和管道是通过转换信息并将其插入到YAML文件中的强大方法。但有时候需要添加一些比插入字符串更复杂一些的模板逻辑。这就需要使用到模板语言中提供的控制结构了。控制流程为我们提供了控制模板生成流程的一种能力，Helm 的模板语言提供了以下几种流程控制：if/else 条件块with 指定范围range 循环块除此之外，它还提供了一些声明和使用命名模板段的操作：

文章目录1. 声明和使用命名模板2. 模板范围3. include 函数前面我们学习了一些 Helm 模板中的一些常用使用方法，但是我们都是操作的一个模板文件，在实际的应用中，很多都是相对比较复杂的，往往会超过一个模板，如果有多个应用模板，我们应该如何进行处理呢？这就需要用到新的概念：命名模板。命名模板我们也可以称为子模板，是限定在一个文件内部的模板，然后给一个名称。在使用命名模板的时候有一个需要特别注意的是：模板名称是全局的，如果我们声明了两个相同名称的模板，最后加载的一个模板会覆盖掉另外的模板，由

文章目录1. Hooks2. 生命周期3. 写一个 hook参考资料：阳明kubernetes 快速学习手册和 Kubernetes 里面的容器一样，Helm 也提供了 Hook 的机制，允许 chart 开发人员在 release 的生命周期中的某些节点来进行干预，比如我们可以利用 Hooks 来做下面的这些事情：在加载任何其他 chart 之前，在安装过程中加载 ConfigMap 或 Secret在安装新 chart 之前执行作业以备份数据库，然后在升级后执行第二个作业以恢复数据在

CNI 简介容器网络的配置是一个复杂的过程，为了应对各式各样的需求，容器网络的解决方案也多种多样，例如有Flannel，Calico，Kube-OVN，Weave等。同时，容器平台/运行时也是多样的，例如有Kubernetes，OpenShift，rkt等。如果每种容器平台都要跟每种网络解决方案一一对接适配，这将是一项巨大且重复的工程。当然，聪明的程序员们肯定不会允许这样的事情发生。想要解决这个问题，我们需要一个抽象的接口层，将容器网络配置方案与容器平台方案解耦。CNI（Container Networ

这节课，我们学习了如何借助 Prometheus、Grafana 和 Ingress-Nginx 快速搭建业务的 HTTP 请求性能监控。得益于 Ingress-Nginx 提供的统一网关，我们能够很方便地从网关层面观察业务接口的性能指标。为了能够让 Prometheus 获取到 Ingress-Nginx 的性能指标，我们通过 patch 的方式暴露了的Metrics接口，并创建了对象来告诉 Prometheus 如何抓取指标数据。

deployment控制器实现流程：Deployment 控制器从 Etcd 中获取到所有携带了“app: nginx”标签的 Pod，然后统计它们的数量，这就是实际状态；Deployment 对象的 Replicas 字段的值就是期望状态；Deployment 控制器将两个状态做比较，然后根据比较结果，确定是创建 Pod，还是删除已有的 Pod可以看到，一个 Kubernetes 对象的主要编排逻辑，实际上是在第三步的“对比”阶段完成的。这个操作，通常被叫作调谐（Reconcile）。这个调谐

简介在Kubernetes中有几种不同的方式发布应用，所以为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了。选择正确的部署策略是要依赖于我们的业务需求的，下面我们列出了一些可能会使用到的策略：重建(recreate)：停止旧版本部署新版本滚动更新(rolling-update)：一个接一个地以滚动更新方式发布新版本蓝绿(blue/green)：新版本与旧版本一起存在，然后切换流量金丝雀(canary)：将新版本面向一部分用户发布，然后继续全量发布A/B测(a/b t

文章目录1. 简介2. Pause 容器特点3. Pause 容器背景4. Pause 容器实现5. Pause 容器的作用6. 共享命名空间1. 简介Pause 容器，又叫 Infra 容器，本文将探究该容器的作用与原理。我们知道在 kubelet 的配置中有这样一个参数：KUBELET_POD_INFRA_CONTAINER=--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:lates

结点上运行的docker设置的参数--graph指向/opt磁盘，通过df -lh查看目前/opt磁盘使用率为48%，启动kubelet此时查看/opt磁盘使用率达到了51%，然后将使用镜像的pod删除，手工将对应的容器docker rm掉，等待GC的镜像回收时间点。然而五分钟过去了，十分钟过去了，docker images时centos镜像依旧顽固地坚守在阵地。.........

tags: 实践。

上一节课，我带你学习了如何使用 ArgoCD 来创建生产可用的 GitOps 工作流。值得注意的是，我们创建的 GitOps 工作流有下面两个重要的特点。源码和 Helm Chart 在同一个仓库下。在 CI 阶段更新了 Helm Chart 镜像版本。在开发和发布分工明确的团队中，我更推荐你将源码和应用定义分离，考虑到安全性和发布的严谨性，也尽量不要通过 CI 直接修改应用定义。

你好，我是王炜。今天是我们 GitOps 高级发布策略的第一课。在之前的课程里，我们通过构建 GitOps 工作流实现了自动发布。不过，我们并没有专门去关注新老版本在做更新时是如何切换流量的，这是因为 Kubernetes 的 Service 和 Pod 滚动更新机制自动帮助我们完成了这部分的工作。在实际的生产环境中，为了提高发布的可靠性，我们通常需要借助发布策略来更加精细地控制流量切换。

可观测性（Observability）是一种软件开发和系统构建的哲学，是对系统内部状态及行为的度量和推断能力，通常包括日志、指标、链路追踪等多个度量维度。也就是说，在软件开发和运维领域中，可观测性是指对于一个复杂的系统，能够通过监控、日志、指标、追踪等手段，快速地发现、诊断、解决问题的能力。

最后，不同版本的业务镜像其实大部分的 Layer 层都是相同的，每次拉取新镜像版本只会有少量层的变化，并不是每次拉取镜像都会额外占用一份镜像空间大小，手动清理他们的收益不大，并且还可能会增加镜像拉取的时间，从而影响应用的更新速度。最后我想说的是，在生产环境中，我并不推荐你使用 StatefulSet 来部署这些中间件，这是因为诸如数据库和消息队列中间件，除了需要持久化以外，还需要实现数据备份和容灾，这并不是 K8s 擅长的，也没必要重复造轮子。，避免旧的 Pod 被同时关闭，防止服务停机。

当然，如果不同的团队开发的是同一个业务，相当于只是给业务做了微服务的拆分，那么在 testing 和 prod 环境就不需要再划分独立命名空间，只需要有一个命名空间将所有微服务汇总部署起来即可。不同的命名空间具备一定的隔离性，业务应用的工作负载以及其他的 K8s 对象可以部署在特定的命名空间中，在不同命名空间中，相同类型的资源可以重名。不过，当你有下面的需求时，我建议你考虑使用命名空间。系统级的命名空间是 K8s 集群默认创建的命名空间，主要用来隔离系统级的对象和业务对象，系统级的命名空间下面四种。

来自设计的这个示例应用是一套微服务架构的应用，你可以在GitHub 上获取源码在这里，backend目录为后端源码，frontend目录为前端源码，deploy目录是应用的，前后端都已经包含构建镜像所需的Dockerfile。前端；后端；数据库。其中，前端采用React编写，它也是应用对外提供服务的入口；后端由Python编写；数据库采用流行的Postgres。应用整体架构如下图所示：端实现了三个功能，分别是存储输入的内容，列出输入内容记录以及删除所有的记录。

以构建 Golang 镜像为例子，向你展示了减小镜像体积的具体方法，不管是最常见的更换基础镜像，还是多阶段构建，都可以有效地减小镜像体积。但是不同构建方法对应的镜像大小仍然有很大差异。多阶段镜像构建方法，它巧妙地将构建和运行环境拆分开来，大大缩小了最终生成的镜像体积。在实际工作中，我强烈推荐你使用它。另外，我还在多阶段构建介绍了一种尽量利用 Docker 缓存的构建技巧，虽然这种方法对于缩小镜像没有帮助，但它能够加快镜像构建的速度。

在上一节课，我们学习了如何使用 GitHub Action 自动构建镜像，我们通过为示例应用配置 GitHub Action 工作流，实现了自动构建，并将镜像推送到了 Docker Hub 镜像仓库。但是，要使用 GitHub Action 构建镜像，前提条件是你需要使用 GitHub 作为代码仓库，那么，如果我所在的团队使用的是 GitLab 要怎么做呢？这节课，我会带你学习如何使用 GitLab CI 来自动构建镜像。我还是以示例应用为例，使用 SaaS 版的 GitLab 从零配置 CI 流水线。

你需要额外注意一个细节，在本地的 Kind 测试集群和示例应用中，Ingress-Nginx 是通过 NodePort 的方式对外暴露的，这是因为我们在本地 Kind 集群中安装的是特殊版本的 Ingress-Nginx，而生产版本的 Ingress-Nginx 一般是通过 LoadBalancer 对外暴露的。一般来说，一个典型的微服务应用在系统的最外层会使用网关或者负载均衡器作为系统的入口，然后，根据路由规则和服务发现机制将流量转发到实际的后端微服务中（一般是业务进程所在的虚拟机上）。

但在 K8s 环境下，由于业务进程是运行在 Pod 的容器当中，而容器实际上又是运行在 K8s 集群的节点（虚拟机）当中的，这就带来一个问题：当有多个 Pod 被调度到同一台节点时，如何避免资源竞争，保障每一个业务所需的资源呢？实际上，m 代表的并不是将完整的 CPU 以“锁定”的方式配给 Pod，它计算的是“时间片”。也就是说，这是一种 CPU 的调度方法，数量越高，被分配到的 CPU 的计算时间片就越多，而那些被分配到较少 CPU 时间片的 Pod，则会因为得不到 CPU 的调度一直处于“阻塞”状态。

在这节课，我为你介绍了主流语言镜像构建的案例，包括后端语言 Golang、Java、Node.js 以及前端 Vue 框架。在这些案例中，我尽量按照真实的生产环境来编写 Dockerfile，我使用到了一些 Dockerfile 的高级用法，例如多阶段构建、使用缓存和使用 .dockerignore 等，这些用法可以帮助我们加速构建镜像和缩小镜像大小。当你需要将实际的业务进行容器化改造时，可以直接参考我编写的案例。此外，我还介绍了如何使用 buildx 构建多平台镜像。

在正式创建 Tekton 流水线之前，你需要先了解一些基本概念，你可以结合下面这张图来理解一下。在上面这张图中，从左往右依次出现了这几个概念：EventListener、TriggerTemplate、PipelineRun、Pipeline、Task 以及 Step，接下来，我就简单介绍一下它们。

在这节课，我向你介绍了如何使用 Harbor 搭建企业级镜像仓库，在安装 Harbor 的过程中，我还简单介绍了 Helm 工具的使用方法，包括添加 Helm 仓库和安装应用。在生产环境下，我们一般会使用 HTTPS 协议来加密访问请求，所以在安装 Harbor 之前，我向你介绍了组件，它可以帮助我们自动签发证书，并按照Ingress的配置生成Secret。需要注意的是，Let’s Encrypt 证书的有效期是 90 天，不过 Cert-manager 在到期前会自动帮助我们续期，使用起来非常方便。

首先，我们先来看看将示例应用改造成 Kustomize 之后的效果，如下图所示。示例应用经过 Kustomize 的改造之后，将包含下面 3 个环境。Dev，开发环境。Staging，预发布环境。Prod，生产环境。这三个环境部署的应用都是同一套，但在配置上所有不同。首先，开发环境对稳定性要求一般，所以我们使用在 Kubernetes 集群内部署的 postgres 示例，并且将 HPA 自动伸缩策略的触发条件配置为 “CPU 平均使用率 90% 时触发。

们希望实现和上一讲 Kustomize 一样的效果，将同一个 Helm Chart 部署到 Dev（开发）、Staging（预发布）、Prod（生产） 三个环境时，控制不同环境的 HPA、数据库以及镜像版本配置。环境差异方面和上一讲提到的一致，除了 Prod 环境以外，其他两个环境都使用在集群内部署的 postgres 数据库，另外，三个环境的 HPA CPU 配置也不同。Helm Chart和。接下来我们简单介绍一下它们。

上一节课，我们介绍了什么是蓝绿发布以及如何实施蓝绿发布。蓝绿发布是一种通过资源冗余来换取回滚效率的发布方式，结合，能够很方便地实现自动化的流量切换。但是它的缺点也是比较明显的：当新环境准备好之后，流量将进行全量切换，无法对新环境进行小规模的流量验证。为了更好地了解新环境的性能和潜在的问题，最好的办法是让新的环境接收一小部分生产流量。通常，我们会把一定比例的生产流量转发到新的环境，以此来验证新环境的表现。这种发布方式就叫做金丝雀发布，又叫做灰度发布。

文章目录课程受众及要求课程支持课程时间Linux基金会云本地计算基金会(CNCF)Linux基金会活动培训场地Linux基础培训产品Linux基金会认证课程受众及要求观众本课程是为现有的和有抱负的开发人员，管理员，架构师和管理人员谁是新的云原生技术和容器编排的世界。知识/技能本课程没有硬性要求，但如果你熟悉以下主题，将会受益匪浅:基本了解Linux系统简单的命令行用法对云的基本理解编程语言的基础知识了解网络概念，如TCP/IP或DNS。课程支持与参加这门课的同学互动的一个好方法是

如果您是现代应用程序开发和部署领域的新手，本课程将为您概述云原生技术以及Kubernetes等容器编排系统如何帮助实现这些技术。Kubernetes是一个非常流行的用于管理容器化工作负载的开源平台，并迅速成为IT部门的标准工作要求。同时，关于平台、框架和工具的信息量可能会让人不知所措，找到正确的方向是一项耗时的任务。Kubernetes提供了一个框架，使您能够为您的工作负载构建一个单独的平台，虽然“不包括电池”，但如果配置得当，它可以帮助解决扩展、负载均衡、编排、自我修复和配置管理等问题。...

是一个用于托管和管理包的平台，包括容器和其他依赖项。GitHub Packages 将源代码和包组合在一起，以提供集成的权限管理和计费，使你能够在 GitHub 上专注于软件开发。GitHub 正在以托管代码仓库为切入点，逐步覆盖整个研发工具链，打造一站式 DevOps 平台。项目管理有 Issues 、Projects，包管理有 Packages，CI 有 Actions，知识管理有 Wiki ，覆盖面越来越广。

在上一节课，我为你介绍了什么是金丝雀发布以及如何实施自动化金丝雀发布。在实施金丝雀发布的过程中，我们通过 Argo Rollout 的金丝雀策略将发布过程分成了 3 个阶段，每个阶段金丝雀的流量比例都不同，经过一段时间之后，金丝雀环境变成了新的生产环境。实际上，这也是一种渐进式的交付方式**，它通过延长发布时间来保护生产环境，降低了发生生产事故的概率**。无法自动判断金丝雀环境是否出错。这可能会导致一种情况，

正式进入实战之前，我们先来了解一下使用 ArgoCD来实现自动多环境管理的整体架构，如下图所示。在这张架构图中，我们会创建一个 ApplicationSet 对象，它是一个 Application 集合。它可以生成 Application CRD 资源，进而自动创建多个 ArgoCD 应用。不同应用实际上就对应了不同的环境。那么，怎么知道要创建几个 Application 对象呢？这就需要用到了。

这节课，我为你总结了在 GitOps 工作流中需要关注的安全问题。根据 GitOps 所涉及到的上下游，我在 7 个方面为你阐述了可能存在的安全隐患以及如何最大程度规避它们。实际上，在安全领域，通常我们认为世界上没有绝对的安全，只有成本、便捷性和安全的综合考量。所以，在我总结的这些安全建议里，你应该根据业务的实际情况进行动态决策，同时根据业务形态来决定在安全上投入的成本，避免过早陷入到大量的安全细节而忽略了业务本身。

在这节课，我编写了一个简单的Deployment工作负载，它包含我要介绍的两种密钥类型，分别是镜像拉取凭据和 Kubernetes Secret 对象。工作负载的Deployment内容如下。metadata:ports:env:valueFrom:其中，我将这节课的示例应用镜像存放到了 GitHub Package 仓库中，也就是域名为ghcr.io的镜像仓库中，同时设置了私有仓库类型。

这节课涉及的知识点比较多，我希望你能多花一点时间放在实战和查询例子上，这会帮助你更好地从零入门 Loki。简单总结一下，这节课我带你学习了如何通过 Loki Stack 来搭建日志系统。在实战环节，我们部署的核心组件包括 Loki、Promtail 和 Grafana。其中，Loki 负责日志的存储和查询，Promtail 负责采集 Pod 日志，Grafana 是日志的 UI 查询界面。要查询日志，我们需要编写 LogQL 语句，它包括日志流选择器和日志管道操作。