当 Kubernetes 中 Node 节点出现状态异常的情况下，节点上的 Pod 会被重新调度到其他节点上去，但是有的时候我们会发现节点 Down 掉以后，Pod 并不会立即触发重新调度，这实际上就是和 Kubelet 的状态更新机制密切相关的，Kubernetes 提供了一些参数配置来触发重新调度到node时间，下面我们来分析下 Kubelet 状态更新的基本流程。 默认情况下,正常的行

Kubernetes的管理层服务包括kube-scheduler和kube-controller-manager。kube-scheduer和kube-controller-manager使用一主多从的高可用方案，在同一时刻只允许一个服务处理具体的任务。Kubernetes中实现了一套简单的选主逻辑，依赖Etcd实现scheduler和controller-manager的选主功能。 如果s

一、TLS bootstrapping 简介 当集群开启了 TLS 认证后，每个节点的 kubelet 组件都要使用由 apiserver 使用的 CA 签发的有效证书才能与 apiserver 通讯；此时如果节点多起来，为每个节点单独签署证书将是一件非常繁琐的事情；TLS bootstrapping 功能就是让 kubelet 先使用一个预定的低权限用户连接到 apiserver，然后向 api

首先我们要理解：  所有的监控的agent底层最终都是查询的/proc和/sys里的信息推送server端,因为Prometheus Operator收集宿主机信息方面也想用pod跑,会面临到问题  常见的zabbix_agent默认读取fs的/proc和/sys,但容器跑agent会导

1、资源指标和资源监控 一个集群系统管理离不开监控，同样的Kubernetes也需要根据数据指标来采集相关数据，从而完成对集群系统的监控状况进行监测。这些指标总体上分为两个组成：监控集群本身和监控Pod对象，通常一个集群的衡量性指标包括以下几个部分： 节点资源状态：主要包括网络带宽、磁盘空间、CPU和内存使用率 节点的数量：即时性了解集群的可用节点数量可以为用户计算服务器使用的费用支出提供参考

Metrics Server 是实现了 Metrics API 的元件,其目标是取代 Heapster 作位 Pod 与 Node 提供资源的 Usage metrics,该元件会从每个 Kubernetes 节点上的 Kubelet 所公开的 Summary API 即10250端口中收集 Metrics。并将收集的信息存储在内存中，所以当通过kubectl top不能查看资源数据的历史情况，

资源类型 CPU 和 memory 都是 资源类型。资源类型具有基本单位。CPU 的单位是 core，memory 的单位是 byte。这些都统称为计算资源。 CPU含义： CPU 资源的限制和请求以cpu为单位。Kubernetes 中的一个 cpu 等于一个core，就是逻辑CPU。1颗逻辑CPU等于1000millicores。500m=0.5颗cpu。 内存含义： 内存的限制

Scheduler  当用户请求向API server创建新的Pod时，API server检查授权、权限等没有任何问题的话，他会把这个请求交由Scheduler，由Scheduler它会检查所有符合该Pod要求的Nodelist，为Pod安排一个落脚点（Node）,选定Node完成后会把选择结果返回给API server，并将选定信息写入etcd中。接下来AP

kubernetes网络通信 容器间的通信 pod内的容器通信（lo） Pod之间的通信 pod IP <—–> pod IP（flannel、calico） Pod与Service之间的通信 podIP <—–> ClusterIP（iptables、ipvs） Service与集群外部的通信 ClusterIP <—–> 集群外部 CNI插

创建证书 由于自动生成的证书 chrome 不允许访问，所以使用自己生成的证书。 12345[root@master-1 ~]# mkdir certs[root@master-1 ~]# (umask 077;openssl genrsa -out dashboard.key 2048)[root@master-1 ~]# openssl req -nodes -newkey rsa:2048