本文将介绍 k8s 中的一些最基本的命令，并辅以解释一些基本概念来方便理解，也就是说，本文是一篇偏向实用性而非学术性的文章，如果你想提前了解一下 k8s 相关的知识的话，可以通过以下链接进行学习：
k8s 是经典的一对多模型，有一个主要的管理节点 master 和许多的工作节点 slaver 。当然，k8s 也可以配置多个管理节点，拥有两个以上的管理节点被称为 高可用 。k8s 包括了许多的组件，每个组件都是单运行在一个 docker 容器中，然后通过自己规划的虚拟网络相互访问。你可以通过 kubectl get pod -n kube-system 查看所有节点上的组件容器。
在管理节点中会比工作节点运行更多的 k8s 组件，我们就是靠着这些多出来的组件来对工作节点发号施令。他们都叫什么这里就不详细提了。反正对于”基本使用“来说，这些名字并不重要。
要想理解一个东西就要先明白它的内在理念。通俗点就是，k8s 做了什么？为了提供更加可靠的服务，就要增加服务器的数量，减少每个服务器的体量来平摊负载，而越来越多的虚拟机就会带来越来越高的运维成本。如何让少量的运维人员就可以管理数量众多的服务器及其上的服务呢？这就是 k8s 做的工作。
k8s 把数量众多的服务器重新抽象为一个统一的资源池 ，对于运维人员来说，他们面前没有服务器1、服务器2的概念，而是一个统一的资源池，增加新的服务器对运维人员来说，只是增加自资源池的可用量。不仅如此，k8s 把所有能用的东西都抽象成了资源的概念，从而提供了一套更统一，更简洁的管理方式。
接下来，我会把每个基本命令当做一节来进行介绍，并辅以介绍一些基本概念。本文介绍的命令涵盖了增删改查四方面，可参加下面表格，因为篇幅较长，我们将 create 及之后的不那么常用的命令放在下一篇文章 k8s 基本使用（下） 里讲：
接下来进入正题，首先来了解一下 k8s 中最最最常用的命令 kubectl get ，要记住，k8s 把所有的东西都抽象成了资源，而 kubectl get 就是用来查看这些资源的。最常见的资源就是 pod 。
不仅我们自己的服务是要包装成 pod 的，就连 k8s 自己也是运行在一堆 pod 上。接下来就让我们查看一下 k8s 的 pod ：
-n 参数指定了要查看哪个命名空间下的 pod 。 k8s 所有的 pod 都被放置在 kube-system 命名空间下。
执行了 kubectl get pod -n kube-system 命令后，你就可以看到如下内容：
其中每一行就是一个资源，这里我们看到的资源是 pod 。你看到的 pod 数量可能和我的不一致，因为这个列表里包含了 k8s 在所有节点上运行的 pod ，你加入的节点越多，那么显示的 pod 也就越多。我们来一列一列的看：
kubectl get 可以列出 k8s 中所有资源
这里只介绍了如何用 kubectl 获取 pod 的列表。但是不要把 get 和 pod 绑定在一起，pod 只是 k8s 中的一种服务，你不仅可以 get pod ，还可以 get svc ( 查看服务 )、 get rs ( 查看副本控制器 )、 get deploy ( 查看部署 )等等等等，虽然说 kubectl get pod 是最常用的一个，但是如果想查看某个资源而又不知道命令是什么， kbuectl get <资源名> 就对了。
如果你想看更多的信息，就可以指定 -o wide 参数，如下：
加上这个参数之后就可以看到资源的所在 ip 和所在节点 node 了。
记得加上 -n
-n 可以说是 kubectl get 命令使用最频繁的参数了，在正式使用中，我们永远不会把资源发布在默认命名空间。所以，永远不要忘记在 get 命令后面加上 -n 。
kubectl get 命令可以列出 k8s 中的资源，而 kubectl get pod 是非常常用的查看 pod 的命令。而 -n 参数则可以指定 pod 所在的命名空间。
kubectl describe 命令可以用来查看某一资源的具体信息，他同样可以查看所有资源的详情， 不过最常用的还是查看 pod 的详情 。他也同样可以使用 -n 参数指定资源所在的命名空间。
举个例子，我们可以用下面命令来查看刚才 pod 列表中的某个 pod，注意不要忘记把 pod 名称修改成自己的：
然后你就可以看到很多的信息，咱们分开说，首先是基本属性，你可以在详细信息的开头找到它：
基本属性
其中几个比较常用的，例如 Node 、 labels 和 Controlled By 。通过 Node 你可以快速定位到 pod 所处的机器，从而检查该机器是否出现问题或宕机等。通过 labels 你可以检索到该 pod 的大致用途及定位。而通过 Controlled By ，你可以知道该 pod 是由那种 k8s 资源创建的，然后就可以使用 kubectl get <资源名> 来继续查找问题。例如上文 DaemonSet/kube-flannel-ds-amd64 ，就可以通过 kubectl get DaemonSet -n kube-system 来获取上一节资源的信息。
内部镜像信息
在中间部分你可以找到像下面一样的 Containers 段落。该段落详细的描述了 pod 中每个 docker 容器的信息，常用的比如 Image 字段，当 pod 出现 ImagePullBackOff 错误的时候就可以查看该字段确认拉取的什么镜像。其他的字段名都很通俗，直接翻译即可。
事件
在 describe 查看详情的时候，最常用的信息获取处就是这个 Event 段落了，你可以在介绍内容的末尾找到它，如下：
是的，如果你看到上面这样，没有任何 Events 的话，就说明该 pod 一切正常。当 pod 的状态不是 Running 时，这里一定会有或多或少的问题，长得像下面一样，然后你就可以通过其中的信息分析 pod 出现问题的详细原因了：
kubectl describe <资源名> <实例名> 可以查看一个资源的详细信息，最常用的还是比如 kubectl describe pod <pod名> -n <命名空间> 来获取一个 pod 的基本信息。如果出现问题的话，可以在获取到的信息的末尾看到 Event 段落，其中记录着导致 pod 故障的原因。
如果你想查看一个 pod 的具体日志，就可以通过 kubectl logs <pod名> 来查看。注意，这个只能查看 pod 的日志。通过添加 -f 参数可以持续查看日志。例如，查看 kube-system 命名空间中某个 flannel pod 的日志，注意修改 pod 名称：
然后就可以看到如下输出：
如果你发现某个 pod 的服务有问题，但是状态还是显示 Running ，就可以使用 kubectl logs 来查看其详细日志。
在本篇文章里，我们了解了 k8s 的宗旨和一些基本概念，并知道了最为常用的 get 、 descibe 及 logs 命令，知道了这三条命令之后就几乎可以从 k8s 中获取所有常用信息了。接下来的 k8s 基本使用（下） 里，我们会更深一步，来了解 k8s 中如何创建、修改及删除资源。
我们创建的service并不存在coredns里面 而是存在了etcd中 当我们请求某个域名的时候 会把请求发给coredns coredns再把请求发给apiserver apiserver 再去etcd中拿取数据返回给dns dns返回给客户端nginx想要请求后端的tomcat 首先nginx会把tomcat的service地址发送给coredns coredns发给apiserver apiserver去etcd中拿取对应的解析地址返回给coredns nginx从coredns中拿到tomcat的ip地址后就会把客户端请求转发给tomcat
当pod需要访问k8s集群外的域名时 pod还是会把解析请求发给coredns 我们会在coredns里面配置forward转发到我们公司内部的域名服务器（bind） 如果域名是公司内部使用的 bind就会解析此域名并把ip返回给coredns
如果此域名为外部互联网域名 我们还会在bind中配置forward转发到公网dns中进行解析
我们配置service地址段的时候 此地址段的第一个IP默认分发给apiserver 第二个IP默认分发给dns
在kubenetes的安装包中包含了许多组件的yaml模板 我们可以通过模板来安装coredns
打开github搜索kubernetes 选择右下角的release 选择k8s相应版本
>
top 按1查看
top 按1查看
文件中的单位是毫核，除以1000是百分比的形式，再除以100是cpu个数
docker stats
文件中单位是字节，除以1024是K，再除以1024是M
serverxml只读
创建卷n60
主机环境准备
然后修改电脑hosts文件，用harbor域名从浏览器中访问，新建项目测试
参考Github开源项目
上帝借由各种途径使人变得孤独，好让我们可以走向自己。 ——赫尔曼·黑塞《德米安》
CI即为 持续集成(Continue Integration,简称CI) ，用通俗的话讲，就是 持续的整合版本库代码编译后制作应用镜像 。建立有效的持续集成环境可以减少开发过程中一些不必要的问题、 提高代码质量、快速迭代 等,
Jenkins :基于Java开发的一种持续集成工具,用于监控持续重复的工作,旨在提供一个开放易用的软件平台,使软件的持续集成变成可能。
Bamboo : 是一个企业级商用软件,可以部署在大规模生产环境中。
CD即持续交付Continuous Delivery和持续部署Continuous Deployment，用通俗的话说，即可以持续的部署到生产环境给客户使用，这里分为两个阶段，持续交付我理解为满足上线条件的过程，但是没有上线，持续部署，即为上线应用的过程
关于 CD环境 ，我们使用以前搭建好的 K8s集群 ，K8s集群可以实现应用的 健康 检测，动态扩容，滚动更新 等优点，关于K8s集群的搭建，小伙伴可以看看我的其他文章
拉取镜像，启动并设置开机自启
配置docker加速
GitLab 不多介绍。一个基于Git的版本控制平台，,提供了Git仓库管理、代码审查、问题跟踪、活动反馈和wiki，当然同时也提供了
切记:这里的端口要设置成80，要不push项目会提示没有报错，如果宿主机端口被占用，需要把这个端口腾出来
external_url '>docker私有镜像仓库一般用来存放公司内部的镜像，比如微服务中会有很多的服务需要放到自己公司内部的镜像仓库上，发布的时候直接从私有镜像仓库拉取。比如我公司的微服务部署在k8s环境上，微服务技术依然选择熟悉的 Spring Cloud ，这样每一个服务其实就是一个 Spring Boot 项目，我们通过Maven的插件会在项目编译、打包之后推送到我们的私有镜像仓库，之后CI工具使用kubelet部署的时候会从私有镜像仓库拉取镜像，最后完成部署，可以说私有镜像仓库是非常重要的一个环节。
接下来我会主要讲述一下私有镜像仓库的搭建以及镜像的管理，包括一些自己遇到的问题。
首先要保证自己的服务器已经安装了 docker 。具体的安装教程可以看 官网 ，这里就不在赘述了。
首先我们需要创建一个自己的CA证书，
比如下图是我自己创建时输入的相关内容：
做好镜像存储目录和证书目录的挂载，运行即可
这一步需要在所有需要拉取镜像的服务器上执行。上月底我在部署正式环境时我就遇到了这个问题，k8s的节点上一直显示拉取镜像失败，后来才发现忘了在k8s服务器上配置证书。
hostname 即生成CA证书的时候最后输入的 hostname ， port 镜像仓库对外暴露的端口号。
如果是在镜像仓库所在的服务器上，执行：
如果不是同一台服务器，同样需要存放创建证书目录，执行：
之后将证书上传到目标服务器，且放在证书目录下，名称为 cacrt 。
为了测试，我拉取一个 redis 镜像，然后给它重新打一个 tag 。
推送到私有镜像仓库：
浏览器显示：
表示刚才推送到私有镜像仓库是成功的。接下来我们测试从另一台服务器拉取刚才的镜像。当然这台服务器一定要按照之前的描述配置好CA证书，还要修改服务器 hosts 文件，配置好 ip 和 hostname 。
拉取镜像：
拉取镜像如下图所示：
根据显示可以看出拉取镜像是成功的。
到这里镜像仓库的搭建、推送和拉取都讲完了，接下来就看看怎么删除镜像。
这里说的删除镜像是指从仓库中删除，即从服务器上删除。在构建仓库的时候我们将镜像的仓库容器内的目录挂载到了服务器的目录。镜像仓库内其实是没有镜像文件，都在服务器对应的目录下。在开发的时候我就遇到过这样一个问题，因为是开发环境项目编译、打包、镜像构建和推送都非常频繁，虽然新的镜像会覆盖老的镜像，但是原有的镜像文件本身并没有被覆盖，这样的结果就是虽然镜像仓库上看镜像只有一个，但是本地服务上存储的是很多个镜像文件（而且基本是没啥用的），最终导致了服务磁盘空间不足的情况。
我们依然以 Redis 举例，我将多不同版本的 Redis 多次像私有仓库推送，不管是 Redis 40、50、60，最终我向仓库推送的版本号都是 redis:v4 （过程省略），最终我们在镜像仓库目录（ /home/registry/ ）下可以看到有多个 sha256 的值，详细目录:
/home/registry/docker/registry/v2/repositories/redis/_manifests/revisions/sha256
如下图：
如果要删除镜像首先需要修改配置文件，进入到docker容器内：
保存之后退出容器。
我们进入到存放镜像的目录下，删除一个镜像的 sha256 的值
上面只是删除了镜像的 sha256 值，并没有删除镜像本身，我们需要调用垃圾回收的命令：
这时候会看到一些输出，比如:
这时候我们在查看下对应目录的磁盘使用情况：
但是变化不明显，那就在删除一个试试。
除了手动删除之外还可以通过API来删除，这个方法我没有测试，感兴趣的小伙伴可以测试一下。在实际过程中我也是使用上述方法删除的，因为我一般都是磁盘使用率到一定比例才进行批量删除的，另外网上也有人通过脚本，感兴趣的小伙伴都可以尝试一下。
删除可以使用使用官方API删除：
查询镜像的 sha256 的值：
今天关于docker私有镜像仓库的内容就讲到这里，如果对上面内容有什么疑问欢迎大家交流探讨，也欢迎大家多多点赞、分享、转发，谢谢大家~~~
k8s是什么
Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。
为什么现在流行使用容器
早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展
后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件
现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用
为什么需要使用k8s容器
若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的 *** 作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的
k8s就可以实现该效果,Kubernetes 提供了一个可d性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。
k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理
名词解释
secret
Secret有三种类型：
Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；/run/secrets/kubernetesio/serviceaccountOpaque：base64编码格式的Secret，用来存储密码、密钥等；kubernetesio/dockerconfigjson：用来存储私有docker registry的认证信息。k8s的组成
k8s是由组件,API,对象等组成
包含所有相互关联组件的 Kubernetes 集群图如下:
组件
控制平面组件kube-apiserver: 为k8s的api服务器,公开了所有Kubernetes API, 其他所有组件都必须通过它提供的API来 *** 作资源数据保证集群状态访问的安全隔离集群状态访问的方式和后端存储实现的方式：API Server是状态访问的方式，不会因为后端存储技术etcd的改变而改变。etcd: 为k8s的键值数据库,保存了k8s所有集群数据的后台数据库。kube-scheduler: 收集和分析当前Kubernetes集群中所有Node节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。 kube-controller-manager: 在主节点上运行 控制器 的组件。cloud-controller-manager: 云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件Node 组件kubelet: 一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。kube-proxy: kube-proxy是集群中每个节点上运行的网络代理,维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。容器运行时: 负责运行容器的软件。插件(Addons)DNS: 集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。Web 界面（仪表盘）: Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。容器资源监控: 容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。集群层面日志: 集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。API
Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 >
对象
Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态
具体来说，他们可以描述：
容器化应用正在运行(以及在哪些节点上)这些应用可用的资源关于这些应用如何运行的策略，如重新策略，升级和容错Kubernetes 架构
Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成
master 流程图
Kubecfg将特定的请求，比如创建Pod，发送给Kubernetes Client。Kubernetes Client将请求发送给API server。API Server根据请求的类型，比如创建Pod时storage类型是pods，然后依此选择何种REST Storage API对请求作出处理。REST Storage API对的请求作相应的处理。将处理的结果存入高可用键值存储系统Etcd中。在API Server响应Kubecfg的请求后，Scheduler会根据Kubernetes Client获取集群中运行Pod及Minion/Node信息。依据从Kubernetes Client获取的信息，Scheduler将未分发的Pod分发到可用的Minion/Node节点上。节点
节点可以是一个虚拟机或者物理机器，取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务， 这些 Pods 由 控制面 负责管理
节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。
节点状态
可以使用 kubectl 来查看节点状态和其他细节信息：
kubectl describe node <�节点名称>
一个节点包含以下信息:
地址HostName：由节点的内核设置。可以通过 kubelet 的 —hostname-override 参数覆盖。ExternalIP：通常是节点的可外部路由（从集群外可访问）的 IP 地址。InternalIP：通常是节点的仅可在集群内部路由的 IP 地址。状况(conditions 字段描述了所有 Running 节点的状态)Ready 如节点是健康的并已经准备好接收 Pod 则为 True；False 表示节点不健康而且不能接收 Pod；Unknown 表示节点控制器在最近 node-monitor-grace-period 期间（默认 40 秒）没有收到节点的消息DiskPressure为True则表示节点的空闲空间不足以用于添加新 Pod, 否则为 FalseMemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 FalsePIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 FalseNetworkUnavailable为True则表示节点网络配置不正确；否则为 False容量与可分配描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。信息关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和 *** 作系统名称。这些信息由 kubelet 从节点上搜集而来。控制面到节点通信
节点到控制面apiserver在安全的 ）上监听远程连接请求以客户端证书的形式将客户端凭据提供给 kubelet控制面到节点API 服务器到 kubelet连接用于获取 Pod 日志挂接（通过 kubectl）到运行中的 Pod提供 kubelet 的端口转发功能。(注: 在连接状态下, 默认apiserver 不检查 kubelet 的服务证书。容易受到中间人攻击，不安全)apiserver 到节点、Pod 和服务SSH 隧道(目前已经废弃)产生原因: 若无服务证书, 又要求避免在非受信网络或公共网络上进行连接,则可以在apiserver 和 kubelet 之间使用ssh隧道Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。Konnectivity 服务为ssh隧道的替代品, Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。控制器
在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。
举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。
控制器模式分为直接控制和通过API服务器来控制
云控制器管理器
云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中， 并分离出相互作用的组件与您的集群交互的组件。
云控制器管理器中的控制器包括：
节点控制器节点控制器负责在云基础设施中创建了新服务器时为之 创建 节点（Node）对象。 节点控制器从云提供商获取当前租户中主机的信息。执行功能:针对控制器通过云平台驱动的 API 所发现的每个服务器初始化一个 Node 对象利用特定云平台的信息为 Node 对象添加注解和标签获取节点的网络地址和主机名检查节点的健康状况。路由控制器Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 容器之间可以相互通信。服务控制器服务（Service）与受控的负载均衡器、 IP 地址、网络包过滤、目标健康检查等云基础设施组件集成。 服务控制器与云驱动的 API 交互，以配置负载均衡器和其他基础设施组件。Kubernetes 安全性
云原生安全
云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)
云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。
基础设施安全
Kubetnetes 基础架构关注领域
建议
通过网络访问 API 服务（控制平面)
所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开，同时应由网络访问控制列表控制，该列表包含管理集群所需的 IP 地址集。
通过网络访问 Node（节点)
节点应配置为 仅能 从控制平面上通过指定端口来接受（通过网络访问控制列表）连接，以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话，这些节点不应完全暴露在公共互联网上。
Kubernetes 云访问提供商的 API
每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时，最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。
访问 etcd
对 etcd（Kubernetes 的数据存储）的访问应仅限于控制平面。根据配置情况，你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。
etcd 加密
在所有可能的情况下，最好对所有驱动器进行静态数据加密，但是由于 etcd 拥有整个集群的状态（包括机密信息），因此其磁盘更应该进行静态数据加密。
集群组件安全
运行的应用程序的安全性关注领域访问控制授权(访问 Kubernetes API)认证方式应用程序 Secret 管理 (并在 etcd 中对其进行静态数据加密)Pod 安全策略服务质量（和集群资源管理）网络策略Kubernetes Ingress 的 TLS 支持容器安全
容器安全性关注领域容器搭建配置(配置不当,危险挂载, 特权用户)容器服务自身缺陷Linux内核漏洞镜像签名和执行代码安全
代码安全关注领域仅通过 TLS 访问(流量加密)限制通信端口范围第三方依赖性安全静态代码分析动态探测攻击(黑盒)Kubernetes架构常见问题
Kubernetes ATTACK 矩阵
信息泄露
云账号AK泄露
API凭证（即阿里云AccessKey）是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证
API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。
API凭证相当于登录密码，用于程序方式调用云服务API
k8s configfile泄露
kubeconfig文件所在的位置:
$HOME/kube/config
Kubeconfig文件包含有关Kubernetes集群的详细信息，包括它们的位置和凭据。
云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理 如果攻击者能够访问到此文件（如办公网员工机器入侵、泄露到Github的代码等），就可以直接通过API Server接管K8s集群，带来风险隐患。
Master节点SSH登录泄露
常见的容器集群管理方式是通过登录Master节点或运维跳板机，然后再通过kubectl命令工具来控制k8s。
云服务器提供了通过ssh登陆的形式进行登陆master节点
若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群
容器组件未鉴权服务
Kubernetes架构下常见的开放服务指纹如下:
kube-apiserver: 6443, 8080kubectl proxy: 8080, 8081kubelet: 10250, 10255, 4149dashboard: 30000docker api: 2375etcd: 2379, 2380kube-controller-manager: 10252kube-proxy: 10256, 31442kube-scheduler: 10251weave: 6781, 6782, 6783kubeflow-dashboard: 8080注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务
了解各个组件被攻击时所造成的影响
组件分工图:
假如用户想在集群里面新建一个容器集合单元, 流程如下:
用户与 kubectl进行交互,提出需求(例: kubectl create -f podyaml)kubectl 会读取 ~/kube/config 配置，并与 apiserver 进行交互，协议：apiserver 会协同 ETCD, kube-controller-manager, scheduler 等组件准备下发新建容器的配置给到节点，协议：apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：；kubelet 与Docker等容器引擎进行交互，创建容器，协议：容器已然在集群节点上创建成功攻击apiserver
apiserver介绍:
在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限
在攻击者眼中Kubernetes APIServer
容器编排K8S总控组件pods, services, secrets, serviceaccounts, bindings, componentstatuses, configmaps,endpoints, events, limitranges, namespaces, nodes, persistentvolumeclaims,persistentvolumes, podtemplates, replicationcontrollers, resourcequotas …可控以上所有k8s资源可获取几乎所有容器的交互式shell利用一定技巧可获取所有容器母机的交互式shell默认情况下apiserver都有鉴权:
未鉴权配置如下:
对于这类的未鉴权的设置来说，访问到 apiserver 一般情况下就获取了集群的权限：
如何通过apiserver来进行渗透,可参考:>
攻击kubelet
每一个Node节点都有一个kubelet(每个节点上运行的代理)服务，kubelet监听了10250，10248，10255等端口。
10250端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下，不带鉴权信息的请求也可以使用10250提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播
在配置文件中,若进行如下配置,则可能存在未授权访问漏洞
/var/bin/kubulet/config/yaml
若10250端口存在未授权访问漏洞,我们可以直接访问/pods进行查看
根据在pods中获取的信息,我们可以在容器中执行命令
curl -Gks >
上述命令得到websocket地址，连接websocket得到命令结果：
使用wscat工具连接websocket
wscat -c “>
即可得到我们执行命令的结果
获取token
/var/run/secrets/kubernetesio/serviceaccount
然后即可访问kube-api server,获取集群权限
curl -ks -H "Authorization: Bearer \ ttps://master:6443/api/v1/namespaces/{namespace}/secrets
"
攻击kubelet总体步骤如下:
访问pods获取信息获取namespace、podsname、containername执行exec获取token/var/run/secrets/kubernetesio/serviceaccount利用Token访问API Server进行对pods *** 作。攻击dashboard
dashboard登陆链接如下:
>
dashboard界面如下:
dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下，通过dashboard我们可以控制整个集群。
默认情况下, dashboard是需要进行鉴权 *** 作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard
通过skip登陆的dashboard默认是没有 *** 作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理，不同的serviceaccount拥有不同的集群权限。
但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole（cluster-admin拥有管理集群的最高权限）
为Kubernetes-dashboard绑定cluster-admin 设置如下:
新建dashboard-adminyaml内容apiVersion: rbacauthorizationk8sio/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbacauthorizationk8sio kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboardkubectl create -f dashboard-adminyaml后通过skip登陆dashboard便有了管理集群的权限
创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。
新建一个Pod如下:
通过该容器的tmp目录管理node节点的文件
攻击etcd
Kubernetes默认使用了etcd v3来存储数据, 若能na
etcd对内暴露2379端口，本地127001可免认证访问 其他地址要带—endpoint参数和cert进行认证。
未授权访问流程:
检查是否正常链接etcdctl endpoint health读取service account tokenetcdctl get / --prefix --keys-only | grep /secrets/kube-system/clusterrole通过token认访问API-Server端口6443，接管集群：kubectl --insecure-skip-tls-verify -s攻击docker remote api(Docker daemon公网暴露)
2375是docker远程 *** 控的默认端口，通过这个端口可以直接对远程的docker 守护进程进行 *** 作。Docker 守护进程默认监听2375端口且未鉴权
当机器以方式启动daemon时，可以在外部机器对该机器的docker daemon进行直接 *** 作：
docker daemon -H=0000:2375
之后依次执行systemctl daemon-reload、systemctl restart docker
外部主机使用 即可 *** 作暴露2375端口的主机
-H
因此当你有访问到目标Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器
检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问>
攻击kubectl proxy
二次开发所产生的问题
管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能，其实都是间接在和 APIServer 做交互
如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。
例如:
给用户销毁自己POD的能力DELETE类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权
推荐工具
Kube-Hunter扫描漏洞
kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器
下载地址: >
CDK(强推)
CDK是一款为容器环境定制的渗透测试工具，在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。
下载地址: >
参考链接
>本文主要在centos7系统上基于 docker 和 flannel 组件部署 v1236 版本的k8s原生集群，由于集群主要用于自己平时学习和测试使用，加上资源有限，暂不涉及高可用部署。
此前写的一些关于k8s基础知识和集群搭建的一些 方案 ，有需要的同学可以看一下。
机器均为8C8G的虚拟机，硬盘为100G。
同一个k8s集群内的所有节点需要确保 mac 地址和 product_uuid 均唯一，开始集群初始化之前需要检查相关信息
如果k8s集群的节点有多个网卡，确保每个节点能通过正确的网卡互联访问
这里可以根据自己的习惯选择ntp或者是chrony同步均可，同步的时间源服务器可以选择阿里云的 ntp1aliyuncom 或者是国家时间中心的 ntpntscaccn 。
k8s集群之间通信和服务暴露需要使用较多端口，为了方便，直接禁用防火墙
这里主要是需要配置内核加载 br_netfilter 和 iptables 放行 ipv6 和 ipv4 的流量，确保集群内的容器能够正常通信。
虽然新版本的k8s已经支持双栈网络，但是本次的集群部署过程并不涉及IPv6网络的通信，因此关闭IPv6网络支持
IPVS是专门设计用来应对负载均衡场景的组件， kube-proxy 中的 IPVS 实现 通过减少对 iptables 的使用来增加可扩展性。在 iptables 输入链中不使用 PREROUTING，而是创建一个假的接口，叫做 kube-ipvs0，当k8s集群中的负载均衡配置变多的时候，IPVS能实现比iptables更高效的转发性能。
详细的官方文档可以参考 这里 ，由于在刚发布的124版本中移除了 docker-shim ，因此安装的 版本≥124 的时候需要注意 容器运行时 的选择。这里我们安装的版本低于124，因此我们继续使用docker。
docker的具体安装可以参考我之前写的 这篇文章 ，这里不做赘述。
CentOS7使用的是 systemd 来初始化系统并管理进程，初始化进程会生成并使用一个 root 控制组 ( cgroup ), 并充当 cgroup 管理器。 Systemd 与 cgroup 集成紧密，并将为每个 systemd 单元分配一个 cgroup 。 我们也可以配置 容器运行时 和 kubelet 使用 cgroupfs 。 连同 systemd 一起使用 cgroupfs 意味着将有两个不同的 cgroup 管理器 。而当一个系统中同时存在cgroupfs和systemd两者时，容易变得不稳定，因此最好更改设置，令容器运行时和 kubelet 使用 systemd 作为 cgroup 驱动，以此使系统更为稳定。 对于 Docker, 需要设置 nativecgroupdriver=systemd 参数。
k8s官方有 详细的文档 介绍了如何设置kubelet的 cgroup driver ，需要特别注意的是，在122版本开始，如果没有手动设置kubelet的cgroup driver，那么默认会设置为systemd
一个比较简单的指定kubelet的 cgroup driver 的方法就是在 kubeadm-configyaml 加入 cgroupDriver 字段
我们可以直接查看configmaps来查看初始化之后集群的kubeadm-config配置。
当然因为我们需要安装的版本高于1220并且使用的就是systemd，因此可以不用再重复配置。
kube三件套就是 kubeadm 、 kubelet 和 kubectl ，三者的具体功能和作用如下：
需要注意的是：
CentOS7的安装比较简单，我们直接使用官方提供的 yum 源即可。需要注意的是这里需要设置 selinux 的状态，但是前面我们已经关闭了selinux，因此这里略过这步。
在集群中所有节点都执行完上面的三点 *** 作之后，我们就可以开始创建k8s集群了。因为我们这次不涉及高可用部署，因此初始化的时候直接在我们的目标master节点上面 *** 作即可。
此时我们再查看对应的配置文件中的镜像版本，就会发现已经变成了对应阿里云镜像源的版本
当我们看到下面这个输出结果的时候，我们的集群就算是初始化成功了。
刚初始化成功之后，我们还没办法马上查看k8s集群信息，需要配置kubeconfig相关参数才能正常使用kubectl连接apiserver读取集群信息。
配置完成后，我们再执行相关命令就可以查看集群的信息了。
这时候我们还需要继续添加剩下的两个节点作为worker节点运行负载，直接在剩下的节点上面运行集群初始化成功时输出的命令就可以成功加入集群：
如果不小心没保存初始化成功的输出信息也没有关系，我们可以使用kubectl工具查看或者生成token
添加完成之后我们再查看集群的节点可以发现这时候已经多了两个node，但是此时节点的状态还是 NotReady ，接下来就需要部署CNI了。
flannel 应该是众多开源的CNI插件中入门门槛最低的CNI之一了，部署简单，原理易懂，且相关的文档在网络上也非常丰富。
针对 kube-flannelyml 文件，我们需要修改一些 参数 以适配我们的集群：
修改完成之后我们直接部署即可
集群部署完成之后我们在k8s集群中部署一个nginx测试一下是否能够正常工作。首先我们创建一个名为 nginx-quic 的命名空间（ namespace ），然后在这个命名空间内创建一个名为 nginx-quic-deployment 的 deployment 用来部署pod，最后再创建一个 service 用来暴露服务，这里我们先使用 nodeport 的方式暴露端口方便测试。
部署完成后我们直接查看状态
最后我们进行测试，这个nginx-quic的镜像默认情况下会返回在nginx容器中获得的用户请求的IP和端口
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）