目录

概念

基础架构

单master节点

多master节点

组件

Master节点核心组件

其他组件

请求发送流程

插件

核心资源

调度资源

Pod

创建pod组件间调用流程

pod生命周期：

初始化容器

镜像拉取策略

重启策略

钩子函数

探针

探针的实现方式

DownwardAPI

ReplicationController

ReplicaSet

Deployment

更新 Deploymen

回滚 Deployment

更新 Deployment 的注意事项

StatefulSet

DaemonSet

CronJob

HPA

配置资源

ConfigMap

创建ConfigMap的四种方式

应用方式

Secret

Secret常用类型：

进行加密

configMap和secret区别

服务发布

Service

service作用

服务访问

支持多种访问方式实现

Ingress

Ingress Controller

路径匹配方式

数据存储

Volume

PV和PVC

PV回收策略（persistentVolumeReclaimPolicy）

访问模式（accessModes）

存储分类

高级调度

容忍和污点

设计理念

配置解析

创建污点

创建容忍

Taint常用命令

准入控制

Resources指定pod资源限制

命名空间资源配额

命名空间下的所有pod资源配额限制

Pod服务质量QoS

认证方式

UserAccount

ServiceAccount

权限

---

概念

容器是什么？

容器顾名思义是一个载体，我们生活当中使用的容器，一般指的是被子，碗等等，用来装东西的。在软件开发运维方面容器承载的是应用程序及其所有依赖项（例如jdk、jar。构建后的文件、nginx）

为什么要用容器化技术？

按照传统方式进行部署时，可以简单的分为两步，在操作系统上安装环境依赖，然后再跑程序。如果需要在另外一台服务器上进行部署还是需要重复上面的操作，安装依赖再运行程序。可能现在觉得两步骤并不麻烦，但当一个繁重的系统，需要依赖很多环境配置和中间件，那部署对于运维人员是一个重复且枯燥的体力活，而且一旦版本不一致还会导致其他问题的产生。

按照容器方式进行部署时，可以启动一个liunx基础容器，将环境依赖和程序在容器中安装运行，当需要在其他服务器部署时，把容器打包为镜像或tar包移植部署，避免了繁琐的部署步骤。

容器化技术的优点 ？

• 跨平台性： 容器可以在不同的操作系统和云平台上运行，提供了跨平台性，使应用程序更加可移植。
• 轻量级： 容器共享主机操作系统的内核，相比虚拟机来说更加轻量级。容器可以更快速地启动和停止，并占用更少的系统资源。
• 快速部署： 容器可以迅速部署，几乎瞬间启动。有助于快速开发、测试和部署应用程序。
• 一致性： 容器包含应用程序及其所有依赖项，确保了在不同环境中一致的运行，从而减少了因环境差异而引起的问题。
• 资源隔离： 每个容器都运行在其独立的用户空间，提供了良好的资源隔离，避免了应用程序之间的冲突。

kubernetes是什么 ？

公司内随着容器的越来越多，容器的管理出现了一些问题，健康检查不到位、容器的扩容、部署、回滚和更新不够灵活。

kubernetes是一个开源的容器编排和管理平台，它用来处理容器的自动化部署、自动恢复、水平伸缩等任务。通过给用户提供操作的接口，可以对容器进行增删改查等操作。

Kubernetes 是希腊语『舵手』的意思，它最开始由 Google 的几位软件工程师创立。作为编排工具，从社区的年龄来讲，Kubernetes 不占优势，Apache 推出的 Mesos 最早。从官方性方面也不占优势，Docker Swarm是docker官方提供的容器编排工具。但是后来因为是谷歌开源出来，社区很活跃，有很多人在使用，所以变成了以后整个行业的主要支柱。

基础架构

单master节点

多master节点

组件

Master节点核心组件

APIServer
        提供资源操作的唯一入口（任何组件想要访问Etcd都要经过APIServer），并且提供认证/授权/kubernets的访问控制。
        可以通过kubectl和自己开发的客户端，通过http的请求通过restapi的形式来访问apiserver，从而实现对整个集群的控制

6443端口

ControllerManager
负责维护整个集群的状态，如，故障检测/扩缩容/滚动更新等

Scheduler
负责资源的调度，按照预定的调度策略，把pod调度到相应的node节点
K8s有丰富的调度策略

其他组件

Kubelet
维护当前节点的容器的生命周期，维护当前节点的volume/网络等的管理，与master节点进行交互

