最近在整理一些kubernetes的官方/权威资料，在这里做个记录。

官方

• kubernetes入门 https://kubernetes.io/zh/docs/home/
• 在线运行 kubernetes 命令 https://kubernetes.io/docs/tutorials/hello-minikube/
• kubernetes 社区 https://github.com/kubernetes/community

培训

• 阿里CNCF云原生技术公开课 https://edu.aliyun.com/roadmap/cloudnative
• 华为kubernetes系列 CKA培训 https://bbs.huaweicloud.com/forum/thread-11064-1-1.html
• 华为的“IP基础快速入门”系列课程 https://support.huawei.com/onlinetoolweb/ptmngsys/Web/OnlineCourse_NE/zh/mooc_ip_basic.html

博客

• 阿里云系统组技术博客https://kernel.taobao.org/
• 腾讯云容器团队https://tencentcloudcontainerteam.github.io/
• 美团技术博客 https://tech.meituan.com/

文章

• 《Site Reliability Engineering: How Google Runs Production Systems》
• 《BGP in the Data Center (O’Reilly 2017)》
• 《数据中心网络：Spine- Leaf 架构设计综述（2016）》

链接

1. Kubernetes 架构路线图

   整个 设计理念: design-proposals 文档已经被抛弃了，转到 KEP 去了，许多文件都是历史文件，可能已过时或未实施。历史文章可以学习。

   Kubernetes Architecture Current and Future - PPT

2. Kubernetes KEPs

3. kubernetes 设计理念归档

4. Kubernetes 增强提案流程

5. Kubernetes 开发指南

   1. k8s贡献：

      • 贡献者指南 : 了解如何为 Kubernetes 做出贡献
      • GitHub 问题 ：如何对pull问题进行分类。
      • 拉取请求流程：拉取请求何时以及为何关闭。
      • 获取最近的构建：如何获取最近的构建，包括通过 CI 的最新构建。
      • 自动化工具 ：在我们的 github 存储库上运行的自动化的描述。

   2. 开发：

      • 开发指南( development.md )：设置开发环境。
      • 测试( testing.md )：如何在开发沙箱中运行单元、集成和端到端测试。
      • 一致性测试( conformance-tests.md ) 什么是一致性测试以及如何创建/管理它们。
      • 随机失败测试 flaky-tests.md ：目标 99.9% Flaky Tests。
      • 日志约定（logging.md）：klog 级别。
      • 分析 Kubernetes ( profiling.md )：如何将 go pprof 分析器插入 Kubernetes。
      • 新 metric ( instrumentation.md )：如何向 Kubernetes 代码库添加新的指标。
      • 编码约定（coding-conventions.md）：为贡献者提供的编码风格建议。
      • 文档约定（Kubernetes 文档）为贡献者提供的文档风格建议。
      • 在本地运行集群（running-locally.md）：用于开发的快速轻量级本地集群部署。

   3. 针对 Kubernetes API 进行开发：

      • REST API文档： 介绍了REST API通过API服务器暴露。
      • 注释（Annotations）：用于将任意非标识元数据附加到对象。自动化 Kubernetes 对象的程序可能会使用注解来存储少量的状态。
      • API 约定( api-conventions.md )：定义 Kubernetes API 中使用的动词和资源。
      • API 客户端库( Client Libraries )：现有客户端库的列表，包括受支持的和用户贡献的。

   4. 编写插件：

      • 身份验证（Authentication）：身份验证令牌的当前和计划状态。
      • 授权插件（Authorization）：授权适用于主 apiserver 端口上的所有 HTTP 请求。本文档解释了可用的授权实现。
      • 准入控制插件（admission_control）

   5. 构建发布：

      参阅kubernetes/release存储库。

   6. SIG 开发人员相关

6. Kubernetes 里程碑管理

7. kubernetes issue

k8s设计思路

来自Kubernetes 架构路线图

1. 核心，标准化的 API 和执行机制。包括

   • REST 机制
   • 安全性
   • Pod
   • 容器
   • cni
   • csi

   基本稳定，变动不大。

2. 应用管理层，部署和路由部分，就是编排和服务网络相关的内容。包括

   • 健康检查/自恢复
   • 伸缩
   • 服务发现
   • 负载均衡
   • 路由

   k8s默认提供了实现，但允许开发者替换成另一套完整的方案。

3. 治理层，提供更高级别的自动化和策略执行，包括

   • 多租户
   • 监控指标
   • 自动伸缩
   • provisioning
   • 授权方案
   • 配额quota方案
   • 网络方案
   • 存储方案

4. 接口层，用于与 Kubernetes API 交互的常用库、工具、UI 和系统。

