Kubernetes（K8S）入门与安装配置

Kubernetes 是一个跨主机集群的开源的容器调度平台，它可以自动化应用容器的部署、扩展和 *** 作 , 提供以容器为中心的基础架构。谷歌旗下开源软件，江湖人称K8S。

上图是一个通过K8S搭建的集群环境，采用三台物理机搭建(三台机器是K8S搭建集群的最低要求)，我先简单介绍一下几个重点名词。

Centos 7 Master * 1 (注意必须是双核以上的CPU，否则无法初始化K8S)

Centos 7 Node * 2

将文件上传至该目录

网盘地址： https://pan.baidu.com/s/1NiAdf0Gp24qjVx2v_HqqyQ

提取码：aew7

执行以下命令

如果不是groupfs,执行下列语句

将最后一行注释

运行docker images可以看到以下几个关键应用

kube-proxy 容器间通讯代理、kube-apiserver API服务端、kube-scheduler 任务调度器、kube-controller-manager 集群控制器、coredns  K8S内置的 DNS 服务器、etcd 用于保存集群所有的网络配置和对象的状态信息、pause前面已经提到用于容器间的通讯以及数据卷的挂载。至此K8S安装完成

图中的第一个红框的命令是需要管理员手动复制，然后在master服务器上执行的。

PS: admin.conf是kubeadm集群管理的核心配置文件，包含整个集群各个节点的授权信息，以及本身的一些配置信息

第二个红框中的命令是在node节点上执行，里面包含了一个加入集群的token认证信息以及ca证书的hashcode。通过该token可以加入K8S集群.

从图中看到master节点处于NotReady状态，说明节点中存在有问题的Pod，查看存在问题的pod，执行以下命令查看所有Pod状态

如果某个Pod的STATUS处于CrashLoopBackOff状态表示创建失败了，那么它会不断自动重新创建。上图中两个coredns处于pending状态，原因是我们没有配置K8S网络通讯协议fannel，从上传的文件中加载并创建flannel网络组件

3.在node节点上执行刚刚由kubeadm生成的节点加入命令

如果出现反复无法加入节点的情况，运行 kubeadm reset 这条命令还原当前节点上 kubeadm init 或者 kubeadm join 所做的所有更改。当想加入新节点忘记token时可以使用 kubeadm token list 查看token，或者 kubeadm token create创建token,采用跳过ca安全认证的方式加入节点。

4.三台机器设置kubelet开机自启,至此通过kubeadm集群配置完成

在主节点上执行以下命令，以下三个配件都是已经配置好的，装载即可。

图中dashboard服务已经被创建，配置文件中关闭了密码验证，只需要浏览器打开 http://192.168.220.131:32000无需登录。

Kubernetes作为一个分布式集群的管理工具，保证集群的安全性是其中一个重要的任务，API Server是集群内部各个组件通信的中介，也是外部控制的入口。所以Kubernetes的安全机制基本就是围绕保护API Server来设计的。Kubernetes使用了认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）三步来保证API Server的安全。

kubeconfig文件包含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥）、集群Context信息（集群名称、用户名）。Kubernetes组件通过启动时指定不同的kubeconfig文件可以切换到不同的集群。

Pod中的容器访问API Server，因为Pod的创建、销毁是动态的，所以要为它手动生成证书就不可行了，Kubernetes使用了Service Account解决Pod访问API Server的认证问题。

Kubernetes设计了一种资源叫做Secret，分为两类，一种是用于ServiceAccount的service-account-token，另一种是用于保存用户自定义保密信息的Oqaque，ServiceAccount中用到包含三个部分：Token、ca.crt、namespace

上面的认证过程，只是确认通信的双方都确认对方是可信的，进而可以互相通信。

鉴权是确定请求方有哪些资源权限，API Server 内部通过用户认证后，然后进入授权流程。对合法用户进行授权并且随后在用户访问时进行鉴权，是权限管理的重要环节。API Server目前支持以下几种授权策略（通过API Server的启动参数 --authorization-mode 设置）

RBAC（Role-Based Access Control，基于角色的访问控制）在Kubernetes v1.5引入，在v1.6版本时升级为Beta版本，并成为kubeadm安装方式下的默认选项，组建其重要程度。相对于其他的访问控制方式，RBAC具有如下优势。

要使用RBAC授权模式，则需要在API Server的启动参数中加上 --authorization-mode=RBAC 。

角色绑定

主体（subject）

BAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding。同其他API资源对象一样，用户可以使用kubectl或者API调用方式 *** 作这些资源对象。

需要注意的是Kubernetes并不会提供用户管理，那么User、Group、ServiceAccount指定的用户又是从哪里来的呢？Kubernetes组件（kubectl、kube-proxy）或是其他自定义的用户在向CA申请证书时，需要提供一个证书请求文件。

在RBAC API中Role表示一组规则权限，权限只会增加（累加权限），不存在一个资源一开始就有很多权限而通过RBAC对其进行减少的 *** 作；Role可以定义在一个namespace中，如果想要跨namespace则可以创建ClusterRole

rules中的参数说明：

ClusterRole

ClusterRole处理具有和Role一致的命名空间内资源的管理能力，因其集群级别的范围，还可以用于以下特殊元素的授权。