Kube-proxy
每个node都会运行一个kube-proxy，提供内部的服务发现和负载均衡，为service的概念提供一个落地的方法。具体来说，就是实现集群内的客户端pod访问service，或者是集群外的主机通过NodePort等方式访问service。

有userSpace(已废弃)、iptables、IPvs工作模式

userSpace:

iptables:只支持轮询调度

ipvs:

Etcd
主要用于一致性存储，保存pod/service和集群的状态等信息
相当于k8s集群需要持久化的数据都会存储在etcd

请求发送流程

• 用户执行kubectl/userClient向api server发起一个命令
• 经过认证授权后，经过scheduler的各种策略，得到一个目标node
• 然后告诉api server，api server 会请求相关node的kubelet，通过kubelet把pod运行起来，apiserver还会将pod的信息保存在etcd
• pod运行起来后，controllermanager就会负责管理pod的状态，如，若pod挂了，controllermanager就会重新创建一个一样的pod，或者像扩缩容等

插件

Kube-dns
提供通过servicename访问服务，但并不是必须的。若不需要通过名字来访问，可以不安装kube-dns，但通常会安装，因为通过名字访问是一个比较重要的功能

DNS服务在kubernetes中经历了三个阶段（SkyDNS-》KubeDNS-》CoreDNS）：

【第一阶段】在kubernetes 1.2版本时，dns服务使用的是由SkyDNS提供的，由4个容器组成：kube2sky、skydns、etcd和healthz。etcd存储dns记录；kube2sky监控service变化，生成dns记录；skydns读取服务，提供查询服务；healthz提供健康检查。

【第二阶段】在kubernetes 1.4版本开始使用KubeDNS，有3个容器组成：kubedns、dnsmasq和sidecar。kubedns监控service变化，并记录到内存（存到内存提高性能）中；dnsmasq获取dns记录，提供dns缓存，提供dns查询服务；sidecar提供健康检查。

【第三阶段】从kubernetes >=1.11版本开始，dns服务有CoreDNS提供，coredns支持自定义dns记录及配置upstream dns server，可以统一管理内部dns和物理dns。coredns只有一个coredns容器。下面是coredns的架构。

Calico

Calico 是一套开源的网络和网络安全方案，用于容器、虚拟机、宿主机之前的网络连接，可以用在kubernetes、OpenShift、DockerEE、OpenStrack等PaaS或IaaS平台上。

Metrics Server

在新版的Kubernetes中系统资源的采集均使用Metrics-server，可以通过Metrics采集节点和Pod的内存、磁盘、CPU和网络的使用率

核心资源

调度资源

Pod

• 最小的调度以及资源单位
• 由一个或者多个容器组成
• 定义容器运行的方式（Command、环境变量）
• 提供容器共享的运行环境（网络、进程空间、存储卷）

为什么pod必须是原子调度的单位？

        如果两个容器app、log紧密合作，需要部署在同一个worker节点，app服务需要1G、log服务需要0.5G，如果节点资源是1.25G，那app服务被调度到该节点，再调度log服务时，会发现资源不够，这样就是成组调度失败。失败之后就需要补偿策略进行回滚，重新选择worker节点，这实现起来就比较复杂。而且目前还没有考虑多请求同时调度的情况，在这种情况下可能产生死锁，要进行回滚更加复杂，调度效率会大大降低。

有了pod进程组的存在，就可以根据pod来进行资源分配，不需要考虑以上情况

创建pod组件间调用流程

pod生命周期：

1. 启动pause容器，初始化网络、设定命名空间
2. 初始化容器，可以有多个，串行机制来实现。例如：调整内核操作
3. 运行主容器，如果有多个就并行执行，各自维护各自的生命周期
4. 在运行主容器过程中，会运行postStart，如果没有配置，就默认success
5. 检测容器是否正常启动。startupprobe
6. 运行期间，如果配置了探针检测：livenessprobe readinessprobe
7. 容器退出：prostop。1）清理注册信息。2）优雅关闭进程

pause容器时pod的父容器，主要负责僵尸进程的回收管理，同时使同一个pod的不同容器共享存储、网络、PID、IPC等，容器之间可以使用localhost:port相互访问，可以使用volume等实现数据共享

初始化容器

在主要的容器启动之前地洞的一个容器：重点是用来做初始化动作

• app容器依赖mysql的数据交互，可以启动一个初始化容器检查mysql服务是否正常启动，正常则启动主容器
• 使用初始化容器对系统内核参数进行调优，然后共享给著容器使用

镜像拉取策略

