Deployment
简述 Kubernetes Deployment 升级过程？
初始创建Deployment时，系统创建了一个ReplicaSet，并按用户的需求创建了对应数量的Pod副本。
当更新Deployment时，系统创建了一个新的ReplicaSet，并将其副本数量扩展到1，然后将旧ReplicaSet缩减1。
之后，系统继续按照相同的更新策略对新旧两个ReplicaSet进行逐个调整。
最后，新的ReplicaSet运行了对应个新版本Pod副本，旧的ReplicaSet副本数量则缩减为0。
简述 Kubernetes Deployment 升级策略？
在Deployment的定义中，可以通过spec.strategy指定Pod更新的策略，目前支持两种策略：Recreate（重建）和 RollingUpdate（滚动更新），默认值为RollingUpdate。
Recreate：设置spec.strategy.type=Recreate，表示Deployment在更新Pod时，会先杀掉所有正在运行的Pod，然后创建新的Pod。RollingUpdate：设置spec.strategy.type=RollingUpdate，表示Deployment会以滚动更新的方式来逐个更新Pod。
同时，可以通过设置spec.strategy.rollingUpdate下的两个参数（maxUnavailable和maxSurge）来控制滚动更新的过程。
升级策略为滚动更新，如何控制滚动更新过程？
可以通过下面的命令查看到更新时可以控制的参数：
kubectl explain deploy.spec.strategy.rollingUpdate
- maxSurge： 此参数控制滚动更新过程，副本总数超过预期pod数量的上限。可以是百分比，也可以是具体的值，默认为1。（上述参数的作用就是在更新过程中，值若为3，那么不管三七二一，先运行三个pod，用于替换旧的pod，以此类推）
- maxUnavailable： 此参数为控制滚动更新过程中，不可用的Pod的数量。（这个值和上面的值没有任何关系，举个例子：我有十个pod，但是在更新的过程中，我允许这十个pod中最多有三个不可用，那么就将这个参数的值设置为3，在更新的过程中，只要不可用的pod数量小于或等于3，那么更新过程就不会停止）。
DaemonSet
DaemonSet资源对象的特性？
DaemonSet这种资源对象会在每个k8s集群中的节点上运行，并且每个节点只能运行一个pod，这是它和deployment资源对象的最大也是唯一的区别。
所以，在其yaml文件中，不支持定义replicas，除此之外，与Deployment、RS等资源对象的写法相同。
它的一般使用场景如下：
- 做每个节点的日志收集工作；
- 监控每个节点的的运行状态；
Secret
简述 Kubernetes Secret 的作用 ？
Secret 对象：主要作用是保管私密数据，比如：密码、OAuth Tokens、SSH Keys等信息。
将这些私密信息放在 Secret 对象中比直接放在 Pod 或 Docker 镜像中更安全，也更便于使用和分发。
简述 Kubernetes Secret 有哪些使用方式？
创建完secret之后，可通过如下三种方式使用：
- 在创建Pod时，通过为Pod指定
Service Account来自动使用该Secret。 - 通过挂载该Secret到Pod来使用它。
- 在Docker镜像下载时使用，通过指定Pod的
spc.ImagePullSecrets来引用它。
Pod
简述Kubernetes Pod 如何实现对节点的资源控制？
Kubernetes集群里的节点提供的资源主要是计算资源，计算资源是可计量的能被申请、分配和使用的基础资源。
当前Kubernetes集群中的计算资源主要包括CPU、GPU及Memory。
CPU与Memory是被Pod使用的，因此在配置Pod时可以通过参数 CPU Request 及 Memory Request 为其中的每个容器指定所需使用的CPU与Memory量，Kubernetes 会根据 Request 的值去查找有足够资源的 Node 来调度此 Pod。
通常，一个程序所使用的CPU与Memory是一个动态的量，确切地说，是一个范围，跟它的负载密切相关：负载增加时，CPU和Memory的使用量也会增加。
简述Kubernetes Requests和Limits如何影响Pod的调度？
当一个Pod创建成功时，Kubernetes调度器（Scheduler）会为该Pod选择一个节点来执行。
对于每种计算资源（CPU和Memory）而言，每个节点都有一个能用于运行Pod的最大容量值。
调度器在调度时，首先要确保调度后该节点上所有Pod的CPU和内存的Requests总和，不超过该节点能提供给Pod使用的CPU和Memory的最大容量值。
Kubernetes 集群外流量怎么访问Pod？
可以通过Service的NodePort方式访问，会在所有节点监听同一个端口，比如：30000，访问节点的流量会被重定向到对应的Service上面。
简述 Kubernetes 初始化容器（init container）？
init container的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。
当所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器。
其他
简述Kubernetes Metric Service？
在Kubernetes从1.10版本后采用Metrics Server作为默认的性能数据采集和监控，主要用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标。
对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成。
Ingress
浅述 Ingress
Ingress 实际上就是 Kubernetes 对“反向代理”的抽象。
目前，Ingress 只能工作在七层，而 Service 只能工作在四层。四层代理有个缺陷就是他只是工作在tcp/ip协议栈。如果外部请求是HTTPS的请求，Service是无法调度的。因此，当你想要在 Kubernetes 里为应用进行 TLS 配置等 HTTP 相关的操作时，都必须通过 Ingress 来进行。
当然，正如同很多负载均衡项目可以同时提供七层和四层代理一样，将来 Ingress 的进化中，也会加入四层代理的能力。这样，一个比较完善的“反向代理”机制就比较成熟了。而 Kubernetes 提出 Ingress 概念的原因其实也非常容易理解，有了 Ingress 这个抽象，用户就可以根据自己的需求来自由选择 Ingress Controller。
比如，如果你的应用对代理服务的中断非常敏感，那么你就应该考虑选择类似于 Traefik 这样支持“热加载”的 Ingress Controller 实现。
Ingress Controller不是Controller Manager中的一部分，他只是一个或一组独立的Pod资源，他通常就是一个运行着有七层代理能力或调度能力的应用，比如：NGINX、HAproxy、Traefik、Envoy等