5. 生态系统，不属于k8s“真正的一部分”。大部分的开发工作都在这一部分：

   • CI/CD
   • 中间件
   • 日志记录
   • 监控
   • 数据处理
   • PaaS
   • serverless/FaaS
   • 工作流
   • 容器运行时
   • 镜像管理
   • 节点管理
   • 云提供商管理

k8s学习路径

来自https://caicloud.io/blog/5d42b1fb0b15e4002bdd6cf6

1. 第一阶段 炼气期

   • Kubernetes 的背景
   • 安装 Kubernetes 环境
   • Kubernetes 基本概念和使用方法

   不要尝试学习过多的资源类型。学会熟练使用以下常用资源并熟记它们的概念：Pod、Node、Label、Event、Service、Configmap & Secret、Deployment、Namespace。

2. 第二阶段 筑基期

   • Kubernetes 的基本架构
   • Kubernetes 容器调度的基本流程

   学习文章，请不要死记硬背 Kubernetes 架构，要开动大脑去理解其背后设计的原因。

   • 深度解读：输入 kubectl run 后，到底发生了什么？
   • Kubernetes The Hard Way

3. 第三阶段 金丹期

   • Kubernetes API 结构
   • 熟悉 Kubernetes 各个子系统
   • 熟悉 Kubernetes 排错相关内容

   学习文章：

   • Kubernetes 集群排错指南 - feisky

4. 第四阶段 元婴期

   • 加深对各个资源的理解
   • 学习更多 Kubernetes 概念和知识
   • 计算/存储/网络/安全/调度

5. 第五阶段 化神期

   • 学习更多 Kubernetes 集群层面的功能
   • 更加深入学习 Kubernetes 架构和组件能力

   各种参数的学习。保持两个基本点不动摇：

   • 一是懂 Kubernetes 架构和最核心的能力
   • 二是懂得怎么快速定位我们需要的能力

6. 第六阶段 练虚期

   • 对 Kubernetes 的扩展机制了如指掌
   • 可以编写 Kubernetes 控制器，能够基于扩展机制灵活地二次开发

   开发：

   • 常见工具
     • kubebuilder：来自 Kubernetes 官方的 API 扩展项目
     • sample-controller：来自 Kubernetes 官方的一个样例
     • operator-sdk：来自红帽的一个 operator 库
     • shell-operator：适合运维开发使用的 shell operator 库
     • meta-controller：来自 Google 的一个更加”傻瓜”式编写控制器的库
   • API 资源扩展能力
     • Annotation：保存少量非结构化第三方数据
     • Finalizer：资源删除时，用户调用外部系统的钩子
     • CustomResourceDefinition：自定义 Kubernetes API
     • API Aggregation：多个 API Server 聚合，适用于较大量的 API 定制
   • API 访问扩展能力
   • 调度器扩展能力
   • 网络扩展能力
   • 存储扩展能力
   • 运行时扩展能力
   • 特殊硬件或资源扩展能力
     • 扩展资源 Extended Resource：通过 Kubernetes 原生 API 方式支持添加自定义资源
     • 设备插件 Device Plugin：使用 Device Plugin 插件，可以对接任何我们需要的硬件
   • 监控扩展能力

   推荐实现一个端到端的 Kubernetes 控制器，可以对整个 Kubernetes 的二次开发有更加深入的了解。此外，针对所有的扩展能力，建议先建立一个全面的认识，再根据需要深入某一项能力。

   除了通过用户手册来学习上面的技术，也可多参考 Kubernetes 的花式设计文档，主要是 Design Proposals、KEPs。

7. 第七阶段 大乘期

   • 了解 Kubernetes 生态项目
   • 跟踪 Kubernetes 社区发展
   • 跟踪 CNCF 社区发展

开启

系统偏好设置 -> 共享

确认

launchctl list | grep ssh

命令行开启或关闭：

sudo launchctl load -w /System/Library/LaunchDaemons/ssh.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/ssh.plist

打开 Hyper-V 管理器。

快速创建，选择Ubuntu即可。

什么是 Journal

Systemd 是Linux 系统中最新的初始化系统（init）。，它主要的设计目标是克服原有 sysvinit 固有的缺点，提高系统的启动速度。

很多主流发行版都迁移到了或者正在迁移到 systemd，CentOS 7 和 Debain 8.0 Jessie 都默认启用了 Systemd。

systemd-journal 是 systemd 引入的系统日志记录工具。在 Debian 中， 日志会首先到达 systemd-journal，并且被保存为 journal 文件，同时再转一个副本给 rsyslog，由 rsyslog 控制写到 /var/log/ 目录下。