通过 spec.containers[].imagePullPolicy 参数可以指定镜像的拉取策略，目前支持的策略如下：

Always：总是拉取，当镜像 tag 为 latest 时，且 imagePullPolicy 未配置，默认为 Always

Never：不管是否存在都不会拉取

IfNotPresent：镜像不存在时拉取镜像，如果 tag 为非 latest，且 imagePullPolicy 未配置，默认为 IfNotPresent

重启策略

可以使用 spec.restartPolicy 指定容器的重启策略

Always：默认策略。容器失效时，自动重启该容器

OnFailure：容器以不为 0 的状态码终止，自动重启该容器

Never：无论何种状态，都不会重启

钩子函数

用来监听容器生命周期的特定时间，并在事件发生时执行已注册的回调函数

• 当一个容器启动后，k8s将立即执行postStart时间关联的动作
• 在容器被终结之前，k8s将立即执行preStop时间关联的动作

两种钩子

名称	作用
poststart	容器创建后自己执行，由于是异步执行，无法保证一定在容器之前运行，如果失败容器回被杀死，并根据restartPolicy决定是否重启
preStop	在容器终止前执行，在完成之前会阻塞容器的操作，默认等待时间30s，通过terminationGracePeriodSeconds宽限时间

探针

名称	作用
startupProbe 启动探针	检测容器中的应用是否正常启动，如果使用了启动探针，则其他探针都会被禁用，需要等待启动探针检测成功之后才可以执行。如果探测失败，Kubelet 会杀死容器，之后根据重启策略进行处理，如果探测成功，或没有配置 startupProbe， 则状态为成功，之后就不再探测 （只会探测一次） 用来检查容器是否真的启动，比如检查端口，检查进程
livenessProbe 存活探针	用于探测容器是否在运行，如果探测失败，kubelet 会“杀死”容器并根据重启策略 进行相应的处理。如果未指定该探针，将默认为 Success （持续探测） 通过curl命令请求一个接口，判断状态码
readinessProbe 就绪探针	一般用于探测容器内的程序是否健康，即判断容器是否为就绪（Ready）状态。如果是，则可以处理请求，反之 Endpoints Controller 将从所有的 Service 的 Endpoints 中删除此容器所在 Pod 的 IP 地址。如果未指定，将默认为 Success 通过curl命令请求一个接口，判断状态码

startupProbe和livenessProbe如果失败，k8s会杀死容器，根据重启策略决定是否重启。readinessProbe如果失败，将容器设定为未就绪状态，将其从负载均衡列表中移除，请求就不会调度到该pod

探针的实现方式

实现方式	说明
ExecAction	在容器内执行一个指定的命令，如果命令返回值为 0，则认为容器健康
TCPSocketAction	通过 TCP 连接检查容器指定的端口，如果端口开放，则认为容器健康
HTTPGetAction	对指定的 URL 进行 Get 请求，如果状态码在 200~400 之间，则认为容器健康

DownwardAPI

可以让容器获取pod的相关元数据信息，比如pod名称，pod的ip，pod的资源限制，获取后通过env、volume的方式将相关的环境信息注入到容器中，从而让容器通过这些环境变量的信息，来设定容器的运行特性

ReplicationController

Replication Controller（简称 RC）可确保 Pod 副本数达到期望值，也就是 RC 定义的数量。如果存在的 Pod 大于设定的值，则 Replication Controller 将终止额外的 Pod。如果太小， Replication Controller 将启动更多的 Pod 用于保证达到期望值。

Replication Controller 类似于进程 管理程序，但是 Replication Controller 不是监视单个节点上的各个进程，而是监视多个节点上的 多个 Pod。

ReplicaSet

ReplicaSet 是支持基于集合的标签选择器的下一代 Replication Controller，它主要用作 Deployment 协调创建、删除和更新 Pod，和 Replication Controller 唯一的区别是，ReplicaSet 支持 标签选择器。

Deployment

• Deployment控制器是工作在ReplicaSet之上的，Deployment通过控制ReplicaSet来控制pod，并不是直接控制pod
• Deployment有ReplicaSet的所有功能
• 无状态应用管理，所有pod等价
• 由于现在企业服务都是集群化部署，服务都是无状态的，也是最常用的控制器

高级功能：无缝迁移、自动扩容缩容、自动灾难恢复、一键回滚

更新 Deploymen

当且仅当 Deployment 的 Pod 模板（即.spec.template）更改时，才会触发 Deployment 更新，例如更改内存、CPU 配置或者容器的 image。

