一、介绍
为什么需要 Kubernetes,它能做什么?
容器是打包和运行应用程序的好方式。在生产环境中,你需要管理运行应用程序的容器,并确保不会停机。 例如,如果一个容器发生故障,则需要启动另一个容器。如果系统处理此行为,会不会更容易?
这就是 Kubernetes 来解决这些问题的方法! Kubernetes 为你提供了一个可弹性运行分布式系统的框架。
Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如,Kubernetes 可以轻松管理系统的 Canary 部署。
Kubernetes 为你提供:
-
服务发现和负载均衡
Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果进入容器的流量很大, Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。
-
存储编排
Kubernetes 允许你自动挂载你选择的存储系统,例如本地存储、公共云提供商等。
-
自动部署和回滚
你可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态 更改为期望状态。例如,你可以自动化 Kubernetes 来为你的部署创建新容器, 删除现有容器并将它们的所有资源用于新容器。
-
自动完成装箱计算
Kubernetes 允许你指定每个容器所需 CPU 和内存(RAM)。 当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。
-
自我修复
Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。
-
密钥与配置管理
Kubernetes 允许你存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。 你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥
二、K8S集群架构
一个K8S集群是由两大部分组成:
- Master节点
-
Master节点主要包括API Server、Scheduler、Controller manager、etcd几大组件
-
- Node节点
- Node节点主要包括kubelet、kube-proxy模块和pod对象
![](https://i-blog.csdnimg.cn/blog_migrate/5518cf17708b6ba6678bdea774203415.png)
三、Master节点
1、API Server
Kubernetes 控制面 的核心是API Server,在Kubernetes 集群中,API Server 扮演着通信枢纽的位置,对外提供统一的API调用入口。
API Server让我们可以查询和操纵 Kubernetes API 中对象(例如:Pod、Namespace、ConfigMap 和 Event)的状态。
大部分操作都可以通过 kubectl 命令行接口或 类似 kubeadm 这类命令行工具来执行, 这些工具在背后也是调用 API。不过,你也可以使用 REST 调用来访问这些 API。
另外,API Server负责直接和 etcd 交互(其他组件不会直接操作 etcd,只有 API Server 这么做),并切, 所有的交互都是以 API Server 为核心的。
总结:API Server 提供了以下的功能:
- 整个集群管理的 API 接口:所有对集群进行的查询和管理都要通过 API 来进行。集群内部的组件(如kubelet)也是通过Apiserver更新和同步数据到etcd中。
- 集群内部各个模块之间通信的枢纽:所有模块之前并不会之间互相调用,而是通过和 API Server 打交道来完成自己那部分的工作。
- 集群安全控制:API Server 提供的验证和授权保证了整个集群的安全。
- 数据中心枢纽:API Server 负责和 Etcd 交互存放集群用到的运行数据。
2、Scheduler
负责对集群内部的资源进行调度。
Scheduler负责节点资源管理,接收来自kube-apiserver创建Pods的任务,收到任务后它会检索出所有符合该Pod要求的Node节点(通过预选策略和优选策略),开始执行Pod调度逻辑。调度成功后将Pod绑定到目标节点上。
Node节点的kubelet 组件通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件,然后从 etcd 获取 pod 清单,下载镜像并启动容器。
3、Controller manager
controller-manager 作为 k8s 集群的管理控制中心,负责集群内 Node、Namespace、Service、Token、Replication 等资源对象的管理,使集群内的资源对象维持在预期的工作状态。
每一个 controller 通过 api-server 提供的 restful 接口实时监控集群内每个资源对象的状态,当发生故障,导致资源对象的工作状态发生变化,就进行干预,尝试将资源对象从当前状态恢复为预期的工作状态,常见的 controller 有 Namespace Controller、Node Controller、Service Controller、ServiceAccount Controller、Token Controller、ResourceQuote Controller、Replication Controller等。
从逻辑上讲,每个控制器都是一个单独的进程, 但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。
这些控制器包括:
- 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。
- 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。
- 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。
- 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌。
4、etcd
etcd在kubernetes集群是用来存放数据并通知变动的。
Kubernetes中没有用到数据库,它把关键数据都存放在etcd中,这使kubernetes的整体结构变得非常简单。在kubernetes中,数据是随时发生变化的,比如说用户提交了新任务、增加了新的Node、Node宕机了、容器死掉了等等,都会触发状态数据的变更。状态数据变更之后呢,Master上的kube-scheduler和kube-controller-manager,就会重新安排工作,它们的工作安排结果也是数据。这些变化,都需要及时地通知给每一个组件。etcd有一个特别好用的特性,可以调用它的api监听其中的数据,一旦数据发生变化了,就会收到通知。有了这个特性之后,kubernetes中的每个组件只需要监听etcd中数据,就可以知道自己应该做什么。kube-scheduler和kube-controller-manager呢,也只需要把最新的工作安排写入到etcd中就可以了
四、Node节点
Node节点主要包括kubelet、kube-proxy模块和pod对象。
1、kubelet
运行在每个计算节点上
1).kubelet 组件通过 api-server 提供的接口监测到 kube-scheduler 产生的 pod 绑定事件,然后从 etcd 获取 pod 清单,下载镜像并启动容器。
2).同时监视分配给该Node节点的 pods,周期性获取容器状态,再通过api-server通知各个组件。
2、kube-proxy
首先k8s 里所有资源都存在 etcd 中,各个组件通过 apiserver 的接口进行访问etcd来获取资源信息
kube-proxy 会作为 daemon(守护进程) 跑在每个节点上通过watch的方式监控着etcd中关于Pod的最新状态信息,它一旦检查到一个Pod资源被删除了或新建或ip变化了等一系列变动,它就立即将这些变动,反应在iptables 或 ipvs规则中,以便之后 再有请求发到service时,service可以通过ipvs最新的规则将请求的分发到pod上
3、Pod
Pod是Kubernetes最基本的操作单元。一个Pod代表着集群中运行的一个进程,它内部封装了一个或多个紧密相关的容器。
五、 容器运行环境
容器运行环境是负责运行容器的软件。
Kubernetes 支持多个容器运行环境: Docker、 containerd、CRI-O 以及任何实现 Kubernetes CRI (容器运行环境接口)。
六、插件(Addons)
插件使用 Kubernetes 资源(DaemonSet、 Deployment等)实现集群功能。 因为这些插件提供集群级别的功能,插件中命名空间域的资源属于 kube-system
命名空间。
下面描述众多插件中的几种。有关可用插件的完整列表,请参见 插件(Addons)。
DNS
尽管其他插件都并非严格意义上的必需组件,但几乎所有 Kubernetes 集群都应该 有集群 DNS, 因为很多示例都需要 DNS 服务。
集群 DNS 是一个 DNS 服务器,和环境中的其他 DNS 服务器一起工作,它为 Kubernetes 服务提供 DNS 记录。
Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。
Web 界面(仪表盘)
Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。
容器资源监控
容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中,并提供用于浏览这些数据的界面。
集群层面日志
集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中,该存储能够提供搜索和浏览接口。
七、相关命令
kubectl help:帮助命令,查看k8s所有命令
kubectl help xxx:查看某个具体命令的详细使用,如kubectl help config:如下图,查看config命令的具体使用,如kubectl config view,查看详细的配置文件,如hzaz1-hubble-02表示集群名称,集群中又有多个namespace。
注意:k8s上namespace只是类似于一个分组,方便进行管理,并不对资源进行隔离,即一个namespace服务如果压力过大,可能影响其它namespace服务,如hubble-manager可能影响到hubble-platform
![](https://i-blog.csdnimg.cn/blog_migrate/9a55f78dbc87d97b6bbf02b1c707fba1.png)
![](https://i-blog.csdnimg.cn/blog_migrate/5c82026273882cacdeb9ca951a28e08c.png)
![](https://i-blog.csdnimg.cn/blog_migrate/35d843073d29ecb789dd8f7ad3a6fb40.png)
kubectl get nodes:获取可用节点
kubectl get pod -A:获取所有pod
kubectl get hpa -n hubble-manager:查看hpa配置
kubectl describe nodes 10.128.228.2:查看节点描述/状态信息
kubectl get service -n hubble-manager:查看hubble-manager命名空间下有哪些service
![](https://i-blog.csdnimg.cn/blog_migrate/e0c9142b0cbace434f9f4c79163d03dc.png)
/data/weiwei/kubectl get service --all-namespaces -- 查看所有命名空间下有哪些service
kubectl get svc --all-namespaces -- 查看所有命名空间下有哪些svc
kubectl delete service m-alarm-query -n hubble-manager :删除hubble-manager集群下名称为m-alarm-query的service
cat ~/.kube/config:查看集群的配置文件
/data/weiwei/kubectl --kubeconfig /data/weiwei/config-hubble-test-01 apply -f /data/weiwei/k8s/qiyi_puppet/script/k8s/hubble-biz-aiops.yaml:将容器部署到指定集群,通过--kubeconfig指定配置文件
/data/weiwei/kubectl --validate=false apply -f . :执行当前目录下所有yaml文件,免校验
/data/weiwei/kubectl describe pod metrics-server-6fdb89bdcb-8t4rs -n kube-system:查看命名空间为kube-system,pod名称为metrics-server-6fdb89bdcb-8t4rs的执行状态信息
kubectl logs metrics-server-6fdb89bdcb-8t4rs -n kube-system -c metrics-server:查看命名空间为kube-system,pod名称为metrics-server-6fdb89bdcb-8t4rs,容器为metrics-server的日志信息
/data/weiwei/kubectl get event :获取event信息
/data/weiwei/kubectl get events --all-namespaces :获取所有命名空间的event
/data/weiwei/kubectl api-versions -n hubble-manager:查看当前可用的API版本
-o wide:查看详情,比如pod的ip
./kubectl get pod -n deepflow -o wide
强制删除pod:/data/weiwei/kubectl delete pod mimir4-ingester-zone-c-0 -n iks-ns-hubble-mimir --force --grace-period=0
在Kubernetes中,当我们想要强制删除一个pod时,需要在调用 `kubectl delete pod` 命令时添加额外的参数,即 `--force` 和 `--grace-period=0`。
- `--force` 参数表示我们希望强制删除pod,即使它还在运行。这将导致Kubernetes立即删除API server上的Pod对象,并使其不再可用。
- `--grace-period=0` 参数表示我们希望跳过正常的Pod终止过程,不等待执行中的请求或操作完成,而是立即进行终止。
- 通常,在删除Pod对象之前,Kubernetes会执行一定的宽限期(默认为30秒),以允许容器实例正常关闭和释放资源。通过将宽限期设置为0,我们要求Kubernetes立即终止容器,而不等待它们清理和关闭。
需要注意的是,这种强制删除方法可能会导致容器没有适当地关闭,同时数据可能丢失。当可以采用其他删除方法时,应该避免使用 `--force --grace-period=0`。这些选项主要针对那些已经处于危险状态或无法正常终止的Pods,例如由于错误、死锁等问题。
查看资源对象的yaml文件:-o yaml
/data/weiwei/kubectl --kubeconfig ~/.kube/config.baidu get svc mimir-baidu-alertmanager-zone-a -o yaml -n iks-ns-hubble-mimir
指定config操作:
/data/weiwei/kubectl --kubeconfig ~/.kube/kubeconfig.cnhb4-hubble-prod01.default.admin apply -f PrometheusRule.yaml
参考: