「Kubernetes」- 日志与监控

  CREATED BY JENKINSBOT

问题描述

该笔记将记录:在 Kubernetes 中,查看 Pod 日志及资源占用情况的方法,以及常见问题处理。

解决方案

查看 Pod 日志

# kubectl logs -n kube-system etcd-k8scp-01

// 查看以停止 Pod 的日志(前一个 Pod 实例)

# kubectl logs -n kube-system etcd-k8scp-01 --previous

// 注意事项,如果 Docker 容器被清理,则 --previous 则无法查看前一个容器的日志。

在本章中,我们将集中介绍基础设施与应用程序层的监控与日志。在Kubernetes的环境中,不同的角色通常有不同的职责:

	管理员角色:如集群管理员、网络运营人员、或命名空间管理员等关注基础设施方面的工作人员。常见的问题可能有:节点是否健康?我们是否应该增设一个工作节点?集群的利用率是多少?用户的配额是否快用完了。
	开发人员角色:主要考虑和操作他们的应用程序的上下文环境,在目前的微服务时代,他们可能要关心几个甚至十几个应用程序。例如,承担开发角色的工作人员可能会问:我是否为我的应用分配了足够的资源?我的应用应该扩展到多少个副本?我是否可以访问正确的卷,以及还有多少容量?是否有运行失败的应用,如果有,原因是什么?

我们首先利用Kubernetes的「存活探针」和「就绪探针」,来讨论集群内部的监视,然后集中讨论如何利用 Heapster 和 Prometheus 来监视集群,最后我们将介绍日志相关的内容。

11.1. Accessing the Logs of a Container

使用kubectl logs命令查看日志:

	# kubectl logs --help
	# kubectl get pods --namespace "your namespace"
	# kubectl logs "pod name" --namespace "your namespace"

如果一个Pod中存在多个容器,则可以是使用-c选项,指定要使用的Pod命名。

11.2. Recover from a Broken State with a Liveness Probe

如何确保当pod中运行的应用程序进入失败状态时, Kubernetes会自动重启Pod?

可以使用存活探针。如果探针失败,那么 kubelet 会自动重启pod。探针是pod规格的一部分,可以添加到 containers一节的字段中。pod中的每个容器都可以拥有一个存活探针。

探针可以有三种类型:它可以是容器内部运行的命令;也可以是一个HTTP请求,指向容器内由网络服务提供的特定路径;或者是更通用的TCP探针。

下面的例子展示了一个基本的HTTP探针:

apiversion: v1
kind: Pod
metadata
  name: liveness-nginx
spec:
  - containers
    name: veness
    image: nginx
    livenessProbe:
      httpGet:
        path: /
        port: 80

