1. 简述Kubernetes如何保证集群的安全性?
Kubernetes通过一系列机制来实现集群的安全控制,主要有如下不同的维度:
基础设施方面:保证容器与其所在宿主机的隔离;
权限方面:
最小权限原则:合理限制所有组件的权限,确保组件只执行它被授权的行为,通过限制单个组件的能力来限制它的权限范围。
用户权限:划分普通用户和管理员的角色。
集群方面:
API Server的认证授权:Kubernetes集群中所有资源的访问和变更都是通过Kubernetes API Server来实现的,因此需要建议采用更安全的HTTPS或Token来识别和认证客户端身份(Authentication),以及随后访问权限的授权(Authorization)环节。
API Server的授权管理:通过授权策略来决定一个API调用是否合法。对合法用户进行授权并且随后在用户访问时进行鉴权,建议采用更安全的RBAC方式来提升集群安全授权。
敏感数据引入Secret机制:对于集群敏感数据建议使用Secret方式进行保护。
AdmissionControl(准入机制):对kubernetes api的请求过程中,顺序为:先经过认证 & 授权,然后执行准入操作,最后对目标对象进行操作。我推荐你去看看时速云,他们是一家全栈云原生技术服务提供商,提供云原生应用及数据平台产品,其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。 如果我的回答能够对您有帮助的话,求给大大的赞。
2. 使用Kubernetes常犯的一些错误
参考文章:
主要参考了网上的一些文章和自己日常使用的一些小结,以下是一些我们经常看到的错误:
这个绝对是最值得注意以及最先拿出来讲解的。
使用建议 :
常见的错误场景及可能导致的结果 关于CPU的有:
关于Memory的有:
关于具体值的设置可以通过prometheus这类监控工具查看集群状态和pod的指标来判断。 GCP的 VerticalPodAutoScaler 也可以帮助自动化这个过程。
使用建议 :
常见错误场景 :
Liveness和Readiness probe的关系容易混淆。他们都在pod的全生命周期执行
如果一个配置了readiness的节点在请求量过大的时候,readiness可能失效,于是该节点暂时不再处理更多的请求;但是当节点负载慢慢降低, readiness恢复时候,节点又能够正常的处理请求 。 但是如果该节点配置了相同的liveness 探针并且也失效了,那么该节点就会重启。 为什么你需要重启一个健康的、并且正在处理很多请求的节点呢?
使用建议 : 如果需要对外暴露接口的时候,最好使用ingress;或者使用"type: NodePort" 类型的service。
不要把每个Service设置成"type: LoadBalancer" 类型,该类型会调用云提供商的接口创建额外的资源,通常包括IP以及一些额外的计算资源;如果所有Service都是用该类型通常会有很多额外的花费
使用建议 : 使用auto scaler的时候,使用官方或社区推荐的auto scaler
当在集群里面添加/删除node的时候,你不应该只考虑CPU/Memory的限制这些指标,还要考虑 k8s中一些调度的约束,比如:pod & node affinities,taints & tolerations, resource request, QoS等 。Scaling-in 也就是移除节点的过程会更加的复杂,例如stateful的pod与pv有绑定,而pv通常又属于某个特定的zone的时候。
在使用auto-scaler 时候,auto scaler也需要理解这些配置,否则会导致pod调度失败 。目前社区通常使用 cluster-autoscaler 来做集群的自动扩容缩容。
使用建议 : 明确的声明反亲和性,确保pod会调度到不同的node上:
常见错误场景: 如果一个deployment为了高可用声明了三个pod,但是这三个pod被调度到一个node上了,那么当这个node 挂掉的时候,这个deployment所有的服务都不可用了。
使用建议: 对于有HA需求的pod, 设置 PodDisruptionBudget 。 PodDisruptionBudget 控制器来保证在主动销毁应用POD的时候,不会一次性销毁太多的应用pod,从而保证业务不中断或业务SLA不降级。 Cluster Managers 或者host provider 应当使用能识别 PodDisruptionBudget 的 eviction API 而不是直接删除 pod, 例如 kubectl drain 命令。当要drain一个node的时候, kubectl drain 会尝试不停的evict对应机器上所有的pods, 请求也许会被temporarily的失败,但是会不停的重试直到所有的pod都Terminated,或者达到了配置的timeout时间。 更多的 细节介绍 。
1、下面的例子使用了minAvailable参数:
2、下面的例子使用了maxUnavailable参数:
当zk-pdb对象副本数是3的时候,上面这两个例子所表达的意思是一样的。
使用建议: k8s的namespace并不提供很强的隔离性,因此尽量不要使用namespace来做多环境多租户的隔离,例如不要把dev,qa,staging,sandbox这些环境和prod部署到一个集群里面。 尽管有一些资源公平性的配置,如: resource requests/limits, quotas, priorityClasses; 以及一些隔离性的配置,如: affinities,tolerations, taints;但是为了达到隔离,通常需要极为复杂的配置。 因此大部分时候,使用多个集群会更加的易于维护。
使用建议: 不要在deployment中的镜像使用 :latest 标签,而是使用固定的版本。 否则可能会导致部署时候,k8s node使用本地的旧版本的image, 导致线上环境出现版本问题。