authoropen in new window

第32节 kubernetes 目录结构

❤️💕💕新时代拥抱云原生，云原生具有环境统一、按需付费、即开即用、稳定性强特点。Myblog:http://nsddd.topopen in new window

[TOC]

分类

Kubernetes 是Go语言开发的，相对来说大部分结构还是很清晰的。

Kubernetes的代码都在 kubernetes目录下，如图，根据功能主要分成以下几类： 1、文档类（api、docs、logo） 2、工具类（build、cluster、Godeps、hack、staging、translations） 3、代码类（cmd、pkg、plugin、test、third_party）

工具类主要用到的 build目录下的文件，自己动手编译的时候会用到；

核心代码集中在cmd和pkg中。这两个是 Kubernetes 最重要的两个包~

cmd内部包含各个组件的入口，具体核心的实现部分在pkg目录下。

我们每一个可执行文件都对应 cmd

关于其他目录：

plugin 目录之前的版本包括 scheduler 部分的代码，当前版本（应该是在1.10之后）已经将scheduler部分代码移到和其他组件一致的 pkg 目录，所以目前 plugin 主要包含的是认证与鉴权部分的代码。

根目录

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree -L 1
.
├── api
├── build
├── CHANGELOG
├── CHANGELOG.md -> CHANGELOG/README.md
├── cluster
├── cmd
├── code-of-conduct.md
├── CONTRIBUTING.md
├── docs
├── go.mod
├── go.sum
├── hack
├── LICENSE
├── LICENSES
├── logo
├── Makefile -> build/root/Makefile
├── Makefile.generated_files -> build/root/Makefile.generated_files
├── _output
├── OWNERS
├── OWNERS_ALIASES
├── pkg
├── plugin
├── README.md
├── SECURITY_CONTACTS
├── staging
├── SUPPORT.md
├── test
├── third_party
└── vendor

makefile 支持交叉编译的；

Kubernetes 的编译方法有三种，makefile 和 docker 是支持交叉编译的。

api

顾名思义，

❯ tree api/ -L 2
api/
├── api-rules
│   ├── aggregator_violation_exceptions.list
│   ├── apiextensions_violation_exceptions.list
│   ├── codegen_violation_exceptions.list
│   ├── README.md
│   ├── sample_apiserver_violation_exceptions.list
│   └── violation_exceptions.list
├── openapi-spec
│   ├── README.md
│   ├── swagger.json
│   └── v3
└── OWNERS

3 directories, 9 files

我们可以看到 swagger.json

我们都知道 api 声明都是有一个 json 文件，通过声明拉取所有的 API
如果我们需要看 API 文档，看 swagger.json

pkg

提示

大量的 kubernetes 的源码所在，除了被抽离为单独组件的部分，例如 api server 的代码，proxy 组件的代码，kubelet 组件的代码。

业务逻辑都在 pkg
命令行参数都在 cmd

关于两个组件： ./pkg/api 和 ./pkg/apis

注意

Api 文件夹下包含和Open API 相关的模型定义等内容。

名称不一样，作用是完全不一样的。

用于根据 OpenAPI 规范形成符合其规定的 API
apis 是包含内建 API Groups 和 API Objects 的，而 scheme 相关的代码大部分在这里。

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree -L 1 pkg
pkg
├── api
├── apis
├── auth
├── capabilities
├── client
├── cloudprovider
├── cluster
├── controller
├── controlplane
├── credentialprovider
├── features
├── fieldpath
├── generated
├── kubeapiserver
├── kubectl
├── kubelet
├── kubemark
├── OWNERS
├── printers
├── probe
├── proxy
├── quota
├── registry
├── routes
├── scheduler
├── security
├── securitycontext
├── serviceaccount
├── util
├── volume
└── windows

apis 目录的详解

目录结构：

root@cubmaster01:~/go/src/k8s.io/kubernetes/pkg/apis# tree -L 1
.
├── abac
├── admission
├── admissionregistration
├── apidiscovery
├── apiserverinternal
├── apps
├── authentication
├── authorization
├── autoscaling
├── batch
├── certificates
├── coordination
├── core
├── discovery
├── events
├── extensions
├── flowcontrol
├── imagepolicy
├── networking
├── node
├── OWNERS
├── policy
├── rbac
├── resource
├── scheduling
└── storage

在Kubernetes源码中，core目录和apps目录是两个不同的目录，用于存放不同的API对象。

core目录下存放的是基础的API对象，例如 Pod、Service、ReplicationController 等。这些API对象是Kubernetes的核心功能，提供了基本的调度、管理和监控功能。
apps目录下存放的是扩展的API对象，例如 Deployment、StatefulSet 等。这些API对象是对基础功能的扩展，提供了更多的调度、管理和监控功能。

总之，core目录和apps目录是用来存放不同类型的API对象的。如果你想了解某个特定的API对象的详细信息，可以在相应的目录下找到对应的文件。

主要目录的解释：

pkg/apis目录是Kubernetes源码中用于存放API对象的目录。这个目录中包含了很多子目录，每个子目录存放了不同类型的API对象。

这些子目录的名称通常由两部分组成，例如 core/v1、apps/v1 等。前面的部分表示API对象的类型，后面的部分表示API对象的版本。

下面是一些常见的子目录及其含义：

