我将从本篇开始维护「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。 Docker 6 岁啦 Docker 从 2013 年首次亮相，至今已 6 年之久，而 Docker 也已一度成为容器技术的代名词，很庆幸能投身 Docker 相关的领域。官方博客 Kind (Kubernetes In Docker) 发布 0.2.0 版本 Kind 是一个利用容器技术快速部署本地 Kubernetes 的工具，主要是用于对 Kubernetes 1.11+ 版本的测试。现在发布的 0.2.0 版本支持最新 Kubernetes v1.13.4 及 Docker 18.06.3 且通过了 CNCF 的一致性认证。 Rancher 发布 K8S 最佳安全实践文章 Rancher 在 CNCF 最近发布的 9 个 Kubernetes 最佳安全实践的基础上发布了一篇更安全的最佳实践，这两篇文章都值得一看。 可以通过下面二维码订阅我的文章公众号【MoeLove】

今年的第一篇文章更新，带来一个重大的消息。 CNCF（云原生计算基金会）在美国时间 2019 年 2 月 28 日宣布 containerd 今天正式毕业了。 这是 CNCF 中毕业的第 5 个项目，之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 和 CoreDNS 。 containerd 2014 年从 Docker 孵化出来，最初是作为 Docker 引擎的底层管理器；在 2017 年 3 月被 CNCF 接受后，containerd 几乎成为了行业容器运行引擎的标准，它专注于简单，健壮和可移植性，任何人都可以使用它来构建自己的容器引擎/平台。 “When Docker contributed containerd to the community, our goal was to share a robust and extensible runtime that millions of users and tens of thousands of organizations have already standardized on as part of Docker Engine,” said Michael Crosby, containerd maintainer and Docker engineer.

年底了，惯例做个小回顾，对这一年做个总结，也对下一年大致做个规划。 不过今儿与往年不同的是昨晚突然发高烧，今儿都没能去上班，感谢我的小可爱在照顾我。这篇文章也是躺在床上用手机编辑的。 还是按照惯例从工作，生活两方面来说。先聊聊工作。 工作 现在在网易有道负责 DevOPS 实践落地及 k8s 容器化平台和自动化平台的规划建设等。 总体来说，现在的工作很开心，更能发挥我的所长，也遇到了不错的团队。 说到现在负责的工作，如果大致有些了解的就会知道这个过程比较漫长，推进起来也会有各种阻力。毕竟要改变很多人的思想和习惯，我也在尽量让这一过程变的更加平滑。 同时也在 push 一些理念到行业内，到社区中，不断的进行交流碰撞总结。 社区贡献 今年下半年的贡献和分享相比去年更多一些。主要的分享有: GITC - 《云原生时代下的 CI/CD 实践》 PyCon China - 《基于 Docker 的 CI/CD 实践》 DockerOne 社区 - 《基于 GitLab 的 CI 实践》 Tech Talk Time - 《Docker 实战和基础架构》 分享的主题基本都围绕在容器化和 CI/CD 方面，但每次分享内容却都不一样。 感谢我的小可爱，也感谢所有支持的朋友们。 社区中主要活跃在 Docker 和 Kubernetes 生态方向。维护一些官方镜像，做测试，解决问题，提交代码之类的，明年希望做的更多。 开了一个知乎专栏 『k8s生态』 明年会花更多时间进行建设。 写了一本掘金小册《Kubernetes 从上手到实践》。 其实这个名字并不能很好的概括小册里面的内容，其中也有源码分析之类的。要再次感谢小可爱，感谢编辑 Linmi ，感谢马达老板和何世友老板写的推荐语。也感谢所有人的支持，希望这本小册能对大家有所帮助。 写小册的过程其实也蛮辛苦的，一般要么晚上写，写到凌晨 2~3 点，要么早上 5~6 点钟左右起床，写到去上班。尤其要感谢小可爱，给了我很多支持。

