Kubernetes 容器编排（4）

最新推荐文章于 2024-05-11 09:08:44 发布

一个小宏混

最新推荐文章于 2024-05-11 09:08:44 发布

阅读量2k

点赞数 52

文章标签： kubernetes 容器云原生

本文链接：https://blog.csdn.net/m0_68695491/article/details/135023948

版权

Downward API

Downward API
用于在容器中获取 POD 的基本信息，kubernetes原生支持

Downward API提供了两种方式用于将 POD 的信息注入到容器内部：
1.环境变量：用于单个变量，可以将 POD 信息直接注入容器内部。
2.Volume挂载：将 POD 信息生成为文件，直接挂载到容器内部中去。

目前 Downward API 支持的字段

1. 使用 fieldRef 可以声明使用:
spec.nodeName - 宿主机名字
status.hostIP - 宿主机 IP
metadata.name - Pod 的名字
metadata.namespace - Pod 的 Namespace
status.podIP - Pod 的 IP
spec.serviceAccountName - Pod 的 Service Account 的名字
metadata.uid - Pod 的 UID
metadata.labels['<KEY>'] - 指定 <KEY> 的 Label 值
metadata.annotations['<KEY>'] - 指定 <KEY> 的 Annotation 值
metadata.labels - Pod 的所有 Label
metadata.annotations - Pod 的所有 Annotation

上面这个列表的内容，随着 Kubernetes 项目的发展肯定还会不断增加。所以这里列出来的信息仅供参考，在使用 Downward API 时，还是要记得去查阅一下官方文档。

所有基本信息可以使用下面的方式去查看（describe方式看不出来）：
[root@kub-k8s-master configmap]# kubectl get pod test-webapp -o yaml
apiVersion: v1
kind: Pod
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"test-webapp","namespace":"default"},"spec":{"containers":[{"image":"daocloud.io/library/nginx","name":"nginx-app","volumeMounts":[{"mountPath":"/usr/share/nginx/html","name":"nginx-volume"}]}],"volumes":[{"configMap":{"name":"nginx-server-conf"},"name":"nginx-volume"}]}}
creationTimestamp: "2021-02-21T09:44:51Z"
name: test-webapp
namespace: default
resourceVersion: "270687"
selfLink: /api/v1/namespaces/default/pods/test-webapp
uid: ed92d685-f800-464f-95dc-d6aa5f92fc9c
......

实战案例

使用fieldRef获取 POD 的基本信息，以环境变量的方式实现

[root@kub-k8s-master prome]# vim test-env-pod.yml
---
apiVersion: v1
kind: Pod
metadata:
    name: test-env-pod
    namespace: kube-system
spec:
    containers:
    - name: test-env-pod
      image: daocloud.io/library/nginx
      env:
      - name: POD_NAME   #第一个环境变量的名字
        valueFrom:      #使用valueFrom方式设置
          fieldRef:    #关联一个字段metadata.name
            fieldPath: metadata.name  #这个字段从当前运行的pod详细信息查看
      - name: POD_NAMESPACE
        valueFrom:
          fieldRef:
            fieldPath: metadata.namespace
      - name: POD_IP
        valueFrom:
          fieldRef:
            fieldPath: status.podIP

注意： POD 的 name 和 namespace 属于元数据，是在 POD 创建之前就已经定下来了的，所以使用 metadata 获取就可以了，但是对于 POD 的 IP 则不一样，因为POD IP 是不固定的，POD 重建了就变了，它属于状态数据，所以使用 status 去获取。

#创建上面的 POD：
[root@kub-k8s-master prome]#  kubectl apply -f test-env-pod.yml
pod/test-env-pod created
#POD 创建成功后，查看：
[root@kub-k8s-master prome]# kubectl exec -it test-env-pod /bin/bash -n kube-system
root@test-env-pod:/# env | grep POD
POD_NAME=test-env-pod
POD_NAMESPACE=kube-system
POD_IP=10.244.1.35
root@test-env-pod:/#

Volume挂载

通过Downward API将 POD 的 Label、等信息通过 Volume 以文件的形式挂载到容器的某个文件中去，然后在容器中打印出该文件的值来验证。

[root@kub-k8s-master prome]# vim test-volume-pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
   name: test-volume-pod
   namespace: kube-system
   labels:
       k8s-app: test-volume
       node-env: test
spec:
   containers:
   - name: test-volume-pod-container
     image: daocloud.io/library/nginx
     volumeMounts:
     - name: podinfo
       mountPath: /etc/podinfo
   volumes:
   - name: podinfo
     downwardAPI:
       items:
       - path: "labels"
         fieldRef:
           fieldPath: metadata.labels
