小白成长之路-k8s原理（二）

---

一、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 的亲和性与反亲和性有两种类型：

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状态：

现在我们添加这个标签：