本文永久链接 – https://tonybai.com/2022/05/10/introduction-of-implement-dsl-using-antlr-and-go 一. 引子 设计与实现一门像Go这样的通用编程语言的确很难！那是世界上少数程序员从事的事业，但是实现一门领域特定语言(Domain Specific Language, DSL)似乎是可行的。 就像著名的语言解析器生成工具ANTLR作者Terence Parr在《编程语言实现模式》一书中说的那样： ...
kubectl是日常访问和管理Kubernetes集群最为常用的工具。 当我们使用kubeadm成功引导启动(init)一个Kubernetes集群的控制平面后，kubeadm会在init的输出结果中给予我们下面这样的“指示”： ... ... Your Kubernetes master has initialized successfully! To start using your cluster, you need to run the following as a regular user: mkdir -p $HOME/.kube sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config sudo chown $(id -u):$(id -g) $HOME/.kube/config ... ... kubeadm init在结尾处输出的这些信息是在告知我们如何配置kubeconfig文件。按照上述命令配置后，master节点上的kubectl就可以直接使用$HOME/.kube/config的信息访问k8s cluster了。并且，通过这种配置方式，kubectl也拥有了整个集群的管理员(root)权限。 ...
由于开发的平台要进行内部公开测试，我们这周在公司内部私有云搭建了一套平台。涉及到Kubernetes相关的基础软件，由我来部署。Kubernetes以及其相关组件都在积极的开发中，版本更新也很快。截至本文撰写时，K8s发布最新稳定版是v1.7.6，而与之配套的Dashboard则是v1.7.0。 最初在部署规划时，我选择了Kubernetes v1.7.6+ dashboard v1.6.3的组合。之前K8s v1.7.3的稳定让我对使用最新Release版有一些信心，但dashboard v1.7.0则是三天前刚发布的，看dashboard的commit log，之前还大规模revert了一次。因此，我保守的选择了v1.6.3。 ...
今天在测试之前搭建好的高可用Harbor时，发现了一个问题：使用docker login harbor时，有时成功，有时失败： # docker login -u user -p passwd http://hub.my-domain.com:36666 Login Succeeded # docker login -u user -p passwd http://hub.my-domain.com:36666 Error response from daemon: login attempt to http://hub.my-domain.com:36666/v2/ failed with status: 401 Unauthorized 我们在DNS中将hub.my-domain.com这个域名解析成两个IP，分别是两个Harbor节点的public IP，这可能是问题的诱发原因，但我还不知道问题根源在哪里。以下是问题的查找过程记录。 ...
Kubernetes API Server是整个Kubernetes集群的核心，我们不仅有从集群外部访问API Server的需求，有时，我们还需要从Pod的内部访问API Server。 然而，在生产环境中，Kubernetes API Server都是“设防”的。在《Kubernetes集群的安全配置》一文中，我提到过：Kubernetes通过client cert、static token、basic auth等方法对客户端请求进行身份验证。对于运行于Pod中的Process而言，有些时候这些方法是适合的，但有些时候，像client cert、static token或basic auth这些信息是不便于暴露给Pod中的Process的。并且通过这些方法通过API Server验证后的请求是具有全部授权的，可以任意操作Kubernetes cluster，这显然是不能满足安全要求的。为此，Kubernetes更推荐大家使用service account这种方案的。本文就带大家详细说说如何通过service account从一个Pod中访问API Server的。 ...
当前手上有两个Kubernetes cluster，一个是采用kube-up.sh安装的k8s 1.3.7版本，另外一个则是采用kubeadm安装的k8s 1.5.1版本。由于1.3.7版本安装在前，并且目前它也是承载了我们PaaS平台的环境，因此对于这个版本的Kubernetes安装环境、配置操作、日志查看、集群操作等相对较为熟悉。而Kubeadm安装的1.5.1版本K8s集群在组件部署、配置、日志等诸多方面与1.3.7版本有了较大差异。刚上手的时候，你会发现你原来所熟知的1.3.7的东西都不在原先的位置上了。估计很多和我一样，采用kubeadm将集群升级到1.5.1版本的朋友们都会遇到这类问题，于是这里打算对Kubeadm方式安装的Kubernetes集群进行一些小小的探索，把一些变动较大的点列出来，供大家参考。 一、环境 这里使用的依然是文章《使用Kubeadm安装Kubernetes》中安装完毕的Kubernetes 1.5.1集群环境，底层是阿里云ECS，操作系统是Ubuntu 16.04.1。网络用的是weave network。 ...