爱死亡机器人

查看containerd状态。配置kubeconfig。

nvidia-ctk命令修改主机上的/etc/containerd/config.toml文件。该文件已更新，以便containerd可以使用NVIDIA Container SDK。可选：确认gpu-feature-discovery和nvidia-device-plugin-daemonset pod重新启动。如果您已经安装了GPU运算符，并希望在群集中的所有节点上应用相同的时间分片配置，请执行以下步骤来配置GPU时间分片。检查硬件型号、主机信息内存、磁盘、cpu、gpu。检查节点可用gpu数量。

https://landscape.cncf.io/kubernetesminikubekindrke2kubesprayharborranchercert-managercontainerdnerdctl

1. secret寻找某个项目空间的secret的key 和value2. kube-benchkube-bench 但是kube-bench master不对3. Falcocat /var/log/syslog | grep falco | grep nginx | grep processservice falco stopgrep -r "Package management process launched" .service falco stopfalco4. auth

为了方便演示，我将示例应用的源码和 Helm Chart 存储在了同一个 Git 仓库，实际上，这并不是一个好的实践。这种方案有两个比较大的问题。首先，当我们手动修改 Helm Chart 并推送到 Git 仓库之后，在业务代码不变的情况下也会触发应用镜像构建，这个过程是没有必要的。其次，在有一定规模的团队中，开发和发布过程是分开的，应用定义仓库一般只有基础架构部门或者 SRE 部门具有修改权限，将源码和应用定义放在同一个 Git 仓库不利于权限控制，开发者也很容易误操作。

文章目录1. 简介2. 学习目标3. Observability4. 遥测（Telemetry）5. Logging6. Prometheus7. Tracing8. 成本管理（Cost Management）9. 其他资源1. 简介术语cloud native observability听起来像是另一个用来推销新工具的流行词。这可能是事实，我们有很多新工具出现来解决监控容器基础设施的问题。服务器的常规监控可能包括收集系统的基本指标，如CPU和内存资源使用情况，以及进程和操作系统的日志记录。微服务体

文章目录反模式架构演进集中中心化 -> 去中心化去中心化 -> 连接/共享 (www)虚拟机托管 -> 云托管微服务：细粒度的可重用性快速浏览关键的云优先设计模式服务网格无服务器架构容器技术单体与微服务与无服务器不断发展的架构模式历史告诉我们什么关键要点作为仓促采用微服务的一部分，架构稳定性差距和反模式可能会出现。了解历史范式转变的警告和陷阱应该使我们能够从以前的错误中吸取教训，并使我们的组织在最新的技术浪潮中蓬勃发展。了解不同架构风格（如单体应用程序、微服务和无服务器功能）的优

是的——尽管 containerd 是一个容器运行时而 Docker 是一个容器引擎，但这是可能的。这意味着可以将 containerd 与另一个称为低级运行时的组件一起使用，以完成与主机操作系统内核交互的工作以创建容器，并在此过程中承担 Docker 的功能。换句话说，它是一个容器引擎，一个允许在一个计算环境中开发的代码在另一个计算环境中工作的系统。容器运行时，例如 Docker 开发的容器运行时 containerd，是容器引擎的一个组件，它挂载容器并与操作系统内核一起启动和支持容器化进程。

是“App of Apps”部署模式的演变。它采用了“App of Apps”的理念并将其扩展为更加灵活并处理广泛的用例。ArgoCD ApplicationSets 作为自己的控制器运行，并补充了 Argo CD 应用程序 CRD 的功能。使用单个清单来定位多个 Kubernetes 集群。使用单个清单从单个或多个 git 存储库部署多个应用程序。改进对单体存储库模式（也称为“monorepo”）的支持。这是您在单个存储库中定义许多应用程序和/或环境的地方。

Creating a Pod and Inspecting itCreate the namespace ckad-prep.In the namespace ckad-prep create a new Pod named mypod with the image nginx:2.3.5. Expose the port 80.Identify the issue with creating the container. Write down the root cause of issue in