core/v1：这个目录下存放的是基础的API对象，例如 Pod、Service、ReplicationController 等。这些API对象是Kubernetes的核心功能，提供了基本的调度、管理和监控功能。
apps/v1：这个目录下存放的是扩展的API对象，例如 Deployment、StatefulSet 等
batch/v1：这个目录下存放的是批处理相关的API对象，例如 Job、CronJob 等。这些API对象主要用于执行批量任务，支持周期性执行、失败重试等功能。
networking.k8s.io/v1：这个目录下存放的是网络相关的API对象，例如 Ingress、Service 负载均衡器等。这些API对象主要用于提供集群内部及外部的网络访问能力。
extensions/v1beta1：这个目录下存放的是扩展的API对象，例如 Deployment、Ingress 等。这些API对象是对基础功能的扩展，提供了更多的调度、管理和监控功能。

这些子目录只是部分目录，Kubernetes中还有许多其他子目录，每个子目录存放的是不同类型的API对象。如果你想了解更多信息，可以在Kubernetes源码仓库中查看。

在Kubernetes源码中，API对象的定义一般都位于pkg/apis目录下。例如，Deployment对象的定义就位于pkg/apis/apps/v1/deployment.go文件中。
具体的位置可能会有所不同，但通常都在这个目录或其子目录下。如果你想查看某个特定的API对象的定义，你可以在Kubernetes源码仓库中搜索关键字，找到对应的文件。
Pod对象的定义位于Kubernetes源码中的pkg/apis/core/v1/pod.go文件中。
这个文件中定义了Pod对象的所有字段，包括名称、命名空间、状态、容器列表等。如果你想了解Pod对象的更多细节，可以在这个文件中查看。

其他目录解释

pkg/apis目录下的这些子目录都是用于存放不同类型的API对象的。

abac目录存放的是授权和认证相关的API对象，例如 AttributePolicies、Policy 等。
admission目录存放的是入门相关的API对象，例如 AdmissionConfiguration、Webhook 等。
admissionregistration目录存放的是入门注册相关的API对象，例如 InitializerConfiguration、ValidatingWebhookConfiguration 等。
apidiscovery目录存放的是API发现相关的API对象，例如 APIGroup、APIResourceList 等。
apiserverinternal目录存放的是API服务器内部相关的API对象，例如 GroupResources、ServerResources 等。
authentication目录存放的是身份验证相关的API对象，例如 TokenReview、UserInfo 等。
authorization目录存放的是授权相关的API对象，例如 SelfSubjectAccessReview、SubjectAccessReview 等。
autoscaling目录存放的是自动伸缩相关的API对象，例如 HorizontalPodAutoscaler、Scale 等。
certificates目录存放的是证书相关的API对象，例如 CertificateSigningRequest、CertificateSigningRequestList 等。
coordination目录存放的是协调相关的API对象，例如 Lease、Lock 等。
core目录存放的是基础的API对象，例如 Pod、Service、ReplicationController
discovery目录存放的是发现相关的API对象，例如 EndpointSlice、ServiceAccountToken 等。
events目录存放的是事件相关的API对象，例如 Event、EventList 等。
extensions目录存放的是扩展的API对象，例如 Deployment、Ingress 等。
flowcontrol目录存放的是流量控制相关的API对象，例如 FlowSchema、FlowSchemaList 等。
imagepolicy目录存放的是镜像策略相关的API对象，例如 ImageReview、ImageReviewStatus 等。
networking目录存放的是网络相关的API对象，例如 Ingress、Service 负载均衡器等。
node目录存放的是节点相关的API对象，例如 Node、NodeList 等。
OWNERS目录存放的是OWNERS文件
policy目录存放的是策略相关的API对象，例如 PodDisruptionBudget、PodSecurityPolicy 等。
rbac目录存放的是基于角色的访问控制（RBAC）相关的API对象，例如 ClusterRole、RoleBinding 等。
resource目录存放的是资源相关的API对象，例如 ConfigMap、PersistentVolume 等。
scheduling目录存放的是调度相关的API对象，例如 PriorityClass、Scheduling 等。
storage目录存放的是存储相关的API对象，例如 StorageClass、VolumeAttachment 等。
pkg/apis/apps目录存放的是Kubernetes的扩展API对象。这些API对象是对基础功能的扩展，提供了更多的调度、管理和监控功能。这些API对象主要用于支持应用的部署、扩展和管理。

例如，pkg/apis/apps/v1目录下存放的是Deployment、StatefulSet、DaemonSet等API对象。这些API对象主要用于支持应用的部署、扩展和管理。
在pkg/apis/apps目录下，你会发现有许多子目录，每个子目录存放的是不同版本的API对象。例如，pkg/apis/apps/v1目录下存放的是Deployment、StatefulSet、DaemonSet等API对象的v1版本，pkg/apis/apps/v1beta1目录下存在pkg/apis/apps目录下，你会发现有许多子目录，每个子目录存放的是不同版本的API对象。例如，pkg/apis/apps/v1目录下存放的是Deployment、StatefulSet、DaemonSet等API对象的v1版本，pkg/apis/apps/v1beta1目录下存放的是Deployment、StatefulSet、DaemonSet等API对象的v1beta1版本。
这些子目录是为了支持Kubernetes的多版本特性而设计的。在Kubernetes中，API对象可以有多个版本，这样就可以在不破坏现有代码的情况下，提供新的功能和改进。这使得Kubernetes更加灵活，也使得Kubernetes的更新和升级变得更加容易。
在pkg/apis/apps目录下，你还会发现有很多文件，这些文件是Kubernetes的代码生成器使用的。Kubernetes的代码生成器是一种工具，可以根据用户的输入生成Kubernetes的API对象代码。这使得Kubernetes的API对象可以更加快速、简单地开发，也使得Kubernetes的API对象可以更加一致、统一地管理。
除了pkg/apis/apps目录，Kubernetes还有许多其他目录，这些目录也是Kubernetes的代码生成器使用的。例如，pkg/apis/authorization目录存放的是认证和授权相关的API对象，pkg/apis/batch目录存放的是批处理相关的API对象，pkg/apis/coordination目录存放的是协调相关的API对象等。

