replicationcontroller 和 deployment 的比较

RC 升级需要yaml 文件 ， deployment 修改配置文件可以实时生效
导致服务中断               不会中断服务访问
直接控制pod                基于RS来控制pod

一、deployment——回滚、更新

K8S集群—一切皆资源

kubectl : 控制K8S集群的命令行工具（tab键）

kubectl  [command] [type] [name] [flags]

command: 子命令，如 get create delete describe

type：资源类型，可以为单数、复数、缩写

name：资源名称（省略则显示所有资源）

flags：指定可选标志，或其他参数

 

 

 yaml 文件格式（带控制器的pod）

控制器功能

kubectl get pods -o wide --show-labels   #查看包含显示标签的详细信息

动态调整集群个数进行扩容

kubectl  scale  deployments  apache  --replicas=3    

滚动更新（默认）

kubectl  edit  deployment  apache  （apache是资源文件中定义的名字）

       找到 container 那一栏，将 apache 换成 nginx

查看后，进行访问发现已更新


回滚历史版本

kubectl  rollout  history  deployment apache    #查看历史版本

kubectl  rollout  undo  deployment apache  --to-revision=1   #回滚历史版本1

 

二、daemonset

在每一个硬件node 节点运行一个 pod，当节点从集群移除时，pod 也会被回收。

副本数量由硬件节点决定，由几个节点就有几个 pod，删除pod后还是会重建。

直接管理 pod，只有两级

 

kubectl  apply  -f  mynginx.yaml

kubectl  get  pods -o wide

---

通常情况下，Pod分配到哪些Node是不需要管理员操心的，这个过程会由scheduler自动实现，因为调度程序会自动进行合理的调度（如通过一系列的评分机制将 pods 合理分配到最优节点上，而不会将 pod 分配在没有足够资源的节点上等）。

但有时，我们需要指定一些调度的限制，例如将两个通信比较频繁的不同服务 pod 调度到同一个可用域等等。

labels 在 K8s 中是一个很重要的概念，作为一个标识，Service、Deployments 和 Pods 之间的关联都是通过 label 来实现的。而每个节点也都拥有 label ，通过设置 label 相关的策略可以使得 pods 关联到对应 label 的节点上。

影响pod调度策略：

（1）nodename：调度到指定pod，无视污点。

（2）nodeselector：节点选择器，调度到匹配标签的node节点，但会受到污点的影响。

（3）resources：资源限制

（4）污点容忍度

（5）污点策略（只对pod生效）—黑名单

NoSchedule——不调度——不吃鸡蛋，宁愿饿着

preferNoSchedule——尽量不调度——尽量不吃鸡蛋

Noexecute——驱逐——这鸡蛋不能吃，吃了就得死

设置策略的时候，必须是键值对+策略的形式

污点标签可以理解为黑名单（标签调度为白名单，注意黑白名单的相互影响），对已经做好在运行的容器不生效。

要使其生效，需要删除旧的容器重新运行,也就是部署前生效。（驱逐策略除外，任何时候有效）

设置策略
kubctl  taint  node node-0001  key=value：NoSchedule  （比如 k1=v1,键值）

kuebctl delete -f  nginx.yaml

kubectl apply -f nginx.yaml

kubectl get pods -o wide

删除策略
kubctl  taint  node node-0001  key-

查看策略
kubectl  describe  nodes | grep -P  "^Taints"

亲和性

亲和性调度可以分成软策略和硬策略两种方式:

软策略：如果没有满足调度要求的节点的话，pod 就会忽略这条规则，继续调度，满足条件最好，没有的话也无所谓了的策略

硬策略：如果没有满足条件的节点的话，就不断重试直到满足条件为止，就是你必须满足我的要求，不然我就不干的策略。

nodeAffinity（节点亲和性）：用来控制 pod 要部署在哪些主机上，以及不能部署在哪些主机上的

podAffinity（pod 亲和性）：解决 pod 可以和哪些 pod 部署在同一个拓扑域中的问题，处理的 pod 与 pod 之间的关系，

比如一个 pod 在一个节点上了，那么另一个也得在这个节点，或者你这个 pod 在节点上了，那么我就不想和你待在同一个节点上。

job 控制器—管理有限生命周期的 pod，单任务控制器，不需要标签

---

Cronjob —计划任务控制器，三级控制

---

三、Service—用户访问这个服务，当pod坏了的时候，自动跟踪新建的pod，跟踪容器的标签；负载均衡

 

ingress：提供暴露应用的入口的方法，可以实现七层服务（service是四层服务）

ingress controller：根据 ingress 生成具体的路由规划，对 pod 实现负载均衡