Kubernetes-in-action (八)

本节内容： kube 运行原理 & 安全防护 (service account, [cluster] role, [cluster] role binding,)

架构

组成

kube控制平面
- etcd分布式持久化存储
- API服务器
  - 唯一与etcd交互的组件
  - 其他组件都与其交互，来获取需要的信息，或执行资源操作
  - 主要将资源变更同步到其他控制器，由他们来进行资源变更，自己则只是通知
- 调度器
  - 控制pod的调度，默认是default-scheduler
- 控制器管理器
  - 每种资源都有对应的控制器，控制器一直观察资源的状态是否与配置的一样，不一样则会请求api server去变更资源的状态以达到与配置一样。
  - 更新流程：控制器 -> api server -> kubectl
  - 控制器和kubectl之间是互不相关的，都由api server这个中心来控制
工作节点
- Kubelet
  - 启动node后持续监控pod的资源状态并告诉api服务器
  - 接受api 服务器的更新指令来更新pod的状态
  - pod探针观测，并执行重启
- Kubelet服务代理（kube-proxy）
  - 将工作节点的流量发到指定的pod，通过iptables实现将流量转发到pod上
- 容器运⾏时（Docker、rkt或者其他）
附加组件
- Kubernetes DNS服务器
  - 利用 api 服务器的监控机制来订阅service和endpoint的变动，以及dns记录的变更
  - 在更新间隙中，可能导致dns无效
- 仪表板
- Ingress控制器
  - 类似一个反向代理服务器
  - 虽然配置了service，但是流量不会通过service，而是直接连上pod，从而pod可以获取到源的client ip
- Heapster（容器集群监控）
- 容器⽹络接⼜插件（本章后⾯会做讨论

kubectl get events --watch 是用来实时查看kubectl接收的事件

pod 运行

每个pod在启动时，都会默认有一个基础容器(只执行暂停操作的容器)，用于处理pod内所有的容器公用一个linux命名空间。
如果基础容器被删除，则kubectl会重建它以及pod的所有容器。
例：一个只声明nginx容器的pod，生成pod时会有两个容器被创建

kube的网络

pod间的通讯实现
- 没有时NAT(网络地址转换)来实现pod的通讯，为了简洁
- 集群内部是一个局域网，所以可以通过ip地址直接访问(不同node)
- 同node上：
  - 每个pod中基础容器会创建网络命名空间让pod内的所有容器都走同一个网络接口
  - pod会通过一个虚拟网络接口来连接到一个网桥： pod A -> veth pair -> bridge -> veth pair -> pod B

service的实现

service 无法被ping通，因为是个虚拟ip地址
service相关的事情都是由kube-proxy进程处理，对于service和endpoint的变化，kube-proxy会更新到相应的iptables中，这样在一个请求在来后会被重定向到pod的地址。

安全防护

kube 中由一系列的认证授权插件，在一个请求到达api服务器时，会经过这些插件，如果有一个通过则说明可以请求

ServiceAccount

作用

一种kube的资源
默认将service account配置的secret加载到pod中
每个ServiceAccount只能在自己的ns中使用

实践

创建一个sa : sa-> service account 缩写，同样使用kubectl get sa等命令
pod绑定这个sa
查看 sa是否可以拉取pod信息 (容器ambassador默认启动一个kube-proxy，所以可以访问api服务器)
- kubectl exec -it curl-custom-sa -c main curl localhost:8001/api/v1/pods
检验pod的secret
- kubectl get sa -o yaml # 查看 token secret 名称
- kubectl describe secret my-sa-token-tc54g # 查看token，默认是jwt格式
- kubectl exec -it curl-custom-sa -c main -- cat /var/run/secrets/kubernetes.io/serviceaccount/token #
  容器内挂载的token内容

apiVersion: v1
kind: ServiceAccount
metadata:name: my-sa
imagePullSecrets:- name: my-secret---apiVersion: v1
kind: Pod
metadata:name: curl-custom-sa
spec:serviceAccountName: my-sacontainers:- name: mainimage: curlimages/curl:7.87.0command: [ "sleep", "9999999" ]- name: ambassadorimage: luksa/kubectl-proxy:1.6.2

RBAC

概念

RBAC授权插件将⽤户⾓⾊作为决定⽤户能否执⾏操作的关键因素
由两组资源控制 (均可用kube get命令)
- Role（⾓⾊）和ClusterRole（集群⾓⾊），它们指定了在资源上可以执⾏哪些动词
  - Role只能用于创建或者指定的ns
    - 可以用yaml文件或者命令(kubectl create role service-reader --verb=get --verb=list --resource=services -n bar)创建