RBAC

about RBAC

在上面我们看到，rbac目录存放的是基于角色的访问控制（RBAC）相关的API对象，例如 ClusterRole、RoleBinding 等。

那么 RBAC 是什么呢，它是一基于角色的权限控制，或许下面的一句话能帮助你理解它：

我们都知道 Kubernetes 中所有的 API对象都保存在 etcd 中，可是，对于这些 API 对象的操作一定是通过访问 kube-apiServer 实现的。其中一个非常重要的原因就是，需要 API Server 来帮忙左授权工作。而在 Kubernetes 的项目中，负责完成授权工作的机制是 RBAC。⚠️

so，directory structure：

root@cubmaster01:/workspces/kubernetes/pkg/apis/rbac# ls -al
total 92
drwxr-xr-x  8 root root  4096 Jan  4 06:58 .
drwxr-xr-x 27 root root  4096 Jan  4 06:58 ..
-rw-r--r--  1 root root   698 Nov 30 03:40 doc.go
drwxr-xr-x  2 root root  4096 Nov 30 03:40 fuzzer
-rw-r--r--  1 root root 12362 Nov 30 03:40 helpers.go
-rw-r--r--  1 root root  9453 Nov 30 03:40 helpers_test.go
drwxr-xr-x  2 root root  4096 Nov 30 03:40 install
-rw-r--r--  1 root root   205 Nov 30 03:40 OWNERS
-rw-r--r--  1 root root  1811 Nov 30 03:40 register.go
-rw-r--r--  1 root root  7897 Jan  4 06:58 types.go
drwxr-xr-x  2 root root  4096 Nov 30 03:40 v1
drwxr-xr-x  2 root root  4096 Nov 30 03:40 v1alpha1
drwxr-xr-x  2 root root  4096 Nov 30 03:40 v1beta1
drwxr-xr-x  2 root root  4096 Jan  4 06:58 validation
-rw-r--r--  1 root root 11402 Dec  9 09:16 zz_generated.deepcopy.go

📜 对上面的解释：

doc.go 文件包含对整个包的文档的引用。
helpers.go 文件包含用于实现 RBAC 功能的帮助程序函数的代码。
helpers_test.go 文件包含用于测试 helpers.go 中的函数的代码。
install 目录包含用于安装 RBAC API 的代码。
OWNERS 文件包含对这个目录的维护者的列表。
register.go 文件包含用于注册 RBAC API 的代码。
types.go 文件包含用于定义 RBAC API 对象的代码。
validation 目录包含用于验证 RBAC API 对象的代码。
v1 目录包含 v1 版本的 RBAC API 对象的定义。
v1alpha1 目录包含 v1alpha1 版本的 RBAC API 对象的定义。
v1beta1 目录包含 v1beta1 版本的 RBAC API 对象的定义。
fuzzer 文件包含用于执行模糊测试的代码。
zz_generated.deepcopy.go 文件包含用于生成深拷贝函数的代码。

可以使用 types.go 文件中定义的 Role 和 RoleBinding 对象来创建和管理角色。您可以使用 register.go 中的代码来注册 RBAC API，从而使其可以在集群中使用。您可以使用 validation 目录中的代码来验证 RBAC API 对象，以确保它们符合要求。

这些文件和目录共同构成了 Kubernetes 中的 RBAC 功能。RBAC 功能使您可以在集群中创建和管理角色，并将角色分配给用户和组，从而控制对资源的访问。

OWENERS 维护者的列表

🔍 GitHub mdopen in new window

在 details 内容中，我们看到了 OWNERS 文件，针对 Kubernetes 的项目对维护者的列表文件做出分析，这个文件，不简单！ ⭕

# See the OWNERS docs at https://go.k8s.io/owners

# approval on api packages bubbles to api-approvers
reviewers:
  - sig-auth-authorizers-approvers
  - sig-auth-authorizers-reviewers
labels:
  - sig/auth

📜 对上面的解释：

OWNERS 文件通常包含有关目录的维护人员的信息。在这种情况下，OWNERS 文件包含有关 pkg/apis/rbac 目录的维护人员的信息。

OWNERS 文件中的 reviewers 字段包含一个用户名列表，表示在该目录中所有代码更改提交之前必须提供批准的用户。这些用户被称为审核员。例如，在本例中，所有代码更改都必须在 sig-auth-authorizers-approvers 和 sig-auth-authorizers-reviewers 两个用户中的一个批准之后才能提交。

OWNERS 文件中的 labels 字段包含一个标签列表，表示与该目录相关的主题或关注点。这些标签可以帮助您快速了解该目录所关注的内容。例如，在本例中，该目录与 sig/auth 主题有关。

OWNERS 文件是用于描述与目录相关的信息的文件，例如审核员和关注点。这些信息有助于协调和管理该目录中的代码。

❓ 我们提到了代码生成器，其实再《深入解析Kubernetes的源码》这本书中，我们了解到了代码生成器，但是书中写的逻辑不是很清晰，导致对代码生成器的理解不是很透彻~

🐭 所以还是推荐看《深入剖析Kubernetes》

