很多朋友在找时都会咨询k8s运维和k8s运维是什么，这说明有一部分人对这个问题不太了解，您了解吗？那么什么是k8s运维是什么？下面就由小编带大家详细了解一下吧！

k8s是什么?

Kubernetes 是一个可移植的，可扩展的开源容器编排平台，用于管理容器化的工作负载和服务，方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务，支持和工具广泛可用。

为什么现在流行使用容器?

早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

为什么需要使用k8s容器?

若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

名词解释

secret

Secret有三种类型：

Service Account：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的目录中；

/run/secrets/kubernetes.io/serviceaccount

Opaque：base64编码格式的Secret，用来存储密码、密钥等；

kubernetes.io/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 服务器负责提供 HTTP 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, 否则为 False

MemoryPressure为True则表示节点存在内存压力，即节点内存可用量低，否则为 False

PIDPressure为True则表示节点存在进程压力，即节点上进程过多；否则为 False

NetworkUnavailable为True则表示节点网络配置不正确；否则为 False

容量与可分配描述节点上的可用资源：CPU、内存和可以调度到节点上的 Pod 的个数上限。

信息关于节点的一般性信息，例如内核版本、Kubernetes 版本（kubelet 和 kube-proxy 版本）、 Docker 版本（如果使用了）和操作系统名称。这些信息由 kubelet 从节点上搜集而来。

控制面到节点通信

节点到控制面

apiserver在安全的 HTTPS 端口（443）上监听远程连接请求

以客户端证书的形式将客户端凭据提供给 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, 8080

kubectl proxy: 8080, 8081

kubelet: 10250, 10255, 4149

dashboard: 30000

docker api: 2375

etcd: 2379, 2380

kube-controller-manager: 10252

kube-proxy: 10256, 31442

kube-scheduler: 10251

weave: 6781, 6782, 6783

kubeflow-dashboard: 8080

注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

组件分工图:

假如用户想在集群里面新建一个容器集合单元, 流程如下:

用户与 kubectl进行交互,提出需求(例: kubectl create -f pod.yaml)

kubectl 会读取 ~/.kube/config 配置，并与 apiserver 进行交互，协议：http/https

apiserver 会协同 ETCD, kube-controller-manager, scheduler 等组件准备下发新建容器的配置给到节点，协议：http/https

apiserver 与 kubelet 进行交互，告知其容器创建的需求，协议：http/https；

kubelet 与Docker等容器引擎进行交互，创建容器，协议：http/unix socket.

容器已然在集群节点上创建成功

攻击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 {namespace}/{podname}/{containername} -d ‘input=1’ -d ‘output=1’ -d ‘tty=1’ -d ‘command=whoami’

上述命令得到websocket地址，连接websocket得到命令结果：

使用wscat工具连接websocket

wscat -c “{websocket}” –no-check

即可得到我们执行命令的结果.

获取token

/var/run/secrets/kubernetes.io/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/kubernetes.io/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-admin.yaml内容

apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata: name: kubernetes-dashboardroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects : kind: ServiceAccount name: kubernetes-dashboard namespace: kubernetes-dashboard

kubectl create -f dashboard-admin.yaml

后通过skip登陆dashboard便有了管理集群的权限.

创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。

新建一个Pod如下:

通过该容器的tmp目录管理node节点的文件

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能na

etcd对内暴露2379端口，本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

检查是否正常链接

etcdctl endpoint health

读取service account token

etcdctl get / –prefix –keys-only | grep /secrets/kube-system/clusterrole

通过token认访问API-Server端口6443，接管集群：

kubectl –insecure-skip-tls-verify -s –token=”[ey…]” -n kube-system get pods

攻击docker remote api(Docker daemon公网暴露)

2375是docker远程操控的默认端口，通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.

当机器以方式启动daemon时，可以在外部机器对该机器的docker daemon进行直接操作：

docker daemon -H=0.0.0.0:2375

之后依次执行systemctl daemon-reload、systemctl restart docker

外部主机使用 即可操作暴露2375端口的主机.

-H

因此当你有访问到目标Docker API 的网络能力或主机能力的时候，你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器，并且挂载主机根目录到容器.

检测目标是否存在docker api未授权访问漏洞的方式也很简单，访问http://[host]:[port]/info路径是否含有ContainersRunning、DockerRootDir等关键字。

攻击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场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

