前面从无到有或是分别以 Docker Desktop, Minikube, kind 来搭建过 Kubernetes 集群。而如今各大云服务提供商基本都推出了各自的 Kubernetes 服务，例如：

1. Google GKE - Google Kubernetes Engine
2. Amazon EKS - Amazon Elastic Kubernetes Service
3. Microsoft AKS - Azure Kubernetes Service
4. IBM Cloud Kubernetes Service
5. Alibaba Cloud Container Service

所以对 Kubernetes 的进一步学习过程中何不一跃而直上云霄，直接尝试 AWS 的 EKS 如何搭建。EKS 是在 2018 年 6 月份正式推出，见 Amazon Elastic Container Service for Kubernetes Now Generally Available。EKS 在 AWS 上是与 ECS 并列的服务，它们的功能也比较类似，都是伸缩性的容器服务，ECS 配置管理更分散，EKS 本身就是一个集群管理工具。它们也有些共同的东西，如 Auto Scaling Groups, Launch Templates。

现在用 Terraform 脚本来演示一下如何创建一个 EKS 集群，并启动三个 EC2 Worker 节点(EKS 也支持 Fargate Worker 节点)，并部署一个应用。Terraform 脚本将会列出完成该任务的基本要素，也将会看看背后发生了什么。 Read More

在 Kubernetes 学习笔记(一) - 初上手 中一上手就尝试了最原始级的安装 Kubernetes 的方式，花了不少时间，好处是能更好的理解 Kubernete 的组成以及各节点是如何协同工作的。从《Kubernetes in Action》第二版中了解了几种简单的方法，为什么要把以下几种方式列出来呢？为了让看到上篇的同学们不至于对 Kubernetes 的安装过程望而却步。下面的前两种方式都是创立的单节点的 Kubernetes 集群。

一：启用 Docker Desktop 的 Kubernetes 特性

Docker Desktop 的 Community 版本从  18.06.0-ce-mac70 2018-07-25 开始加入了对 Kubernetes 的支持，在 2018-11-19 后，Docker Desktop 开始用 2.0.0.0 这样的版本。当前的 Docker Desktop Community 版是 2.2.0.4，所带的 Kubernetes 是 v1.15.5，要启用它只要进到它的 Preferences..., Read More

原本是继续阅读《每天5分钟玩转Kubernetes》一书的，发现该书所用的 Kubernetes 版本着实有点老旧( 1.7), 当前版本是 1.18。操作起来有些不同，所以找来了最新的 《Kubernetes in Action》第二版 来看，该书还在写作当中。第二章全是讲 Docker 的内容，本人读书有个不好的习惯，就是不喜欢跳过跳过。看了总会有收获的，这不，就从中稍微理清了 Docker 容器内进程与 Namespace 的关系。

Docker 容器间的进程本质上是宿主主上的一个进程，它能相互隔离靠的是 chroot, namespace 和 cgroup(对 CPU, 内存，磁盘，带宽等的配额)。千万不要认为启动一个 Docker 容器就是启动了一个虚拟机。

其中 namespace 实现了以下几项资源的隔离

1. Mount: 挂载点(文件系统)
2. PID: 进程 ID
3. Network: 网络设备，网络栈，端口等
4. IPC： 进程间通信，信号量，消息队列和共享等
5. UTS： 主机名和域名
6. User ID: 用户和组 ID

Read More

经过前几天从 Docker Swarm 到 Docker Compose 的历练之后，终于踏上了 Kubernetes 的学习征程了。虽说前两者并非必要的学习 Kubernetes 的基础，但了解它们之后与 Kubernetes 中的一些概念可以进行对比理解。

本系列是阅读 《每天5分钟玩转Kubernetes》的笔记，书名倒是来的轻松，对我来说每天 5 分钟根本吸收不了什么知识。如果把阅读该书比作台上的话，基本就是台上 5 分钟，台下 50 分钟都不够，实际操作起来不光是版本有差异，还会出现各种意外带来惊喜与折磨。另外该书所采用的版本是 Kubernetes 1.7.4, 当前为 1.18，有不小的差别。

Kubernetes 是当今容器编排引擎的事实标准，以前为 Google 内部项目的 Omega 开源为 Kubernetes。传说中的容器编排三足鼎力，Kubernetes, Docker Swarm 和 Apache Mesos, 现在已是 Kubernetes 的一骑绝尘。Mac 下的 Docker Desktop 版本已内置了 Kubernetes 的支持。AWS 中在 ECS 外也支持了 EKS(Elastic Kubernetes Service)。 Read More