代码生成器

Kubernetes的代码生成器是一种工具，用于生成Kubernetes的API对象代码。它可以根据用户的输入，自动生成Kubernetes API对象的 Go 代码。Kubernetes的代码生成器使用了一种叫做 OpenAPI 的技术，可以通过定义 API 对象的模型来生成代码。

Kubernetes的代码生成器有许多优点，例如：

减少重复工作：使用代码生成器，可以减少手写代码的工作量。
提高代码质量：使用代码生成器，可以保证生成的代码质量更高，因为它是根据模板生成的。
保证代码一致性：使用代码生成器，可以保证生成的代码风格一致，因为它是根据模板生成的。

Kubernetes的代码生成器对Kubernetes的作用非常重要，它使得Kubernetes的API对象可以更加快速、简单地开发，也使得Kubernetes的API对象可以更加一致、统一地管理。

通过使用代码生成器，Kubernetes的开发人员可以专注于API对象的业务逻辑，而不必担心底层实现细节。这大大降低了开发难度，也提高了开发效率。

此外，使用代码生成器还可以保证Kubernetes的API对象代码质量更高，因为它是根据模板生成的。这能够避免人为疏忽导致的代码错误，使得Kubernetes的API对象更加可靠。

总的来说，Kubernetes的代码生成器是一种非常有用的工具，它为Kubernetes的API对象的开发和管理带来了很多便利。

Kubernetes源码中的代码生成器例子，以及它们所在的地址目录：

Deployment代码生成器：pkg/apis/apps/v1/codegen
Service代码生成器：pkg/apis/core/v1/codegen
Pod代码生成器：pkg/apis/core/v1/codegen
ReplicationController代码生成器：pkg/apis/core/v1/codegen
Job代码生成器：pkg/apis/batch/v1/codegen
CronJob代码生成器：pkg/apis/batch/v1beta1/codegen

提醒

更多关于代码生成器的知识，推荐阅读：

Kubernetes Deep Dive：CustomResources 的代码生成open in new window

staging

这个目录准确来说是存放核心组件的，但是是临时存储的，我们可以参考 README.mdopen in new window 文件

此目录是已拆分到自己的存储库的包的暂存区。这里的内容将定期发布到各自的顶级 k8s.io 存储库。

目前在此处暂存的存储库：

staging/ 目录中的代码是权威的，即代码的唯一副本。您可以直接修改此类代码。

使用 Kubernetes 代码中的暂存存储库

Kubernetes 代码通过目录中的符号链接使用此目录中的存储库 vendor/k8s.io到此暂存区域。例如，当 Kubernetes 代码从k8s.io/client-go存储库导入一个包时，该导入被解析为staging/src/k8s.io/client-go相对于项目根目录：

// pkg/example/some_code.go
package example