清理

检查当前 journal 使用磁盘量

journalctl --disk-usage

清理方法可以采用按照日期清理，或者按照允许保留的容量清理

journalctl --vacuum-time=2d
journalctl --vacuum-size=500M

启用日志限制持久化配置，可以修改 /etc/systemd/journald.conf

SystemMaxUse=16M
ForwardToSyslog=no

然后重启

systemctl restart systemd-journald.service

检查journal是否运行正常以及日志文件是否完整无损坏

journalctl --verify

原文链接：https://toutiao.io/posts/sgqi2d/preview

业务背景

为什么需要获取用户的地理位置？

1.算法推荐类需求：例如需要用户的地区信息、美拍热门推荐、美拍同城直播列表等；

2.统计类需求：获取用户地区维度做相应的统计指标报表 (新增、活跃、留存等)；

3.用户画像及其他在线业务类：如美拍账号经济体系需要检测校验用户的常用登陆地信息。

怎么获取用户的地理位置？

1.手机定位服务（需要用户授权）

通过经纬度获取用户的位置信息，有以下几种方式：

/ GPS：根据系统 GPS 模块获取经纬度，精度 10-100 米左右，限制是容易受环境影响，在室内几乎不起作用；

/ 基站（移动网络）：根据运营商基站位置计算经纬度，精度 1000-3000 米左右，限制是定位较慢，精度差；

/ WIFI：根据周围 WIFI 路由器位置计算经纬度，精度 100-200 米左右，限制是受周围 WIFI 数量和分布影响，需要打开手机 WIFI 开关；

2.用户属性（需要用户主动设置）

系统设置的地区，如 iOS 系统需要设置语言与地区；

用户属性设置，如手机 QQ 设置的所在地。

3.IP（不需要用户参与）

传输层 TCP 协议直连，可以直接获取 Remote_Addr；

HTTP 应用层，通过 HTTP Header （X-Forwarded-For，X-Real-Ip）；

获取了用户请求的来源 IP，通过 IP 库查找对应的地区信息。

总体来说，需要用户参与的能定位到唯一的设备和用户，但是需要用户主动上传位置信息或相关信息；不需要用户参与的定位方式不需要硬件支持，普适性更强。

Tips

IP 地址属于运营商的资产，运营商很容易将属于自己的 IP 资产与地理位置绑定起来，运营商可以将一段段的 IP 地址绑定到某台物理设备上，于是就生成了 IP 地理信息库(GeoIP)，当把全球的 IP 地理信息库融合为一体，就可以根据用户的 IP 来粗略获得用户的位置信息。

IP 的应用场景

全球 IPV4 全库约有 43 亿 IP 地址数据，根据不同的属性可以将 IP 地址分成 9 种不同的应用场景，分别是住宅用户、企业专线、学校机构、移动网络（3G/4G）、WLAN 热点、基础设施、数据中心、交换中心、卫星通信等。这 9 种应用场景可分为非人类使用的场景和有真人使用的场景：

• • 非人类使用的场景：例如交换中心、数据中心和基础设施，这三类场景下的IP地址会定位到其所在机房，能定位到街道级别，但此类 IP 地址一般不用于普通用户访问互联网；
  • 真人使用的场景：例如企业专线和学校机构，IP 地址使用人群出现的位置相对固定，能定位到街道级别；

住宅用户、WLAN热点、移动网络（3G/4G）和卫星通讯，IP地址使用人群出现的位置覆盖相对较广，能定位到一定的区域。

住宅用户这类场景下的IP地址可以覆盖一个行政区的部分区域，能定位到街道级别或者区县级别；

WLAN热点可定位到区县级别或者城市级别；

移动网络（3G/4G）可定位到省级别；

卫星通讯可定位到国家级别。

IP 库从何而来

IP 库按照精度可以分为城市级数据库、区县级数据库、街级数据库，如图所示国内外也有不同类型的常用 IP 库：

其中 IPIP.NET 受到多数知名企业的青睐，如今日头条、滴滴、快手、小米、GrowingIO、诸葛 IO 等。

架构设计与实现原理

使用场景

1.IP 与地区的映射关系每天都在变更，IP 库需要定期更新，以保证 IP 转地区的准确性、时效性；

2.用户不关心具体的 IP 库格式以及背后复杂的查询算法，并且用户希望使用当前最新的 IP 库，因此需要封装一层供用户使用；

3.一些业务方不希望强耦合于 IP 库，调用的频次比较低，比较适合访问 HTTP API 就能获取 IP 与地区的映射，如线上 API 服务；

