如果采用 Logstash 集中接收 Filebeat 的日志输入，容易造成单点瓶颈；如果采用 Kafka 接收 Filebeat 的日志输入，日志的时效性又得不到保障。这里直接将 Filebeat 采集的日志直接输出到 Elasticsearch。 1. 准备工作 节点规划 这里没有区分 master、data、client 节点，而是

1. 创建负载时，通过 nodeSelector 指定 Node 给节点添加标签 1 kubectl label node node2 project=A 指定 nodeSelector 创建工作负载 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: nginx-nodeselector spec: replicas: 1 selector: matchLabels: app: nginx-nodeselector template: metadata: labels: app: nginx-nodeselector spec: nodeSelector: project: A containers: - name: nginx image: nginx EOF 查看工作负载 1 2 3 4 kubectl get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES

1. 应用架构与业务发展、运维能力匹配 在行业会议、文档博客中，我们时常能见到各种优秀的解决方案，但是如果直接照搬到自己的业务，却又频频碰壁。因为，这些技术方案是特定的业务场景孵化出来的，不同的业务形态、不同的业务规模、不同的业务发展阶段都会影响

1. 为什么需要二次调度 Kubernetes 调度器的作用是将 Pod 绑定到某一个最佳的节点。为了实现这一功能，调度器会需要进行一系列的筛选和打分。 Kubernetes 的调度是基于 Request，但是每个 Pod 的实际使用值是动态变化的。经过一段时间的运行之后，节点的负载并不均衡。一些节点负载

1. 抓取 Tekton Metrics 新增 ConfigMap 配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: config-observability namespace: tekton-pipelines labels: app.kubernetes.io/instance: default app.kubernetes.io/part-of: tekton-pipelines data: metrics.backend-destination: prometheus metrics.taskrun.level: "task" metrics.taskrun.duration-type: "histogram" metrics.pipelinerun.level: "pipeline" metrics.pipelinerun.duration-type: "histogram" EOF 修改 data 中的配置，会改变上报指标的粒度，甚至会严重影响 Prometheus 的性能，需要谨慎修改。 重启 Tekton 1 kubectl -n tekton-pipelines rollout restart deployment tekton-pipelines-controller [可选] 将 tekton-pipelines-controller 设置为 NodePort