kubernetes应用访问、授权、调度、Helm、存储快速理解

k8s所有的访问需要经过API Server。

一、ServiceAccount

对于命名空间内的pod用于访问k8s API而设计，创建命名空间时自动创建一个default的serviceAccount。命名空间内的pod的创建会自动将spec.serviceAccount设置为default。主要总结为，每个pod被创建的时候默认拥有default serviceAccount的权限，默认的serviceAccount只能访问本命名空间的资源，而若是想跨命名空间访问必须再建立Pod的时候指定某个命名空间的serviceAccount，那么对该pod的访问就限定了绑定了该命名空间的其他pod。下图所示创建了一个未指定serviceAccount的pod。

可见该pod的服务账户为default,也就是说pod在访问API server的时候携带的token为default的权限，即角色权限访问控制，RBAC。

二、RBAC授权

RBAC授权支持Role与ClusterRole两种，其中Role作用于名称空间级别，ClusterRole用于组织集群级别资源权限集合，例如Nodes、非资源类型端点、作用于所有命名空间的资源。

授权分别需要用到RoleBinding和ClusterRoleBinding。RoleBinding用于将Role的权限绑定到一个或一组用户，且只隶属某一个命名空间。ClusterRoleBinding将ClusterRole中定义的权限绑定到一个或一组用户。

roleBinding授权示例：

 

表示在testing的命名空间里，将kube-user1用户指定为pods-reader角色。然后我们可以创建该角色。

apiGroup表示API组名称，为空表示核心组。组的概念可参考https://www.orchome.com/1358

resources：表示可访问的资源。

vervs：对可访问的资源可进行的操作。

ClusterroleBinding授权示例：

定义了一个node-reader的ClusterRole的角色，可以访问nodes，对nodes的操作权限为get、watch、list。

集群角色用户意义，Kube-user1具有在testing命名空间访问pods权限，但无法访问其他命名空间pods。为解决此问题，1.集群管理员在集群范围内定义一组访问命名空间的级别clusterRole资源，然后各自命名空间中通过RoleBinding进行引用。但集群中有些资源是不属于任何命名空间的，因此需要利用ClusterroleBinding功能。例如URL类型的资源，不过这些资源已经由系统默认的名称为system:discovery的Cluster与ClusterroleBinding自动设定，也就是说属于system:discovery这个角色的用户或用户组默认对这些URL资源有GET的权限。

kubeadm安装设定集群时，自动创建了/etc/kubernetes/admin.conf文件，且内部定义的用户kubernetes-admin使用证书文件/etc/kubernetes/pki/piserver-kubelet-client.crt进行认证。而此证书Subject信息“/O=system: masters/；CN=kubernetes-admin，O表示用户名所属组，CN表示用户名，而kubernetes-admin用户属于system:master组的，而该组的角色被自动绑定到cluster-admin角色拥有集群所有权限。于是为 Kubemetes 集群额外自定义超级管理员的方法至少具有两种：1.创建证书，其中Subject中O值为system:master。2.创建ClusterRoleBinding将用户绑定在cluster-admin。

三、service与ingress：

我们利用k8s的yaml文件方式进行部署tomcat应用。

首先建立tomcat_deploy.yaml文件,内容如下：主要指定命名空间，期望副本数，打的标签名，镜像名，容器编排端口。

执行

创建pod，待所有pod都处于running状态。

建立用于访问pod的service,tomcat_svc如下：主要规定命名空间，给自己打标签，类型为NodePort则可以由外部端口进行访问，匹配的pod标签名称（需要与pod设置的标签一致）、访问端口，即客户端访问service的80端口会映射到service内部pod的8080端口。

执行

此时通过本服务器的地址ip:31635即能访问tomcat应用。即完成了通过service进行访问pod应用。

ingress

ingress是凌驾于service之上的服务访问层，为什么要用ingress，个人理解:随着service的增多，管理起来较为麻烦，并且都是ip的方式较为难记，ingress可以使用域名的方式较容易记忆。ingress其实是一堆转发规则，将来自客户端的请求通过iptables或者ipvs向对应的service进行转发。

ingress也属于k8s应用，因此如果想通过ingress访问应用，ingress也必须暴露对外接口用于接收外部请求，相应的service也应当暴露接口用于ingress访问。

ingress安装：

1.去github下载ingress的部署文件,网不好可以码云上下载https://gitee.com/lamefox/github-ingress-nginx/tree/master/deploy/static。其中mandatory.yaml文件。运行kubectl apply -f mandatory.yaml部署了ingress。