4.一些服务性能要求场景比较高，并且调用频次比较高，适合将 IP 库加载到内存缓存在程序内调用，如 collector-server（SDK 用户行为上报收集服务）；

5.离线统计场景需要访问 IP 库，如 Hive IP 地区相关的 udf 方法。

整体架构及模块功能介绍

economy-api ：检测账号是否安全的 api 接口服务

根据不同业务场景美图搭建的 GeoIP 整体架构图如上所示，接下来具体介绍各个模块的功能。

Geo Lib Server

Geo Lib Server 是基于 Netty 搭建 IP 库的 HTTP File Server 服务，提供 IP 库下载接口，服务内部实现 IP 库定期更新、IP 库校验、IP 库多版本管理等功能。它的架构如上图所示，其中包含 6 个模块：

• • IPFileDownloader：负责从 IPIP.NET 下载 IP 数据到本地磁盘，并对校验文件大小与 Content-Length；
  • IPFileHandler：解析 IP 数据，根据地区映射 Location 表，生成公司内部的 IP 库格式；
  • IPFileVerifier：对应生成的 IP 库数据做检验，如：对应 IP 库的大小、IP 库的变化情况等；
  • IPFileCompressor：对生成的 IP 库进行压缩，便于后面的 IP 库的传输（gzip）；
  • IPFileUploader：把新版的 IP 库上传一份到 HDFS，供 Kafka-ETL 与 Hive Job 统计使用；

Tips

1.IP 库只有在所有流程处理完后，才能对外提供下载；IP 库上传HDFS，只有上传成功并且完整，才能对外提供；那如何保证呢？ Linux 内核给我们提供了原子的 rename，而 HDFS DistributedFileSystem 提供了原子的 rename。

2.IP 库下载接口从本地磁盘加载，如何减少网络传输性能开销？ 使用 Netty FileRegion 内部封装 Java NIO 的 FileChannel.transferTo()方法，transferTo()方法将数据从一个文件 channel 传输到一个可写 channel，在内部它依赖于操作系统对 Zero-copy 的支持。使用 Netty FileRegion 内部封装 Java NIO 的 FileChannel.transferTo()方法，transferTo()方法将数据从一个文件 channel 传输到一个可写 channel，在内部它依赖于操作系统对 Zero-copy 的支持。

GeoIP HTTP

GeoIP HTTP 是一个无状态的 HTTP 服务，提供一个 IP 与地区相关的 REST API。 每天定时从 Geo Lib Server 下载最新的 IP 库到本地磁盘，并更新内存的 IP 库，保证了 IP 数据的时效性。GeoIP HTTP 提供 HTTP REST API 供第三方调用，主要是 IP 转地区，地区 id 与地区名称的映射等接口，它提供的功能如下：

• • 通过 IP，可查找到 IP 对应的国家、省份、城市
  • id 获取对应的地区名
  • 获取中国的所有省份列表（包括直辖市、自治区、港澳台）
  • 查询中国省份下的城市信息
  • 获取所有地区列表
  • 判断 IP 是否属于欧盟国家
  • ……

Geo Client

Geo Client 封装的 IP 库使用客户端，主要供 IP 查询地区信息的功能，内部兼容多种 IP 库格式，支持 IP 库定期更新。

IP 库格式演进

信息组成

在 IP 库内地区名称往往会与地区 ID 做成映射，其目的主要是为了节省存储、避免城市名称重复，例如城市名伯明翰在美国、英国都有，甚至一个国家不止一个；二来也可以避免一些直辖市等特殊情况。

地区信息 Location 表，其形式如下：

IP 库的文本格式如下：

基于 IP 库查询数据

IP 库的 IP 是连续并且有序的，每个IP 段对应的一个地区。

若要查询一个 IP 所属的地区，需要遍历所有的 IP 段，寻找查询的 IP 是落在哪个 IP 段之间，例如：要查询 1.0.1.10，通过上面这张图，我们很容易知道这个 IP 是中国福建的。其遍历方式主要有三种：顺序遍历、二分法和红黑树。

将每一个 IP 段看作一个节点元素，每个节点元素之间是连续有序的。 基于 JDK 自带的 TreeSet，以 end_ip 实现比较算法，符合 ip_start =< ip <= end_ip 即可实现快速查询。

遇到哪些问题？

随着时间的增长， IP 库越来越大，需要消耗越来越多的内存空间以及加载时间。并且考虑到 IP 定期更新，每次更新完有大量对象晋升老年代引发 Minor GC 停顿时间过长；另外， ETL 与 Hive 统计任务通过 DistributeCache 分发 IP 库至各个结算节点，也会占用更多的网络带宽资源。