1. Configuring a Pod to Use a ConfigMapCreate a new file named config.txt with the following environmentvariables as key/value pairs on each line.DB_URL equates to localhost:3306DB_USERNAME equates to postgresCreate a new ConfigMap named db-config

1. Implementing the Adapter PatternThe adapter pattern helps with providing a simplified, homogenized view of an application running within a container. For example, we could stand up another container that unifies the log output of the application contai

Defining and Mounting a PersistentVolumeCreate a Persistent Volume named pv, access mode ReadWriteMany, storage class name shared, 512MB of storage capacity and the host path /data/config.Create a Persistent Volume Claim named pvc that requests the Pe

nodePortnodePort提供了集群外部客户端访问service的一种方式，:nodePort提供了集群外部客户端访问service的端口，即nodeIP:nodePort提供了外部流量访问k8s集群中service的入口。比如外部用户要访问k8s集群中的一个Web应用，那么我们可以配置对应service的type=NodePort，nodePort=30001。其他用户就可以通过浏览器http://node:30001访问到该web服务。而数据库等服务可能不需要被外界访问，只需被内部服务访问即

https://blog.51cto.com/ygqygq2/2308576

https://kubernetes.io/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/

文章目录1. 背景2. 什么是准入控制器插件3. 为什么需要准入控制器？4. 如何启用一个准入控制器？5. 怎么关闭准入控制器？6. 哪些插件是默认启用的？每个准入控制器的作用是什么？AlwaysAdmitAlwaysPullImagesAlwaysDenyCertificateApprovalCertificateSigningCertificateSubjectRestrictionsDefaultStorageClassDefaultTolerationSecondsDenyExecOnPrivile

背景除了内置的 admission 插件， 准入插件可以作为扩展独立开发，并以运行时所配置的 Webhook 的形式运行。 此页面描述了如何构建、配置、使用和监视准入 Webhook什么是准入 Webhook？准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。 可以定义两种类型的准入 webhook，即 验证性质的准入 Webhook 和 修改性质的准入 Webhook。 修改性质的准入 Webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的

1. 背景Kubernetes的官方文档中并没有对apiVersion的详细解释，而且因为K8S本身版本也在快速迭代，有些资源在低版本还在beta阶段，到了高版本就变成了stable。如Deployment:1.6版本之前 apiVsersion：extensions/v1beta11.6版本到1.9版本之间：apps/v1beta11.9版本之后:apps/v12. 各种apiVersion的含义alpha该软件可能包含错误。启用一个功能可能会导致bug随时可能会丢弃对该功能

文章目录1. 背景2. 介 绍3. 术 语4. Flannel5. Calico本文将在介绍技术原理和相应术语的基础上，再集中探索与详细对比目前最流行的CNI插件：Flannel、Calico、Weave和Canal，对比介绍它们的原理、使用方法、适用场景和优缺点等。1. 背景容器网络是容器选择连接到其他容器、主机和外部网络（如Internet）的机制。容器的runtime提供了各种网络模式，每种模式都会产生不同的体验。例如，Docker默认情况下可以为容器配置以下网络：none：将容器添加到.

1. Routing Traffic to Pods from Inside and Outside of a ClusterCreate a deployment named myapp that creates 2 replicas for Pods with the image nginx. Expose the container port 80.Expose the Pods so that requests can be made against the service from insi

1. Defining and Querying Labels and AnnotationsCreate three different Pods with the names frontend, backend and database that use the image nginx.Declare labels for those Pods as follows:frontend: env=prod, team=shinybackend: env=prod, team=legacy, a

Defining a Pod’s Readiness and Liveness ProbeCreate a new Pod named hello with the image bonomat/nodejs-hello-world that exposes the port 3000. Provide the name nodejs-port for the container port.Add a Readiness Probe that checks the URL path / on the p

