故障一

故障现象

kubelet 启动不了，通过命令 journalctl -u kubelet 查看日志，报 Failed to start ContainerManager failed to initialize top level QOS containers: failed to update top level Burstable QOS cgroup : failed to set supported cgroup subsystems for cgroup [kubepods burstable]: failed to find subsystem mount for required subsystem: pids

故障分析

根据报错，有用的信息是 failed to find subsystem mount for required subsystem: pids，通过命令 ls -l /sys/fs/cgroup/systemd/kubepods/burstable/ 查看，该目录下没有 pids 目录。

SupportPodPidsLimit 在 kubernetes 1.14+ 默认开启。 SupportNodePidsLimit 在 1.15+ 默认开启。

相关Issues：https://github.com/kubernetes/kubernetes/issues/79046

解决方法

• 方法一：编辑 kubelet 配置文件，添加 --feature-gates=SupportPodPidsLimit=false,SupportNodePidsLimit=false 参数，后面在重启 kubelet 服务。
• 方法二：可以升级系统内核 5+ 版本

临时存储简介

Node节点通常还可以具有本地的临时性存储，由本地挂载的可写入设备或者 RAM来提供支持。 临时（Ephemeral） 意味着对所存储的数据不提供长期可用性的保证。

Pods 通常可以使用临时性本地存储来实现缓冲区、保存日志等功能。 kubelet 可以为使用本地临时存储的 Pods 提供这种存储空间，允许后者使用 emptyDir 类型的卷将其挂载到容器中。

kubelet 也使用此类存储来保存节点层面的容器日志， 容器镜像文件、以及运行中容器的可写入层。

临时存储有哪些

• 本地临时存储（local ephemeral storage）
• emptyDir

本地临时存储（local ephemeral storage）：Kubernetes在1.8的版本中引入了一种类似于CPU，内存的新的资源模式：ephemeral-storage，并且在1.10版本kubelet中默认打开这个特性。ephemeral-storage是为管理和调度Kubernetes中运行的应用短暂存储。

emptyDir：emptyDir 类型Volume在Pod分配到Node上时被创建，Kubernetes会在Node节点上自动分配一个目录，因此无需指定宿主机Node上对应的目录文件。 这个目录初始内容为空，当Pod从Node上移除时，emptyDir中的数据会被永久删除。

注释：容器的 crashing 事件并不会导致 emptyDir 中的数据被删除。

前言

前几天 纯上 同学问了一个问题：

我 ps aux 看到的RSS内存只有不到30M，但是free看到内存却已经使用了7,8G了，已经开始swap了，请问ps aux的实际物理内存统计是不是漏了哪些内存没算？我有什么办法确定free中used的内存都去哪儿了呢？

这个问题不止一个同学遇到过了，之前子嘉同学也遇到这个问题，内存的计算总是一个迷糊账。 我们今天来把它算个清楚下!

前言

终于，我们推出了Kubernetes 1.19，这是2020年的第二个发行版，并且迄今为止最长的发行周期持续了20周。它由33项增强功能组成。12个增强功能进入稳定版，18个增强功能进入测试版，13个增强功能进入alpha版。

由于 COVID-19、George Floyd 抗议以及我们作为发布团队经历的其他一些全球性事件，因此1.19版本与常规版本完全不同。由于这些事件，我们决定调整我们的时间表，并让 SIG、工作组和贡献者有更多的时间来完成任务。额外的时间也让大家有时间关注 Kubernetes 项目之外的生活，并确保他们的精神状态更加良好。

贡献者是 Kubernetes 的核心，《 Kubernetes行为准则》要求人们彼此优秀，尽管我们的世界动荡不安，但我们从社区中看到的只是伟大和谦卑。

Kubectl 备忘录

Kubectl 自动补全

BASH 环境下设置

1
2
3
4
5
6
7
8
9
10
11
12

# Centos 或者 RedHat 需要安装 bash-completion 包命令
$ yum install -y bash-completion