如何设计新版 IP 库格式？

IP 库格式直接影响了它的查询性能，首先梳理它存在以下问题：

• • 地区信息重复，同一个地区存在多个 IP 段

    27.148.160.0 27.148.195.255 10184:中国 10262:福建 10550:厦门 27.148.219.0 27.148.219.255 10184:中国 10262:福建 10550:厦门 27.148.224.0 27.148.224.255 10184:中国 10262:福建 10550:厦门 ….

  • 每个 IP 段对应一个对象， 占用较大堆空间

根据以上问题提出的优化方案如下：

1.很多 IP 段表示同一地区——将地区信息进行去重操作；

2.红黑二叉树的 TreeSet 是基于占用空间较大的 Java 对象做的——通过较为紧凑有序的字节数据代表 IP 库，并基于二分查找。

据此，我们的 IP 库经历了三次迭代：

/ 第一版

其中第一块数据是有序紧凑排列的 IP 段信息，包括开始 IP、结束 IP、地区信息位置偏移量及地区信息长度；第二块数据是地区信息，每一行代表一个完整的地区信息（country → province/area → city )。其中 12 字节的 IP segment 组成如下所示：

该版本的查询方式是通过二分法遍历 IP 找出所在 IP 段，并根据其偏移量获取地区信息，由于每次查询都要二分所有 IP 段，较低效。

/ 第二版

根据第一版的问题我们参考早期的「HashMap 数组+链表」的实现，对所有 IP 地址第一部分进行分组并建立索引。

分组后查询可先进行分组查找再进行二分法查找，提高部分查询性能。但由于每个 IP 开头不同对应的 IP 段个数不一样，IP 段个数较多的部分依然需要较长的查询时间。

/ 第三版

在第三版我们继续细化，对 IP 的前两段进行分组构建快速查询。

迭代至此，美图 IP 库组成如下所示：

IP 库由字节组成，首先 header 包含 4 个字节，它代表整个索引区的长度；接着是分组索引，它包含 2562564 字节长度；IP 段如上文所述包括开始 IP、结束 IP、地区偏移量及地区信息长度；最后的地理信息由于字符不确定，它的字节长度无法预计。

当一个 IP 传输过来时，我们取其前两段找到分组，得到它对应的 IP 段范围，再对分组内的 IP 段进行二分法查找对应的 IP 段，通过地区信息的偏移量及其长度确认其地理信息进行解析。

后续 IP 库设计

目前我们的 IP 库包含两个 IP 信息：开始 IP 及结束 IP，在 IP 段是有序连续的情况下，后续我们只需保留结束 IP 即可。

实践经验

IP 库体积

基于上文所述迭代演化，IP 库从原来文本格式的 200+ M 压缩至如今的数据格式 30+ M。

查询性能耗时（查询 2800w 线上 IP 数据）

未来展望

美图 IP 库接下来的优化主要分为三个方向：

1.争取通过优化格式使 IP 库体积越来越小，查询性能得到更大的提升；

2.扩展更多海外 IP 数据及经纬度信息；

3.IP 库监控方面提高识别率，调整监控幅度。

参考文献

• 什么是高精准IP地址定位？
• http://ipip.net
• IP 库之手机基站数据篇
• 为什么根据 IP 地址查询物理所在地，而不是 mac 地址？

在Mac下进行git操作，在默认设置下，中文文件名在工作区状态输出，中文名不能正确显示，而是显示为八进制的字符编码，平时操作非常不方便。可以使用一下命令取消 0x80 以上的字符进行quote编码

$ git config --global core.quotepath false

或者手动更改配置文件~/.gitconfig，编辑添加如下内容即可：

[core]
quotepath = false

麒麟堡垒机用于运维管理的认证、授权、审计等监控管理。因为也有开源版本，所以颇受欢迎。厂家也提供了比较完善的用于Windows访问的一系列工具，比如ssh登陆原生支持putty，xshell，sercurecrt等工具。

而对于 Mac，一般使用原生 shell 或 iterm2 登陆服务器。由于Mac小众的特点，客户公司也很少对其做兼容，使用Mac的也只能自力更生了。

ssh {username}--{server-id}@{proxy-ip}
ssh kelu--9876@1.1.1.1

稍微解释下，username是你登陆堡垒机的账号，server-id是堡垒机界面上显示的要登陆服务器的id，proxy-ip是堡垒机中转服务器的IP。

其实通过堡垒机登陆服务器的逻辑就是，将你的认证信息交给堡垒机验证，验证通过后堡垒机根据id找到目的服务器，注入服务器默认账户的账号密码，将请求转发过去，完成。