1. 介绍链接：https://github.com/flannel-io/flannelCoreOS开发的项目Flannel，可能是最直接和最受欢迎的CNI插件。它是容器编排系统中最成熟的网络结构示例之一，旨在实现更好的容器间和主机间网络。随着CNI概念的兴起，Flannel CNI插件算是早期的入门。与其他方案相比，Flannel相对容易安装和配置。它被打包为单个二进制文件flanneld，许多常见的Kubernetes集群部署工具和许多Kubernetes发行版都可以默认安装Flannel。Fl

文章目录1. 为什么用kata-container2. 什么是kata-container3. kata container组件3.1 Agent3.2 Runtime3.3 Proxy3.4 Shim参考链接：https://blog.csdn.net/zhonglinzhang/article/details/864896951. 为什么用kata-container弥补了传统容器技术安全性的缺点，Kata Containers通过使用硬件虚拟化来达到容器隔离的目的。每一个container/

文章目录1. 背景2. 服务是如何工作的？3. Linux内核中的DNAT4. 问题5. 意见建议6. 内核修复7. 方案（一）：使用 TCP 协议发送 DNS 请求8. 方案（二）：避免相同五元组 DNS 请求的并发9. 方案（三） Kubernetes 集群中使用 NodeLocal DNSCache9.1 优势9.2 架构图9.3 环境检查9.4 部署9.5 两种种方案测试nodelocaldns实效性9.6 测试coredns+nodelocaldns的效果1. 背景【摘要】 目前18.6版

我们熟悉了Kubernetes 声明式 API 的设计、特点，以及使用方式。下面详细讲解Kubernetes 声明式 API 的工作原理，以及如何利用这套 API 机制，在 Kubernetes 里添加自定义的 API 对象。你可能一直就很好奇：当我把一个 YAML 文件提交给 Kubernetes 之后，它究竟是如何创建出一个 API 对象的呢？这得从声明式 API 的设计谈起了。在 Kubernetes 项目中，一个 API 对象在 Etcd 里的完整资源路径，是由：Group（API 组）、Ve

在上一篇文章中，我和你详细分享了 Kubernetes 中声明式 API 的实现原理，并且通过一个添加 Network 对象的实例，为你讲述了在 Kubernetes 里添加 API 资源的过程。在今天的这篇文章中，我就继续和你一起完成剩下一半的工作，即：为 Network 这个自定义 API 对象编写一个自定义控制器（Custom Controller）。正如我在上一篇文章结尾处提到的，“声明式 API”并不像“命令式 API”那样有着明显的执行逻辑。这就使得基于声明式 API 的业务功能实现，往往需要

文章目录1. Role2. RoleBinding3. ClusterRole 和ClusterRoleBinding4. 细化RBAC与运用过程在 Kubernetes 项目中，负责完成授权（Authorization）工作的机制，就是 RBAC，基于角色的访问控制（Role-Based Access Control）RBAC 体系的核心概念：Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限。Subject：被作用者，既可以是“人”，也可以是“机器”

文章目录1. 简介2. 总结1. 简介在持久化存储领域，用户呼声最高的定制化需求，莫过于支持“本地”持久化存储了。也就是说，用户希望 Kubernetes 能够直接使用宿主机上的本地磁盘目录，而不依赖于远程存储服务，来提供“持久化”的容器 Volume。这样做的好处很明显，由于这个 Volume 直接使用的是本地磁盘，尤其是 SSD 盘，它的读写性能相比于大多数远程存储来说，要好得多。这个需求对本地物理服务器部署的私有 Kubernetes 集群来说，非常常见。所以，Kubernetes 在 v1.

以DigitalOcean 的块存储（Block Storage）服务，来作为实践对象。DigitalOcean 是业界知名的“最简”公有云服务，即：它只提供虚拟机、存储、网络等为数不多的几个基础功能，其他功能一概不管。而这，恰恰就使得 DigitalOcean 成了我们在公有云上实践 Kubernetes 的最佳选择。目标：编写的 CSI 插件的功能，就是：让我们运行在 DigitalOcean 上的 Kubernetes 集群能够使用它的块存储服务，作为容器的持久化存储。备注：在 Digital

