container structure ¶1. 分层不是固定死的，但有典型结构 Docker 镜像的层其实是由 Dockerfile 的每一条指令生成的，所以每个镜像的层数和内容都不完全一样，但通常会有一些“典型层”： ¶常见镜像分层结构举例 假设你的 Dockerfile 是这样写的： 123456FROM ubuntu:20.04 # 基础层RUN apt-get updat

kube-apiserver kube-apiserver 是 Kubernetes 集群中最核心的组件之一，仅运行在master node上面，可以理解为整个集群的“大门”或“中枢神经”。 ¶kube-apiserver 的作用 集群的 API 网关 kube-apiserver 提供了 RESTful API 接口，所有对 Kubernetes 的操作（比如 kubectl、Dashb

etcd etcd 是 Kubernetes 集群中最核心的分布式键值数据库，仅运行在master node上面。它的主要作用是存储和管理整个集群的所有配置信息和状态数据。你可以把它理解为 Kubernetes 的“大脑”或“账本”。 ¶etcd 的主要作用 保存集群状态 所有 Kubernetes 对象（如 Pod、Service、Deployment、ConfigMap、Secret

architecture **Monolithic Architecture（单体架构）和Microservices Architecture（微服务架构）**是两种常见的软件架构模式。下面从多个维度进行对比： ¶1. 定义 ¶单体架构（Monolithic Architecture） 特点：所有功能模块都集成在一个整体应用中，作为一个单独的部署单元运行。 例子：传统的 Spring MVC W

这是一些常见的kubectl和docker命令 kubectl ¶other kubectl get nodes kubectl get namespaces / ns kubectl delete all --all - 注意，使用这个命令的时候，kubernetes服务也会被删除，但是会自动重新创建 kubectl apply -f {YAML} kubectl dele

containerd & runc containerd 和 runc 的关系在容器运行时体系中非常重要，经常被问到。可以用一句话概括： containerd 是一个高级的容器管理器，runc 是底层的容器运行工具，containerd 调用 runc 来创建和管理容器进程。 下面详细解释： ¶1. 各自是什么？ containerd 一个容器运行时守护进程，负责容器的整个生命周

铺垫 ¶设计原则 针对接口编程，而不是针对实现编程 优先使用对象组合（黑箱），而不是类继承（白箱） ¶需要重新设计的原因 通过显示地指定一个类来创建对象 对特殊操作的依赖 对硬件和软件平台的依赖 对对象表示或实现的依赖 算法依赖 紧耦合 - 屎山（ 通过生成子类来拓充功能 不能方便地对类进行修改 ¶怎样重新选择设计模式 考虑设计模式是怎么样解决设计问题的 浏览模式的意图部分 - 1.4

转移训练就是在已经训练好的模型上通过少量新数据再对模型进行调参，从而训练出一个新模型，使之可以运用于特定任务，有点类似于初级版的fine-tune。由于也是调参，所以转移训练和全新训练的过程大差不差，大致为以下： 预处理数据 (transform) 建立数据集 (dataloader) 准备，调整模型 (model) 开练 得到结果 预测 顺便介绍一个我觉得很好用的PyTorch学习资源 引

0. 一些表述问题 通过一个类来访问另一个类的成员，通常指的是在类的外部通过派生类直接访问基类的数据成员 1. 绪论 下面是生存周期 static - 静态，单文件内 external - 静态，全局默认，可以跨文件访问 register - 不知道是个啥 auto - 局部变量的默认生存周期，到点就亖 switch就算没有break也可以正常退出 2. 数据流啊？ typedef -

由于众所周知的原因，下载一些资源的时候需要代理，下面是几种常见情况的代理设置 终端 macOS终端和Windows终端是一样的。首先打开命令行的rc文件，macOS一般为~/.zshrc（用的zsh环境），Linux一般为~/.bashrc（用的bash环境），没有就新建一个。在文件末尾加上以下配置 12alias proxy='export all_proxy=socks5://127