import (
  "k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)

一旦完成向外部存储库的转换，这些存储库实际上将由k8s.io/<package-name>.

src/k8s

src/k8s.io/目录是Kubernetes项目的根目录，包含了Kubernetes系统的所有源代码。这是src/k8s.io/目录的高层结构：

root@cubmaster01:/workspces/kubernetes/staging/src/k8s.io# tree -L 1
.
├── api
├── apiextensions-apiserver
├── apimachinery
├── apiserver
├── client-go
├── cli-runtime
├── cloud-provider
├── cluster-bootstrap
├── code-generator
├── component-base
├── component-helpers
├── controller-manager
├── cri-api
├── csi-translation-lib
├── dynamic-resource-allocation
├── kms
├── kube-aggregator
├── kube-controller-manager
├── kubectl
├── kubelet
├── kube-proxy
├── kube-scheduler
├── legacy-cloud-providers
├── metrics
├── mount-utils
├── noderesourcetopology-api
├── pod-security-admission
├── sample-apiserver
├── sample-cli-plugin
└── sample-controller

目录功能：

api/目录包含Kubernetes API的定义。
apiextensions-apiserver/目录包含用于扩展Kubernetes API的代码。
apimachinery/目录包含用于构建Kubernetes API的工具。
apiserver/目录包含Kubernetes API服务器的源代码。
client-go/目录包含用于访问Kubernetes API的客户端库。
cli-runtime/目录包含用于扩展kubectl的库。
cloud-provider/目录包含用于支持云平台的代码。
cluster-bootstrap/目录包含用于引导新集群的工具。
code-generator/目录包含用于生成Kubernetes代码的工具。
component-base/目录包含Kubernetes组件的基础库。
component-helpers/目录包含用于帮助构建Kubernetes组件的库。
controller-manager/目录包含Kubernetes控制器管理器的代码。
csi-translation-lib/目录包含用于在Kubernetes和容器存储接口(CSI)之间进行转换的库。
cri-api/目录包含用于运行容器的代码。
dynamic-resource-allocation/目录包含用于动态分配资源的代码。
kms/目录包含用于管理加密密钥的代码。
kube-aggregator/目录包含用于提供聚合API服务器的代码。
kube-controller-manager/目录包含Kubernetes控制器管理器的代码。
kubectl/目录包含kubectl命令行工具的源代码。
kubelet/目录包含kubelet的源代码。
kube-proxy/目录包含Kubernetes代理的代码。
kube-scheduler/目录包含Kubernetes调度程序的代码。
legacy-cloud-providers/目录包含已废弃的云提供商代码。
metrics/目录包含用于收集Kubernetes度量指标的代码。
mount-utils/目录包含用于挂载文件系统的工具。
noderesourcetopology-api/目录包含用于描述节点资源拓扑结构的API。
pod-security-admission/目录包含用于控制pod安全性的代码。
sample-apiserver/目录包含Kubernetes示例API服务器的代码。
sample-cli-plugin/目录包含用于扩展kubectl的示例插件的代码。
sample-controller/目录包含Kubernetes示例控制器的代码。

staging/src/k8s.io/api/

root@cubmaster01:/workspces/kubernetes/staging/src/k8s.io# ls api
admission              authorization       coordination  flowcontrol  node       roundtrip_test.go
admissionregistration  autoscaling         core          go.mod       OWNERS     scheduling
apidiscovery           batch               discovery     go.sum       policy     SECURITY_CONTACTS
apiserverinternal      certificates        doc.go        imagepolicy  rbac       storage
apps                   code-of-conduct.md  events        LICENSE      README.md  testdata
authentication         CONTRIBUTING.md     extensions    networking   resource

功能：

admission/目录包含代码，用于控制对资源的访问。
admissionregistration/目录包含代码，用于注册资源访问控制组件。
apidiscovery/目录包含代码，用于描述Kubernetes API的发现机制。
apiserverinternal/目录包含代码，用于实现Kubernetes API服务器的内部功能。
apps/目录包含代码，用于管理应用程序资源。
authentication/目录包含代码，用于控制身份验证。
authorization/目录包含代码，用于控制授权。
autoscaling/目录包含代码，用于控制资源的自动扩展。
batch/目录包含代码，用于管理批处理资源。
certificates/目录包含代码，用于管理证书资源。
coordination/目录包含代码，用于管理分布式协调资源。
core/目录包含代码，用于管理核心资源。
rbac/目录包含代码，用于管理角色基本访问控制(RBAC)资源。
scheduling/目录包含代码，用于管理调度资源。
storage/目录包含代码，用于管理存储资源。

除了这些目录之外，还有一些文件，它们也是重要的部分：

doc.go是文档的入口文件。
go.mod和go.sum是Go的依赖管理文件。
LICENSE文件包含Kubernetes使用的许可证。
OWNERS文件包含负责维护目录的人员列表。
README.md文件包含有关目录的信息。
SECURITY_CONTACTS文件包含有关安全问题的联系人列表。
testdata/目录包含测试数据。
code-of-conduct.md文件包含有关Kubernetes社区行为准则的信息。
CONTRIBUTING.md文件包含有关如何为Kubernetes贡献代码的信息。
roundtrip_test.go文件包含用于测试的代码。

⚠️ 📜 对上面的解释：

我们可以进一步再观察 apps 目录，这个名称很眼熟，pkg/apis/apps/ 目录和 staging/src/k8s.io/api/apps/ 它们的目录结构很接近，请问它们有什么不一样，我想了解它们的对比而加深对它们的理解

pkg/apis/apps/ 目录和 staging/src/k8s.io/api/apps/目录

pkg/apis/和staging/src/k8s.io/api/目录都是Kubernetes源码的一部分。它们之间的主要区别是，pkg/apis/目录下的代码更加抽象，通常是由staging/src/k8s.io/api/目录下的代码实现的。

在Kubernetes中，pkg/apis/目录下的代码定义了API资源的抽象接口。这些接口描述了资源的类型、字段和操作，但没有实现具体的逻辑。相反，staging/src/k8s.io/api/目录下的代码实现了这些接口。这些实现提供了资源的具体功能，并将其与Kubernetes系统的其他部分集成在一起。

例如，pkg/apis/apps/目录下定义了一组接口，用于表示应用程序资源。 staging/src/k8s.io/api/apps/目录下的代码实现了这些接口，并提供了应用程序资源的具体功能。

为了跟清楚的了解，我截取了它们的目录结构：

总结：

pkg/apis/apps/目录和staging/src/k8s.io/api/apps/目录都是Kubernetes源码的一部分。它们都是用于管理应用程序资源的代码。
pkg/apis/apps/目录中的代码定义了抽象的API接口，用于描述应用程序资源的类型、字段和操作。它并没有提供资源的具体功能。
staging/src/k8s.io/api/apps/目录中的代码实现了pkg/apis/apps/目录中的接口。它提供了应用程序资源的具体功能，并将其与Kubernetes系统的其他部分集成在一起。
总的来说，pkg/apis/目录中的代码是Kubernetes中API资源的抽象接口，而staging/src/k8s.io/api/目录中的代码则是这些接口的具体实现。

cmd

cmd 算是入口，也是命令行的定义地方。

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree -L 1 cmd
cmd
├── clicheck
├── cloud-controller-manager
├── dependencycheck
├── dependencyverifier
├── gendocs
├── genkubedocs
├── genman
├── genswaggertypedocs
├── genutils
├── genyaml
├── importverifier
├── kubeadm
├── kube-apiserver
├── kube-controller-manager
├── kubectl
├── kubectl-convert
├── kubelet
├── kubemark
├── kube-proxy
├── kube-scheduler
├── linkcheck
├── OWNERS
├── preferredimports
├── prune-junit-xml
└── yamlfmt

提示

kube-apiserver 中有 apiserver.go 文件，就是 apiserver 启动入口

cmd 有很多的子目录，不同的子目录都对应的接口，比如上面的 API Server

我们甚至可以直接在里面 go build ：

❯ cd cmd/kube-apiserver;ls
apiserver.go  app  OWNERS
❯ go build apiserver.go

不过一般使用功能强大的 Makefile ，而且Makefile支持交叉编译。

Kubernetes 是很多组件的二进制相互配合部署起来的。

kube-apiserver

以 kube-apiserver cmd 目录为例：

📜 对上面的解释：

options ：一般里面的 options 是解析入参，并且进行入参校验
里面的核心都是调到 pkg/* 下面的，比如说 api、apis对象

build

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree -L 1 build
build
├── build-image
├── common.sh
├── copy-output.sh
├── dependencies.yaml
├── lib
├── make-build-image.sh
├── make-clean.sh
├── nsswitch.conf
├── OWNERS
├── package-tarballs.sh
├── pause
├── README.md
├── release-images.sh
├── release-in-a-container.sh
├── release.sh
├── root
├── run.sh
├── server-image
├── shell.sh
├── tools.go
└── util.sh

vendor

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree -L 1 vendor/
vendor/
├── bitbucket.org
├── cloud.google.com
├── github.com
├── go.etcd.io
├── golang.org
├── gonum.org
├── google.golang.org
├── go.opencensus.io
├── go.opentelemetry.io
├── gopkg.in
├── go.starlark.net
├── go.uber.org
├── k8s.io
├── modules.txt
├── OWNERS
└── sigs.k8s.io

hack

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree -L 1 hack/
hack/
├── benchmark-go.sh
├── boilerplate
├── build-cross.sh
├── build-go.sh
├── cherry_pick_pull.sh
├── conformance
├── dev-build-and-push.sh
├── dev-build-and-up.sh
├── dev-push-conformance.sh
├── e2e-internal
├── e2e-node-test.sh
├── generate-docs.sh
├── gen-swagger-doc
├── get-build.sh
├── ginkgo-e2e.sh
├── grab-profiles.sh
├── install-etcd.sh
├── jenkins
├── lib
├── lint-dependencies.sh
├── list-feature-tests.sh
├── local-up-cluster.sh
├── logcheck.conf
├── make-rules
├── module-graph.sh
├── OWNERS
├── pin-dependency.sh
├── print-workspace-status.sh
├── README.md
├── run-in-gopath.sh
├── run-prometheus-on-etcd-scrapes.sh
├── serve-prom-scrapes.sh
├── testdata
├── test-go.sh
├── test-integration.sh
├── tools
├── unwanted-dependencies.json
├── update-all.sh
├── update-codegen.sh
├── update-conformance-yaml.sh
├── update-generated-api-compatibility-data.sh
├── update-generated-device-plugin-dockerized.sh
├── update-generated-device-plugin.sh
├── update-generated-docs.sh
├── update-generated-kms-dockerized.sh
├── update-generated-kms.sh
├── update-generated-kubelet-plugin-registration-dockerized.sh
├── update-generated-kubelet-plugin-registration.sh
├── update-generated-pod-resources-dockerized.sh
├── update-generated-pod-resources.sh
├── update-generated-protobuf-dockerized.sh
├── update-generated-protobuf.sh
├── update-generated-runtime-dockerized.sh
├── update-generated-runtime.sh
├── update-generated-stable-metrics.sh
├── update-generated-swagger-docs.sh
├── update-gofmt.sh
├── update-import-aliases.sh
├── update-internal-modules.sh
├── update-kustomize.sh
├── update-mocks.sh
├── update-netparse-cve.sh
├── update-openapi-spec.sh
├── update-translations.sh
├── update-vendor-licenses.sh
├── update-vendor.sh
├── update-yamlfmt.sh
├── verify-all.sh
├── verify-api-groups.sh
├── verify-boilerplate.sh
├── verify-cli-conventions.sh
├── verify-codegen.sh
├── verify-conformance-requirements.sh
├── verify-conformance-yaml.sh
├── verify-description.sh
├── verify-e2e-test-ownership.sh
├── verify-external-dependencies-version.sh
├── verify-flags
├── verify-flags-underscore.py
├── verify-generated-device-plugin.sh
├── verify-generated-docs.sh
├── verify-generated-files-remake.sh
├── verify-generated-files.sh
├── verify-generated-kms.sh
├── verify-generated-kubelet-plugin-registration.sh
├── verify-generated-pod-resources.sh
├── verify-generated-protobuf.sh
├── verify-generated-runtime.sh
├── verify-generated-stable-metrics.sh
├── verify-generated-swagger-docs.sh
├── verify-gofmt.sh
├── verify-golangci-lint.sh
├── verify-govet-levee.sh
├── verify-govet.sh
├── verify-import-aliases.sh
├── verify-import-boss.sh
├── verify-imports.sh
├── verify-internal-modules.sh
├── verify-linkcheck.sh
├── verify-mocks.sh
├── verify-netparse-cve.sh
├── verify-non-mutating-validation.sh
├── verify-no-vendor-cycles.sh
├── verify-openapi-spec.sh
├── verify-pkg-names.sh
├── verify-prerelease-lifecycle-tags.sh
├── verify-prometheus-imports.sh
├── verify-publishing-bot.py
├── verify-readonly-packages.sh
├── verify-shellcheck.sh
├── verify-spelling.sh
├── verify-staging-meta-files.sh
├── verify-test-code.sh
├── verify-test-featuregates.sh
├── verify-test-images.sh
├── verify-typecheck-providerless.sh
├── verify-typecheck.sh
├── verify-vendor-licenses.sh
├── verify-vendor.sh
└── verify-yamlfmt.sh

plugin

plugin目录之前的版本包括 scheduler 部分的代码，当前版本（应该是在1.10之后）已经将scheduler部分代码移到和其他组件一致的pkg目录，所以目前 plugin 主要包含的是认证与鉴权部分的代码。

root@cubmaster01:~/go/src/k8s.io/kubernetes# tree plugin/ -L 4
plugin/
├── OWNERS
└── pkg
    ├── admission
    │   ├── admit
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── alwayspullimages
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── antiaffinity
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   └── doc.go
    │   ├── certificates
    │   │   ├── approval
    │   │   ├── OWNERS
    │   │   ├── signing
    │   │   ├── subjectrestriction
    │   │   └── util.go
    │   ├── defaulttolerationseconds
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── deny
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── eventratelimit
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   ├── apis
    │   │   ├── cache.go
    │   │   ├── cache_test.go
    │   │   ├── config.go
    │   │   ├── doc.go
    │   │   └── limitenforcer.go
    │   ├── extendedresourcetoleration
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── gc
    │   │   ├── gc_admission.go
    │   │   └── gc_admission_test.go
    │   ├── imagepolicy
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   ├── certs_test.go
    │   │   ├── config.go
    │   │   ├── config_test.go
    │   │   ├── doc.go
    │   │   ├── gencerts.sh
    │   │   └── OWNERS
    │   ├── limitranger
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   └── interfaces.go
    │   ├── namespace
    │   │   ├── autoprovision
    │   │   └── exists
    │   ├── network
    │   │   ├── defaultingressclass
    │   │   └── denyserviceexternalips
    │   ├── noderestriction
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   └── OWNERS
    │   ├── nodetaint
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── OWNERS
    │   ├── podnodeselector
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── podtolerationrestriction
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   ├── apis
    │   │   ├── config.go
    │   │   └── doc.go
    │   ├── priority
    │   │   ├── admission.go
    │   │   └── admission_test.go
    │   ├── resourcequota
    │   │   └── admission_test.go
    │   ├── runtimeclass
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   └── OWNERS
    │   ├── security
    │   │   ├── doc.go
    │   │   ├── podsecurity
    │   │   └── podsecuritypolicy
    │   ├── securitycontext
    │   │   └── scdeny
    │   ├── serviceaccount
    │   │   ├── admission.go
    │   │   ├── admission_test.go
    │   │   ├── doc.go
    │   │   └── OWNERS
    │   └── storage
    │       ├── persistentvolume
    │       ├── storageclass
    │       └── storageobjectinuseprotection
    └── auth
        ├── authenticator
        │   ├── OWNERS
        │   └── token
        ├── authorizer
        │   ├── doc.go
        │   ├── node
        │   ├── OWNERS
        │   └── rbac
        ├── doc.go
        └── OWNERS

test

e2e 测试代码

Kubernetes 的 ETC 目录

Kubernetes 是一个广泛使用的容器编排平台，下面是 Kubernetes 的目录和文件，包括了平台的核心组件和证书等相关文件。

├── audit-policy.yml
├── controller-manager.conf
├── kubeadm.yaml
├── kubelet.conf
├── manifests
│   ├── etcd.yaml
│   ├── kube-apiserver.yaml
│   ├── kube-controller-manager.yaml
│   └── kube-scheduler.yaml
├── pki
│   ├── apiserver.crt
│   ├── apiserver-etcd-client.crt
│   ├── apiserver-etcd-client.key
│   ├── apiserver.key
│   ├── apiserver-kubelet-client.crt
│   ├── apiserver-kubelet-client.key
│   ├── ca.crt
│   ├── ca.key
│   ├── etcd
│   │   ├── ca.crt
│   │   ├── ca.key
│   │   ├── healthcheck-client.crt
│   │   ├── healthcheck-client.key
│   │   ├── peer.crt
│   │   ├── peer.key
│   │   ├── server.crt
│   │   └── server.key
│   ├── front-proxy-ca.crt
│   ├── front-proxy-ca.key
│   ├── front-proxy-client.crt
│   ├── front-proxy-client.key
│   ├── sa.key
│   └── sa.pub
└── scheduler.conf

audit-policy.yml

audit-policy.yml 是 Kubernetes 的审核策略文件，它规定了哪些事件需要被记录，以及记录的内容。

controller-manager.conf

controller-manager.conf 是 Kubernetes 的控制器管理器的配置文件。

kubeadm.yaml

kubeadm.yaml 是 Kubernetes 的初始化配置文件，包含了初始化集群所需要的信息。

kubelet.conf

kubelet.conf 是 Kubernetes 的 kubelet 组件的配置文件。

manifests

manifests 目录包含 Kubernetes 的核心组件的配置文件，它们是：

etcd.yaml: etcd 是 Kubernetes 集群的数据库，存储了集群的状态信息。
kube-apiserver.yaml: kube-apiserver 是 Kubernetes 的 API 服务器，负责处理 API 请求。
kube-controller-manager.yaml: kube-controller-manager 是 Kubernetes 的控制器管理器，负责管理集群的各种控制器。
kube-scheduler.yaml: kube-scheduler 是 Kubernetes 的调度器，负责将 Pod 分配到合适的节点上运行。

pki

pki 目录包含 Kubernetes 的证书和密钥文件，它们是：

apiserver.crt: kube-apiserver 的证书。
apiserver-etcd-client.crt 和 apiserver-etcd-client.key: kube-apiserver 和 etcd 之间通信的证书和密钥。
apiserver.key: kube-apiserver 的私钥。
apiserver-kubelet-client.crt 和 apiserver-kubelet-client.key: kube-apiserver 和 kubelet 之间通信的证书和密钥。
ca.crt 和 ca.key: Kubernetes 的根证书和密钥。
etcd 目录：etcd 的证书和密钥文件。
front-proxy-ca.crt 和 front-proxy-ca.key: 前置代理的证书和密钥。
front-proxy-client.crt 和 front-proxy-client.key: 前置代理和 kube-apiserver 之间通信的证书和密钥。
sa.key 和 sa.pub: Kubernetes 的 Service Account 的证书和密钥。

scheduler.conf

scheduler.conf 是 Kubernetes 的调度器的配置文件。

补充

这里可以在补充部分 sealer 的实现实现：

展开如下：

SaveAll函数用于将所有配置信息保存到文件中。

func (c *ClusterFile) SaveAll(opts SaveOptions) error {
	var (
		clusterfileBytes [][]byte
		config           []byte
		plugin           []byte
	)
	fileName := common.GetDefaultClusterfile()
	err := os.MkdirAll(filepath.Dir(fileName), os.ModePerm)
	if err != nil {
		return fmt.Errorf("failed to mkdir %s: %v", fileName, err)
	}

	cluster, err := yaml.Marshal(c.cluster)
	if err != nil {
		return err
	}
	
	clusterfileBytes = append(clusterfileBytes, cluster)

	if len(c.configs) != 0 {
		for _, cg := range c.configs {
			config, err = yaml.Marshal(cg)
			if err != nil {
				return err
			}
			clusterfileBytes = append(clusterfileBytes, config)
		}
	}

	if len(c.plugins) != 0 {
		for _, p := range c.plugins {
			plugin, err = yaml.Marshal(p)
			if err != nil {
				return err
			}
			clusterfileBytes = append(clusterfileBytes, plugin)
		}
	}

	if len(c.kubeadmConfig.InitConfiguration.TypeMeta.Kind) != 0 {
		initConfiguration, err := yaml.Marshal(c.kubeadmConfig.InitConfiguration)
		if err != nil {
			return err
		}
		clusterfileBytes = append(clusterfileBytes, initConfiguration)
	}

	if len(c.kubeadmConfig.JoinConfiguration.TypeMeta.Kind) != 0 {
		joinConfiguration, err := yaml.Marshal(c.kubeadmConfig.JoinConfiguration)
		if err != nil {
			return err
		}
		clusterfileBytes = append(clusterfileBytes, joinConfiguration)
	}
	
	if len(c.kubeadmConfig.ClusterConfiguration.TypeMeta.Kind) != 0 {
		clusterConfiguration, err := yaml.Marshal(c.kubeadmConfig.ClusterConfiguration)
		if err != nil {
			return err
		}
		clusterfileBytes = append(clusterfileBytes, clusterConfiguration)
	}

	if len(c.kubeadmConfig.KubeletConfiguration.TypeMeta.Kind) != 0 {
		kubeletConfiguration, err := yaml.Marshal(c.kubeadmConfig.KubeletConfiguration)
		if err != nil {
			return err
		}
		clusterfileBytes = append(clusterfileBytes, kubeletConfiguration)
	}

	if len(c.kubeadmConfig.KubeProxyConfiguration.TypeMeta.Kind) != 0 {
		kubeProxyConfiguration, err := yaml.Marshal(c.kubeadmConfig.KubeProxyConfiguration)
		if err != nil {
			return err
		}
		clusterfileBytes = append(clusterfileBytes, kubeProxyConfiguration)
	}

	content := bytes.Join(clusterfileBytes, []byte("---\n"))
	err = utilsos.NewCommonWriter(fileName).WriteFile(content)
	if err != nil {
		return fmt.Errorf("failed to save clusterfile to disk:%v", err)
	}

	if opts.CommitToCluster {
		return saveToCluster(content, opts.ConfPath)
	}
	return nil
}

有意思的是：部分的 Kubernetes 的保存中，config 和 plug 是以一维切片的形式存储的，而clusterfileBytes 用来收集所有的内容，使用的是二维数组的方式存储的，KubeadmConfig 是随便存储的。获取到 config 和 plug 也只是判断是否为 0

END 链接

Ⓜ️回到目录🏠
🫵参与贡献💞❤️‍🔥💖open in new window)

# 第32节 kubernetes 目录结构

# 分类

# 根目录

# api

# pkg

# apis 目录的详解

# 其他目录解释

# RBAC

# OWENERS 维护者的列表

# 代码生成器

# staging

# 使用 Kubernetes 代码中的暂存存储库

# src/k8s

# staging/src/k8s.io/api/

# pkg/apis/apps/ 目录和 staging/src/k8s.io/api/apps/目录

# cmd

# kube-apiserver

# build

# vendor

# hack

# plugin

# test

# Kubernetes 的 ETC 目录

# audit-policy.yml

# controller-manager.conf

# kubeadm.yaml

# kubelet.conf

# manifests

# pki

# scheduler.conf

# 补充

# END 链接

第32节 kubernetes 目录结构

分类

根目录

api

pkg

apis 目录的详解

其他目录解释

RBAC

OWENERS 维护者的列表

代码生成器

staging

使用 Kubernetes 代码中的暂存存储库

src/k8s

staging/src/k8s.io/api/

pkg/apis/apps/ 目录和 staging/src/k8s.io/api/apps/目录

cmd

kube-apiserver

build

vendor

hack

plugin

test

Kubernetes 的 ETC 目录

audit-policy.yml

controller-manager.conf

kubeadm.yaml

kubelet.conf

manifests

pki

scheduler.conf

补充

END 链接