回顾在上一篇文章中，我以 Flannel 项目为例，为你详细讲解了容器跨主机网络的两种实现方法：UDP 和 VXLAN。不难看到，这些例子有一个共性，那就是用户的容器都连接在 docker0 网桥上。而网络插件则在宿主机上创建了一个特殊的设备（UDP 模式创建的是 TUN 设备，VXLAN 模式创建的则是 VTEP 设备），docker0 与这个设备之间，通过 IP 转发（路由表）进行协作。然后，网络插件真正要做的事情，则是通过某种方法，把不同宿主机上的特殊设备连通，从而达到容器跨主机通信的目的。实际

第一步，将这个 Operator 的代码 Clone 到本地：$ git clone https://github.com/coreos/etcd-operator第二步，将这个 Etcd Operator 部署在 Kubernetes 集群里。不过，在部署 Etcd Operator 的 Pod 之前，你需要先执行这样一个脚本：$ example/rbac/create_role.sh这个脚本的作用，就是为 Etcd Operator 创建 RBAC 规则。这是因为，Etcd Operato

Docker网络原理网络栈”，就包括：网卡（Network Interface）、回环设备（Loopback Device）、路由表（Routing Table）和 iptables 规则。作为一个容器，它可以声明直接使用宿主机的网络栈（–net=host），即：不开启 Network Namespace，比如：$ docker run –d –net=host --name nginx-host nginx在这种情况下，这个容器启动后，直接监听的就是宿主机的 80 端口。像这样直接使用宿主机网

FlexVolume原理在 Kubernetes 中，存储插件的开发有两种方式：FlexVolume 和 CSI。举个例子，现在我们要编写的是一个使用 NFS 实现的 FlexVolume 插件。对于一个 FlexVolume 类型的 PV 来说，它的 YAML 文件如下所示：apiVersion: v1kind: PersistentVolumemetadata: name: pv-flex-nfsspec: capacity: storage: 10Gi accessM

我以网桥类型的 Flannel 插件为例，为你讲解了 Kubernetes 里容器网络和 CNI 插件的主要工作原理。不过，除了这种模式之外，还有一种纯三层（Pure Layer 3）网络方案非常值得你注意。其中的典型例子，莫过于 Flannel 的 host-gw 模式和 Calico 项目了。我们先来看一下 Flannel 的 host-gw 模式。假设现在，Node 1 上的 Infra-container-1，要访问 Node 2 上的 Infra-container-2。当你设置 Flanne

Kubernetes 默认调度器的设计原理和架构在调度过程中 Predicates 和 Priorities 这两个调度策略主要发生作用的阶段。首先，我们一起看看 PredicatesPredicates 在调度过程中的作用，可以理解为 Filter，即：它按照调度策略，从当前集群的所有节点中，“过滤”出一系列符合条件的节点。这些节点，都是可以运行待调度 Pod 的宿主机。默认的调度策略有如下三种第一种类型，叫作 GeneralPredicates。顾名思义，这一组过滤规则，负责的是最基.

文章目录1. 优先级2. 抢占3. 调度过程1. 优先级在上一篇文章中，我为你详细讲解了 Kubernetes 默认调度器的主要调度算法的工作原理。在本篇文章中，我再来为你讲解一下 Kubernetes 调度器里的另一个重要机制，即：优先级（Priority ）和抢占（Preemption）机制。首先需要明确的是，优先级和抢占机制，解决的是 Pod 调度失败时该怎么办的问题。正常情况下，当一个 Pod 调度失败后，它就会被暂时“搁置”起来，直到 Pod 被更新，或者集群状态发生变化，调度器才会对这

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

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