下载地址:

参考链接

在应用的整个生命周期里，开发和运维都和它密不可分。一个塑造它，一个保养它。

如果应用需要部署到K8S中，开发和运维在其中都做了什么呢？

从开发侧来说，我们的应用应该具备以下能力：

健康 检测接口用于检测应用的 健康 状态，在K8S中，使用Readiness和Liveness分别来探测应用是否就绪和是否存活，如果未就绪或者未存活，K8S会采取相应的措施来确保应用可用。

如果我们应用未定义好相应的 健康 检测接口，K8S就无法判断应用是否正常可用，整个应用对我们来说就是黑匣子，也就谈不上应用稳定性了。

定义一个简单的 健康 检测接口如下：

如上我们定义了 health 接口，当应用启动后，只需要探测这个接口，如果返回OK，表示应用是正常的。

当然，上面的接口是非常简单的，在实际情况下，应用本身也许还依赖起来应用，比如redis，mysql，mq等，如果它们异常，应用是不是异常的呢？那我们的应用 健康 检测需不需要检测其他应用的 健康 状态呢？

既然我们定义好了 健康 检测接口，那我们的YAML模板就可以增加 健康 检测功能，如下：

应用发版是常规不能再常规的操作，通常情况下都是滚动更新的方式上线，也就是先起一个新应用，再删一个老应用。

如果这时候老应用有部分的流量，突然把老应用的进程杀了，这部分流量就无法得到正确的处理，部分用户也会因此受到影响。

怎么才会不受影响呢？

假如我们在停止应用之前先告诉网关或者注册中心，等对方把我们应用摘除后再下线，这样就不会有任何流量受到影响了。

在K8S中，当我们要删除Pod的时候，Pod会变成Terminating状态，kubelet看到Pod的状态如果为Terminating，就会开始执行关闭Pod的流程，给Pod发SIGTERM信号，如果达到宽限期Pod还未结束就给Pod发SIGKILL信号，从Endpoints中摘除Pod等。

从上面可知，Pod在停止之前会收到SIG信号，如果应用本身没有处理这些信号的能力，那应用如果知道什么时候该结束呢？

下面简单定义一个处理SIG信号的功能。

当接收到SIG信号的时候，就会调用 Shutdown 方法做应用退出处理。

除此，还要结合K8S的 PreStop Hook 来定义结束前的钩子，如下：

如果使用注册中心，比如nacos，我们可以在 PreStop Hook 中先告诉nacos要下线，如下：

Metrics主要用来暴露应用指标，可以根据实际情况自定义指标，以便于监控工具Prometheus进行数据收集展示。

有些语言有现成的exporter，比如java的jmx_exporter，没有的就需要自己在应用中集成。

比如：

这种会暴露默认的Http指标，可以通过 curl 127.0.0.1:9527/metrics 获取指标。

如果需要自定义指标的话，只需按规则定义即可，如下：

这样就定义了 httpserver_request_total 和 httpserver_request_duration_seconds 指标，引用过后就能在 /metrics 中看到对应的数据。

定义好了指标，下面就是收集了。既可以通过自定义收集规则收集，也可以通过自动发现的方式收集，为了方便，主要采用自动发现的方式。

我们只需要在deployment的templates中定义好annotation，prometheeus就会自动添加采集目标，如下：

Trace用于跟踪，每个请求都会生成一个 TraceID ，这个ID会伴随请求的整个生命周期，我们也可以根据这个ID查询请求的整个链路情况。

链路追踪，目前市面上有很多开源系统，比如Skywalking，Jeager，Zipkin等，它们各有各的特点，如下。

我比较推荐使用Jaeger，它是CNCF的毕业项目，成长空间和云原生的系统架构兼容性比较好。

不过，我这里采用的Skywalking。

Skywalking有许多现成的客户端，比如Java、Python等，可以直接使用，它们都会自动埋点，但是对于Go来说就只有自己手动埋点了，需要我们自己去写代码。

比如：

定义reporter用于上报数据给Skywalking，这就是一个简单的集成Trace的例子。

应用的可观测性主要来源日志、监控、链路追踪，标准的日志有利于日志收集以及排查问题。

原则上，不论是什么类型的日志输出，什么格式的日志内容，都能收集。但是为了方便友好，建议把日志输出到标准输出，这样收集更方便。