- RoleBinding （⾓⾊绑定）和 ClusterRoleBinding （集群⾓⾊绑定），它们将上述⾓⾊绑定到特定的⽤户、组或ServiceAccounts上
  - RoleBinding：将role绑定到一个或多个 service account 或者组、用户
    - 可以跨命名空间绑定service account
    - 命令： kubectl create rolebinding test --role=service-reader --serviceaccount=foo:default -n foo

实践：Role，RoleBinding

创建两个ns： foo，bar
- kubectl create ns foo, kubectl create ns bar
在两个空间中创建具有kube-proxy和curl工具的pod
- kubectl create -f curl-custom-sa.yaml -n bar
- kubectl create -f curl-custom-sa.yaml -n foo

apiVersion: v1
kind: Pod
metadata:name: curl-custom-sa
spec:serviceAccountName: defaultcontainers:- name: mainimage: curlimages/curl:7.87.0command: ["sleep", "9999999"]- name: ambassadorimage: luksa/kubectl-proxy:1.6.2

创建一个role，并给role赋予访问service的权限
- kubectl create -f role.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: fooname: service-reader
rules:- apiGroups: [ "" ]verbs: [ "get", "list" ]resources: [ "services" ]

给role绑定 foo，bar两个空间default的serviceaccount
- kubectl create rolebinding test --role=service-reader --serviceaccount=foo:default -n foo
- kubectl create rolebinding test2 --role=service-reader --serviceaccount=bar:default -n foo
通过pod访问api server，查看是否具有访问权限
- kubectl exec -it curl-custom-sa -c main -n bar -- curl http://localhost:8001/api/v1/namespaces/foo/services
- kubectl exec -it curl-custom-sa -c main -n foo -- curl http://localhost:8001/api/v1/namespaces/bar/services

RoleBinding可以在foo空间中声明, 但是可以将role 绑定到 bar空间的service account，因为role的声明是在foo中,
若是如此配置，则可以让bar空间的pod访问到foo空间的services （如上述实践）

由此得出： RoleBinding、Role都是和命名空间相关的，既这个命名空间的资源可以让谁访问，是这个空间内的谁还是其他的谁(角色)

实践：ClusterRole，ClusterRoleBinding

有些资源不在命名空间中，所以需要用集群范围的角色定义。如 pv、node、ns
集群资源只能用 ClusterRoleBinding 而不能用 RoleBinding

创建一个cluster role，并赋予访问pv的权限. [不需要指定命名空间]
创建cluster role binding，将role绑定到foo，bar的service account
- kubectl create clusterrolebinding pv-test --clusterrole=pv-reader --serviceaccount=foo:default --serviceaccount=bar:default
检查名称空间内的pod是否具有访问pv的权限
- kubectl exec -it curl-custom-sa -c main -n bar -- curl http://localhost:8001/api/v1/persistentvolumes
- kubectl exec -it curl-custom-sa -c main -n foo -- curl http://localhost:8001/api/v1/persistentvolumes

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

实践：ClusterRole，RoleBinding

使用RoleBinding结合ClusterRole： ClusterRole中配置资源范围只有RoleBinding所在的命名空间

使用ClusterRoleBinding结合ClusterRole: ClusterRole中配置资源范围作用与整个集群。

在foo，bar中创建一个rolebinding，将clusterrole view (kube自带的) 绑定他们。
- kubectl create rolebinding view-test --clusterrole=view --serviceaccount=foo:default -n foo
- kubectl create rolebinding view-test --clusterrole=view --serviceaccount=bar:default -n bar
查看foo和bar中的pod是否可以查询命名空间内所有pod
- kubectl exec -it curl-custom-sa -c main -n foo -- curl http://localhost:8001/api/v1/namespaces/foo/pods
- kubectl exec -it curl-custom-sa -c main -n bar -- curl http://localhost:8001/api/v1/namespaces/bar/pods
查看foo和bar中的pod是否可以查询集群内所有pod
- kubectl exec -it curl-custom-sa -c main -n bar -- curl http://localhost:8001/api/v1/pods # 失败， 403
删除foo中的role binding，添加一个cluster role binding，再次查看是否可以查询集群内的所有pod
- kubectl delete rolebinding view-test -n foo
- kubectl create clusterrolebinding view-test --clusterrole=view --serviceaccount=foo:default
- kubectl exec -it curl-custom-sa -c main -n foo -- curl http://localhost:8001/api/v1/pods # 成功