k8s权威指南-从xx到oo的实践全接触

基本概念与术语

集群的2种管理角色：master和node

master

集群的控制节点，负责整个集群的管理与控制，运行着关键进程：

1，k8s api server： 提供了HTTP Rest 接口的关键服务进程，是所有资源的增删改查的入口，是集群控制的入口进程。

2，k8s controller manager k8s所有资源对象的自动化控制中心

3，k8s scheduler 负责资源调度（pod调度）的进程，

还需要启动一个etcd服务，负责所有资源对象的保存

node

k8s集群中工作负载节点，宕机后其上的工作负载会转移至其他节点。运形的进程：

1，kubectl 负责pod对应容器的创建起停，与master 节点协作，

2，kubectl-proxy 实现k8s service 的通信与负载均衡

3，docker 引擎。本机容器的创建管理

node 可以动态的加入集群，默认情况下kubectl 会向master 注册自己。

kubectl会定时向master 节点汇报自身情况，，master 获取每个节点的资源情况。node 无法上报信息，master判定为失联，node 的状态被标记为不可用，not ready ,随后master 触发工作负载大转移。

命令

kubectl  get  nodes
k  describe   node   xxxx  #节点信息查看

pod

每个pod 有一个特殊的容器，根容器pause容器，pause 容器对应的镜像属于屁平台的一部分。

构建pod 原因：

以pause 容器作为pod的根容器，以他的状态作为整个容器组的状态

pod里的多个业务容器共享pause 容器的ip ，共享pause容器挂载的volume

每个pod 独占一个ip ， podIp 一个po里的多个容器共享podip， k8s 内底层网络支持集群内任意2个pod 之间的tcp/ip 直接通信， 这采用虚拟二层网络技术实现， flannel openvswitch .

普通pod 和 静态pod static pod (不存放于etcd,,而在具体的某个node 上的一个具体文件中，并只在此node 启动，)

普通node一旦被创建，会被放入etcd 中，随后被ks master调度到某个具体的node上进行绑定，随后pod 被node上的kubectl 进程实例化成一组容器启动。

当pod 中的某个容器停止后，k8s 自动检测到并重新启动，这个pod （重启pod 里的所有容器），如果node 宕机，则会将这个node 上的所有pod调度到其他节点上去

event 事件的记录

资源限额

1个计算资源进行配额限定需要设定以下两个参数：

Requests ：该资源的最小申请量，系统必须满足要求

Limits ：该资源最大允许使用的量，不能被突破，当容器试图使用超过这个量的资源时，可能会被 Kubernetes Kill 并重启

通常把 Request设置为一个比较小的数值，符合容器平时的工作负载情况下的资源需求，把Limit设置为峰值负载情况下资源占用的最大量。

标签

Label 可以附加到各种资源对象上，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上去，

Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。

常用标签：

版本标签：＂release ”：” stable ”，”release ”：”can ”．．．

环境标签：

架构标签：

分区标签：

质量管理标签：

两种 Label Selector 的表达式：

基于等式的（ Equality-based ）：采用“等式类”的表达式匹配标签

name = redis-slave ：匹配所有具有标签 name edis-slave 的资源对象

env != production ：匹配所有不具有标签 env=production 的资源对象

基于集合的（Set-based ）

name in (redis-master，redis-slave ）：匹配所有具有标签 name=redis-master 或者 name=redis-slave 的资源对象

name not in ( php－frontend ）：匹配所有不具有标签 name=php－frontend 的资源对象。

多个selector表达式的组合实现复杂条件选择

多个表达式之间用“，”进行分隔即可，几个条件之间是“AND ”的关系：

name=redis-slave,env!=production

name notin (php-fr ntend),env!=production

新出现的管理对象如 Deplo nent ReplicaSet Daemon Set Job 可以在 Se lector 中使用基于集合的筛选条件定义

selector:

matchLabels :

app: myweb

matchExpressions:

- {key: tier， operator：In , values: [frontend)}

- {key: environment , operator : NotIn , values: [dev)}

matchlabels 和matchExpressions 为and 关系

label selector 使用场景：

kube-controller 进程通过资源对象RC上定义的 Label Selector 来筛选要监控的 Pod 副本的数量，从而实现 Pod 副本的数量始终符合预期设定的全自动控制流程

kube-proxy 进程通过Service的Label Selector来选择对应的Pod，自动建立起每个Service 到对应 Pod 的请求转发路由表，从而实现 Service 的智能负载均衡机制

通过对某些 Node 定义特定的 Label ，并且在 Pod 定义文件中使用 NodeSelector 这种标签调度策略， kube heduler 进程可以实现 Pod “定向调度”的特性

RC

Replication Controller

它其实是定义了一个期望的场景，即声明某种 Pod 的副本数量在任意时刻都符合某个预期值，定义如下内容：

Pod 待的副本数（ replicas ）

用于筛选目标 Pod 的Label Selector

当Pod 的副本数量小于预期数量时，用于创建新的Pod 的Pod 模板（template）

Master 节点上的 Controller Manager 定期巡检系统中存活的pod 数量，并确保目标pod 实例的数量刚好等于rc 的期望值。

动态调整

k scale rc redis-slave --replicas=3

注意：删除RC 并不会影响通过该RC 已经创建好的pod,为了删除所有pod，可设置replicas的值为0 ，然后更新该RC

k8s 提供了stop 和delete 一次性删除RC 和RC控制的全部pod