1. Service 资源

1.1 Service

Service 是软件服务（例如 mysql）的命名抽象，包含代理要侦听的本地端口（例如 3306）和一个选择算符，选择算符用来确定哪些 Pod 将响应通过代理发送的请求。

Service几种模式:

• ClusterIP

适用于集群内部的服务间通信。

apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app: my-appports:- protocol: TCPport: 80targetPort: 8080

• NodePort

适用于需要从集群外部通过node节点的映射访问服务的场景。

api版version: v1
kind: Service
metadata:name: my-service
spec:selector:app: my-apptype: NodePortports:- protocol: TCPport: 80targetPort: 8080nodePort: 30007

• LoadBalancer

适用于需要从互联网访问服务的场景。

apiVersion: v1
kind: Service
metadata:name: my-service
spec:selector:app: my-apptype: LoadBalancerports:- protocol: TCPport: 80targetPort: 8080

• Ingress

适用于需要基于路径或主机名路由流量的场景。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:name: my-ingress
spec:rules:- host: my-app.comhttp:paths:- path: /pathType: Prefixbackend:service:name: my-serviceport:number: 80

• ExternalName

将 Service 映射到一个外部名称，通常是一个 DNS 名称。适用于需要将 Kubernetes 服务与外部服务集成的场景。

apiVersion: v1
kind: Service
metadata:name: my-service
spec:type: ExternalNameexternalName: my-external-service.com

1.2 Endpoints

Endpoints 是实现实际服务的端点的集合。即是通过service发现的后端pods的集合.

1.3 Ingress

Ingress 是允许入站连接到达后端定义的端点的规则集合。

1.4 EndpointSlice

EndpointSlice 是实现某 Service 的端点的子集.

1.5 IngressClass

IngressClass 代表 Ingress 的类，被 Ingress 的规约引用

2. 配置和存储资源

2.1 ConfigMap

ConfigMap 包含供 Pod 使用的配置数据。存储非敏感的配置数据。如配置文件、环境变量等。

有2种方法可以加载configmap中的环境变量:

apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: my-imageenvFrom:- configMapRef:name: my-configmap

或者

apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: my-imageenv:- name: MY_ENV_VARIABLEvalueFrom:configMapKeyRef:name: my-configmapkey: my-config-key

2.2 Secret

Secret 包含某些类别的秘密数据。 存储敏感数据，并确保数据的安全性和访问控制。如密码、密钥、证书等。

用户名密码的引用方式:

apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: my-imageenv:- name: DB_USERNAMEvalueFrom:secretKeyRef:name: my-secretkey: username- name: DB_PASSWORDvalueFrom:secretKeyRef:name: my-secretkey: password

证书文件的引用:

secret的导入

kubectl create secret tls my-tls-secret \--cert=path/to/tls.crt \--key=path/to/tls.key

pod中的引用

apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: my-imagevolumeMounts:- name: tls-certsmountPath: /app/tlsreadOnly: truevolumes:- name: tls-certssecret:secretName: my-tls-secret

2.3 PersistentVolume

PersistentVolume (PV) 是管理员制备的一个存储资源。全局资源

2.4 PersistentVolumeClaim

PersistentVolumeClaim 是用户针对一个持久卷的请求和申领。名称空间资源

2.5 StorageClass

StorageClass 为可以动态制备 PersistentVolume 的存储类描述参数。全局资源

2.5.1 PV,PVC,StorageClass之间的关系

1. Storage Class：定义了一种存储类型，包括存储的类型、回收策略等。它允许动态创建 PV。
2. Persistent Volume (PV)：是集群中的一块存储资源，类似于一个物理磁盘。PV 可以是静态创建的，也可以是通过 Storage Class 动态创建的。
3. Persistent Volume Claim (PVC)：是用户对存储资源的请求，类似于对 PV 的申请。PVC 可以绑定到一个 PV，从而使用该 PV 提供的存储资源。

2.6 Volume

Volume 表示 Pod 中一个有名字的卷，可以由 Pod 中的任意容器进行访问。

2.7 CSIDriver

CSIDriver 抓取集群上部署的容器存储接口（CSI）卷驱动有关的信息。

2.8 CSINode

CSINode 包含节点上安装的所有 CSI 驱动有关的信息。

2.9 CSIStorageCapacity

CSIStorageCapacity 存储一个 CSI GetCapacity 调用的结果。

2.10 StorageVersionMigration v1alpha1

StorageVersionMigration 表示存储的数据向最新存储版本的一次迁移。

3. RBAC 鉴权资源

3.1 Role和RoleBinding

Role 和 RoleBinding 是 Kubernetes 中用于管理命名空间级别权限的两个核心资源。它们与 ClusterRole 和 ClusterRoleBinding 类似，但作用范围仅限于特定的命名空间。

3.1.1 Role