# Ubuntu 或者 Debian 需要安装 bash-completion 包命令
$ apt install -y bash-completion

# 写入当前用户 .bashrc 文件中
$ echo "source /usr/share/bash-completion/bash_completion" >> ~/.bashrc
$ echo "source <(kubectl completion bash)" >> ~/.bashrc

# 让当前终端生效
$ source ~/.bashrc

Harbor 镜像回收流程

Harbor 镜像回收分两部分：

• 1、删除镜像 TAG
• 2、执行垃圾清理

早期 Harbor 1.0 版本时，删除镜像TAG可以通过UI界面手动一个个选取删除，也可以调用官方提供的SDK删除（很早以前官方不维护了）。后来官方在 1.9 版本提供TAG保留策略，解决以前镜像Tag回收麻烦的问题。

TAG保留策略有那些策略，如下图：

集群相关

简述ETCD及其特点？

etcd 是 CoreOS 团队发起的开源项目，是一个管理配置信息和服务发现（service discovery）的项目，它的目标是构建一个高可用的分布式键值（key-value）数据库，基于 Go 语言实现。

特点：

• 简单：支持 REST 风格的 HTTP+JSON API
• 安全：支持 HTTPS 方式的访问
• 快速：支持并发 1k/s 的写操作
• 可靠：支持分布式结构，基于 Raft 的一致性算法，Raft 是一套通过选举主节点来实现分布式系统一致性的算法。

简述ETCD适应的场景？

etcd基于其优秀的特点，可广泛的应用于以下场景：

• 服务发现(Service Discovery)：服务发现主要解决在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听udp或tcp端口，并且通过名字就可以查找和连接。
• 消息发布与订阅：在分布式系统中，最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。 应用中用到的一些配置信息放到etcd上进行集中管理。
• 负载均衡：在分布式系统中，为了保证服务的高可用以及数据的一致性，通常都会把数据和服务部署多份，以此达到对等服务，即使其中的某一个服务失效了，也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后，每个etcd的核心节点都可以处理用户的请求。所以，把数据量小但是访问频繁的消息数据直接存储到etcd中也可以实现负载均衡的效果。
• 分布式通知与协调：与消息发布和订阅类似，都用到了etcd中的Watcher机制，通过注册与异步通知机制，实现分布式环境下不同系统之间的通知与协调，从而对数据变更做到实时处理。
• 分布式锁：因为etcd使用Raft算法保持了数据的强一致性，某次操作存储到集群中的值必然是全局一致的，所以很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。
• 集群监控与Leader竞选：通过etcd来进行监控实现起来非常简单并且实时性强。

数据库

简述NoSQL是什么？

NoSQL，指的是非关系型的数据库。NoSQL 有时也称作 Not Only SQL（意即”不仅仅是SQL”） 的缩写，其显著特点是不使用SQL作为查询语言，数据存储不需要特定的表格模式。

简述NoSQL（非关系型）数据库和SQL（关系型）数据库的区别？

NoSQL和SQL的主要区别有如下区别：

• 存储方式：
  • 关系型数据库是表格式的，因此存储在表的行和列中。他们之间很容易关联协作存储，提取数据很方便。
  • NoSQL数据库则与其相反，它是大块的组合在一起。通常存储在数据集中，就像文档、键值对或者图结构。
• 存储结构
  • 关系型数据库对应的是结构化数据，数据表都预先定义了结构（列的定义），结构描述了数据的形式和内容。预定义结构带来了可靠性和稳定性，但是修改这些数据比较困难。
  • NoSQL数据库基于动态结构，使用与非结构化数据。由于NoSQL数据库是动态结构，可以很容易适应数据类型和结构的变化。
• 存储规范
  • 关系型数据库的数据存储为了更高的规范性，把数据分割为最小的关系表以避免重复，获得精简的空间利用。
  • NoSQL数据存储在平面数据集中，数据经常可能会重复。单个数据库很少被分隔开，而是存储成了一个整体，这样整块数据更加便于读写 。
