1. k8s节点介绍

一 ：K8s功能

自动化部署容器与复制

随时扩展或收缩容器规模

组织容器成组，提供容器间的负载均衡

快速更新及回滚容器版本

弹性伸缩，如果某个容器失效就进行替换

二 ：k8s重要组件

（1） Master组件

Master节点上面主要由四个模块组成，APIServer，scheduler，controller manager，etcd

① APIServer，负责对外提供RESTful的kubernetes API服务，他是系统管理命令的统一入口，任何对资源进行增删改查的操作都要交给APIServer处理后交给etcd。Kubectl（k8s提供的客户端工具，该工具内部就是对kubernetes api的调用）是直接和APIServer交互的

② Schedule：他的职责很明确，就是负责调度pod到适合的node上，如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个node组成的列表，输出是pod和一个node的绑定，即将这个pod部署到这个node上，kubernetes目前提供了调度算法，但是同样也保留了接口，用户可以根据自己的需求定义自己的调度算法

③ Controller manager：如果说APIserver做的事“前台”工作的话，那么controller manager就是负责“后台”的，每个资源一般都对应一个控制器，而controller manager 就是负责管理这些控制器的。比如我们通过APIServer创建一个Pod，当这个pod创建成功后，APIServer的任务就算完成了，而后面保证这个Pod的状态始终和我们预期的一样，那重任就是由controller manager去保证了

④ Etcd：它是一个高可用的键值存储系统，kubernetes使用它来存储各个资源的状态，从而实现了Restful的API

（2） Node组件

① runtime：runtime是指容器运行环境，目前kubernetes支持docker和rkt两种容器

② kubelet：kubelet是master在每个node节点上面的agent，是node节点上面最重要的模块，他负责管理该node上面的所有容器，但是如果容器不是通过kubernetes创建的，它并不会管理，本质上，他负责使Pod得运行状态与期望的状态一致

③ kube-proxy：kube-proxy该模块实现了kubernetes中的服务发现和反向代理功能，反向代理方面：kube-proxy支持tcp和upd连接转发，默认基于round robin算法将客户端流量转发到与service对应的一组后端pod，服务发现方面，kube-proxy使用etcd的watch机制，监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响，另外kube-proxy还支持session affinity

（3） Pod组件

① Pod：pod是k8s进行资源调度的最小单位，每个pod中运行着一个或多个密切相关的业务容器，这些业务容器共享这个pause容器的IP和Volume,我们以这个不易死亡的pause容器作为pod的根容器，以他的状态表示整个容器组的状态，一个pod一旦被创建就会放到ETCD中存储，然后由master调度到一个node绑定，由这个node上的kubelet进行实例化，每个pod会被分配一个单独的pod IP，pod IP + Containerport 组成了一个ENDpoin

（4） Service组件

① Service其功能使应用暴露，pods是有生命周期的，也有独立的IP地址，随着Pods的创建与销毁，一个必不可少的工作就是保证各个应用能够感知这种变化，这就要提到service了，service 是YAML或JSON定义的由Pods通过某种策略的逻辑组合，更重要是，pods的独立IP需要通过service暴露到网络中

搭建kubernetes群集环境有哪些方法

1：Minikube安装方式

Minikube是一个工具，可以本地快速运行一个单点，尝试Kubernetes或日常开发的用户使用。但是这种方式仅可用于学习和测试部署，不能用于生产环境。

2：kubeadm安装方式

kubeadm是一个kubernetes官方提供的快速安装和初始化拥有最佳实践（best practice）的kubernetes集群的工具，提供kubeadm init和kubeadm join，用于快速部署Kubernetes集群。目前kubeadm还处于beta 和alpha状态，不推荐用在生产环境，但是可以通过学习这种部署方法来体会一些官方推荐的kubernetes最佳实践的设计和思想。

 

kubeadm的目标是提供一个最小可用的可以通过Kubernetes一致性测试的集群，所以并不会安装任何除此之外的非必须的addon。kubeadm默认情况下并不会安装一个网络解决方案，所以用kubeadm安装完之后，需要自己来安装一个网络的插件。所以说，目前的kubeadm是不能用于生产环境的

3：二进制安装（生产部署的方法）

从官方下载发行版的二进制包，手动部署每个组件，组成Kubernetes集群，这种方式符合企业生产环境标准的Kubernetes集群环境的安装，可用于生产方式部署。

三： 基础信息

使用kubernetes1.14.2，所有节点操作系统centos7.5.本文档部署中所需要kubernetes相关安装包和镜像可提前在FQ服务器上下载，然后同步到k8s部署机器上，具体信息如下

