QoS是 Quality of Service 的缩写，即服务质量。为了实现资源被有效调度和分配的同时提高资源利用率，kubernetes针对不同服务质量的预期，通过 QoS（Quality of Service）来对 pod 进行服务质量管理。对于一个 pod 来说，服务质量体现在两个具体的指标：CPU 和内存。当节点上内存资源紧张时，kubernetes 会根据预先设置的不同 QoS 类别进行相应处理。
QoS 主要分为Guaranteed、Burstable 和 Best-Effort三类，优先级从高到低。
对于绑定 CPU 和具有相对可预测性的工作负载（例如，用来处理请求的 Web 服务）来说，这是一个很好的 QoS 等级。属于该级别的pod有以下两种：
一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们内部的一些服务 gitlab 之类的也是跑在Kubernetes集群上的，我们就不希望对外的一些服务和内部的服务跑在同一个节点上了，害怕内部服务对外部的服务产生影响；但是有的时候我们的服务之间交流比较频繁，又希望能够将这两个服务的 Pod 调度到同一个的节点上。这就需要用到 Kubernetes 里面的一个概念：亲和性和反亲和性。
亲和性有分成节点亲和性(nodeAffinity)和 Pod 亲和性(podAffinity)。
在了解亲和性之前，我们先来了解一个非常常用的调度方式：nodeSelector。我们知道label是kubernetes中一个非常重要的概念，用户可以非常灵活的利用 label 来管理集群中的资源，比如最常见的一个就是 service 通过匹配 label 去匹配 Pod 资源，而 Pod 的调度也可以根据节点的 label 来进行调度。
我们可以通过下面的命令查看我们的 node 的 label：1
2
3
4
5$ kubectl get nodes --show-labels
NAME STATUS ROLES AGE VERSION LABELS
master Ready master 147d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/hostname=master,node-role.kubernetes.io/master=
node02 Ready <none> 67d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,course=k8s,kubernetes.io/hostname=node02
node03 Ready <none> 127d v1.10.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,jnlp=haimaxy,kubernetes.io/hostname=node03
现在我们先给节点node02增加一个com=youdianzhishi的标签，命令如下：1
2$ kubectl label nodes node02 com=youdianzhishi
node "node02" labeled
负载均衡问题
apiserver 需要有回环路访问，简单说就是自己给自己发请求）为了解决kubernets apiserver高可用问题，故用以下方式来解决：
| IP | Hostname | 备注 |
|---|---|---|
| 172.19.170.183 | master-1 | 安装keepalived + haproxy |
| 172.19.170.184 | master-2 | 安装keepalived + haproxy |
| 172.19.170.185 | master-3 | 安装keepalived + haproxy |
| 172.19.170.186 | node-1 | 无 |
| 172.19.170.187 | node-2 | 无 |
| 172.19.170.100 | vip | 申请阿里云的SLB获取到 |
1 | cat <<EOF >> /etc/hosts |
1 | ssh-keygen -t rsa |
kube-scheduler是 kubernetes 系统的核心组件之一，主要负责整个集群资源的调度功能，根据特定的调度算法和策略，将 Pod 调度到最优的工作节点上面去，从而更加合理、更加充分的利用集群的资源，这也是我们选择使用 kubernetes 一个非常重要的理由。如果一门新的技术不能帮助企业节约成本、提供效率，我相信是很难推进的。
默认情况下，kube-scheduler 提供的默认调度器能够满足我们绝大多数的要求，我们前面和大家接触的示例也基本上用的默认的策略，都可以保证我们的 Pod 可以被分配到资源充足的节点上运行。但是在实际的线上项目中，可能我们自己会比 kubernetes 更加了解我们自己的应用，比如我们希望一个 Pod 只能运行在特定的几个节点上，或者这几个节点只能用来运行特定类型的应用，这就需要我们的调度器能够可控。
kube-scheduler 是 kubernetes 的调度器，它的主要作用就是根据特定的调度算法和调度策略将 Pod 调度到合适的 Node 节点上去，是一个独立的二进制程序，启动之后会一直监听 API Server，获取到 PodSpec.NodeName 为空的 Pod，对每个 Pod 都会创建一个 binding。
| IP | Hostname | 备注 |
|---|---|---|
| 172.19.170.183 | master-1 | 私有云安装keepalived + haproxy + etcd |
| 172.19.170.184 | master-2 | 私有云安装keepalived + haproxy + etcd |
| 172.19.170.185 | master-3 | 私有云安装keepalived + haproxy + etcd |
| 172.19.170.186 | node-1 | 无 |
| 172.19.170.187 | node-2 | 无 |
| 172.19.170.100 | vip | 私有云使用keepalive+haproxy搭建，公有云使用内部负载均衡器 |
1 | cat <<EOF >> /etc/hosts |
1 | ssh-keygen -t rsa |