继续向 Kubernetes 进发，上一篇 Docker Swarm 集群模式实操 了解完 Swarm 后，有必要对 Docker Compose 了解一番。Docker Swarm 是把 Docker 宿主机组成集群，部署服务时只要告知 Manager 节点，它就会自动找到相应节点去运行相应的容器。Compose 完全是另一个概念，它把相关联的多个容器组织成一个整体来部署，如由负载容器，多个 Web 容器和一个 Redis 缓存容器构成一个整体。

由其名 Compose 正式有了容器编排这么一个概念，后来将要学的 Kubernetes 是更高级别的组织，运行，管理容器的工具。Compose  由于把容器组织起来了，所以能够一条命令启动多个相关联的容器，而无需单独启动一个一个的容器。

关于 Docker Compose  的安装，在 Mac OS X 下的  Docker Desktop 自带了 docker-compose; 由于 Docker Compose 是用 Python 编写的，我们可以用  pip install docker-compose 的安装，安装后使用它的命令就是 docker-compose。

下方的 Docker Container, Swarm, Compose 三者之间的关系图很形像 Read More

在正式进入 Kubernetes 之前希望能对早先的 Docker Swarm 有所了解，虽然它目前基本上没什么用处。Swarm 提供的是 Docker 宿主机的集群，集群中至少有一个 Manager(或多个), 再加上 0 或多个 Worker。它的大意是有个 Docker 服务(容器)通过 Manager 告诉用所管理的 Swarm 集群来执行，它就会在该集群中找到相应的宿主机来执行。Manager 和 Workder 都可用来运行 Docker 容器，但只有 Manager 才能执行部分管理命令。

下面两张图很好的体现了我们平时在一个宿主机上和 Swarm 集群宿主机上运行 Docker 容器的区别

所有容器自己扛

=>

容器大家一起扛

Docker 在 1.12 之后自带了 Swarm 模式。本文实质上对 使用Docker Swarm模式搭建Swarm集群 的一次实际操作与体验。只是自己方便使用了三个 Vagrant 虚拟机进行实践，其中一个 Swarm Manager 节点，两个 worker 节点 Read More

常要在 Linux 下分析日志或其他类型的文件，基本用的命令也就 grep, awk, sed, cut, vim, cat, find, xargs, tail, more 或 less。本人工作平台为 Mac OS X, 而 Mac 下的 grep, sed, awk 的行为与 Linux 下的 GNU 标准的相应命令是有差别的, 所以我总是在 Mac 下安装 GNU 的 grep, sed, awk 等命令来替代系统默认的。

比如安装下面的命令

$ brew install findutils gawk gnu-sed grep

以上会安装 GNU 的 find, awk, sed 和 grep 命令，使用时要加个前缀，如 gfind, gawk, gsed 或 ggrep，也可以设置别名或符号链接来替换掉系统的相应命令。

注： brew install coreutils 会安装众多 Linux 下的基本命令替代品，ls, cat, cut 都在其中，使用它也是要加上前缀 g, 如 gls, gcut 等。

以下 grep, find, grep, sed 以 GNU 的行为为准。 Read More

通常我们注册 Spring Bean 是通过像 @Named, @Bean, @Component, @Service 这样的注解来注册的，或者用更为古老的 XML 配置文件的方式。难免有时候要根据实际业务需求在 Spring  运行期间动态注册 Spring Bean, 比如基本某种形式的配置文件或系统属性来注册相应的 Bean, 这好像又回到了 XML 文件注册方式，也不尽然。

那为什么在运行期还要去注册 Spring Bean 呢，直接 new 对象不行吗？当然行得通，不过这样的话就不能更好的使用到  Spring IOC 的好处了。像待注册的 Bean 构造函数可以直接用到其他的 Spring  对象，或 @Value 引入环境变量，还有 @PostContruct 这样的行为。

最初思考如何注册 Spring Bean 时还是费了不少周折，如今清晰了许多。了当的说，不管是 Spring  初始时还是运行时，注册 Bean 的关键(应是唯一) 入口就是 BeanDefinitionRegistry 接口的方法 Read More

看到本文标题也许要奇怪了，Python 的 print 难道不是也上可以看到结果的吗？在 Python shell 下只要 

>> print('Hello world!')
Hello world!

不就立马能看到控制台输出的 "Hello world!" 吗。或者是一个 Python 脚本文件 hello.py

import time

for i in range(3):
    print('Hello {}'.format(i))
    time.sleep(3)

然后执行 python hello.py 的话，我们也同样能看到在控制台下在预定的每 3 秒输出一行

Hello 0
Hello 1
Hello 2

但执行下面的命令试图重定向输出到文件时的效果就不一样了 Read More