Ip地址	主机名	角色
192.168.124.24	K8s-master01	主节点1，etc节点1
192.168.124.26	K8s-master02	主节点2，etc节点2
192.168.124.27	K8s-master03	主节点3，etc节点3
192.168.124.29	K8s-node01	工作节点1
192.168.124.30	K8s-node02	工作节点2
192.168.124.31	K8s-node03	工作节点3
192.168.124.32	K8s-ha01	Nginx节点1，harbor节点1
192.168.124.33	K8s-ha02	Nginx节点2，harbor节点2

本套环境

kubernetes1.14.2

Docker 18.09.6-ce

Etcd 3.3.13

Flanneld 0.11.0

插件

-  Coredns

-  Dashboard

-  Metrics-server

镜像仓库：

-  harbor（两个仓库相互同步，对外提供统一入口VIP地址）

主要配置策略

kube-apiserver高可用（nginx负载层）

- 使用nginx+keepalived实现高可用，VIP：192.168.124.250

- 关闭非安全端口8080和匿名访问：

- 在安全端口6443接受https请求；

- 严格的认证和授权策略（x509，token，RBAC）；

- 开启bootstrap token认证，支持kubelet TLS bootstrapping；

- 使用https访问kubelet，etcd，加密通信；

kube-controller-manager高可用：

-  3节点高可用；

-  关闭非安全端口，在安全端口 10252 接收 https 请求；

-  使用 kubeconfig 访问 apiserver 的安全端口；

-  自动 approve kubelet 证书签名请求 (CSR)，证书过期后自动轮转；

-  各controller 使用自己的 ServiceAccount 访问 apiserver；

 

kube-scheduler高可用：

-  3节点高可用；

-  使用 kubeconfig 访问 apiserver 的安全端口；

 

kubelet：

-  使用 kubeadm 动态创建 bootstrap token，而不是在 apiserver 中静态配置；

-  使用TLS bootstrap机制自动生成 client 和 server 证书，过期后自动轮转；

-  在 kubeletConfiguration 类型的 JSON 文件配置主要参数；

-  关闭只读端口，在安全端口 10250 接收 https 请求，对请求进行认证和授权，拒绝匿名访问和非授权访问；

-  使用 kubeconfig 访问 apiserver 的安全端口；

 

kube-proxy：

-  使用kubeconfig 访问 apiserver 的安全端口；

-  在KubeProxyConfiguration 类型的 JSON 文件配置主要参数；

-  使用ipvs代理模式；

 

集群插件：

-  DNS：使用功能、性能更好的 coredns；

-  Dashboard：支持登录认证；

-  Metric：metrics-server，使用 https 访问 kubelet 安全端口；

-  Log：Elasticsearch、Fluend、Kibana；

-  Registry 镜像库：Harbor私有仓库，两个节点相互同步；

 

                                                                                                                   

kubernetes集群部署中生成的证书文件如下：

ca-key.pem                       根私钥（controller-manager配置的时候，跟上--service-account-private-key-file）

ca.pem                              根证书（apiserver配置的时候，跟上--service-account-key-file）

kubernetes-key.pem         集群私钥

kubernetes.pem                集群证书

kube-proxy.pem                 proxy证书-node节点进行认证

kube-proxy-key.pem           proxy私钥-node节点进行认证

admin.pem                         管理员证书-主要用于kubectl认证

admin-key.pem                   管理员私钥-主要用于kubectl认证

 

                                                                                                                   

TLS作用：就是对通讯加密，防止中间人窃听；同时如果证书不信任的话根本就无法与 apiserver 建立连接，更不用提有没有权限向 apiserver 请求指定内容。

RBAC作用：RBAC 中规定了一个用户或者用户组(subject)具有请求哪些 api 的权限；在配合 TLS 加密的时候，实际上 apiserver 读取客户端证书的 CN 字段作为用户名，读取 O 字段作为用户组。

 

总之想要与apiserver通讯就必须采用由apiserver CA签发的证书，这样才能形成信任关系，建立TLS连接；另外可通过证书的CN、O字段来提供RBAC所需用户与用户组。

 

                                                                                                                   

kubernetes集群会默认开启RABC（角色访问控制机制），这里提前了解几个重要概念：

- DRBC

K8S 1.6引进，是让用户能够访问K8S API资源的授权方式（不授权就没有资格访问K8S的资源）

- 用户

K8S有两种用户：User 和 Service Account。其中，User给用户使用，Service Account给进程使用，让进程有相关权限。如Dashboard就是一个进程，可以创建一个Service Account给它使用。

- 角色

Role是一系列权限的集合，例如一个Role可包含读取和列出Pod的权限（ClusterRole和Role类似，其权限范围是整个集群）

- 角色绑定

RoleBinding把角色映射到用户，从而让这些用户拥有该角色的权限（ClusterRoleBinding和RoleBinding类似，可让用户拥有ClusteRole的权限）

- Secret

Secret是一个包含少量敏感信息如密码，令牌或密钥的对象。把这些信息保存在Secret对象中，可以在这些信息被使用时加以控制，并可以减低信息泄露的风险。