面试题整理9----谈谈对k8s的理解2
- 1. Service 资源
- 1.1 Service
- ClusterIP
- NodePort
- LoadBalancer
- Ingress
- ExternalName
- 1.2 Endpoints
- 1.3 Ingress
- 1.4 EndpointSlice
- 1.5 IngressClass
- 2. 配置和存储资源
- 2.1 ConfigMap
- 2.2 Secret
- 2.3 PersistentVolume
- 2.4 PersistentVolumeClaim
- 2.5 StorageClass
- 2.5.1 PV,PVC,StorageClass之间的关系
- 2.6 Volume
- 2.7 CSIDriver
- 2.8 CSINode
- 2.9 CSIStorageCapacity
- 2.10 StorageVersionMigration v1alpha1
- 3. RBAC 鉴权资源
- 3.1 Role和RoleBinding
- 3.1.1 Role
- 3.1.2 RoleBinding
- 3.1.3 常见用例
- 3.2 ClusterRole和ClusterRoleBinding
- 3.2.1 ClusterRole
- 3.2.2 ClusterRoleBinding
- 3.2.3 常见用例
- 3.3 LocalSubjectAccessReview
- 3.4 SelfSubjectAccessReview
- 3.5 SelfSubjectRulesReview
- 3.6 SubjectAccessReview
1. Service 资源
1.1 Service
Service 是软件服务(例如 mysql)的命名抽象,包含代理要侦听的本地端口(例如 3306)和一个选择算符,选择算符用来确定哪些 Pod 将响应通过代理发送的请求。
Service几种模式:
适用于集群内部的服务间通信。
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
ports:
- protocol: TCP
port: 80
targetPort: 8080
适用于需要从集群外部通过node节点的映射访问服务的场景。
api版version: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
type: NodePort
ports:
- protocol: TCP
port: 80
targetPort: 8080
nodePort: 30007
适用于需要从互联网访问服务的场景。
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: my-app
type: LoadBalancer
ports:
- protocol: TCP
port: 80
targetPort: 8080
适用于需要基于路径或主机名路由流量的场景。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- host: my-app.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: my-service
port:
number: 80
将 Service 映射到一个外部名称,通常是一个 DNS 名称。适用于需要将 Kubernetes 服务与外部服务集成的场景。
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: ExternalName
externalName: 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-container
image: my-image
envFrom:
- configMapRef:
name: my-configmap
或者
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
env:
- name: MY_ENV_VARIABLE
valueFrom:
configMapKeyRef:
name: my-configmap
key: my-config-key
2.2 Secret
Secret 包含某些类别的秘密数据。 存储敏感数据,并确保数据的安全性和访问控制。如密码、密钥、证书等。
用户名密码的引用方式:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: my-container
image: my-image
env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: my-secret
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: 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-container
image: my-image
volumeMounts:
- name: tls-certs
mountPath: /app/tls
readOnly: true
volumes:
- name: tls-certs
secret:
secretName: my-tls-secret
2.3 PersistentVolume
PersistentVolume (PV) 是管理员制备的一个存储资源。全局资源
2.4 PersistentVolumeClaim
PersistentVolumeClaim 是用户针对一个持久卷的请求和申领。名称空间资源
2.5 StorageClass
StorageClass 为可以动态制备 PersistentVolume 的存储类描述参数。全局资源
2.5.1 PV,PVC,StorageClass之间的关系
- Storage Class:定义了一种存储类型,包括存储的类型、回收策略等。它允许动态创建 PV。
- Persistent Volume (PV):是集群中的一块存储资源,类似于一个物理磁盘。PV 可以是静态创建的,也可以是通过 Storage Class 动态创建的。
- 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 示例:
- 查看特定命名空间中的 pods
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
- 管理特定命名空间中的 ConfigMaps
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: configmap-admin
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
3.1.2 RoleBinding
RoleBinding
将 Role
绑定到一个或多个用户、组或服务账户上,从而授予这些实体在特定命名空间内的相应权限。你可以把它看作是一种命名空间级别的“角色绑定”。
RoleBinding 示例:
- 将
pod-reader
Role 绑定到特定用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
- 将
configmap-admin
Role 绑定到一个服务账户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: configmap-admin-binding
namespace: default
subjects:
- kind: ServiceAccount
name: configmap-admin-sa
roleRef:
kind: Role
name: configmap-admin
apiGroup: rbac.authorization.k8s.io
3.1.3 常见用例
-
命名空间管理员:创建一个具有特定命名空间内所有权限的
Role
,并将其绑定到命名空间管理员用户或组。 -
应用程序访问控制:为应用程序创建一个
Role
,允许它访问和修改特定命名空间内的资源(如 pods、services、configmaps 等),并将其绑定到应用程序使用的服务账户。 -
CI/CD 管道:为 CI/CD 管道创建一个
Role
,允许它在特定命名空间内创建、更新和删除部署、服务等资源,并将其绑定到 CI/CD 工具使用的服务账户。 -
多租户环境:在多租户环境中,为每个租户创建一个独立的命名空间,并为每个租户分配一个
Role
和RoleBinding
,以限制他们对资源的访问权限。
通过合理地使用 Role
和 RoleBinding
,你可以实现细粒度的访问控制,确保集群中各个命名空间的安全性和稳定性。
3.2 ClusterRole和ClusterRoleBinding
ClusterRole
和 ClusterRoleBinding
是 Kubernetes 中用于管理集群级别权限的两个核心资源。它们与 Role
和 RoleBinding
类似,但作用范围是整个集群,而不仅仅是某个命名空间。
3.2.1 ClusterRole
ClusterRole
定义了一组跨集群范围的权限。你可以把它看作是一种集群级别的“角色”,它描述了哪些 API 组、资源类型以及操作可以被允许。
ClusterRole 示例:
- 查看所有命名空间中的 pods
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
- 管理集群中的所有 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 示例:
- 将
pod-reader
ClusterRole 绑定到特定用户
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io
- 将
configmap-admin
ClusterRole 绑定到一个服务账户
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: configmap-admin-binding
subjects:
- kind: ServiceAccount
name: configmap-admin-sa
namespace: kube-system
roleRef:
kind: ClusterRole
name: configmap-admin
apiGroup: rbac.authorization.k8s.io
3.2.3 常见用例
-
集群管理员:创建一个具有所有权限的
ClusterRole
,并将其绑定到集群管理员用户或组。 -
监控和日志收集:为监控和日志收集工具创建一个
ClusterRole
,允许它们读取集群中的各种资源(如 pods、nodes、services 等),并将其绑定到相应的服务账户。 -
CI/CD 管道:为 CI/CD 管道创建一个
ClusterRole
,允许它创建、更新和删除部署、服务等资源,并将其绑定到 CI/CD 工具使用的服务账户。 -
备份和恢复:为备份和恢复工具创建一个
ClusterRole
,允许它读取和修改持久卷、配置映射等资源,并将其绑定到备份和恢复工具使用的服务账户。
3.3 LocalSubjectAccessReview
LocalSubjectAccessReview 检查用户或组是否可以在给定的命名空间内执行某操作。
3.4 SelfSubjectAccessReview
SelfSubjectAccessReview 检查当前用户是否可以执行某操作。
3.5 SelfSubjectRulesReview
SelfSubjectRulesReview 枚举当前用户可以在某命名空间内执行的操作集合。
3.6 SubjectAccessReview
SubjectAccessReview 检查用户或组是否可以执行某操作。
至此对k8s的理解应该就差不多了.当然面试中不过不拦着可以继续对K8s的监控,告警,日志,流量治理,CICD等各个面继续深入阐述自己的理解.