Role 定义了一组在特定命名空间内的权限。你可以把它看作是一种命名空间级别的“角色”，它描述了哪些 API 组、资源类型以及操作可以被允许。

Role 示例：

1. 查看特定命名空间中的 pods

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: pod-reader
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]

2. 管理特定命名空间中的 ConfigMaps

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: defaultname: configmap-admin
rules:
- apiGroups: [""]resources: ["configmaps"]verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3.1.2 RoleBinding

RoleBinding 将 Role 绑定到一个或多个用户、组或服务账户上，从而授予这些实体在特定命名空间内的相应权限。你可以把它看作是一种命名空间级别的“角色绑定”。

RoleBinding 示例：

1. 将 pod-reader Role 绑定到特定用户

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-podsnamespace: default
subjects:
- kind: Username: janeapiGroup: rbac.authorization.k8s.io
roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.io

2. 将 configmap-admin Role 绑定到一个服务账户

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: configmap-admin-bindingnamespace: default
subjects:
- kind: ServiceAccountname: configmap-admin-sa
roleRef:kind: Rolename: configmap-adminapiGroup: rbac.authorization.k8s.io

3.1.3 常见用例

1. 命名空间管理员：创建一个具有特定命名空间内所有权限的 Role，并将其绑定到命名空间管理员用户或组。

2. 应用程序访问控制：为应用程序创建一个 Role，允许它访问和修改特定命名空间内的资源（如 pods、services、configmaps 等），并将其绑定到应用程序使用的服务账户。

3. CI/CD 管道：为 CI/CD 管道创建一个 Role，允许它在特定命名空间内创建、更新和删除部署、服务等资源，并将其绑定到 CI/CD 工具使用的服务账户。

4. 多租户环境：在多租户环境中，为每个租户创建一个独立的命名空间，并为每个租户分配一个 Role 和 RoleBinding，以限制他们对资源的访问权限。

通过合理地使用 Role 和 RoleBinding，你可以实现细粒度的访问控制，确保集群中各个命名空间的安全性和稳定性。

3.2 ClusterRole和ClusterRoleBinding

ClusterRole 和 ClusterRoleBinding 是 Kubernetes 中用于管理集群级别权限的两个核心资源。它们与 Role 和 RoleBinding 类似，但作用范围是整个集群，而不仅仅是某个命名空间。

3.2.1 ClusterRole

ClusterRole 定义了一组跨集群范围的权限。你可以把它看作是一种集群级别的“角色”，它描述了哪些 API 组、资源类型以及操作可以被允许。

ClusterRole 示例：

1. 查看所有命名空间中的 pods

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: pod-reader
rules:
- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]

2. 管理集群中的所有 ConfigMaps

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: configmap-admin
rules:
- apiGroups: [""]resources: ["configmaps"]verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3.2.2 ClusterRoleBinding

ClusterRoleBinding 将 ClusterRole 绑定到一个或多个用户、组或服务账户上，从而授予这些实体相应的权限。你可以把它看作是一种集群级别的“角色绑定”。

ClusterRoleBinding 示例：

1. 将 pod-reader ClusterRole 绑定到特定用户

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: read-pods
subjects:
- kind: Username: janeapiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: pod-readerapiGroup: rbac.authorization.k8s.io

2. 将 configmap-admin ClusterRole 绑定到一个服务账户

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: configmap-admin-binding
subjects:
- kind: ServiceAccountname: configmap-admin-sanamespace: kube-system
roleRef:kind: ClusterRolename: configmap-adminapiGroup: rbac.authorization.k8s.io

3.2.3 常见用例

1. 集群管理员：创建一个具有所有权限的 ClusterRole，并将其绑定到集群管理员用户或组。

2. 监控和日志收集：为监控和日志收集工具创建一个 ClusterRole，允许它们读取集群中的各种资源（如 pods、nodes、services 等），并将其绑定到相应的服务账户。

3. CI/CD 管道：为 CI/CD 管道创建一个 ClusterRole，允许它创建、更新和删除部署、服务等资源，并将其绑定到 CI/CD 工具使用的服务账户。

4. 备份和恢复：为备份和恢复工具创建一个 ClusterRole，允许它读取和修改持久卷、配置映射等资源，并将其绑定到备份和恢复工具使用的服务账户。

3.3 LocalSubjectAccessReview

LocalSubjectAccessReview 检查用户或组是否可以在给定的命名空间内执行某操作。

3.4 SelfSubjectAccessReview

SelfSubjectAccessReview 检查当前用户是否可以执行某操作。

3.5 SelfSubjectRulesReview

SelfSubjectRulesReview 枚举当前用户可以在某命名空间内执行的操作集合。

3.6 SubjectAccessReview

SubjectAccessReview 检查用户或组是否可以执行某操作。

至此对k8s的理解应该就差不多了.当然面试中不过不拦着可以继续对K8s的监控,告警,日志,流量治理,CICD等各个面继续深入阐述自己的理解.