下面的ClusterRole可以让用户有权访问任意一个或所有命名空间的secrets（视其绑定方式而定）：

RoleBinding可以将角色中定义的权限授予用户或用户组，RoleBinding包含一组权限列表（subjects），权限列表中包含有不同形式的待授予权限资源类型（users、groups、Service Account）；RoleBinding同样包含对被Bind的Role引用，RoleBinding适用于某个命名空间内授权，ClusterRoleBinding适用于集群范围内授权。

下面例子中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane，这一 *** 作让jane可以读取default命名空间中的Pod：

RoleBinding也可以引用ClusterRole，来对当前namespace内用户、用户组或ServiceAccount进行授权，这种 *** 作允许集群管理员在整个集群内定义一些通用ClusterRole，然后在不同的namespace中使用RoleBinding来引用

例如，以下RoleBinding引用一个ClusterRole，这个ClusterRole具有整个集群内对secrets的访问权限，但是其授权用户dave只能访问development空间中的secrets（因为RoleBinding定义在development命名空间）

集群角色绑定中的角色只能是集群角色，用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许manager组的用户读取任意namespace中的secret：

示例1：普通角色的资源列表：

解释：如上限定在default的命名空间的名为pod-and-pod-logs-reader的普通角色，对pod和pods/log资资源就有get和list的权限。

示例2：更精细粒度的资源控制，可通过resourceNamess指定特定的资源实例，以限制角色只能够对具体的某个实例进行访问控制。

解释：如上限定在default的命名空间的名为configmap-updater的普通角色，对名为my-configmap的configmaps类型的特定资源，具有update和get权限。

示例1：类型为user（用户）。

示例2：类型为group（组）。

示例3：查看default的服务账户。

Kubernetes系统通过三个独⽴的组件间的相互协作来实现服务账户的⾃动化，三个组件具体为：Admission Controllers准⼊控制器、令牌控制器（token controller）和Service Account账户控制器。Service Account控制器负责为名称空间管理相应的资源，并确保每个名称空间中都存在⼀个名为“default”的Service Account对象。

当请求通过了前面的认证和授权之后，还需要经过准入控制处理通过之后，apiserver 才会处理这个请求。Admission Control 有一个准入控制列表，我们可以通过命令行设置选择执行哪几个准入控制器。只有所有的准入控制器都检查通过之后，apiserver 才执行该请求，否则返回拒绝。

在kubernetes中，一些高级特性正常运行的前提条件为，将一些准入模块处于enable状态。总结下，对于kubernetes apiserver，如果不适当的配置准入控制模块，他就不能称作是一个完整的server，某些功能也不会正常的生效。

允许所有请求

拒绝所有请求

强制设置Pod拉取镜像策略为Always。这样能够保证私有镜像只能被有拉取权限的使用者使用。

它会拦截所有想在privileged container上执行命令的请求。(如果自己的集群支持privileged container，自己又希望限制用户在这些privileged container上执行命令，那么强烈推荐使用它。)

这个插件禁止那些通过主机执行而获得privileges去执行exec和attach Pod的命令。

通过webhook决定image策略，需要同时配置–admission-control-config-file

一个serviceAccount为运行在pod内的进程添加了相应的认证信息。当准入模块中开启了此插件（默认开启），如果pod没有serviceAccount属性，将这个pod的serviceAccount属性设为“default”；确保pod使用的serviceAccount始终存在；如果LimitSecretReferences 设置为true，当这个pod引用了Secret对象却没引用ServiceAccount对象，弃置这个pod；如果这个pod没有包含任何ImagePullSecrets，则serviceAccount的ImagePullSecrets被添加给这个pod；如果MountServiceAccountToken为true，则将pod中的container添加一个VolumeMount 。

它会观察所有的请求，确保在namespace中ResourceQuota对象处列举的container没有任何异常。如果在kubernetes中使用了ResourceQuota对象，就必须使用这个插件来约束container。(推荐在admission control参数列表中，这个插件排最后一个。)

实现配额控制。他会观察所有的请求，确保没有违反已经定义好的约束条件，这些条件定义在namespace中LimitRange对象中。如果在kubernetes中使用LimitRange对象，则必须使用这个插件。

禁止创建设置了 Security Context 的 pod。这个插件将会将使用了 SecurityContext的pod中定义的选项全部失效。关于 SecurityContext的描述：SecurityContext 在container中定义了 *** 作系统级别的安全设定（uid, gid, capabilities, SELinux等等）。

确保处于termination状态的namespace不再接收新的对象创建请求，并拒绝请求不存在的namespace。

根据镜像的历史使用记录，为容器设置默认资源请求和限制

为PVC设置默认StorageClass

设置Pod的默认forgiveness toleration为5分钟

使用Pod Security Policies时必须开启

限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源（v1.7版本以上才支持）

参考：

https://www.cnblogs.com/xzkzzz/p/9909468.html

https://www.cnblogs.com/Dev0ps/p/10852445.html

https://www.kubernetes.org.cn/1995.html

https://www.kubernetes.org.cn/4061.html

https://www.jianshu.com/p/5a6e9ee8ab5a

https://www.jianshu.com/p/fd61330596eb

https://www.cnblogs.com/itzgr/p/11112879.html

https://www.cnblogs.com/yanjieli/p/11859041.html

---