我个人理解，在K8s中，完全没必要把日志输出到文件，浪费不说，没多大意义，因为所有的日志我们都会收集到日志系统，而输出到文件的日志也会随着应用发版而丢失，所以输出到文件的意义是什么呢？

开发把系统开发完，就会交付给运维部署。为了保障应用的稳定性，运维在部署应用的时候应该考虑以下几点。

K8S中可以部署有状态应用，也可以部署无状态应用。对于有状态应用，我其实很少部署到K8S中，大部分还是部署的无状态应用，至于为什么，用多了就晓得了。

对于业务应用，强烈建议使其保持无状态，就算有需要持久化的东西，要么保存到数据库，要么保存到对象存储或者其他单独的文件系统中，不要挂载到应用Pod上。

这样的好处是，应用和数据是分开的，应用可以随意启停、扩展、迁移等。

保持高可用应该是每个运维人员的使命。

在K8S中，我们应该怎么配置呢？（1）应用Pod应该是多副本

（2）应用Pod之间做反亲和性，避免同一应用调度到同一台主机，如下。

（3） 为了避免应用因为节点维护等原因驱逐Pod，导致全部Pod被驱逐，特别配置了PodDisruptionBudget，保障应用至少有一个可用，如下。

（4）如果某个节点因为一些原因需要驱逐一些Pod，为了避免重要应用被驱逐，应该给应用配置较高的QoS，如下：

所谓优雅上线能力，就是要确保应用能够提供服务了，再接入外界流量，不能在还没完全启动的情况下就提供服务。

在K8S中，应用在启动后会加入endpoints中，然后通过service接入流量，那在什么情况下才算启动成功呢？主要是通过K8S的 ReadinessProbe 来进行检测。这时候开发的 健康 检测接口就派上用场了，如下：

所以我们K8S的YAML文件应该加上如上的配置。

所谓异常自愈，就是应用本身在出现Crash，或者应用Pod所在节点出现异常的情况，应用能够自动重启或者迁移。这时候就需要通过K8S的 LivenessProbe 来进行检测了，如下。

当K8S的YAML清单加上如上配置过后，就会定时去探测应用是否正常，如果异常，就会触发重启的动作。如果是节点异常，K8S会对Pod进行重新调度。

应用通过HTTPS访问是比较常见的，企业级应用建议自己购买相应的SSL证书，然后进行配置即可。

比如。

上面介绍了开发和运维对于应用上线应该做的工作， 不全但够用 。

在不同的企业都有不同的尿性，但是作为运维，我们都要牢牢记住 稳定 永远是第一尿性。通过上面的梳理，我们的应用模板就整理如下：

如果我的文章对你有所帮助，还请帮忙一下，你的支持会激励我输出更高质量的文章，非常感谢！

你还可以把我的公众号设为「 星标 」，这样当公众号文章更新时，你会在第一时间收到推送消息，避免错过我的文章更新。

本文将介绍 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 中如何创建、修改及删除资源。

（1）服务发现与调度

（2）负载均衡

（3）服务自愈

（4）服务弹性扩容

（5）横向扩容

（6）存储卷挂载

总而言之，k8s可以使我们应用的部署和运维更加方便。想要了解更多，我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。

希望能给您提供帮助，可以给个大大的赞不。

Kubernetes（k8s）是Google开源的容器集群管理系统（谷歌内部:Borg），它主要用于?容器编排?启动容器、自动化部署、扩展和管理容器应用和回收容器。k8s的目标是让部署容器化的应用简单并且高效，k8s提供了应用部署、规划、更新、维护的一种机制。

用kubernetes去管理Docker集群，既可以将Docker看成Kubernetes内部使用的低级别组件；另外，kubernetes不仅仅支持Docker还支持Rocket，这是另一种容器技术。

扩展资料：

从背景上说，Kubernetes是由Google与RedHat公司共同主导的开源“容器编排”项目，它起源于Google公司的Borg系统。

所以它在超大规模集群管理方面的经验要明显优于其他容器编排技术，加上Kubernetes在社区管理方面的民主化，使得它很快打败了Docker公司推出的容器编排解决方案(Compose+Swarm)，从而成为了容器编排领域事实上的标准。

而在功能上Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。

感谢您阅读本篇对k8s运维的详细介绍，如果你对k8s运维是什么还不够了解，想进一步学习关于k8s运维的知识，可以在本站首页搜索你想知道的！