2.创建ingress资源，主要就规定了域名请求时转发的应用名和端口。

3.运行

可查看ingress描述。然后我们需要修改windows的hosts文件，添加dns解析，这是因为这个域名是我们自己设置的，在根服务器中并没有我们的域名解析，需要我们自己在本地添加，windows系统会首先读取本地的dns解析。这里我们输入tomcat.ilinux.io：31635也就是域名+应用端口号去访问tomcat应用。

四、资源调度

核心目标：基于资源可用性将POD资源公平的分布于集群节点之上。

预选：主要检查项目

        1.节点可用性，CheckNodeCondition

        2.Pod指定主机名是否匹配，HostName

        3.Pod标签是否匹配，MatchNodeSelector

        4.Pod指定端口是否被占用， PodFitsHostPorts

        5.Pod请求的存储是否能用，NoDiskConflict

        6.Pod申请资源是否够用，PodFitsResources 

优选：将预选出来的节点利用优选函数进行打分，分值越高代表越适合部署。

常用优选函数：

LeastRequestedPriority   计算公式（cpu((capacity - sum(r quested)) * IO/capacity) + memory(( capacity sum( requested)) * I O/capacity))/2

BalancedResourceAllocation   以 CPU 和内存资源占用率的相近程序作为评估标准，者越接近的节点权重越高。

NodePreferAvoidPodsPriority  ，它将根据节点是否设置了注解信息“ scheduler.alpha.kub ernetes.io/preferAvoidPods ”来计算其优选级

NodeAffinityPriority ：基于节点亲和性调度偏好进行优先级评估，它将根据 Pod源中的 nodeSe lector 对给定节点进行匹配度检查，成功匹配到的条目越多则节点得分越高。

节点亲和度：分为硬亲和度和软亲和度。主要是对节点特性的规定。

硬亲和：需要Pod完全满足节点亲和性要求才能部署，否则无法部署。

软亲和：使用weight方式，如无法满足节点亲和度，但部署到weight大的节点也能接受。

五、HELM

Charts：helm程序包 ，包含了运行一个应用所需的镜像，依赖，资源定义等。

Repository：Charts仓库。

Config：应用程序实例化安装运行时使用的配置信息。

Release：应用程序实例化后运行于K8S集群中一个Charts实例。

helm的默认Charts仓库为kubernetes官方仓库，默认名称为stable，为k8s安装Charts时会首先去官方仓库获取相关的Charts，https://kubernetes-charts.storage.googleapis.com

主要命令：

helm repo update #更新仓库

helm search #stable仓库中维护的Charts列表

helm search redis #查看可安装的redis

helm inspect stable/redis #查看指定库Charts详细信息

helm install stable/redis -n redis (--dry-run)  #安装，--dry-run 表示安装测试并非真安装

helm list #列出已安装生成的release

helm delete redis #删除

一般不建议自定义Charts文件。

六、存储与数据持久化

（一）节点级别存储：

emptyDir与hostPath

emptyDir：生命周期与Pod绑定。Pod在存储在，Pod亡存储亡。

hostPath：Pod借用宿主机的存储，但Pod如果换了其他节点，则无法再使用存储。

PV机制，简化用户配置网络存储卷。

Pod进行存储卷挂载格式

name:存储卷名称

mountPath:挂载到容器上的路径。

readOnly :卷是否只读。

subPath:挂载子路径

（二）网络存储卷：

NFS：

volumes中定义了一个名为“redisdata”的网络存储卷，服务器地址nfs.ilinux.io,路径/data/redis，挂载到容器的/data目录下。

RDB：是一个Ceph提供的网络存储平台，需要事先安装一套Ceph的集群。

可以看出，存储卷定义为三台集群机器。且在集群池kube中创建了redis镜像，此镜像拥有ext4文件系统。拥有访问认证，认证文件位于ceph-secret。

GlusterFS：开源集群网络存储系统

Cinder：需要将k8s集群部署于OpenStack构建的IaaS环境中才可用

（三）PV与PVC与Pod

PV为集群管理员配置提供的某存储系统上的一段存储空间，是对底层存储的抽象，将共享存储作为一种由用户申请使用的资源。PV是集群级别的资源，用户申请PV资源需要通过PVC来绑定。PVC向PV做出申请，PVC与Pod进行绑定。

创建PV：

主要描述PV信息，5GB大小，存储器位置和路径。创建后，查看状态若为Available则未被PVC所绑定。

创建PVC：

描述了PVC绑定信息。该PVC绑定了pvc-nfs-0001。

Pod中使用PVC：

Pod绑定PVC卷