简述Kubernetes如何保证集群的安全性？

2024-05-06 02:35

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, 导致线上环境出现版本问题。