• 存储扩展
  • 关系型数据库数据存储在关系表中，操作的性能瓶颈可能涉及到多个表，需要通过提升计算机性能来克服，因此更多是采用纵向扩展
  • NoSQL数据库是横向扩展的，它的存储天然就是分布式的，可以通过给资源池添加更多的普通数据库服务器来分担负载。
• 查询方式
  • 关系型数据库通过结构化查询语言来操作数据库（即通常说的SQL）。SQL支持数据库CURD操作的功能非常强大，是业界的标准用法。
  • NoSQL查询以块为单元操作数据，使用的是非结构化查询语言（UnQl），它是没有标准的。
  • 关系型数据库表中主键的概念对应NoSQL中存储文档的ID。
  • 关系型数据库使用预定义优化方式（比如索引）来加快查询操作，而NoSQL更简单更精确的数据访问模式。
• 事务
  • 关系型数据库遵循ACID规则（原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)）。
  • NoSQL数据库遵循BASE原则（基本可用（Basically Availble）、软/柔性事务（Soft-state ）、最终一致性（Eventual Consistency））。
  • 由于关系型数据库的数据强一致性，所以对事务的支持很好。关系型数据库支持对事务原子性细粒度控制，并且易于回滚事务。
  • NoSQL数据库是在CAP（一致性、可用性、分区容忍度）中任选两项，因为基于节点的分布式系统中，不可能同时全部满足，所以对事务的支持不是很好。

运维工具

简述Ansible及其优势？

Ansible是一款极其简单的开源的自动化运维工具，基于Python开发，集合了众多运维工具(puppet, cfengine, chef, func, fabric)的优点。实现了批量系统配置，批量程序部署，批量运行命令等功能。
同时Ansible是基于模块工作，其实现批量部署的是ansible所运行的模块。

Ansible其他重要的优势：

• 跨平台支持：Ansible在物理、虚拟、云和容器环境中为Linux、Windows、UNIX和网络设备提供无代理支持。
• 人类可读的自动化：Ansible playbook以YAML文本文件的形式编写，易于阅读，有助于确保每个人都理解他们将要做的事情。
• 对应用程序的完美描述：Ansible playbook可以进行任何更改，并且可以描述和记录应用程序环境的每个细节。
• 易于管理的版本控制：Ansible剧本和项目是纯文本。它们可以像源代码一样处理，并放在现有的版本控制系统中。
• 支持动态库存：Ansible管理的机器列表可以从外部资源动态更新，以便随时捕获所有受管服务器的正确的当前列表，无论基础设施或位置如何。
• 易于与其他系统集成的编排：HP SA、Puppet、Jenkins、Red Hat Satellite，以及存在于环境中的其他系统，都可以被利用并集成到Ansible工作流中。

基础服务

简述Linux中常见的系统服务，其作用分别是？

常见的系统服务及其作用有：

• NTP/Chrony：用于时钟同步；
• DHCP：动态主机配置协议，用于自动分配主机地址，默认使用UDP 63端口；
• DNS：域名解析，运行在UDP协议之上，默认使用53端口；
• NFS：网络文件系统，依赖于RCP协议，其基本原则是“容许不同的客户端及服务端通过一组RPC分享相同的文件系统”，它是独立于操作系统，容许不同硬件及操作系统的系统共同进行文件的分享。
• Postfix：邮件服务；
• rsync：远程数据备份服务。
• VPN：虚拟专用网。

更多服务参考：http://c.biancheng.net/view/1059.html。

简述FTP主要的工作模式？

FTP工作模式是以服务端角度来区分，有主动模式和被动模式。

• 主动模式是指由FTP服务端主动向客户端发起连接，服务端端口号为20（用于传输）和21（用于控制），即20端口向客户端的一个大于1024的随机端口传输数据；
• 被动模式是指由FTP客户端向服务端发起连接，服务端采用随机端口等待客户端的随机端口来访问，从而传输数据。