用自己 Kubernetes 学习笔记(一) - 初上手 一文中的方法用 Vagrant 虚拟机安装的 Kubernetes 集群，部署应用什么的都没问题，然而却在用
$ kubectl exec -it <pod-name> -- sh
试图登陆 docker 容器时出问题了，总是报错说
error: unable to upgrade connection: pod does not exist
kubectl 登陆不了 docker 容器，而且 kubectl logs 也会报一样的错，必须到具体的工作节点上用 docker exec 或 docker logs 才能访问到该节点上的容器信息。
这就不太对头，网上找了下原因，结果是因为节点间通信时选错了 IP 地址。
比如三个 Vagrant 虚拟机分别是
在 k8s-master 中初始集群时用的命令也是指定的 172.28.128.14 IP 地址 阅读全文 >>
Java 多线程编程常用的一个接口是 ExecutorService, 其实就一个线程池的接口，一般由两种方式创建线程池，一为 Executors 的工厂方法，二则创建 ForkJoinPool 实例，当然也有直接使用 ThreadPoolExecutor 的。
关于什么时候用 ForkJoinPool 或普通的线程池(如 Executors.newFixedThreadPool(2) 或 new ThreadPoolExecutor(...)) 不过多的述说。如果要运用到 ForkJoinTask 的话就要用 ForkJoinPool, 它是 Java7 新引入的线程池类型。
关于 Java7 的 fork-join 框架可参考很多年前的一篇 Java 的 fork-join 框架实例备忘。ForkJoinPool 的一个典型特征是能够进行 Work stealing。它也是 Akka actor 效率高效的一个有力保证。
本文只能某一种情形下在选择普通线程池与 ForkJoinPool 的区别，直接说吧，普通线程更容易造成死锁，而 ForkJoinPool 却能应对相同的状况。 阅读全文 >>
在 AWS 上创建好 EKS 后，想要在本地用 kubectl 来管理 EKS，必须用 aws eks update-kubeconfig 来更新本地的 ~/.kube/config 文件或者 KUBECONFIG 环境变量指向的别的配置文件。
比如说你创建 EKS 的用户在本地 ~/.aws/credentials 中的 profile 是 my-aws-profile, 那么完整的 update-kubeconfig 命令就是
$ aws eks --profile my-aws-profile --region us-east-1 update-kubeconfig --name myeks-cluster
Updated context arn:aws:eks:us-east-1:069762108088:cluster/myeks-cluster in /Users/yanbin/.kube/config
再来执行 kubectl get pods 如果出现错误 error: You must be logged in to the server (Unauthorized)，肯定是因为你使用的 awscli 命令比较老(到底有多老呢？在 github 上已经无法追溯了，大概是 1.16.266 之前的)。大约生成的 ~/.kube/config 文件末尾像下面那样 阅读全文 >>
前面从无到有或是分别以 Docker Desktop, Minikube, kind 来搭建过 Kubernetes 集群。而如今各大云服务提供商基本都推出了各自的 Kubernetes 服务，例如：
所以对 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 脚本将会列出完成该任务的基本要素，也将会看看背后发生了什么。 阅读全文 >>
在 Kubernetes 学习笔记(一) - 初上手 中一上手就尝试了最原始级的安装 Kubernetes 的方式，花了不少时间，好处是能更好的理解 Kubernete 的组成以及各节点是如何协同工作的。从《Kubernetes in Action》第二版中了解了几种简单的方法，为什么要把以下几种方式列出来呢？为了让看到上篇的同学们不至于对 Kubernetes 的安装过程望而却步。下面的前两种方式都是创立的单节点的 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..., 阅读全文 >>
原本是继续阅读《每天5分钟玩转Kubernetes》一书的，发现该书所用的 Kubernetes 版本着实有点老旧( 1.7), 当前版本是 1.18。操作起来有些不同，所以找来了最新的 《Kubernetes in Action》第二版 来看，该书还在写作当中。第二章全是讲 Docker 的内容，本人读书有个不好的习惯，就是不喜欢跳过跳过。看了总会有收获的，这不，就从中稍微理清了 Docker 容器内进程与 Namespace 的关系。
Docker 容器间的进程本质上是宿主主上的一个进程，它能相互隔离靠的是 chroot, namespace 和 cgroup(对 CPU, 内存，磁盘，带宽等的配额)。千万不要认为启动一个 Docker 容器就是启动了一个虚拟机。
其中 namespace 实现了以下几项资源的隔离
经过前几天从 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)。 阅读全文 >>
继续向 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 三者之间的关系图很形像 阅读全文 >>
在正式进入 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 节点 阅读全文 >>
常要在 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 的行为为准。 阅读全文 >>