假如更新 Nginx Pod 的 image 使用 nginx:latest，并使用--record 记录当前更改的参数，后期 回滚时可以查看到对应的信息： 
# kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 -- record 
	deployment.extensions/nginx-deployment image updated 

当然也可以使用 edit 命令直接编辑 Deployment，效果相同： 
# kubectl edit deployment.v1.apps/nginx-deployment 
	deployment.apps/nginx-deployment edited 
 
 同样可以使用 kubectl rollout status 查看更新过程：
 # kubectl rollout status deployment.v1.apps/nginx-deployment
	Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 
	new replicas have been updated...
	Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 
	new replicas have been updated...
	Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 
	new replicas have been updated...
	Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 
	new replicas have been updated...
	Waiting for deployment "nginx-deployment" rollout to finish: 1 old 
	replicas are pending termination...
	Waiting for deployment "nginx-deployment" rollout to finish: 1 old 
	replicas are pending termination...
	deployment "nginx-deployment" successfully rolled out

回滚 Deployment

查看历史信息

使用 kubectl rollout history 查看更新历史：
# kubectl rollout history deployment/nginx-deployment
	REVISION CHANGE-CAUSE
	1 <none>
	2 kubectl set image deployment nginx-deployment nginx=nginx:1.9.1 
	--record=true
	3 kubectl set image deployment nginx-deployment 
	nginx=dotbalo/canary:v1 --record=true
	4 kubectl set image deployment nginx-deployment 
	nginx=dotbalo/canary:v2 --record=true

查看 Deployment 某次更新的详细信息，使用--revision 指定某次更新版本号：
 # kubectl rollout history deployment/nginx-deployment --revision=3
	deployment.apps/nginx-deployment with revision #3
	Pod Template:
	 Labels: app=nginx
	pod-template-hash=645959bf6b
	 Annotations: kubernetes.io/change-cause: kubectl set image deployment 
	nginx-deployment nginx=dotbalo/canary:v1 --record=true
	 Containers:
	 nginx:
	 Image: dotbalo/canary:v1
	 Port: 80/TCP
	 Host Port: 0/TCP
	 Environment:<none>
	 Mounts: <none>
	 Volumes: <none>

回滚

如果只需要回滚到上一个稳定版本，使用 kubectl rollout undo 即可：
# kubectl rollout undo deployment/nginx-deployment
	deployment.apps/nginx-deployment

如果要回滚到指定版本，使用--to-revision 参数：
# kubectl rollout undo deployment/nginx-deployment --to-revision=2
	deployment.extensions/nginx-deployment

更新 Deployment 的注意事项

历史版本清理策略：

在默认情况下，revision 保留 10 个旧的 ReplicaSet，其余的将在后台进行垃圾回收，可以 在.spec.revisionHistoryLimit 设置保留 ReplicaSet 的个数。当设置为 0 时，不保留历史记录

更新策略：

• .spec.strategy.type==Recreate，表示重建，先删掉旧的Pod再创建新的Pod；
• .spec.strategy.type==RollingUpdate，表示滚动更新，可以指定maxUnavailable和maxSurge 来控制滚动更新过程；

• • .spec.strategy.rollingUpdate.maxUnavailable，指定在回滚更新时最大不可用的Pod数量， 可选字段，默认为25%，可以设置为数字或百分比，如果maxSurge为0，则该值不能 为0；
  • .spec.strategy.rollingUpdate.maxSurge可以超过期望值的最大Pod数，可选字段，默认为 25%，可以设置成数字或百分比，如果maxUnavailable为0，则该值不能为0

StatefulSet

常用于部署有状态的且需要有序启动的应用程序。

适用于以下：

• 需要稳定的独一无二的网络标识符
• 需要持久化数据
• 需要有序的、优雅的部署和扩展
• 需要有序的自动滚动更新

