第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/v1apps/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 文件中定义的 RoleRoleBinding 对象来创建和管理角色。您可以使用 register.go 中的代码来注册 RBAC API,从而使其可以在集群中使用。您可以使用 validation 目录中的代码来验证 RBAC API 对象,以确保它们符合要求。

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

OWENERS 维护者的列表

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-approverssig-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

提醒

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

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.modgo.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/目录下的代码实现了这些接口,并提供了应用程序资源的具体功能。

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

image-20230107141113159

总结:

  1. pkg/apis/apps/目录和staging/src/k8s.io/api/apps/目录都是Kubernetes源码的一部分。它们都是用于管理应用程序资源的代码。
  2. pkg/apis/apps/目录中的代码定义了抽象的API接口,用于描述应用程序资源的类型、字段和操作。它并没有提供资源的具体功能。
  3. staging/src/k8s.io/api/apps/目录中的代码实现了pkg/apis/apps/目录中的接口。它提供了应用程序资源的具体功能,并将其与Kubernetes系统的其他部分集成在一起。
  4. 总的来说,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 目录为例:

image-20230303135004177

📜 对上面的解释:

  • 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.crtapiserver-etcd-client.key: kube-apiserver 和 etcd 之间通信的证书和密钥。
  • apiserver.key: kube-apiserver 的私钥。
  • apiserver-kubelet-client.crtapiserver-kubelet-client.key: kube-apiserver 和 kubelet 之间通信的证书和密钥。
  • ca.crtca.key: Kubernetes 的根证书和密钥。
  • etcd 目录:etcd 的证书和密钥文件。
  • front-proxy-ca.crtfront-proxy-ca.key: 前置代理的证书和密钥。
  • front-proxy-client.crtfront-proxy-client.key: 前置代理和 kube-apiserver 之间通信的证书和密钥。
  • sa.keysa.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 链接