#创建上面的 POD ：
[root@kub-k8s-master prome]# kubectl apply -f test-volume-pod.yaml
[root@kub-k8s-master prome]# kubectl get pod -n kube-system
[root@k8s-master prome]# kubectl exec -it test-volume-pod /bin/bash -n kube-system

Secret、ConfigMap，以及 Downward API 这三种 Projected Volume 定义的信息，大多还可以通过环境变量的方式出现在容器里。但是，通过环境变量获取这些信息的方式，不具备自动更新的能力。一般情况下，建议使用 Volume 文件的方式获取这些信息。

ServiceAccount详解

官方文档地址：Configure Service Accounts for Pods | Kubernetes

k8s中提供了良好的多租户认证管理机制，如RBAC、ServiceAccount还有各种Policy等。

什么是 Service Account：Pod里的进程也可以与 apiserver 联系。当它们在联系 apiserver 的时候，它们就会被认证为一个特定的 Service Account。

使用场景：Service Account它并不是给kubernetes集群的用户使用的，而是给pod里面的进程使用的，它为pod提供必要的身份认证。----专门为pod里面的进程和apiserver通信提供认证的。

Service account与User account区别:
1. User account是为人设计的，而service account则是为Pod中的进程调用Kubernetes API或其他外部服务而设计的
2. User account是跨namespace的，而service account则是仅局限它所在的namespace；
3. 每个namespace都会自动创建一个default service account
4. Token controller检测service account的创建，并为它们创建secret

Service Account应用示例

Service Account（服务账号）示例

因为平时系统会使用默认service account，我们不需要自己创建，感觉不到service account的存在，本实验是使用自己手动创建的service account

1、创建serviceaccount
[root@kub-k8s-master ~]# kubectl create serviceaccount mysa
serviceaccount/mysa created
# yaml 方法创建
[root@kub-k8s-master ~]# vim mysa.yml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysa
  namespace: default
2、查看mysa
[root@kub-k8s-master ~]# kubectl describe sa mysa
Name:                mysa
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   mysa-token-cknwf
Tokens:              mysa-token-cknwf
Events:              <none>
3、查看mysa自动创建的secret
[root@kub-k8s-master ~]# kubectl  get secret
NAME                  TYPE                                  DATA   AGE
db-user-pass          Opaque                                2      11h
default-token-6svwp   kubernetes.io/service-account-token   3      4d23h
mysa-token-cknwf      kubernetes.io/service-account-token   3      76s
mysecret              Opaque                                2      11h
mysecret-01           Opaque                                2      6h58m
pass                  Opaque                                1      7h6m
user                  Opaque                                1      7h7m
4、创建角色和绑定
[root@kub-k8s-master ~]# vim role.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: mysa-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: mysa-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: mysa
  namespace: default
roleRef:
  kind: Role
  name: mysa-role
  apiGroup: rbac.authorization.k8s.io
5、使用mysa的sa资源配置pod
[root@kub-k8s-master ~]# cd prome/
[root@kub-k8s-master prome]# vim mysa-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: mysa-pod
spec:
  serviceAccountName: mysa
  containers:
  - name: app
    image: 10.36.192.206:8088/newrain857/kubectl
    command: ["tail","-f","/dev/null"]
6、导入
[root@kub-k8s-master prome]# kubectl apply -f .
pod/mysa-pod created
role.rbac.authorization.k8s.io/mysa-role created
rolebinding.rbac.authorization.k8s.io/mysa-binding created
serviceaccount/mysa created
7、查看
[root@kub-k8s-master prome]# kubectl get pod mysa-pod -o yaml
8、测试
[root@kube-master sa]# kubectl exec -it mysa-pod /bin/sh
/ # kubectl get pod
NAME             READY   STATUS    RESTARTS      AGE
nginx            1/1     Running   1 (50m ago)   17h
mysa-pod   1/1     Running   0             9m5s
/ # kubectl delete pod nginx
Error from server (Forbidden): pods "nginx" is forbidden: User "system:serviceaccount:default:pod-reader" cannot delete resource "pods" in API group "" in the namespace "default"
# 可以看到，我们已经成功限制了pod对资源的访问

RBAC 详解(基于角色的访问控制)

在Kubernetes中，授权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直允许）这6种模式。
RBAC基于角色的访问控制--全拼Role-Based Access Control----做权限控制的，顾名思义就是通过给角色赋予相应的权限，从而使得该角色具有访问相关资源的权限。
k8s里面有两种用户,一种是User,一种就是service account(服务使用的账号)。
User account是为人设计的属于用户账户（个人使用的账号），此外User Account是跨Namespace的，而ServiceAccount则是仅局限它所在的Namespace。
在RABC API中，通过如下的步骤进行授权：
1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。

