解释ConfigMap的作用。

ConfigMap是K8s的一种机制，是明文键值，通常用于配置文件等无需加密的场景，可以将配置数据注入到应用的Pod内部，ConfigMap中保存的数据不可超过1MiB，如果超出此限制，可以使用挂载存储卷或者使用独立的数据库或者服务器，ConfigMap允许将配置清单与镜像内容分离，以保持容器化的应用程序的可移植性。

Secret和ConfigMap相比较有哪些优点。

Secret是包含少量敏感数据的对象，使用Secret意味着不需要在应用程序代码中包含机密数据，Secret可以独立于使用它的Pod创建，所以相对与ConfigMap数据被泄露的风险较小，K8s以及集群中允许的应用还可以对Secret采取额外的预防措施。

解释ResourceQuota的作用。

ResourceQuota：资源配额，可以对每个命名空间中的资源消耗总量提供限制，可以限制某种类型对象的总的数目上限，也可以限制命名空间中的Pod可以使用的计算资源的总上限，如果命名空间下的计算资源的配额被启用，则用户必须为这些资源设定请求值和约束值，否则配额系统将拒绝Pod的创建。

解释Service Account的用途。

Service Account：服务账户，是未来方便Pod里面的进程调用K8s API或其它外部服务而设计的，每个namespace都会自动创建一个default service account。Token controller检测service account的创建，并为它创建令牌secret并与APIServer进行交互，创建Pod时，如果没有指定服务账户，Pod会被指定给命名空间中的default服务账户。

详细解释Role和ClusterRole。

基于角色的访问控制是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法，Role总是用来在某个命名空间内设置访问权限，在创建Role时，必须指定该Role所属的命名空间。ClusterRole是一个集群作用域的资源。

什么是K8s的NetworkPolicy？

Pod有两种隔离方式：出口的隔离和入口的隔离，NetworkPolicy是一种以应用为中心的结构，允许设置如何允许Pod与网络上的各类网络“实体”通信。未匹配任何策略的Pod默认拒绝所有访问，NetworkPolicy可以多条策略叠加，满足任一规则即可通行。

详细描述在K8s中如何控制跨Namespace的Pod访问？

核心依靠NetworkPolicy实现跨命名空间流量管控，以标签筛选、网段规则、命名空间选择器限定访问权限，通过namespaceSelector命名空间标签来匹配一组命名空间，对于开放的端口可以允许匹配标签的来源访问，一旦创建了NetworkPolicy，所有未被策略明确允许的流量都会被拒绝。

举例说明K8s中都有哪些常规的维护管理操作。

1.集群节点维护

1).节点的封锁：禁止新Pod调度到该节点，用于停机维护。

2).节点驱逐：清空节点上运行的Pod到其它节点。

3).节点标签/污点管理：调度规则调整、业务节点隔离

2.Pod日常运维

1).查看Pod运行状态、日志排查故障。

2).进入Pod容器内部调试、执行命令。

3).Pod重启、异常Pod删除重建。

4).资源配额、CPU内存使用率监控核查。

3.存储运维

PV/PVC挂载、解绑、存储扩容，存储卷权限、读写故障排查。

4.集群版本与组件维护

kubeadm集群小版本升级、kube-apiserver、kubelet等组件重启排查。

如何升级K8s到新的版本？在升级过程中应该注意哪些事项？

首先要确定升级的版本，禁止Master节点接收新调度，驱逐Master节点上的现有任务，安装指定版本的kubeadm，然后查看可升级的列表并升级集群，然后恢复Master节点的调度能力。

注意逐个节点滚动升级，避免多节点同时下线，驱逐Pod会短暂迁移服务，避开业务高峰期操作，升级前必须要备份etcd、核心配置，预留回滚方案，升级出现异常问题可以退回旧版本。