本文来自 LC3 与京东基础架构部技术总监 鲍永成 先生面对面的沟通，以及下面的文章的总结
京东是如何打造全球最大Kubernetes集群支撑万亿电商交易的
京东对待 Kubernetes 的态度是做减法，简化 Kubernetes 中一些组件，以稳定，简单，方便运维为目标，抽离出了一些基础设施，如 DNS，负载均衡，时钟，存储，日志等功能，运行在容器平台之外
京东内部会将一个集群做的比较大，一般是一个集群一个物理 pod，大概 3000 台机器，也有一个集群管理 3 个 物理 pod，即 9000 - 10000 台机器左右，而一个数据中心中会有多个集群，为什么做大集群，而不做多个小集群，主要还是从人力管理的成本上考虑，集群太多会导致运维困难，但是集群规模大了之后会也会有一些别的问题。
集群的每个节点（64C）上大概能跑 40+ 个 Pod，新的机器（80C）大概能跑 80-90 个Pod
一个数据中心会共享一套基础设施，如 DNS，负载均衡，监控日志系统，文件存储，数据库等。
基本上一个数据中心都是公用一套的基础设施，包含 DNS，LB，日志，监控，文件存储，数据库等
DNS 非常适合容器化，京东自己开发了一套 containerDNS，用来适配 Kubernetes 的 watch，但是会有一个问题就是原来的域名解析是物理机，机器原来就几万台，现在上了容器后，一台物理机就有几十上百的的 container，导致解析数量增长了上百倍，带来一个问题就是抖动和延迟都非常大，就会间接影响业务的 TP 响应，后来京东将域名解析服务改成了 DPDK 的服务，就非常稳定了，可以从监控中看到是一条非常平稳的线。
上游现在的 CoreDNS 也非常好，提供了大量可以拓展的功能，但是性能测试下来不尽如人意，所以目前也在跟 CoreDNS 接洽，希望能将京东做的事情回馈给社区 现在的性能是bind9的19倍，是CoreDNS的60多倍，每秒查询率能冲到800万QBS。
没有细聊，可以参考 contaienrLB 的文章，主要使用了 fullnat，OSPF/BGP，DPDK
应用所有的日志都要写文件，然后在宿主机上有个程序把日志抓出来传到另外一个地方来分析查询
容器中 stdout 的日志只保留前 4K，不能将所有的日志都写到 stdout 中