Kui 简介

Kui 为构建云原生应用程序提供了新的开发经验。Kui使您能够操作复杂的 JSON 和 YAML 数据模型，集成不同的工具，并提供对操作数据的聚合视图快速访问。

演示

1
2

# 查看 monitoring 命名空间中 pods
$ kubectl kui get pods -n monitoring --ui

1
2

# 查看 deployment 概要
$ kubectl kui get deployment -n monitoring --ui

白话kubernetes Runtime

回想最开始接触 k8s 的时候, 经常搞不懂 CRI 和 OCI 的联系和区别, 也不知道为啥要垫那么多的 “shim”(尤其是 containerd-shim 和 dockershim 这两个完全没啥关联的东西还恰好都叫 shim). 所以嘛, 这篇就写一写 k8s 的 runtime 部分, 争取一篇文章把下面这张 Landscape 里的核心项目给白话明白

前言

如果你使用过 kubeadm 部署过 Kubernetes 的环境, master 主机节点上就一定会在相应的目录创建了一大批证书文件, 本篇文章就来说说 kubeadm 到底为我们生成了哪些证书。

在Kubernetes的部署中, 创建证书, 配置证书是一道绕不过去坎儿, 好在有kubeadm这样的自动化工具, 帮我们去生成, 配置这些证书. 对于只是想体验Kubernetes或只是想测试的亲来说, 这已经够了, 但是作为Kubernetes的集群维护者来说, kubeadm更像是一个黑盒, 本篇文章就来说说黑盒中关于证书的事儿~

使用kubeadm创建完Kubernetes集群后, 默认会在 /etc/kubernetes/pki 目录下存放集群中需要用到的证书文件, 整体结构如下图所示:

故障一

问题表现

集群中有台node服务器因为资源达到上限出现假死现状，重启后发现calico node 无法启动成功，提示如下信息：

1

:Readiness probe failed: caliconode is not ready: BIRD is not ready: BGP not established with 172.18.0.1

使用 calicoctl node status 命令查看node状态信息提示如下：

1
2
3
4
5
6
7
8
9

Calico process is running.

IPv4 BGP status
+--------------+-------------------+-------+----------+--------------------------------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |              INFO              |
+--------------+-------------------+-------+----------+--------------------------------+
| 172.18.0.1   | node-to-node mesh | start | 01:56:41 | Connect Socket: Network        |
|              |                   |       |          | unreachable                    |
+--------------+-------------------+-------+----------+--------------------------------+

概览

当 Kubernetes 中 Node 节点出现状态异常的情况下，节点上的 Pod 会被重新调度到其他节点上去，但是有的时候我们会发现节点 Down 掉以后，Pod 并不会立即触发重新调度，这实际上就是和 Kubelet 的状态更新机制密切相关的，Kubernetes 提供了一些参数配置来触发重新调度到嗯时间，下面我们来分析下 Kubelet 状态更新的基本流程。

1. kubelet 自身会定期更新状态到 apiserver，通过参数 --node-status-update-frequency 指定上报频率，默认是 10s 上报一次。
2. kube-controller-manager 会每隔 --node-monitor-period 时间去检查 kubelet 的状态，默认是 5s。
3. 当 node 失联一段时间后，kubernetes 判定 node 为 notready 状态，这段时长通过 --node-monitor-grace-period 参数配置，默认 40s。
4. 当 node 失联一段时间后，kubernetes 判定 node 为 unhealthy 状态，这段时长通过 --node-startup-grace-period 参数配置，默认 1m0s。
5. 当 node 失联一段时间后，kubernetes 开始删除原 node 上的 pod，这段时长是通过 --pod-eviction-timeout 参数配置，默认 5m0s

   kube-controller-manager 和 kubelet 是异步工作的，这意味着延迟可能包括任何的网络延迟、apiserver 的延迟、etcd 延迟，一个节点上的负载引起的延迟等等。因此，如果 --node-status-update-frequency 设置为5s，那么实际上 etcd 中的数据变化会需要 6-7s，甚至更长时间。Kubelet在更新状态失败时，会进行 nodeStatusUpdateRetry 次重试，默认为 5 次。

Kubelet 会在函数 tryUpdateNodeStatus 中尝试进行状态更新。Kubelet 使用了 Golang 中的 http.Client() 方法，但是没有指定超时时间，因此，如果 API Server 过载时，当建立 TCP 连接时可能会出现一些故障。

因此，在 nodeStatusUpdateRetry * --node-status-update-frequency 时间后才会更新一次节点状态。

同时，Kubernetes 的 controller manager 将尝试每 --node-monitor-period 时间周期内检查nodeStatusUpdateRetry 次。在 --node-monitor-grace-period 之后，会认为节点 unhealthy，然后会在--pod-eviction-timeout 后删除 Pod。

kube proxy 有一个 watcher API，一旦 Pod 被驱逐了，kube proxy 将会通知更新节点的 iptables 规则，将 Pod 从 Service 的 Endpoints 中移除，这样就不会访问到来自故障节点的 Pod 了。