在K8s中这些资源分属于两个级别，名称空间（role/rolebinding）和集群级别（clusterrole/clusterrolebinding）这两个都是标准的K8s资源，可以直接定义。
Role与ClusterRole
Role普通角色:一个Role对象只能用于授予对某一单一命名空间中资源的访问权限，普通角色只是在当前的名称空间生效。
ClusterRole集群角色:整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现，可以访问整个集群资源。
简介
role/ClusterRole:
1、允许的操作，如get,list,update,create,delete等权限
2、允许操作的对象，如pod,svc等资源

rolebinding:将哪个用户绑定到哪个role上
clusterrolebinding:绑定到集群角色上
如果使用clusterrolebinding绑定到clusterrole上，表示绑定的用户拥有所有namespace的权限
#这里面有哪些重要的东西：role，clusterrole，binding，账号。

创建k8s账号与RBAC授权使用

创建账号
1、创建私钥
[root@kub-k8s-master ~]# (umask 077; openssl genrsa -out soso.key 2048)
Generating RSA private key, 2048 bit long modulus
...............................+++
..........................+++
e is 65537 (0x10001)
用此私钥创建一个csr(证书签名请求)文件
[root@kub-k8s-master ~]# openssl  req -new -key soso.key -out soso.csr -subj  "/CN=soso" # 这个地方是用户名
拿着私钥和请求文件生成证书
[root@kub-k8s-master ~]# openssl x509 -req -in soso.csr -CA  /etc/kubernetes/pki/ca.crt  -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out soso.crt -days 365
Signature ok
subject=/CN=soso
Getting CA Private Key
生成账号
[root@kub-k8s-master ~]# kubectl config set-credentials soso --client-certificate=soso.crt --client-key=soso.key --embed-certs=true
User "soso" set.
3、设置上下文环境--指的是创建这个账号的环境在当前名称空间中
[root@kub-k8s-master ~]# kubectl config set-context soso@kubernetes --cluster=kubernetes --user=soso
Context "soso@kubernetes" created.
查看当前的工作上下文
[root@kub-k8s-master ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://192.168.96.10:6443
....
4、切换用户（切换上下文）
[root@kub-k8s-master ~]# kubectl  config use-context soso@kubernetes
Switched to context "soso@kubernetes".
验证是否已经切换到了新的上下文
[root@kub-k8s-master ~]# kubectl config current-context
soso@kubernetes
5.测试（还未赋予权限）
[root@kub-k8s-master ~]# kubectl  get pod
Error from server (Forbidden): pods is forbidden: User "soso" cannot list resource "pods" in API group "" in the namespace "default"

创建一个角色（role）---设置权限
1.切回管理帐号先
[root@kub-k8s-master ~]# kubectl  config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes"
创建角色（命令）：
[root@kub-k8s-master ~]# kubectl  create role  role-reader  --verb=get,list,watch --resource=pod,svc
role.rbac.authorization.k8s.io/role-reader created
--verb： 相当于是权限
--resource：给什么资源使用
yaml文件方式:
[root@kub-k8s-master ~]# vim role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: role-reader
rules: #定义规则
 - apiGroups: [""]  #表示当前pod使用核心的APIserver组，默认用""表示就可以
   resources: ["pods","svc"]
   verbs: ["get", "list", "watch", "create", "update", "delete"] #["*"]表示所有权限

[root@kub-k8s-master ~]# kubectl apply -f role.yaml 
role.rbac.authorization.k8s.io/role-reader created
[root@kub-k8s-master ~]# kubectl get roles
NAME          AGE
role-reader   30s
[root@kub-k8s-master ~]# kubectl describe role role-reader
Name:         role-reader
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"Role","metadata":{"annotations":{},"name":"role-reader","namespace":"default"},"...
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list watch create update delete]
  svc        []                 []              [get list watch create update delete]

2.绑定用户soso（上面创建的用户），绑定用户到role-reader
[root@kub-k8s-master ~]# kubectl  create  rolebinding myrole-binding  --role=role-reader  --user=soso
rolebinding.rbac.authorization.k8s.io/myrole-binding created
yaml文件方式：
[root@k8s-master ~]# vim role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: myrolebind
subjects:  #定义对那个主体进行操作，有三种Subjects:Service Account、User Account、Groups
- kind: User
  name: soso
  apiGroup: rbac.authorization.k8s.io
roleRef:  #定义使用哪个角色
  kind: Role
  name: role-reader
  apiGroup: rbac.authorization.k8s.io