Kubernetes容器探针的相关文档(https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes%EF%BC%89

11.3. Controlling Traffic Flow to a Pod Using a Readiness Probe

存活探针(请参阅11.2节)能够指示pod启动和运行的状态,但是如何确保在应用程序准备好服务请求之后再接受访问?

可以向pod规格添加就绪探针。与存活探针类似,就绪探针也有三种类型(具体信息请参阅相关文档)。

下面是一个简单的例子,其中就绪探针在nginx Dockerl映像的单个pod上运行。就绪探针向端口80发送了一个HTTP的请求:

apiversion: v1
kind: Pod
metadata:
  name: readiness-nginx
spec:
  containers:
    - name: readiness
      image: nginx
      readinessProbe:
        httpGet:
          path: /
          port: 80

虽然上面介绍的就绪探针与1.2节中所介绍的存活探针相同,但一般情况下两者是不一样的,因为它们旨在提供应用程序不同方面的信息。存活探针负责查看应用程序进程是否处于活动状态,但是应用程序可能并没有准备好接收请求。而就绪探针负责检査应用程序是否可以正确服务请求。因此、只有当通过就绪探针的检査,podオ能成为服务(请参阅5.1节)的一部分。

请参阅Kubernetes容器探针的相关文档(https://kubernetes.io/docs/conceptsworkloads/pods/pod-lifecycle/#container-probes%EF%BC%89

11.4. Adding Liveness and Readiness Probes to Your Deployments

如何自动检查应用是否健康,且在不健康的时候让 Kubernetes做相应的处理?

为了通知 Kubernetes应用的状况,可以添加存活探针和就绪探针,如下所示。首先定义一个部署清单文件:

# foo.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata
  name: webserver
spec:
  replicas: 1
  template:
    metadata:
      name: webserver
    spec:
      containers:
        - name: nginx
          image: nginx:stable
          containerPort: 80
          # 在pod规格中的 containers一节中定义存活探针和就绪探针。请参阅上述介的例子(请参阅112节和11.3节),并向部署pod模板的容器规格中添加如下内容:
          livenessProbe:
            initialDelaySecond: 2
            periodSeconds: 10
            httpGet
          readinessProbe:
            initialDelaySecond: 2
            periodSeconds: 10
            httpGet:
            path: 2
            port: 80

现在启动部署并检査探针:

	# kubectl create -f foo.yaml
	# kubectl get pods
	# kubectl describe pod/webserver-4288715076-dk9c7

为了确认pod内的容器是否健康、是否可以接受访问, Kubernetes提供了系列的健康检査机制。在 Kubernetes里,健康检査称为探针,定义在「容器」一级,而非pod一级,它由两个不同的组成部分:

	每个工作节点上的kubelet使用规格中的livenessProbe指令决定什么时候重启容器。这些存活探针可以帮助应付突发问题或死锁。
	一套pod的服务负载平衡使用readinessProbe指令决定是否Pod准备好并可以接受访问了。如果没有准备好,就从服务器的访问点池中将该pod排除在外。请注意只有当所有容器都谁备就绪,pod才会被当成准备就绪。

至于何时该选用哪种探针,应当根据容器的行为进行选择:

	如果在探测失败的时候,容器可以并且应该被杀掉重启,那么请使用存活探针,并将restartPolicy设置为Always或OnFailure。
	如果想在pod准备就绪之后再接受访问,那么可以使用就绪探针。

请注意后者的情况下,就绪探针也起到了存活探针的作用。

配置存活探针与就绪探针(https://kubernetes.io/docs/asks/configure-podcontainer/configure-liveness-readiness-probes%EF%BC%89
Pod生命周期的相关文档(https://kubernetes.io/docs/concepts/workloadspods/pod-lifecycle%EF%BC%89
初始化容器的相关文档(在v1.6及之后的版本中相对稳定)(https://kubernetes.io/docs/concepts/workloads/pods/init-containers/%EF%BC%89

11.5. Enabling Heapster on Minikube to Monitor Resources

如果需要在 Minitube中使用kubect1 top命令监视资源使用状况的时候,但遇到了Heapster插件未运行的错误,如何解决?

# kubectl top pods
Error from server(Notfound): the server could not find the requested resource(getserviceshttpheapster:)

最新版本的 minitube命令包含了插件管理器,可以在此管理器上通过一个命令激活 Heapster I以及其他插件,如 Ingress控制器等

	# minikube addons enable heapster

启用 Heapster插件会在kube-system命名空间中生成两个pod:一个pod运行Heapster,另外一个运行INFLUXDB时间序列数据库和Grafana的仪表盘。

等待几分钟,在收集到第一个指标后, kubectl top命令即可正常返回资源的指标:

	# kubectl top node
	# kubectl top pods --all-namespaces

现在可以访问 Grafana的仪表盘,并根据喜好自定义显示的内容:

	# minikube service monitoring-grafana -n kube-system

该命令运行完毕后,浏览器将自动打开,并显示如图11-1所示的内容。

11.6. Using Prometheus on Minikube

如何以集中的方式査看集群的系统指标和应用程序指标?

可以按照以下步骤使用Prometheus:

	1.创建一个ConfigMap文件保存 Prometheus的配置。
	2.为Prometheus设置服务账号,并通过RBAC(请参阅10.3节)赋予该服务账号(请参阅10.1节)访问所有指标的权限。
	3.为 Prometheus创建一个应用,它将包括一个部署个服务及一个Ingress资源,所以可以在集群外通过浏览器访问该应用。

(1)首先,需要通过 Config Map对象(请参阅8.3节关于配置映射的介绍)设置 Prometheus。后面的 Prometheus应用会用到该对象。创建一个名为prometheus, yml文件保存 Prometheus的配置,其内容(略过)

	我们可以利用此文件创建配置映射,如下所示:
	# kubectl create configmap prom-config-cm --from-file=prometheus. yml

(2)接下来,设置 Prometheus的服务账号,并在名为 prometheus-rbac. yaml的清单文件中指定角色(权限),内容略过

	现在可以使用该清单文件,创建服务账号,并指定角色:
	# kubectl create -f prometheus-rbac.yaml

(3)现在所有的前提条件都已经准备就绪(配置和访问权限),可以开始配置Prometheus应用。前面说过,该应用包括一个部署,一个服务和一个ingress资源,并且用到了上一个步骤中定义的配置映射和服务账号。接下来,在 prometheus-app. yaml清单文件中定义该 Prometheus应用,内容略过

	现在利用清单文件创建该应用
	# kubectl create -f prometheus-app yaml

恭喜你创建了一个成熟的应用!现在用户可以通过$MINISHIFT_IP/graph路径访问Prometheus

Prometheus是个强大且灵活的监视与预警系统。你可以利用它,最好是再加上某个测量代码库(hrps:/ prometheus.io/docs/instrumenting/clientlibs/)让应用汇报高层次的的指标,如汇报运行过的交易数量等,就像 kubelet汇报CPU使用率一样

Prometheus速度快且具有扩展性,但是需要借助其他软件完成各项指标的可视化。典型的做法是与 Grafana相连接。

在Kubernetes p的1.7.0版本到1.7.2版本中使用 Prometheus存在已知的问题,因为kubelet显示容器指标的行为在v1.7.0中发生了改变

Prometheus的配置在v1.7.0到v1.32中可以正常使用,但是如果在v1.7.3以及更新的版本中使用时,需要参考“ Prometheus配置文件实例”(https:/github.com/prometheus/prometheus/blob/masterdocumentation/ examples/ prometheus- kubernetes yml#L88)一文,进行相应的修改。

请注意此处介绍的解决方案不仅限于 Minitube。事实上,只要可以创建服务账号(也就是说,有足够的权限赋予 Prometheus必要的权限),那么这个解决方案适用于很多环境,包括GKE、ACS或 Openshift

Prometheus测量的相关文档(hrps:/ prometheus.io/ docs/practicesinstrumentation/)
Prometheus I中 Grafana与 Prometheus I的使用文档( htps: prometheus.iodocs/visualization/grafana/)

11.7. Using Elasticsearch–Fluentd–Kibana (EFK) on Minikube

如何以集中的方式査看集群中所有应用的日志?

可以使用 Elasticsearch + Fluentd + Kibana,具体内容如下。

首先,为了做好准备,请确保为 Minitube分配了足够的资源。例如,使用–cpus=4 –memory=4000,并确保 ingress 插件已被激活。

	# minitube start
	# minitube addons list | grep ingress
	# minikube addons enable ingress

接下来,创建名为efk-logging.yaml的清单文件,跳过……

现在可以启动EFK了: kubectl create -f efk-logging.yaml

所有应用都启动以后,所有应用都启动以后,可以利用下面的用户名和密码登录 Kiana,用户名: kiana;密码: changer

打开“https://$IP/app/kiana#/discover?_g=()”,并单击 Discover页签,就可以看到日志了。

可以使用下列命令清理或重启EFK栈

	kubectl delete deploy/es &&
	kubectl delete deploy/kiana && \
	kubectl delete svc/elasticsearch && \
	kubectl delete svc/kiana &&\
	kubectl delete Ingress/Kibana-public && \
	kubectl delete daemonset/fluent

通过 Logstash也可以査看日志。我们在解決方案中选择使用 Fluent,是因为它是云原生计算基金会( Cloud Native Computing Foundation,CNCF)的项日且备受关注。

请注意启动 Kiana需要花费一定的花时间,而且可能需要反复加载几次该网络应用才能完成配置。

Manoj Bhagwat的博文“在 Kubernetes上利用 Fluent和 Elasticsearch集中管理Docker日志
hrps://ediun.com%E2%91%A1nano/.bhaga60ocentralize-your-docker-logs-with-fluenid-and-elasticsearch-on-kubernetes42d2acOe8b6c

Kubernetes基于AWS的EFK機
https://github.com/skillshare/kubernetes-elk

Elk-kubernetes (https://github. com/kayrus/elk-kubernetes)

参考文献

Kubectl Reference Docs / top