啊啊
您还未设置简介,点击设置!3
您还未设置简介,点击设置!3
您还未设置简介,点击设置!3
您还未设置简介,点击设置!3
advertised.listeners cannot contain any of controller.listener.names
翻译：
adverted.listeners 不能包含任何 controller.listener.names
controller.listener.names的网口不能与外部的adverted.listeners一样，所以你需要删除advertised.listeners的advertised.listeners=PLAINTEXT://172.21.0.1:9092。
参数值必须为listeners中定义的某个listener或者对应name的listener在listeners中的定义使用了0.0.0.0作为host，在advertised.listeners中可以指定某个网卡ip。
所以，你需要改成
listeners=PLAINTEXT://172.21.0.1:9091,INTERNAL://172.21.0.1:9092
advertised.listeners=INTERNAL://172.21.0.1:9091
listener.security.protocol.map=INTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT
inter.broker.listener.name must be a listener name defined in advertised.listeners. The valid options based on currently configured listeners are
inter.broker.listener.name 必须是 adverted.listeners 中定义的 listeners 名称。基于当前配置的listeners的有效选项
你需要内部broker之间指定一个网口进行内部交互，配置inter.broker.listener.name，如：
listeners=PLAINTEXT://172.21.0.1:9092,PLAINTEXT1://172.21.0.1:9091
advertised.listeners=PLAINTEXT1://172.21.0.1:9091
listener.security.protocol.map=PLAINTEXT1:PLAINTEXT,PLAINTEXT:PLAINTEXT
controller.listener.names=PLAINTEXT
inter.broker.listener.name=PLAINTEXT1
令人惊讶的是，没有答案指向最简单的跨浏览器解决方案
要找到与昨天完全相同的时间。
var yesterday = new Date(Date.now() - 86400000); // that is: 24 * 60 * 60 * 1000
如果你不介意潜在的日历怪异的不精确性（比如夏令时），这个方法很好用，否则我建议使用 https://moment.github.io/luxon/
令人惊讶的是，没有答案指向最简单的跨浏览器解决方案
要找到与昨天完全相同的时间。
var yesterday = new Date(Date.now() - 86400000); // that is: 24 * 60 * 60 * 1000
如果你不介意潜在的日历怪异的不精确性（比如夏令时），这个方法很好用，否则我建议使用 https://moment.github.io/luxon/
$ kubectl wait --for=condition=complete --timeout=600s job/myjob
1、客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML。
2、api-server 处理用户请求，将 pod 信息存储至 etcd 中。
3、kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出。
4、选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中。
5、随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器。
1、客户端提交创建请求，可以通过 api-server 提供的 restful 接口，或者是通过 kubectl 命令行工具，支持的数据类型包括 JSON 和 YAML。
2、api-server 处理用户请求，将 pod 信息存储至 etcd 中。
3、kube-scheduler 通过 api-server 提供的接口监控到未绑定的 pod，尝试为 pod 分配 node 节点，主要分为两个阶段，预选阶段和优选阶段，其中预选阶段是遍历所有的 node 节点，根据策略筛选出候选节点，而优选阶段是在第一步的基础上，为每一个候选节点进行打分，分数最高者胜出。
4、选择分数最高的节点，进行 pod binding 操作，并将结果存储至 etcd 中。
5、随后目标节点的 kubelet 进程通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件，然后从 etcd 获取 pod 清单，下载镜像并启动容器。
kubectl 向 api server 发起一个create pod 请求
apiserver接收到pod创建请求后，不会去直接创建pod，而是生成一个包含创建信息的yaml。
apiserver 将刚才的yaml信息写入etcd数据库。到此为止仅仅是在etcd中添加了一条记录， 还没有任何的实质性进展。
scheduler 查看 k8s api ，类似于通知机制。
首先判断：pod.spec.Node == null?
若为null，表示这个Pod请求是新来的，需要创建；因此先进行调度计算，找到最闲的node。
然后将信息在etcd数据库中更新分配结果：pod.spec.Node = nodeA (设置一个具体的节点)
ps:同样上述操作的各种信息也要写到etcd数据库中中。
kubelet 通过监测etcd数据库(即不停地看etcd中的记录)，发现api server 中有了个新的Node；
如果这条记录中的Node与自己的编号相同(即这个Pod由scheduler分配给自己了)；
则调用node中的docker api，创建container。
从容器的角度出发，限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。
在kubernetes中，每个Pod都有个QoS标记，QoS的英文全称为 Quality of Service，中文名为服务质量，它取决于用户对服务质量的预期，也就是期望的服务质量。对于Pod来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是内存。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据Pod具有的不同QoS标记，采取不同调度和驱逐策略。
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：
如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：
1、当 NODE节点上内存资源不够的时候，QoS级别是BestEffort的Pod会最先被kill掉；当NODE节点上内存资源充足的时候，QoS级别是BestEffort的POD可以使用NODE节点上剩余的所有内存资源。
2、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort的Pod已经都被kill掉了，那么会查找QoS级别是Burstable的POD，并且这些POD使用的内存已经超出了requests设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。
3、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort和Burstable的Ppod都已经被kill掉了，那么会查找QoS级别是Guaranteed的POD，并且这些POD使用的内存已经超出了limits设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。
详细参考：配置Pod的服务质量（QoS）