statefulSet为每个Pod维护了一个粘性标识。而StatefulSet创建的Pod一般使用Headless Service(无头服务）进行Pod之前的通信，和普通的Service的区别子啊与Headless Service没有Cluster IP，它使用Endpoint进行互相通信

DaemonSet

在每个节点上跑一个 Pod，可以用来做节点监控、节点日志收集等

DaemonSet不管理Replicas，因为DaemonSet不是基于期望的副本数，而是基于节点数量来控制Pod数量

DaemonSet典型用法，在每个节点上运行集群存储守护进程、日志收集守护进程、监控守护进程、网络插件为Pod提供网络服务。

CronJob

Job 用来表达的是一次性的任务，而 CronJob 会根据其时间规划反复运行。

HPA

根据监控指标进行自动扩容伸缩。HPA v1为稳定版自动水平伸缩，只支持CPU指标 ，V2为beta版本，分为v2beta1(支持CPU、内存和自定义指标) ，v2beta2(支持CPU、内存、自定义指标Custom和额外指标ExternalMetrics)

• 必须安装metrics-server或其他自定义metrics-server
• 必须配置requests参数
• 不能扩容无法缩放的对象，statefulset一般代表有状态服务，副本不可随便修改，而Job一般代表短生命周期的，所以基本可以认为HPA目前是专门控制deployment的扩缩容的（不建议直接控制RS，否则将无法滚动升级）

一般生产环境不能直接使用，因为某项指标的升高并不是因为监控的此服务导致的，可能是由于下游服务导致，扩容此服务无法解决该问题

配置资源

ConfigMap

configmap资源主要为容器注入相关的程序配置信息，用来定制程序的运行方式。定义好一个configmap资源后，如果pod需要使用，通过环境变量或者存储卷的形式将其挂载并加载相关的配置，大大降低配置文件与容器镜像的耦合关系。

创建ConfigMap的四种方式

1.通过--from-literal（文字的）

# kubectl create cm myconfigmap1 --from-literal=username=root --from-literal=pasword=123.com

2、通过from-file（文件）

# echo root > username
# echo 123.com  > password
#  kubectl create cm myconfigmap2 --from-file=username --from-file=password 

3、通过-- from- env-file

#vim env.txt 
username=root
password=123.com

# kubectl create cm myconfigmap3 --from-env-file=env.txt 

4、通过yaml配置文件

# vim myconfigmap4.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: myconfigmap4
data:
  username: root
  password: 123.com
  
# kubectl apply -f myconfigmap4.yaml

应用方式

1、使用valueFrom一对一定义环境变量

2、使用envFrom定义环境变量

3、以文件的形式挂载ConfigMap（可以挂载nginx配置文件）

        如果引用secret数据的应用， 要求会随着secret资源对象内保存的数据的更新，而实时更新，那么应该使用volumes挂载的方式引用资源因为用环境变量的方式引用不会实时更新数据。

Secret

        Secret是用来保存小片敏感数据的k8s资源，例如密码，token，或者秘钥。这类数据当然也可以存放在Pod或者镜像中，但是放在Secret中是为了更方便的控制如何使用数据，并减少暴露的风险。

Secret常用类型：

• Opaque：通用型Secret，默认类型；
• kubernetes.io/service-account-token：作用于ServiceAccount，包含一个令牌，用于标识API服务账户；
• kubernetes.io/dockerconfigjson：下载私有仓库镜像使用的Secret， 和宿主机的/root/.docker/config.json一致，宿主机登录后即可产生该文件；
• kubernetes.io/basic-auth：用于使用基本认证（账号密码）的Secret，可以使用Opaque取代；
• kubernetes.io/ssh-auth：用于存储ssh密钥的Secret；
• kubernetes.io/tls：用于存储HTTPS域名证书文件的Secret，可以被Ingress使用；
• bootstrap.kubernetes.io/token：一种简单的 bearer token， 用于创建新集群或将新节点添加到现有集群，在集群安装时可用于自动颁发集群的证书。

进行加密

-----把需要保存的数据加密（”base64“的方式）
# echo root | base64
cm9vdAo=
# echo 123.com | base64
MTIzLmNvbQo=

------解码
# echo -n cm9vdAo | base64 --decode 
root
# echo -n MTIzLmNvbQo | base64 --decode 
123.com

------编写secret4的yaml文件
# vim secret4.yaml
apiVersion: v1
kind: Secret
metadata:
  name: secret4
data:
  username: cm9vdAo=
  password: MTIzLmNvbQo=
  
# kubectl apply -f secret4.yaml

configMap和secret区别

相同点：

• key/value的形式
• 属于某个特定的namespace
• 可以导出到环境变量
• 可以通过目录/文件形式挂载
• 通过 volume 挂载的配置信息均可热更新

不同点：

• Secret 可以被 ServerAccount 关联
• Secret 可以存储 docker register 的鉴权信息，用在 ImagePullSecret 参数中，用于拉取私有仓库的镜像
• Secret 支持 Base64 加密
• Secret 分为 kubernetes.io/service-account-token、kubernetes.io/dockerconfigjson、Opaque 三种类型，而 Configmap 不区分类型

服务发布

Service

为什么使用service？

通过Ip访问pod，但是pod的Ip不固定，一旦pod发生重建，ip地址会变更

pod如果扩展多份，会造成客户端无法有效新增Pod，如果Pod进行缩容又会造成客户端访问错误。

提供访问一个或者多个Pod实例的稳定访问地址，通过标签选择器进行绑定

service作用

暴露流量：让用户可以通过 ServiceIP+ ServicePort访问对应后端的Pod应用

负载均衡：提供基于4层的TCP/IP负载均衡,并不提供HTTP/HTTPS等负载均衡

不过 Service 并不直接与Pod建立关联关系,它们之间还有一个中间层 Endpoints, Endpoints对象是由IP地址和端口组成的列表,这些IP地址和端口来自于 Service标签选择器所匹配到的 PodIP、 Podport,默认情况下,创建 Service资源时,其关联Endpoints对象会被自动创建

服务发现：当发现新增Pod则自动加入至 Service的后端，如发现Pod异常则自动剔除Service后端

服务访问

1.同一个命名空间下，可以通过servicename直接访问

2.不同命名空间下，需要servicename.namespace来访问

3.外部服务， 希望 Service 指向外部集群中的服务，通过Service和Endpoints代理访问

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-svc-external
  name: nginx-svc-external
  namespace: ingress-nginx
spec:
  ports:
  - name: http
    port: 9090
    protocol: TCP
    targetPort: 9090
  sessionAffinity: None
  type: ClusterIP
---
apiVersion: v1
kind: Endpoints
metadata:
  labels:
    app: nginx-svc-external
  name: nginx-svc-external
  namespace: ingress-nginx
subsets:
- addresses:
  - ip: 192.168.25.234  //还可以添加多个ip 
  ports:
  - name: http
    port: 9090
    protocol: TCP

访问结果

支持多种访问方式实现

• ClusterIP：在集群内部使用，默认值，只能从集群中访问。
• NodePort：在所有安装了 Kube-Proxy 的节点上打开一个端口，此端口可以代理至后端 Pod，可以通过 NodePort 从集群外部访问集群内的服务，格式为 NodeIP:NodePort。
• LoadBalancer：使用云提供商的负载均衡器公开服务，成本较高。
• ExternalName：通过返回定义的 CNAME 别名，没有设置任何类型的代理，需要 1.7 或 更高版本 kube-dns 支持。

Ingress

为什么使用Ingress？

使用NodePort类型的Service可以将集群内部服务暴露给集群外部客户端，但是存在以下几个问题

• 一个端口只能一个服务使用,所有通过 Nodeport暴露的端口都需要提前规划;
• 如果通过 Nodeport暴露端口过多,后期维护成本太大,且不易于管理;
• 目前 Service底层使用的是 Iptables、IPVS,仅支持4层协议,无法完成https协议传输

ingress为k8s集群中的服务提供了入口，可以提供负载均衡和基于名称（域名）的虚拟主机、应用的灰度发布等功能，常用的Ingress有Treafik、Nginx、HAP Roxy、Istio等

Ingress Controller

Ingress Controller是一类以代理HTTP/HTTPS协议为主的代理程序。

类似于Nginx服务，负责读取Ingress的规则，然后转换将规则转换为nginx.conf配置文件，这样就可以根据对应的规则来实现流量的调度。会实时感知后端service对应的pod变化，结合Ingress的规则，进而完成对应的配置动态更新

注意：不经过Service转发，Service只是识别出Pod的IP

路径匹配方式

pathType：路径的匹配方式，目前有 ImplementationSpecific、Exact 和 Prefix 方式

• Exact：精确匹配，比如配置的 path 为/bar，那么/bar/将不能被路由；
• Prefix：前缀匹配，基于以 / 分隔的 URL 路径。比如 path 为/abc，可以匹配 到/abc/bbb 等，比较常用的配置
• ImplementationSpecific：这种类型的路由匹配根据 Ingress Controller 来实现， 可以当做一个单独的类型，也可以当做 Prefix 和 Exact

数据存储

Volume

• 声明在Pod中的容器可访问的文件目录
• 可以挂载在Pod中一个或者多个容器的指定路径下

临时存储卷：emptyDir（ 一般 emptyDir 卷用于 Pod 中的不同 Container 共享数据 ）

本地存储卷：hostPath、local

网络文件系统：NFS、Glusterfs、CephFS

PV和PVC

volume无法解决的问题？

当某个数据卷不再被挂载使用时，里面的数据如何处理？

如果想要实现只读挂载如何处理？

如果想要只能一个Pod挂载如何处理？

如何只允许某个Pod使用10G的空间？

PV：持久卷，集群中的一块存储，可由集群管理员根据PV所支持的存储卷插件定义好底层存储类型、及存储空间

PVC：持久卷申领，用户通过PVC进行存储资源申请，根据用户申请的存储（大小、类型）来绑定符合条件的PV持久卷

定义PVC时,用户可通过访问模式、存储资源空间需求、限制、标签选择器、卷名称、卷类型等标准来筛选集群上的PV资源

• accessmodes：PvC的访问模式;它同样支持RWO、RWX、ROX三种方式;
• resources：申明使用的存储空间的最小值和最大值;
• selector：筛选PV时额外使用的标签选择器
• volume Name：直接指定要绑定的PV资源名称;
• strogeclassname：指定从哪类存储资源下筛选PV,如果指定的名称不存在,则无法绑定成功。如果指定的资源下没有符合的空间也无法绑定成功。比如申请20G空间，但pV都只有10G空间,则无法满足

PV回收策略（persistentVolumeReclaimPolicy）

1.retain（保留）：需要手动回收

删除pvc后将保留其绑定的pv及存储的数据，但会把该pv置为Released状态，它不可再被其他pvc所绑定，且需要有管理员手动进行后续回收操作：首先删除pv，接着手动清理其关联的外部存储组件上的数据，最后基于该组件重新创建pv

2.Recycle（回收）：基本擦除（rm -rf /thevolume/*)

对于支持该回收策略的存储卷插件，删除pvc时，其绑定的pv所关联的外部存储组件上的数据会被清空，随后该pv将转为Available状态，可再次接受其他pvd的绑定请求，不过目前仅NFS和Hostpath支持回收策略

3.delete（删除）

对于支持该回收策略的卷插件，删除一个pvc将同时删除其绑定的pv资源及该pv关联的外部存储组件

pvc中的storageClassName未指定所以就可以从所有的pv中进行匹配选择

访问模式（accessModes）

用于描述用户应用对存储资源的访问权限，访问权限包括下面几种方式：
ReadWriteOnce（RWO）：读写权限，但是只能被单个节点挂载（块存储不能共享只能被单个节点挂载）
ReadOnlyMany（ROX）： 只读权限，可以被多个节点挂载
ReadWriteMany（RWX）：读写权限，可以被多个节点挂载

存储分类

• 文件存储：一些数据可能需要被多个节点使用，比如用户的头像、用户上传的文 件等，实现方式：NFS、NAS、FTP、CephFS等。
• 块存储：一些数据只能被一个节点使用，或者是需要将一块裸盘整个挂载使用， 比如数据库、Redis等，实现方式：Ceph、GlusterFS、公有云。
• 对象存储：由程序代码直接实现的一种存储方式，云原生应用无状态化常用的实 现方式，实现方式：一般是符合S3协议的云存储，比如AWS的S3存储、Minio、七牛云等。

高级调度

容忍和污点

设计理念

Taint在Node上打上污点，让不能容忍这个污点的Pod不能部署 在打了污点的Node上。

Toleration是让Pod容忍节点上配置的污点，可以让一些 需要特殊配置的Pod能够调用到具有污点和特殊配置的节点上。

配置解析

创建污点

（一个节点可以有多个污点）：

kubectl taint nodes NODE_NAME TAINT_KEY=TAINT_VALUE:EFFECT

比如：

kubectl taint nodes k8s-node01 ssd=true:PreferNoSchedule

创建容忍

方式一完全匹配：

tolerations:
- key: "taintKey"
  operator: "Equal"
  value: "taintValue"
  effect: "NoSchedule"

方式二不完全匹配：

tolerations:
- key: "taintKey"
  operator: "Exists"
  effect: "NoSchedule"

方式三大范围匹配（不推荐key为内置Taint）

- key: "taintKey"
  operator: "Exists"

NoSchedule：禁止调度到该节点，已经在该节点上的Pod不受影响

NoExecute：禁止调度到该节点，如果不符合这个污点，会立马被驱逐（或在一段时间后）

PreferNoSchedule：尽量避免将Pod调度到指定的节点上，如果没有更合适的节点，可以部署到该节点

Taint常用命令

创建一个污点（一个节点可以有多个污点）：
kubectl taint nodes NODE_NAME TAINT_KEY=TAINT_VALUE:EFFECT
比如：
kubectl taint nodes k8s-node01 ssd=true:PreferNoSchedule

查看一个节点的污点：
kubectl get node k8s-node01 -o go-template --template {{.spec.taints}}
kubectl describe node k8s-node01 | grep Taints -A 10

删除污点（和label类似）：
基于Key删除： kubectl taint nodes k8s-node01 ssd基于Key+Effect删除： kubectl taint nodes k8s-node01 ssd:PreferNoSchedule修改污点（Key和Effect相同）：
kubectl taint nodes k8s-node01 ssd=true:PreferNoSchedule --overwrite

准入控制

Resources指定pod资源限制

requests：启动Pod时申请分配的资源大小；

limits：限制Pod运行时最大可用的资源大小；

单位：

cpu：100m = 0.1核

memory：“100Mi" = 100MB

命名空间资源配额

当系统存在多个用户或团队共享具有固定节点的 Kubernetes集群时,一般会根据不同团队创建不同的命名空间,但可能会出现某个应用将该命名空间的CPU或内存耗尽的情况,无法保证其公平分配原则。可以通过 Resourcequotas资源配额来解决这个问题。

ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4"         # 限制最多启动pod的个数
    requests.cpu: "1"     #  该空间下所有的request相加限制最高CPU的request请求数上限
    requests.memory: 1Gi      # 该空间下所有的request相加限制最高内存的request请求数上限
    limits.cpu: "2"         # 该空间下所有的limit相加限制最高CPU的limit上限
    limits.memory: 2Gi      # 该空间下所有的limit相加限制最高内存的limit上限

命名空间下的所有pod资源配额限制

limitRange

为什么要有limitRange？

如果ResourceQuota限制该空间下可以有100个pod，但是

如果创建的pod没有限制，设置默认的requests和limits配额，或者限制requests和limits最大最小是多少

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
spec:
  limits:
  - default:               # default：默认limits配置
      cpu: 1
      memory: 512Mi
    defaultRequest:        # defaultRequest：默认requests配置
      cpu: 0.5
      memory: 256Mi
    type: Container

内存、cpu设置最小配置和最大配置

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-mem-limit-range
spec:
  limits:
  - max:               # max：内存CPU的最大配置
      cpu: 800m
      memory: 1Gi
    min:               # min：内存CPU的最小配置
      cpu: 200m
      memory: 500Mi
    type: Container

限制申请存储空间的大小

apiVersion: v1
kind: LimitRange
metadata:
  name: storagelimits
spec:
  limits:
  - type: PersistentVolumeClaim
    max:         # max：最大PVC的空间
      storage: 2Gi
    min:         # min：最小PVC的空间
      storage: 1Gi

Pod服务质量QoS

Guaranteed：每个容器都为cpu资源设置了具有相同值的requests和limits属性，容器都为内存资源设置了具有相同值的requests和limits属性的pod资源会自动归属此类别，这类pod资源具有最高优先级

Burstable：至少有一个容器设置了cpu或内存资源的requests属性，但不满足guaranteed类别的pod资源自动归属此类别，具有中等优先级

BestEffort（默认）：没有为任何容器设置Requests核limits属性，这类pod对象服务质量是最低级别

当k8s集群内存资源紧缺，优先杀死BestEffort类别容器。接下来就轮到Burstable类别的容器，如果有多个，看谁实际运行占用的内存资源多，优先干掉谁。

认证方式

UserAccount

用户账户，是给K8S集群外部用户使用的，如kubectl访问K8S集群要用useraccount用户，kubeadm搭建的K8s集群默认useraccount用户是kubernetes-admin。

ServiceAccount

pod使用的账户，如果创建pod没有填写ServiceAccount的对应的名称，系统会给一个默认的ServiceAccount。该默认的ServiceAccount可以访问集群的元数据信息。如果pod想对集群做操作，那默认的SA就没有足够的权限，我们可以自行创建SA，而后赋予对应的权限，然后注入到pod中，pod就拥有了对应的权限

权限

ClusterRole：配置权限，允许对整个集群做权限限制

Role：只允许对该Namespace做权限限制

K8s利用Role和ClusterRole两类角色来赋予相应的权限，同时也需要用到另外两类资源Rolebinding和ClusterRolebinding来完成用户与角色之间的绑定关系

RoleBinding：将角色和对象进行绑定，范围限定在 namespace；

ClusterRoleBinding：将集群角色和对象进行绑定，不受 namespace 限制；

角色--》组--》用户