文章目录
一、Service原理
1.1概述
暴漏服务的重要方式
KubernetesService定义了这样一种抽象:一个Pod的逻辑分组，一种可以访问它们的策略-- 通常称为微服务。这一组Pod能够被Service访问到，通常是通过'Label Selector
1.2为什么需要service
如果不用service可以实现如图的效果，部署nginx和tomcat,但是如果tomcat的pod坏了一台，deployment会创建新的Pod,但是pod的ip变化了，之前可以实现负载均衡，但是现在ip变了，负载均衡无法代理到新的pod ip上
如果我们中间加了service
service：标签选择器和集群
不管Pod如何更新，都会被加入到负载均衡集群
1.3service
service-userspace:
service-iptables:
service-ipvs:
1.4service类型
ClusterIP:
如图所示，deployment所控制的是两台机器，nginx代理的是23和46两台，现在46机器损坏，控制器会创建新的pod，但是新的pod，ip地址会发生改变，nginx无法代理，也就无法实现负载均衡
ClusterIP:提供一个集群内部的虚拟ip以供Pod访问,他只会收集满足条件的pod
NodePort:
由于用户无法访问虚拟ip，所以我们引入了NodePort，他会提供一个真实的ip，供外部访问
LoadBalancer:
通过外部的负载均衡器来访问
1.5service组件协同
clusterIP：
案例：
会自动生成一个资源清单：
二、configMap原理
配置信息的保存方式
2.1概述
ConfigMap 功能在 Kubernetes1.2 版本中引入，许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API给我们提供了向容器中注入配置信息的机制ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制等对象
2.2命令
--from-file
要求
文件内部必须是一行一对的k=v，可以在使用的时候注入至内部变成环境变量
1.txt
name-zhangsan
passwd=123
文件内部不符合要求，创建的时候依然可以变为k,val的形式，但是不会成为内部的环境变量
2.txt
今天去爬山
案例1：
注入环境变量
案例2：
把环境变量作为启动参数
2.3类型
Clusterip:
如图所示是一个简单的nginx负载均衡，他现在代理的是23和46这两台机器，如果第二台机器出现问题了，那么deployment会重建一个新的，但是这个新的机器ip地址可能会发生变化，导致nginx无法实现负载均衡
Clusterip：他会收集满足条件的pod，他会动态的更新后端Pod的状态
NodePort:
创建的真实ip就可以指向我们当前的Pod上
整个集群的高可用：
三、volume
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失--容器以干净的状态(镜像最初的状态)重新启动。其次，在Pod'中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题
2.1emptydir
当 Pod 被分配给节点时，首先创建emptyDir'卷，并且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入emptyDir'卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除Pod 时，emptyDir中的数据将被永久删除
容器崩渍不会从节点中移除 pod，因此emptyDir 卷中的数据在容器崩溃时是安全的
emptyDir 的用法有:
》暂存空间，例如用于基于磁盘的合并排序、用作长时间计算崩溃恢复时的检查点>Web 服务器容器提供数据时，保存内容管理器容器提取的文件
案例1：
验证：访问nginx页面并
打印busybox容器日志：
或者可以在节点上查看日志
我们在日志中加入元素并查看busybox日志：确实访问一致
案例2：共享内存
2.2hostPath
hostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中
hostPath 用途如下
》运行需要访问 Docker 内部的容器;使用/var/lib/docker'的hostPath》在容器中运行 cAdvisor;使用/dev/cgroups的hostPath允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在，是否应该创建，以及它应该以什么形式存在 除了所需的'path属性之外，用户还可以为hostPath卷指定`type
类型：
注意：
案例：
path:/data是pod最后分配节点的跟data
必须保证节点有这个目录才会创建成功
2.3pv/pvc
回收策略：
状态：
保护：
案例：
所有的几点都要安装yum install -y nfs-common nfs-utils rpcbindmkdir /nfsdata
master:创建共享目录并赋予权限
为了方便测试，可以多创建几个测试文件
查看当前的共享结果：
验证：
node1节点上：
部署PV：
创建PVC：
改一下数量：
验证的stateful的特性：有序创建，有序回收
特性：
2.4storageClass
一种动态的申请存储机制
nfs-client-provisioner:
四、调度管理
3.1概念
案例：自定义调度器
基于shell自定义：
3.2特点
3.3亲和性
生产上为了保证应用的高可用性，需要将同一应用的不同pod分散在不同的宿主机上，以防宿主机出现宕机等情况导致pod重建，影响到业务的连续性。要想实现这样的效果，需要用到k8s自带的pod亲和性和反亲和性特性。
Pod 的亲和性与反亲和性有两种类型：
yaml
requiredDuringSchedulingIgnoredDuringExecution ##一定满足
preferredDuringSchedulingIgnoredDuringExecution ##尽量满足**podAffinity(亲和性)：**pod和pod更倾向腻在一起，把相近的pod结合到相近的位置，如同一区域，同一机架，这样的话pod和pod之间更好通信，比方说有两个机房，这两个机房部署的集群有1000台主机，那么我们希望把nginx和tomcat都部署同一个地方的node节点上，可以提高通信效率；
**podAntiAffinity(反亲和性)：**pod和pod更倾向不腻在一起，如果部署两套程序，那么这两套程序更倾向于反亲和性，这样相互之间不会有影响。
第一个pod随机选则一个节点，做为评判后续的pod能否到达这个pod所在的节点上的运行方式，这就称为pod亲和性；我们怎么判定哪些节点是相同位置的，哪些节点是不同位置的；我们在定义pod亲和性时需要有一个前提，哪些pod在同一个位置，哪些pod不在同一个位置，这个位置是怎么定义的，标准是什么？以节点名称为标准，这个节点名称相同的表示是同一个位置，节点名称不相同的表示不是一个位置。
案例：软策性：
从运行结果来看，他都运行在Node2节点上，说明node2优于node1
硬策略：
状态为pending
满足条件：
验证：满足条件
反亲和性：软策略
反亲和性：硬策略
总结：
3.4容忍和污点
污点：
污点的组成：
我们使用descibe查看详细信息
添加污点：
再次查看：
删除污点：
我们创建10个pod:
master出现节点了.所以说明不是master无法分配节点，而是它本身存在污点
容忍：
我们先把master本身的污点加上：
设置方式：
特殊类型：
3.5固定节点调度
pod.spec.nodename将pod直接调度到指定节点上，跳过scheduler的调度策略，属于强制匹配
为了更方便实验，可以把nodeName改为master节点
及时设置污点，也能分配到master节点
我们也可以通过标签选择器去实现
因为我们没有这个标签，所以容器处于pending状态：
现在我们添加这个标签：