时间飞逝，转眼已经到了圣诞节，今年又要结束了。感谢还在关注的小伙伴，今年确实更新很少，能不取关的都是真爱… 今年发生了很多事情，留着过几天年终总结的时候再说。有很大一部分的休息时间都用来完成了我的第一本掘金小册 《Kubernetes 从上手到实践》 小册已经正式上线，特意送上各位小伙伴一份礼物，小册 8 折优惠。直接扫码 或者点击此链接即可。 以下是关于小册的一些介绍： 随着容器化及微服务等概念的普及，各个公司都在围绕着如何打造生产环境可用的，高效的容器调度平台，应用快速部署，扩容等平台进行探索。Kubernetes 是 Google 在 2014 年基于其多年在 Borg 系统实践总结出的经验而开源出的一套标准化，可扩展的系统。 而发展至现在（2018年）Kubernetes 已经基本成为了容器编排领域事实上的标准，并且大量的公司都已在生产中使用，无论是国外的 Google， Amazon, GitHub 等，还是国内的阿里，腾讯，京东，滴滴及其他中小公司都在进行着大量的探索及实践。 之前在容器化尚未大量推进的时候，开发工程师只需要关注自己业务代码的实现，而运维工程师在反复的为部署，扩容所需的环境而费时费力。 为了解决环境一致性的问题，也为了能够提高资源的利用率，容器化开始逐步推进，开发工程师的交付由原先的交付代码变成了交付镜像，运维工程师可以将精力集中于保障服务的可高用上。 但为了能够快速的发版验证功能，不再受单体化架构的拖累，微服务的概念也在实践中逐步推进，从原先的单体集中式的服务，拆分为多个松耦合的微服务。到了这时，微服务 + 容器化已经大势所趋，生产中要大量使用，则容器编排变的愈发重要。Kubernetes 在容器编排领域目前已成为事实上的标准，大量公司均已在生产中推进，此时，无论是开发工程师还是运维工程师，皆需要了解并掌握 Kubernetes 的基础技能，才不至于丢失自己的竞争力。 Kubernetes 所涉及的知识点很多, 并且版本迭代也很快，本小册将集中于 Kubernetes 的基础技能，以最常见 Case 入手，帮助大家更快的掌握相关知识并将其用于生产实践中。同时在此过程中，也会深入至 Kubernetes 必要的原理中，同时也会提供相关涉及到的 Docker 及 Linux 内核知识的补充，以便让大家不仅知其然，而且知其所以然。 你会学到什么？ Kubernetes 基础架构 Kubernetes 的基础技能, 覆盖常见 Case 从零搭建 Kubernetes 集群 与 Kubernetes 相关的 Docker 和 Linux 内核知识补充 深入 Kubernetes 组件的原理和源码解析 了解 Kubernetes 进阶相关知识体系 适宜人群 了解 Docker，希望能进入 K8S 领域的各领域工程师； 正在或即将在生产环境使用 K8S 的后端工程师； 需要维护或在公司落地 K8S 的运维工程师； 想要走在技术前沿的前端/后端/运维工程师； 准备查缺补漏的容器相关开发工程师；

如果你在用 Docker 或者 Kubernetes 想必你对 容器运行时 这个概念应该不会太陌生。 在 Docker 中，当你使用 docker info 即可查看当前所使用的 runtime。 ➜ ~ docker info ... Server Version: 18.06.1-ce Storage Driver: overlay2 Backing Filesystem: extfs Supports d_type: true Native Overlay Diff: true Logging Driver: json-file Cgroup Driver: cgroupfs ... Swarm: inactive Runtimes: nvidia runc Default Runtime: runc Init Binary: docker-init containerd version: 468a545b9edcd5932818eb9de8e72413e616e86e runc version: 69663f0bd4b60df09991c08812a60108003fa340 init version: fec3683 Security Options: seccomp Profile: default ... 同时，你还可以自己在 /etc/docker/daemon.

使用 Docker 时，最常用的命令无非是 docker container 和 docker image 相关的子命令，当然最初没有管理类命令（或者说分组）的时候，最常使用的命令也无非是 docker run docker commit docker build 和 docker images 这些。 今天来聊一下和 Docker 中核心概念 image 相关的重要命令， docker build 或者说 docker image build 为了简便起见，下文的命令全部使用 docker build 。 Docker Image 先简单介绍下 Docker Image， 通常情况下我们将其称之为镜像，镜像是由多个层组成的文件，这些层用于在容器内执行代码（命令）等。每个镜像基本上都是根据应用程序完整的可执行版本进行构建的，并且需要注意的是，它会依赖于主机的系统内核。当用户在运行镜像时，这将会创建一个或者多个容器实例。 Dockerd Dockerd 是 Docker 的服务端，默认情况下提供 Unix Domain Socket 连接，当然也可以监听某个端口，用于对外提供服务。 所以有时候，我们也可以使用服务器上的 Docker daemon 来提供服务，以加快构建速度及解决一些网络问题之类的。 好的，基础概念了解了， 那我们开始进入正题。 使用 Dockerfile 我们知道构建镜像的方法有多种，本文中我们只介绍使用 Dockerfile 通过 docker build 的方式构建镜像。 为了简便，我们以一个简单的 Dockerfile 开始。构建一个容器内使用的 kubectl 工具 (当然选择它的原因在于 kubectl 足够大，并不考虑可用性，这个稍后解释)

继上次分享后，有读者留言问 dind 使用 insecure-registry 相关的问题。 请教个问题，基于gitlab CI做java项目持续集成，用到了docker in docker， docker build使用的Dockerfile中使用了一个insecure registry，在dind的容器中如何配置insecure registry 我的回复是： 首先, 不推荐使用 insecure registry 毕竟有其固有限制， 如果一定要用的话， 其实在 services 层配置一个 command 就可以，这也是最简单的， 例如： services: - name: docker:dind command: ["--insecure-registry=myregistry:5000"] 由于留言字数的限制，就单独写个小文来回复下。 这个做法实际效果如下： (Tao) ➜ kubernetes git:(master) ✗ sudo docker run -d --privileged --name dind docker:dind --insecure-registry="myregistry:5000" 8fb68865638ebc65255bb568fbe1fd6b4ed4fca771075d8e55ebbbbdf0aef6d2 (Tao) ➜ kubernetes git:(master) ✗ sudo docker top dind UID PID PPID C STIME TTY TIME CMD root 18270 18252 1 11:27 ?