tcpdump 简介

对于 tcpdump 的使用，大部分管理员会分成两类。有一类管理员，他们熟知 tcpdump 和其中的所有标记；另一类管理员，他们仅了解基本的使用方法，剩下事情都要借助参考手册才能完成。出现这种情况的原因在于， tcpdump 是一个相当高级的命令，使用的时候需要对网络的工作机制有相当深入的了解。

在今天的文章中，我想提供一个快速但相当实用的 tcpdump 参考。我会谈到基本的和一些高级的使用方法。我敢肯定我会忽略一些相当酷的命令，欢迎你补充在评论部分。

在我们深入了解以前，最重要的是了解 tcpdump 是用来做什么的。 tcpdump 命令用来保存和记录网络流量。你可以用它来观察网络上发生了什么，并可用来解决各种各样的问题，包括和网络通信无关的问题。除了网络问题，我经常用 tcpdump 解决应用程序的问题。如果你发现两个应用程序之间无法很好工作，可以用 tcpdump 观察出了什么问题。 tcpdump 可以用来抓取和读取数据包，特别是当通信没有被加密的时候。

location 教程

示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

location  = / {
    # 精确匹配 / ，主机名后面不能带任何字符串
    [ configuration A ] 
}

location  / {
    # 因为所有的地址都以 / 开头，所以这条规则将匹配到所有请求
    # 但是正则和最长字符串会优先匹配
    [ configuration B ] 
}

location /documents/ {
    # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
    # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
    [ configuration C ] 
}

location ~ /documents/Abc {
    # 匹配任何以 /documents/ 开头的地址，匹配符合以后，还要继续往下搜索
    # 只有后面的正则表达式没有匹配到时，这一条才会采用这一条
    [ configuration CC ] 
}

location ^~ /images/ {
    # 匹配任何以 /images/ 开头的地址，匹配符合以后，停止往下搜索正则，采用这一条。
    [ configuration D ] 
}

location ~* \.(gif|jpg|jpeg)$ {
    # 匹配所有以 gif,jpg或jpeg 结尾的请求
    # 然而，所有请求 /images/ 下的图片会被 config D 处理，因为 ^~ 到达不了这一条正则
    [ configuration E ] 
}

location /images/ {
    # 字符匹配到 /images/，继续往下，会发现 ^~ 存在
    [ configuration F ] 
}

location /images/abc {
    # 最长字符匹配到 /images/abc，继续往下，会发现 ^~ 存在
    # F与G的放置顺序是没有关系的
    [ configuration G ] 
}

location ~ /images/abc/ {
    # 只有去掉 config D 才有效：先最长匹配 config G 开头的地址，继续往下搜索，匹配到这一条正则，采用
    [ configuration H ] 
}

location ~* /js/.*/\.js

背景

在 Kubernetes 开源生态中，资源监控有 metrics-server、Prometheus等，但这些监控并不能实时推送 Kubernetes 事件，监控准确性也不足。当 kubernetes 集群中发生 Pod因为 OOM 、拉取不到镜像、健康检查不通过等错误导致重启，集群管理员其实是不知道的，因为 Kubernetes 有自我修复机制，Pod宕掉，可以重新启动一个。这样让集群管理员很难立即发现服务问题。

Kubernetes 事件

Kubernetes中，事件分为两种：

• Warning事件：表示产生这个事件的状态转换是在非预期的状态之间产生的
• Normal事件：表示期望到达的状态，和目前达到的状态是一致的

Derrick 简介

Derrick 是一个可以帮助开发者快速完成应用容器化的工具。Derrick 主要关注的是希望容器化的开发者如何在本地进行开发的问题。开发者可以通过使用 Derrick 加速本地应用容器化迁移的过程。

Derrick 自动生成以下配置

• Dockerfile
• .dockerignore
• docker-compose.yml
• Jenkinsfile
• kubernetes-deployment.yaml

ELK 是什么？[1]

ELK 是三个开源项目的首字母缩写，这三个项目分别是：Elasticsearch、Logstash 和 Kibana。

• Elasticsearch 是一个分布式的开源搜索和分析引擎，适用于所有类型的数据，包括文本、数字、地理空间、结构化和非结构化数据。
• Logstash 是服务器端数据处理管道，能够同时从多个来源采集数据，转换数据，然后将数据发送到诸如 Elasticsearch 等“存储库”中。
• Kibana 则可以让用户在 Elasticsearch 中使用图形和图表对数据进行可视化。

Elasticsearch 的用途是什么？[2]

Elasticsearch 在速度和可扩展性方面都表现出色，而且还能够索引多种类型的内容，这意味着其可用于多种用例：

• 应用程序搜索
• 网站搜索
• 企业搜索
• 日志处理和分析
• 基础设施指标和容器监测
• 应用程序性能监测
• 地理空间数据分析和可视化
• 安全分析
• 业务分析