【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（上）
目录
一、k8s 安全管理：认证、授权、准入控制概述
1.1 认证
认证基本介绍
授权基本介绍
准入控制基本介绍
为什么需要准入控制器呢？
k8s 客户端访问 apiserver 的几种认证方式
kubeconfig 文件
1.2 授权
Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 的关系如下：
用户基于 rbac 授权有几种方案：
1.3 准入控制
查看 apiserver 启用的准入控制器有哪些？
二、UserAccount 和 ServiceAccount 介绍
三、ServiceAccount 使用案例介绍
3.1 创建 sa（ServiceAccount）并绑定到 pod
1）创建 sa
2）创建 pod
3）对 sa 做授权
4）再次请求
四、RBAC 认证授权策略
4.1 RBAC 介绍
4.2 Role：角色
4.3 ClusterRole：集群角色
4.4 RoleBinding：角色绑定、ClusterRolebinding：集群角色绑定
五、资源的引用方式
一、k8s 安全管理：认证、授权、准入控制概述
1.1 认证
认证基本介绍
kubernetes 主要通过 APIserver 对外提供服务，那么就需要对访问 apiserver 的用户做认证，如果任何人都能访问 apiserver，那么就可以随意在 k8s 集群部署资源，这是非常危险的，也容易被黑客攻击渗透，所以需要我们对访问 k8s 系统的 apiserver 的用户进行认证，确保是合法的符合要求的用户。
授权基本介绍
认证通过后仅代表它是一个被 apiserver 信任的用户，能访问 apiserver，但是用户是否拥有删除资源的权限，需要进行授权操作，常见的授权方式有 rbac 授权。
准入控制基本介绍
当用户经过认证和授权之后，最后一步就是准入控制了，k8s 提供了多种准入控制机制，它有点类似"插件"，为 apiserver 提供了很好的"可扩展性"。请求 apiserver 时，通过认证、鉴权后、持久化("api 对象"保存到 etcd)前，会经过"准入控制器"，让它可以做"变更和验证"。
为什么需要准入控制器呢？
如果我们创建 pod 时定义了资源上下限，但不满足 LimitRange 规则中定义的资源上下限，此时 LimitRanger 就会拒绝我们创建此 pod。
假如我们定义了一个名称空间叫做 test-aa，这个名称空间做下资源限制：限制最多可以使用10vCPU、10Gi 内存，在这个名称空间 test-aa 下创建的所有 pod，定义 limit 的时候，所有 pod 的 limit 值不能超过 test-aa 这个名称空间设置的 limit 上限。
k8s 客户端访问 apiserver 的几种认证方式
1）客户端认证：
客户端认证也称为双向 TLS 认证， kubectl 在访问 apiserver 的时候，apiserver 也要认证kubectl 是否是合法的，他们都会通过 ca 根证书来进行验证，如下图：
2）Bearertoken
Bearertoken 的方式，可以理解为 apiserver 将一个密码通过了非对称加密的方式告诉了kubectl，然后通过该密码进行相互访问，如下图：
Kubectl 访问 k8s 集群，要找一个 kubeconfig 文件，基于 kubeconfig 文件里的用户访问 apiserver。
3）Service account
上面客户端证书认证和 Bearertoken 的两种认证方式，都是外部访问 apiserver 的时候使用的方式，那么我们这次说的 Service account 是内部访问 pod 和 apiserver 交互时候采用的一种方式。Service account 包括了，namespace、token、ca，且通过目录挂载的方式给予 pod，当 pod运行起来的时候，就会读取到这些信息，从而使用该方式和 apiserver 进行通信。如下图：
kubeconfig 文件
在 K8S 集群当中，当我们使用 kubectl 操作 k8s 资源时候，需要确定我们用哪个用户访问哪个 k8s 集群，kubectl 操作 k8s 集群资源会去 /root/.kube 目录下找 config 文件，可以通过 kubectl config 查看 config 文件配置，如下：
[root@k8s-master01 ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:certificate-authority-data: DATA+OMITTEDserver: https://192.168.78.133:6443 # apiserver 的地址name: kubernetes # k8s 集群的名字
contexts:
- context:cluster: kubernetesuser: kubernetes-adminname: kubernetes-admin@kubernetes # 上下文的名字
current-context: kubernetes-admin@kubernetes # 当前上下文的名字
kind: Config
preferences: {}
users:
- name: kubernetes-adminuser:client-certificate-data: REDACTEDclient-key-data: REDACTED在上面的配置文件当中，定义了集群、上下文以及用户。其中 Config 也是 K8S 的标准资源之一，在该配置文件当中定义了一个集群列表，指定的集群可以有多个；用户列表也可以有多个，指明集群中的用户；而在上下文列表当中，是进行定义可以使用哪个用户对哪个集群进行访问，以及当前使用的上下文是什么。
使用 kubeconfig 文件组织集群访问：使用 kubeconfig 文件组织集群访问 | Kubernetes
1.2 授权
用户通过认证之后，默认什么权限都没有，需要一些后续的授权操作，如对资源的增删改查等，kubernetes1.6 之后开始有 RBAC（基于角色的访问控制机制）授权检查机制。
Kubernetes的授权是基于插件形成的，其常用的授权插件有以下几种：
- Node（节点认证）
- ABAC (基于属性的访问控制)
- RBAC（基于角色的访问控制）
- Webhook（基于 http 回调机制的访问控制）
鉴权模块：鉴权概述 | Kubernetes
什么是 RBAC（基于角色的授权）？
让一个用户（Users）扮演一个角色（Role），角色拥有权限，从而让用户拥有这样的权限，随后在授权机制当中，只需要将权限授予某个角色，此时用户将获取对应角色的权限，从而实现角色的访问控制。如图：
在 k8s 的授权机制当中，采用 RBAC 的方式进行授权，其工作逻辑是，把对对象的操作权限定义到一个角色当中，再将用户绑定到该角色，从而使用户得到对应角色的权限。如果通过rolebinding 绑定 role，只能对 rolebingding 所在的名称空间的资源有权限，上图 user1 这个用户绑定到 role1 上，只对 role1 这个名称空间的资源有权限，对其他名称空间资源没有权限，属于名称空间级别的。
另外，k8s 为此还有一种集群级别的授权机制，就是定义一个集群角色（ClusterRole），对集群内的所有资源都有可操作的权限，从而将 User2 通过 ClusterRoleBinding 到 ClusterRole，从而使 User2 拥有集群的操作权限。
Role、RoleBinding、ClusterRole 和 ClusterRoleBinding 的关系如下：
- 用户基于 rolebinding 绑定到 role
限定在 rolebinding 所在的名称空间
- 用户基于 rolebinding 绑定到 clusterrole
上面我们说了两个种角色绑定：
（1）用户通过 rolebinding 绑定 role
（2）用户通过 rolebinding 绑定 clusterrole
rolebinding 绑定 clusterrole 的好处：
假如有 6 个名称空间，每个名称空间的用户都需要对自己的名称空间有管理员权限，那么需要定义 6 个 role 和 rolebinding，然后依次绑定，如果名称空间更多，我们需要定义更多的 role，这个是很麻烦的，所以我们引入 clusterrole，定义一个 clusterrole，对 clusterrole 授予所有权限，然后用户通过 rolebinding 绑定到 clusterrole，就会拥有自己名称空间的管理员权限了
注：RoleBinding 仅对当前名称空间有对应的权限。
- 用户基于 clusterrolebinding 绑定到 clusterrole
用户基于 rbac 授权有几种方案：
- 基于 rolebinding 绑定到 role 上；
- 基于 rolebinding 绑定到 clusterrole 上；
- 基于 clusterrolebinding 绑定到 clusterrole 上。
Role 和 ClusterRole：使用 RBAC 鉴权 | Kubernetes
RoleBinding 和 ClusterRoleBinding：使用 RBAC 鉴权 | Kubernetes
1.3 准入控制
在 k8s 上准入控制器的模块有很多，其中比较常用的有 LimitRanger、ResourceQuota、ServiceAccount、PodSecurityPolicy(k8s 1.25 废弃了)等等，对于前面三种准入控制器系统默认是启用的，我们只需要定义对应的规则即可；对于 PodSecurityPolicy(k8s 1.25 废弃了)这种准入控制器，系统默认没有启用，如果我们要使用，就必需启用以后，对应规则才会正常生效；这里需要注意一点，对应 psp 准入控制器，一定要先写好对应的规则，把规则和权限绑定好以后，在启用对应的准入控制器，否则先启用准入控制器，没有对应的规则，默认情况它是拒绝操作，这可能导致现有的 k8s 系统跑的系统级 pod 无法正常工作；所以对于 psp 准入控制器要慎用，如果规则和权限做的足够精细，它会给我们的 k8s 系统安全带来大幅度的提升，反之，可能导致整个 k8s 系统不可用。
查看 apiserver 启用的准入控制器有哪些？
[root@k8s-master01 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep enable-admission-plugins- --enable-admission-plugins=NodeRestriction提示：
apiserver 启用准入控制插件需要使用 --enable-admission-plugins 选项来指定，该选项可以使用多个值，用逗号隔开表示启用指定的准入控制插件；这里配置文件中显式启用了NodeRestrication 这个插件；默认没有写在这上面的内置准入控制器，它也是启用了的，比如LimitRanger、ResourceQuota、ServiceAccount 等等；对于不同的 k8s 版本，内置的准入控制器和启用与否请查看相关版本的官方文档；对于那些没有启动的准入控制器，我们可以在上面选项中直接启用，分别用逗号隔开即可。
准入控制器参考：准入控制器参考 | Kubernetes
二、UserAccount 和 ServiceAccount 介绍
kubernetes 中账户分为：UserAccounts（用户账户） 和 ServiceAccounts（服务账户） 两种：UserAccount 是给 kubernetes 集群外部用户使用的，如 kubectl 访问 k8s 集群要用useraccount 用户，kubeadm 安装的 k8s，默认的 useraccount 用户是 kubernetes-admin。
k8s 客户端(一般用 kubectl) ------> APIServer
APIServer 需要对客户端做认证，使用 kubeadm 安装的 K8s，会在用户家目录下创建一个认证配置文件 /root/.kube/config 这里面保存了客户端访问 APIServer 的密钥相关信息，这样当用 kubectl访问 k8s 时，它就会自动读取该配置文件，向 APIServer 发起认证，然后完成操作请求。
# 用户名称可以在 kubeconfig 中查看
[root@k8s-master01 ~]# cat .kube/config | grep "\- name"
- name: kubernetes-admin
ServiceAccount 是 Pod 使用的账号，Pod 容器的进程需要访问 API Server 时用的就是ServiceAccount 账户；ServiceAccount 仅局限它所在的 namespace，每个 namespace 创建时都会自动创建一个 default service account；创建 Pod 时，如果没有指定 Service Account，Pod 则会使用 default Service Account。
用户账号与服务账号：管理服务账号 | Kubernetes
三、ServiceAccount 使用案例介绍
3.1 创建 sa（ServiceAccount）并绑定到 pod
1）创建 sa
[root@k8s-master01 ~]# kubectl create sa sa-test
serviceaccount/sa-test created[root@k8s-master01 ~]# kubectl get serviceaccounts
NAME SECRETS AGE
default 0 68d
sa-test 0 17s2）创建 pod
[root@k8s-master01 ~]# mkdir serviceaccount
[root@k8s-master01 ~]# cd serviceaccount/
[root@k8s-master01 serviceaccount]# vim pod.yaml
apiVersion: v1
kind: Pod
metadata:name: sa-testnamespace: defaultlabels:app: sa
spec:serviceAccountName: sa-testcontainers:- name: sa-nginxports:- containerPort: 80image: nginximagePullPolicy: IfNotPresent[root@k8s-master01 serviceaccount]# kubectl apply -f pod.yaml
pod/sa-test created[root@k8s-master01 serviceaccount]# kubectl get pods
NAME READY STATUS RESTARTS AGE
sa-test 1/1 Running 0 4s# 进入容器内部访问 service
[root@k8s-master01 serviceaccount]# kubectl exec -it sa-test -- bash
root@sa-test:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt namespace token
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes/api/v1/namespaces/kube-system
{"kind": "Status","apiVersion": "v1","metadata": {},"status": "Failure","message": "namespaces \"kube-system\" is forbidden: User \"system:serviceaccount:default:sa-test\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"kube-system\"","reason": "Forbidden","details": {"name": "kube-system","kind": "namespaces"},"code": 403上面结果能看到 sa 能通过 https 方式成功认证 API，但是没有权限访问 k8s 资源，所以 code状态码是 403，表示没有权限操作 k8s 资源。
3）对 sa 做授权
[root@k8s-master01 ~]# kubectl create clusterrolebinding sa-test-admin --clusterrole=cluster-admin --serviceaccount=default:sa-test
4）再次请求
root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes/api/v1/namespaces/kube-system
{"kind": "Status","apiVersion": "v1","metadata": {},"status": "Failure","message": "namespaces \"kube-system\" is forbidden: User \"system:serviceaccount:default:sa-test\" cannot get resource \"namespaces\" in API group \"\" in the namespace \"kube-system\"","reason": "Forbidden","details": {"name": "kube-system","kind": "namespaces"},"code": 403
}root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes/api/v/namespaces/kube-system
{"kind": "Namespace","apiVersion": "v1","metadata": {"name": "kube-system","uid": "5d0a0f96-745a-4116-8fa5-464def457f38","resourceVersion": "15","creationTimestamp": "2022-10-22T05:31:58Z","labels": {"kubernetes.io/metadata.name": "kube-system"},"managedFields": [{"manager": "kube-apiserver","operation": "Update","apiVersion": "v1","time": "2022-10-22T05:31:58Z","fieldsType": "FieldsV1","fieldsV1": {"f:metadata": {"f:labels": {".": {},"f:kubernetes.io/metadata.name": {}}}}}]},"spec": {"finalizers": ["kubernetes"]},"status": {"phase": "Active"}
}# 访问 pod 资源
}root@sa-test:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes/api/v/pods通过上面可以看到，对 sa 做授权之后就有权限访问 k8s 资源了。
使用默认的服务账号访问 API 服务器：为 Pod 配置服务账号 | Kubernetes
四、RBAC 认证授权策略
4.1 RBAC 介绍
在 Kubernetes 中，所有资源对象都是通过 API 进行操作，他们保存在 etcd 里。而对 etcd 的操作我们需要通过访问 kube-apiserver 来实现，上面的 Service Account 其实就是 APIServer 的认证过程，而授权的机制是通过 RBAC：基于角色的访问控制实现。
RBAC 有四个资源对象，分别是 Role、ClusterRole、RoleBinding、ClusterRoleBinding。
4.2 Role：角色
一组权限的集合，在一个命名空间中，可以用其来定义一个角色，只能对命名空间内的资源进行授权。如果是集群级别的资源，则需要使用 ClusterRole。例如：定义一个角色用来读取 Pod的权限。
下面是一个位于 "rbac" 名字空间的 Role 的示例，可用来授予对 Pod 的读访问权限：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: rbacname: pod-read
rules:
- apiGroups: [""]resources: ["pods"]resourceNames: []
verbs: ["get","watch","list"]rules 中的参数说明：
apiGroups：支持的 API 组列表，例如："apiVersion: apps/v1"等
resources：支持的资源对象列表，例如 pods、deployments、jobs 等
resourceNames: 指定 resource 的名称
verbs：对资源对象的操作方法列表。
4.3 ClusterRole：集群角色
ClusterRole 同样可以用于授予 Role 能够授予的权限。 因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限：
集群范围资源（比如节点（Node））
非资源端点（比如
/healthz）跨名字空间访问的名字空间作用域的资源（如 Pod）
比如，你可以使用 ClusterRole 来允许某特定用户执行
kubectl get pods --all-namespaces
下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 Secret 授予读访问权限， 或者跨名字空间的访问权限（取决于该角色是如何绑定的）：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:# "namespace" 被忽略，因为 ClusterRoles 不受名字空间限制name: secret-clusterrole
rules:
- apiGroups: [""]# 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets"resources: ["secrets"]verbs: ["get", "watch", "list"]Role 和 ClusterRole：使用 RBAC 鉴权 | Kubernetes
4.4 RoleBinding：角色绑定、ClusterRolebinding：集群角色绑定
角色绑定和集群角色绑定用于把一个角色绑定在一个目标上，可以是 User，Group，Service Account，使用 RoleBinding 为某个命名空间授权，使用 ClusterRoleBinding 为集群范围内授权。
例如：将在 rbac 命名空间中把 pod-read 角色授予用户 es
apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "es" 读取 "rbac" 名字空间中的 Pod
# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:name: pod-read-bindnamespace: rbac
subjects:
# 你可以指定不止一个“subject（主体）”
- kind: Username: es # "name" 是区分大小写的apiGroup: rbac.authorization.k8s.io
roleRef:# "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系kind: Role # 此字段必须是 Role 或 ClusterRolename: pod-read # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配apiGroup: rbac.authorizatioin.k8s.io
要跨整个集群完成访问权限的授予，你可以使用一个 ClusterRoleBinding。 下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 Secret。
apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源
kind: ClusterRoleBinding
metadata:name: read-secrets-global
subjects:
- kind: Groupname: manager # 'name' 是区分大小写的apiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRolename: secret-readerapiGroup: rbac.authorization.k8s.ioRoleBinding 和 ClusterRoleBinding：使用 RBAC 鉴权 | Kubernetes
五、资源的引用方式
多数资源可以用其名称的字符串表示，也就是 Endpoint 中的 URL 相对路径，例如 pod 中的日志是 GET /api/v1/namaspaces/{namespace}/pods/{podname}/log。如果需要在一个RBAC对象中体现上下级资源，就需要使用“/”分割资源和下级资源。
例如：若想授权让某个主体同时能够读取 Pod 和 Pod log，则可以配置 resources 为一个数组：
# 创建 test 名称空间
[root@k8s-master01 serviceaccount]# kubectl create ns test# 创建 role
[root@k8s-master01 serviceaccount]# vim role-test.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:name: logs-readernamespace: test
rules:
- apiGroups: [""]resources: ["pods","pods/log"]verbs: ["get","list","watch"][root@k8s-master01 serviceaccount]# kubectl apply -f role-test.yaml
role.rbac.authorization.k8s.io/logs-reader created
[root@k8s-master01 serviceaccount]# kubectl get role -n test
NAME CREATED AT
logs-reader 2022-12-29T10:33:18Z# 创建服务账户
[root@k8s-master01 serviceaccount]# kubectl create sa sa-test -n test
serviceaccount/sa-test created# 创建角色绑定
[root@k8s-master01 serviceaccount]# kubectl create rolebinding sa-test-1 -n test --role=logs-reader --serviceaccount=test:sa-test# 创建 pod
[root@k8s-master01 serviceaccount]# vim pod-test.yaml
apiVersion: v1
kind: Pod
metadata:name: sa-test-podnamespace: testlabels:app: sa
spec:serviceAccountName: sa-testcontainers:- name: sa-tomcatports:- containerPort: 80image: nginximagePullPolicy: IfNotPresent[root@k8s-master01 serviceaccount]# kubectl apply -f pod-test.yaml
pod/sa-test-pod created# 进入 pod 访问资源
[root@k8s-master01 serviceaccount]# kubectl exec -it -n test sa-test-pod -- bash
root@sa-test-pod:/# cd /var/run/secrets/kubernetes.io/serviceaccount/
root@sa-test-pod:/var/run/secrets/kubernetes.io/serviceaccount# ls
ca.crt namespace token# 可以访问 test 空间的 pods 资源
root@sa-test-pod:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes.default/api/v1/namespaces/test/pods/# 可以访问 test 空间的 pods/log 资源
root@sa-test-pod:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes.dfault/api/v1/namespaces/test/pods/sa-test-pod/log# 不能访问默认空间下的资源
root@sa-test-pod:/var/run/secrets/kubernetes.io/serviceaccount# curl --cacert ./ca.crt -H "Authorization: Bearer $(cat ./token)" https://kubernetes.dfault/api/v1/namespaces/default/pods/log资源还可以通过名称（ResourceName）进行引用，在指定 ResourceName 后，使用 get、delete、update、patch 请求，就会被限制在这个资源实例范围内。
例如，下面的声明让一个主体只能对名为 my-configmap 的 Configmap 进行 get 和 update 操作：
apiVersion: rabc.authorization.k8s.io/v1
kind: Role
metadata:namaspace: defaultname: configmap-update
rules:
- apiGroups: [""]resources: ["configmaps"]resourceNames: ["my-configmap"]verbs: ["get","update"]
对资源的引用：使用 RBAC 鉴权 | Kubernetes
上一篇文章：【云原生 | Kubernetes 实战】17、K8s 配置管理中心 Secret 实现加密数据配置管理_Stars.Sky的博客-CSDN博客
下一篇文章：【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（下）_Stars.Sky的博客-CSDN博客
【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（上）相关推荐
- 【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（下）
目录 一.常见角色(role)授权的案例 1.1 允许读取核心 API 组的 Pod 资源 1.2 允许读写 apps API 组中的 deployment 资源 1.3 允许读取 Pod 以及读写 ...
- 【云原生 • Kubernetes】认识 k8s、k8s 架构、核心概念点介绍
目录 一.Kubernetes 简介 二.Kubernetes 架构 三.Kunbernetes 有哪些核心概念? 1. 集群 Cluster 2. 容器 Container 3. POD 4. 副本 ...
- 【云原生 | Kubernetes 系列】K8s 实战 管理 Secret 详解
kubectl 管理 Secret 前言 一.使用 kubectl 管理 Secret 1.1.创建 Secret 1.2.验证 Secret 1.3.解码 Secret 1.4.清理 二.使用配置文 ...
- 【云原生 | Kubernetes 系列】K8s 实战 一文学会如何从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器
PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器 前言 一.Pod 安全性 二.访问权限 三.标准化 PodSecurityPolicy 3.1.去掉纯粹变更性质的 ...
- 【云原生 • Kubernetes】认识 k8s 网络、外部网络访问 k8s 内部服务
目录 一.认识 Kubernetes 网络 二.外部网络如何访问 k8s 内部服务 1. NodePort 2. Load Balancer 3. Ingress 一.认识 Kubernetes 网络 ...
- 云原生|kubernetes|多集群管理之kubeconfig文件配置和使用（定义，使用方法，合并管理多集群）
前言: kubernetes集群通常并不是只有一个集群,特别是对于业务量比较多的公司来说,可能集群的规模会非常大.所有的业务都放到一个kubernetes集群内是不现实的,也不是科学的,就如同你不会把 ...
- 【云原生 | Kubernetes 实战】01、K8s-v1.25集群搭建和部署基于网页的 K8s 用户界面 Dashboard
目录 一.K8s 概述 可以查看官方文档:概述 | Kubernetes 组件交互逻辑: 二.kubeadm 安装 K8s-v1.25高可用集群 k8s 环境规划: 1.初始化环境 2.安装 Dock ...
- 【Kubernetes 企业项目实战】05、基于云原生分布式存储 Ceph 实现 K8s 数据持久化（下）
目录 一.K8s 对接 ceph rbd 实现数据持久化 1.1 k8s 安装 ceph 1.2 创建 pod 挂载 ceph rbd 二.基于 ceph rbd 生成 pv 2.1 创建 ceph- ...
- 【云原生Kubernetes系列第五篇】kubeadm v1.20 部署K8S 集群架构（人生这道选择题，总会有遗憾）
系列文章目录 ??即日起,更新云原生相关知识,喜欢的小伙伴可以给我点个三连喔 ??收录至专栏 云原生 ??[云原生Docker系列第一篇]Docker镜像管理 ??[云原生Docker系列第二篇]Do ...
最新文章
- 如何查看笔记本电脑配置参数_教你如何查看 MacBook 配置，超简单
- Hadoop MapReduce概念学习系列之mr程序详谈（二十三）
- Java数据结构与算法(12) - ch06递归(回文anagram)
- 进入云原生、分布式的时代，什么才是数据库的正确打开方式
- Http Module 介绍
- 环保牵手大数据 佛企需反向挖掘数据价值
- IntelliJ IDEA 背景色以及字体设置
- 超出部分用省略号代替的样式
- Android开发检测网络是否连接
- vue对象中的实例属性
- 结合ENVI与ArcMAP的NC数据处理(均值、最大最小值等)心得记录
- 【君思智慧园区】智慧能源综合管理平台，智慧能源管理云平台建设方案！
- 霍尼韦尔摄像头ip地址修改_Honeywell 安防系统使用手册(IP-ALARM-II).pdf
- SQLMap——Tamper学习
- windows10显示文件后缀名
- 事件委托（代理）的理解
- 32位linux升级64位系统下载地址,使用i386-32位Linux不能升级到amd64位，只能全新安装Linux-amd64版...
- x86,8086,386是什么
- CAD怎么批量打印图纸？如何快速打印批量CAD图纸？
- 清华大学c语言程序设计教程下载,清华大学出版社-图书详情-《C语言程序设计教程》...