上个月受 DockOne 社区邀请，做了一次 CI 实践方面的线上分享，在此记录下。 本文讲述 GitLab CI 的架构及其能力特性，分析它在 DevOps 实践中的作用。 通过分析 Docker In Docker 的技术细节，详细讲述 CI 实践以及在生产环境中的所做的优化，包括但不限于镜像仓库等，以达到数倍的性能提升。 本次分享内容以 GitLab Community Edition 11.0.4 edb037c 为例。 为何选择 GitLab CI 认识 GitLab CI 什么是 GitLab CI GitLab CI 是 GitLab 为了提升其在软件开发工程中作用，完善 DevOPS 理念所加入的 CI/CD 基础功能。可以便捷的融入软件开发环节中。通过 GitLab CI 可以定义完善的 CI/CD Pipeline。 优势 GitLab CI 是默认包含在 GitLab 中的，我们的代码使用 GitLab 进行托管，这样可以很容易的进行集成 GitLab CI 的前端界面比较美观，容易被人接受 包含实时构建日志，容易追踪 采用 C/S 的架构，可方面的进行横向扩展，性能上不会有影响 使用 YAML 进行配置，任何人都可以很方便的使用。 重点概念 Pipeline Pipeline 相当于一个构建任务，里面可以包含多个流程，如依赖安装、编译、测试、部署等。 任何提交或者 Merge Request 的合并都可以触发 Pipeline

拖了很久没有更新，抱歉啦~ 今天受邀写篇如何在 CentOS 7 上配置 Python 3 环境的文章。往常我都选择直接把我早年写的一篇文章源码编译MongoDB丢过去，让他们看其中的源码编译 Python 那一节，不过那节写的其实不太详细，而且最近被很多人催，所以还是单独写一篇好了。 当前最新的 CentOS 7.3 默认安装的是 Python 2 ，并且默认的官方 yum 源中不提供 Python 3 的安装包。有些用户想要升级使用 Python 3 但实际可能有各种各样的问题，导致出错，反观一下激进的 Fedora 社区，在23的时候，就将默认的版本修改成了 Python3 （如果我没记错的话）。 先说下我所使用的系统环境， 一个新创建的 Docker 容器。 使用 cat /etc/redhat-release 可以看到运行的是 CentOS 7.3 版本。 在纯净的 CentOS 系统上安装 Python 环境主要有两种办法。 一种是通过源码编译安装，另外一种就是安装已经打好的 RPM 包。依照个人习惯，我们先来看一下如何通过源码编译的方式安装 Python 3.6 并且配置虚拟环境。 使用源码进行编译安装 基础环境 先安装安装几个必须的包，以方便后续的操作 ➜ yum install wget gcc make ➜ # wget 用于下载源码包 ➜ # gcc 和 make 用于编译 上 Python的官网 下载源码包 ➜ wget https://www.

简介 Redis 的客户端和服务端之间采取了一种独立名为 RESP(REdis Serialization Protocol) 的协议，作者主要考虑了以下几个点： 容易实现 解析快 人类可读 注意：RESP 虽然是为 Redis 设计的，但是同样也可以用于其他 C/S 的软件。 数据类型及示例 RESP 主要可以序列化以下几种类型：整数，单行回复(简单字符串)，数组，错误信息，多行字符串。Redis 客户端向服务端发送的是一组由执行的命令组成的字符串数组，服务端根据不同的命令回复不同类型的数据，但协议的每部分都是以 “\r\n” (CRLF) 结尾的。另外 RESP 是二进制安全的，不需要处理从一个进程到另一个进程的传输，因为它使用了前缀长度进行传输。 在 RESP 中, 一些数据的类型通过它的第一个字节进行判断： 单行回复：回复的第一个字节是 “+” 错误信息：回复的第一个字节是 “-” 整形数字：回复的第一个字节是 “:” 多行字符串：回复的第一个字节是 “\$” 数组：回复的第一个字节是 “*” 单行回复 以 “+” 开头，以 “\r\n” 结尾的字符串形式。e.g. +OK\r\n 响应的客户端库，应该返回除 “+” 和 CRLF 以外的内容，例如上面的内容，则返回 “OK”. e.g. 127.0.0.1:6379> set name TaoBeier +OK\r\n # 服务端实际返回 --- OK # redis-cli 客户端显示 错误信息 错误信息和单行回复很像，不过是把 “+” 替换成了 “-“。而这两者之间真正的区别是，错误信息会被客户端视为异常，并且组成错误类型的是错误消息本身。e.