问题1.修复容器中的top指令和/proc系统的信息呢?
我们可以使用lxcfs方案,将宿主机的/var/lib/lxcfs/proc文件挂载到了Docker容器下的/proc目录,使得容器进程读取对应的文件的时候,会从容器的Cgroups中读取到正确的资源限制,返回正确的top命令值
问题2,如果容器的rootfs是以只读的方式挂载的,如何在容器中修改Ubuntu镜像的内容呢?
我们修改一个镜像中的文件时候,联合文件系统首先从上到下在各个层中查找有没有目标文件,如果找到,就将这个文件复制到可读写层进行修改,修改的结果会屏蔽下层的文件,然后保存,后续的使用过程中,上层的文件会覆盖下层的文件,这种复制改写的操作被称为copy-on-write
问题3,在查看Docker容器的Namespace的时候,是否注意到有一个叫做cgroup的Namesapce呢?其作用呢?
Linux内核后来支持了一个Namesapce名为Cgroup Namespace,我们可以在正常的情况下,查看/proc/$PID/cgroup,每个进程都有自己的Cgroup Namesapce,就可以获得一个自己的Cgroups文件目录视图,就可以被Namesapce进行隔离了
问题4,Kubernets的控制器模式,和事件驱动有啥区别和联系呢?
对于控制器来说,被监听的对象是一个持续的对象,如果有一个状态,那么这个状态应该是具有持久性的,无论何时去查询,都是这个状态
对于事件驱动来说,如果是ADD时候发出的一个事件,那么控制器错过了这个事件,就没办法知道这个事件了
问题5:如果一个新节点加入集群可以同步数据从老节点上,这样,是不是有必要将这个节点Pod和其PV一对一的绑定呢?
应该是不需要,因为保存存储并不依赖于DNS名字保证拓补状态的应用,可以使用Operator实现,不一定需要保证PV一对一
问题6,在Kubernetes v1.11之前,DaemonSet管理的Pod的调度过程,之前是由DaemonSet Controller完成而不是调度完成的,其中原因呢?
因为之前的调度器并不是很完善,缺乏优先级和抢占机制,所以没法保证DaemonSet,部署系统级,高优先级的DaemonSet一定成功,所以可能影响到集群的部署了
问题7,在Operator的实现过程中,我们用到了CRD,CRD有啥不使用的场景吗,有啥性能瓶颈的原因?
CRD 并不支持protobuf,当API Object 的数量大于1K,或者单个对象大于1KB,高频请求时候,CRD响应就会出现问题
而且业务的需求并不能用CRD进行建模的时候,需要等待API最终返回,或者需要检查API的返回值,也是不能用CRD的,同时,当需要完整的APIServer而不只是API对象的时候,使用API Aggregator.
问题8,需要使用延迟绑定,Local Persistent Volume目前还不能支持Dynamic Provisioning,为何延迟绑定和Dynamic Provisioning有冲突吗?为何延迟绑定和Dynamic Provisiong有冲突呢?
延迟绑定和Volume Bind的时机,推迟到了第一个使用到该Volume的Pod到达调度器的时候,对于Dynamic Provisiong来说,管理在Volume的控制循环中PVC创建PV然后绑定起来,这个时间点和Pod调度的时间点是不相关的
问题9,什么时候使用FlexVolume,什么时候使用CSI,CSI和FlexVolume的最大区别,在于CSI可以实现Provision阶段,对于不需要Provision的情况,比如远程存储服务总是实现准备好或者准备起来比较简单的情况,考虑使用到FlexVolume,生产环境下,优先推荐CSI的方案
问题10:Flannel通过隧道机制,实现了容器之间三层网络的联通,那么能否保证二层网络的联通呢?
Kubernetes并不会知道你如何打通的网络,其只关心能否将封装的IP包发送到目的地,具体的实现并不Care
问题11:能否总结一下三层网络方案和隧道模式的异同?各自优缺点?
无论使用那种隧道进行封装,都会进行解封包这个操作,这就会带来一定的性能损耗,而三层网络方案可以避免这个过程,提升整体的性能
隧道模式的优点,依赖的底层过程比较直白,内核实现也比较成熟和稳定,但是三层网络方案,维护成本比较高,容易遇到路由规则分发和设置出现问题的情况,容器数量多的时候,路由规则会比较复杂
最终实现哪个方案,看自己的需求
问题12:为何宿主机进入了MemoryPressure或者DiskPressure状态后,新的Pod就不会调到这个宿主机上呢?
在Kubernetes里,有一个名为Taint Nodes by Condition的机制,这个Node被发现某种状态的时候,就会利用Controller给Node加上Taint,阻止新的Pod调用到这个宿主机上
问题13:Kubernetes默认调用器和Mesos的两级调用器有何异同
Mesos的两级调度器,就是自己充当0层调度器,负责统一管理整个集群的资源,将可用资源当做Resourece Offer的方式暴露出去,上层的大数据框架有自己的调度模式,这样,方便上层的大数据框架去自己接入,自己调度,接入Mesos中
而且,这样,使得Mesos本身能够统一地对上层框架进行资源分配,资源利用率和调度效率就能够很好的保证了
这样,Mesos比起Kubernetes而说,更加方便接入,但是使用起来,也比Kubernetes更加难以操作
问题14:整个集群发生影响调度结果的变化,调度器会执行一个称为MoveAllToActiveQueue操作,将失败的Pod从unscheduelableQ移动到activeQ中,这是为何?
因为默认调度器在调度失败后,就会将这个Pod放在unschedulableQ中,unschedulableQ的Pod不会出现在下个调度周期中的,这个集群本身发生变化的时候,Pod就会称为可调度的,这时候调度器就会将其移动到activeQ中,获得了下一次调度的机会
原本调度成功的Pod被更新后,可能触发unschedulableQ中有affinity或者anti-affinity关系的Pod就会变成可调度的,也需要重新做人的机会
问题15:Device Plugin为容器分配的GPU信息,是通过CRI哪个接口传递给dockershim的,最后交给Docker API呢?
既然是Device的信息,那么应该是CreateContainerRequest接口,这个接口中有Devices的描述
问题16:安全容器的意义不止于安全,宿主机的Linux内核是3.6,但是容器运行要求Linux内核是4.0,这样是否可以将应用运行在一个Kate Containers里呢?gVisor是否能提供这种能力呢?
答案是不能,因为gVisor是将其交给了宿主机的系统来执行操作的,但是gVisor为代表的用户态Kernel方案是安全容器的未来,只是现在仍不够完善
问题17:日志输出给stdout和stderr,是否有什么隐患和问题,如何处理呢?
因为所有的日志都是经过DockerDaemon的处理才会到宿主机磁盘上,宿主机,没法以容器作为单位进行日志的搜集,这样,还是考虑通过宿主机的Agent进行日志的处理和手机
问题18:Kubernetes和OpenStack社区的不同有哪些?各有哪些优缺点?
OpenStack社区比较强调民主化,但是导致了很多低价值或者周边型的项目不断冲击OpenStack社区,降低了社区的含金量,而且拖慢了比如Cinder,Neutron等核心项目的演进步伐和方向
但是CNCF基金会成功的帮助了Kubernetes社区分流了低价值和周边项目的干扰,让其专注于主线的严谨