[root@k8s-master ~]# kubectl apply -f role-binding.yaml 
rolebinding.rbac.authorization.k8s.io/myrolebind created
[root@k8s-master ~]# kubectl get rolebinding 
NAME         AGE
myrolebind   25s
3.切换用户
[root@kub-k8s-master ~]# kubectl  config use-context soso@kubernetes
Switched to context "soso@kubernetes".
4.查看权限（只授权了default名称空间pod和svc的get，list，watch权限）
[root@kub-k8s-master ~]# kubectl  get pod
NAME                    READY   STATUS    RESTARTS   AGE
lifecycle-demo          1/1     Running   1          22h
mypod                   1/1     Running   0          8h
nginx-configmap         1/1     Running   0          4h29m
nginx-pod               1/1     Running   0          39m
[root@kub-k8s-master ~]#  kubectl  get pod -n kube-system  #无权访问kube-system
Error from server (Forbidden): pods is forbidden: User "soso" cannot list resource "pods" in API group "" in the namespace "kube-system"
[root@kub-k8s-master ~]# kubectl  delete pod nginx-pod   #无权限删除
Error from server (Forbidden): pods "nginx-pod" is forbidden: User "soso" cannot delete resource "pods" in API group "" in the namespace "default"
5.切换用户
[root@kub-k8s-master ~]# kubectl  config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
实验二，绑定用户到集群角色
6.删除soso账号之前绑定的rolebinding
[root@kub-k8s-master ~]# kubectl  delete rolebinding myrolebind
rolebinding.rbac.authorization.k8s.io "myrolebind" deleted
7.创建clusterrole #可以访问全部的namespace
[root@kub-k8s-master ~]# kubectl create clusterrole myclusterrole --verb=get,list,watch --resource=pod,svc
clusterrole.rbac.authorization.k8s.io/myclusterrole created
yaml文件方式：
[root@kub-k8s-master ~]# vim clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: myclusterrole
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch
[root@kub-k8s-master ~]# kubectl apply -f clusterrole.yaml
[root@kub-k8s-master ~]# kubectl get clusterrole
8.绑定集群角色到用户soso
[root@kub-k8s-master ~]# kubectl  create clusterrolebinding my-cluster-rolebinding   --clusterrole=myclusterrole --user=soso
clusterrolebinding.rbac.authorization.k8s.io/my-cluster-rolebinding created
yaml文件方式：
[root@kub-k8s-master ~]# vim clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: my-cluster-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: soso
[root@kub-k8s-master ~]# kubectl apply -f clusterrolebinding.yaml
[root@kub-k8s-master ~]# kubectl get clusterrolebinding
9.切换账号
[root@kub-k8s-master ~]# kubectl  config use-context soso@kubernetes
Switched to context "soso@kubernetes".
10.查看权限 查看kube-system空间的pod
[root@kub-k8s-master ~]# kubectl  get pod -n kube-system
NAME                                     READY   STATUS    RESTARTS   AGE
coredns-5644d7b6d9-sm8hs                 1/1     Running   0          5d
coredns-5644d7b6d9-vddll                 1/1     Running   0          5d
etcd-kub-k8s-master                      1/1     Running   0          5d
... 
注意：11.切换为管理员用户
[root@kub-k8s-master ~]# kubectl  config use-context kubernetes-admin@kubernetes

设置上下文和账户切换

#设置工作上下文（前提得有用户）
[root@kub-k8s-master ~]# kubectl  config   set-context  soso@kubernetes --cluster=kubernetes --user=soso
Context "soso@kubernetes" created.
#查看当前的工作上下文
[root@kub-k8s-master ~]# kubectl config view
apiVersion: v1
clusters:
- cluster:
....
#切换上下文（切换用户）
[root@kub-k8s-master ~]# kubectl config use-context soso@kubernetes
Switched to context "soso@kubernetes".
切换为管理员用户
[root@kub-k8s-master prome]# kubectl  config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
#查看某个资源类型是由哪个apiserver版本提供
[root@kub-k8s-master ~]# kubectl explain ClusterRole

一个小宏混

关注

52
点赞
踩
41

收藏

觉得还不错? 一键收藏
0
评论
Kubernetes 容器编排（4）

用于在容器中获取 POD 的基本信息，kubernetes原生支持Downward API提供了两种方式用于将 POD 的信息注入到容器内部：1.环境变量：用于单个变量，可以将 POD 信息直接注入容器内部。2.Volume挂载：将 POD 信息生成为文件，直接挂载到容器内部中去。
复制链接

扫一扫