Kubernetes

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。runc v1.0.0-rc9 发布不知不觉，runc v1.0.0-rc9 于近日发布了。早先关注过我文章的朋友们应该看到过我从去年开始每次在 runc 新版本发布时都有专门写一篇文章进行介绍。这次版本的定位主要是修复 CVE-2019-16884 所以我也就不再单独写文章介绍了（另一个原因是现在在假期，还是多抽空陪陪家人） 先对 CVE-2019-16884 做个简单的介绍。这是一个中等级别的漏洞，其主要影响是 runc 源码中的 libcontainer/rootfs_linux.go 在文件挂载至 /proc 时，少做了一些检查，可绕过 AppArmor 的限制，所以可能导致被一些恶意镜像所利用。 主要的修复方式是将原先的 checkMountDestination 函数改写为 checkProcMount，并在其中添加了对源文件类型的判断，只允许 procfs 类型的文件挂载至 /proc 。 此漏洞影响到的范围是 runc 以及一些使用 runc 作为基础组件的容器管理软件。请尽快进行升级。 此版本的地址是：https://github.com/opencontai... Docker v19.03.3-rc1 发布自从 Docker 修改维护周期后，Docker 对软件的质量要求有了显著提高，每次版本发布前会经历多阶段的测试和回归，确保软件没有什么问题后才会发布正式版。 按现在的进度来看 v19.03.3 应该会在一两周内放出。新版本会将 containerd 升级至最新的 1.2.10 ，并修复了一个在 5.2 版本内核上 overlay2 文件系统挂载时的错误。 关于此版本感兴趣的朋友可以参考 ReleaseNote 上游进展Kubernetes v1.17 已经进入发布周期，这个版本的发布周期会比较短，现在已经发布了 v1.17.0-alpha 版本，计划是在 12 月 9 日可以最终发布。(想想看，距现在也就两个月的时间，你的集群现在是哪个版本呢？) 另外，在近期将会发布 v1.13.12 版本，这将是 v1.13 分支的最后一个版本，如果还是使用此版本的朋友，请尽快进行升级了。（当然，与它同时发布的也还有 1.16.2，1.15.5 和 1.14.8 如果要升级可以等这几个版本发布后再进行升级，免得还得重复升级） ...

喜大普奔，在祖国70岁生日的这一天，TensorFlow2.0正式Release，本文主要介绍一下TensorFlow2.0的新特性。TensorFlow 1.15 官方已经宣布该版本是1.X的最后一个版本了。 主要特点和改进TensorFlow 2.0专注于简单性和易用性，具有以下更新： 使用Keras轻松构建模型，渴望执行模式在任何平台上进行生产中的稳健模型部署强大的研究实验通过减少重复并删除已经标记不再使用的端点来简化API有关2.0最佳实践的详细信息，参照the Effective 2.0 guide 这里我强调一下渴望执行模式。TensorFlow 2.0 主推的 eager execution mode 采用和解释执行图完全不同的深度学习计算方式。 类似 PyTorch 的做法，前向计算过程把对基本计算单元（operator）的调用记 录在一个内存数据结构 tape 里，随后，反向计算过程（计算 gradients 的） 可以回溯这个 tape，以此调用 operator 对应的 gradient operator。这个 tape 提供一个操作让用户可以获取每个参数的 gradient。 HighlightsTF 2.0提供Keras作为用于构建和训练模型的中央高级API。 Keras提供了一些模型构建API，例如顺序，功能和子类化以及急切的执行（用于立即迭代和直观调试）以及tf.data（用于构建可扩展的输入管道）。分发策略：TF 2.0用户将能够使用tf.distribute.Strategy API通过最少的代码更改来分发培训，从而获得出色的现成性能。它支持Keras model.fit以及自定义训练循环的分布式训练。提供多GPU支持，以及对多工作人员和Cloud TPU的实验性支持功能，而不是会话。不鼓励使用传统的声明式编程模型来构建图形并通过tf.Session执行它，并通过编写常规的Python函数来代替。使用tf.function装饰器，这些函数可以转换为图形，可以远程执行，序列化并针对性能进行优化。tf.train.Optimizers和tf.keras.Optimizers的统一。对TF2.0使用tf.keras.Optimizers。作为公共API删除了compute_gradients，使用GradientTape计算梯度。AutoGraph将Python控制流转换为TensorFlow表达式，允许用户在装饰有tf.function的函数中编写常规Python。 AutoGraph也适用于与tf.data，tf.distribute和tf.keras API一起使用的函数。交换格式与SavedModel的统一。所有TensorFlow生态系统项目（TensorFlow Lite，TensorFlow JS，TensorFlow Serving，TensorFlow Hub）都接受SavedModels。模型状态应保存到SavedModels或从SavedModels恢复。API更改：许多API符号已重命名或删除，参数名称也已更改。这些变化中的许多变化都是出于一致性和清晰性。 1.x API在compat.v1模块中仍然可用。添加环境变量TF_CUDNN_DETERMINISTIC。设置为TRUE或“ 1”将强制选择确定性cuDNN卷积和最大池算法。启用此功能后，算法选择过程本身也是确定性的。TensorFlow 2.0与kubernetes这两个在各自领域最火的框架，结合的工作其实业界已经有很多尝试了，包括谷歌的kubeflow。Distributed TensorFlow虽然提供了分布式能力，可以利用服务器集群加快训练，但是还有许多缺点： 训练时TensorFlow各个Task资源无法隔离，很有可能会导致任务间因资源抢占互相影响。缺乏调度能力，需要用户手动配置和管理任务的计算资源。集群规模大时，训练任务的管理很麻烦，要跟踪和管理每个任务的状态，需要在上层做大量开发。用户要查看各个Task的训练日志需要找出对应的服务器，并ssh过去，非常不方便。TensorFlow原生支持的后端文件系统只支持：标准Posix文件系统（比如NFS）、HDFS、GCS、memory-mapped-file。大多数企业中数据都是存在大数据平台，因此以HDFS为主。然而，HDFS的Read性能并不是很好。而这些正是Kubernetes所擅长的地方。当你试着去创建一个大规模TensorFlow集群时，发现并不轻松； 尤其是蚂蚁金服开源的ElasticDL，该项目是基于TensorFlow 2.0的Kubernetes-native 弹性分布式深度学习系统。

Kubernetes提供了两种内建的云端负载均衡机制用于发布公共应用，一种是工作于传输层的Service资源，它实现的是TCP负载均衡器；另一种是Ingress资源，它实现的是HTTP(S)负载均衡器。 今天我们来重点讨论Ingress资源。HTTP（S）负载均衡器是应用层负载均衡机制的一种，支持根据环境做出更好的调度决策。与传输层调度器相比，它提供了可自定义URL映射和TLS等功能，并支持多种健康状态检查机制。 Ingress是Kubernetes API的标准资源类型之一，它其实就是一组基于DNS名称或URL路径把请求转发至指定的Service资源的规则，用于将集群外部的请求流量转发至集群内部完成服务发布。然而，Ingress资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则要想真正发挥作用还需要其他功能的辅助，如监听某套接字，然后根据这些规则的匹配机制路由请求流量。这种能够为Ingress资源监听套接字并转发流量的组件称为Ingress Controller。 一、部署HelmHelm是一个包管理工具, 把Kubernetes资源(比如deployments、services或 ingress等) 打包到一个chart中，方便将其chart保存到chart仓库用来存储和分享, Helm支持发布应用配置的版本管理, 使发布可配置, 简化了Kubernetes部署应用的版本控制、打包、发布、删除、更新等操作。 安装Helm1、官网下载Helm二进制文件，当前最新版本为2.14.0； wget https://storage.googleapis.com/kubernetes-helm/helm-v2.14.0-linux-amd64.tar.gz2、解压缩文件并将目录中二进制文件移动到/usr/local/bin/下； tar -zxvf helm-v2.14.0-linux-amd64.tar.gzmv linux-amd64/helm /usr/local/bin/helm3、为Tiller添加权限，详见Role-based Access Control，新建rbac-config.yaml，内容如下： apiVersion: v1kind: ServiceAccountmetadata: name: tiller namespace: kube-system---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata: name: tillerroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-adminsubjects: - kind: ServiceAccount name: tiller namespace: kube-system执行create命令： kubectl create -f rbac-config.yaml4、初始化 Helm 并安装 Tiller 服务 helm init --upgrade --service-account tiller --tiller-image sapcc/tiller:v2.14.05、查看helm版本，出现以下信息，确认安装成功： Client: &version.Version{SemVer:"v2.14.0", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}Server: &version.Version{SemVer:"v2.14.0", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}6、chart列表 ...

使用场景当我们需要进行服务端认证，甚至双向认证时，我们需要生成密钥对和服务信息，并使用ca对公钥和服务信息进行批准签发，生成一个证书。 我们简单描述下单向认证和双向认证的场景流程 在单向认证场景中： 服务端会将自己的证书和公钥告知客户端客户端向CA查询该证书的合法性，确认合法后会记录服务端公钥客户端会与服务端明文通信确认加密方式，客户端确认加密方式后，会生成随机码作为对称加密密钥，以服务端的公钥对对称加密密钥进行加密，告知服务端，服务端以自己的私钥解密得到对称加密密钥，之后， 客户端与服务端之间使用对称加密密钥进行加密通信。在双向认证的场景中: 服务端会将自己的证书和公钥告知客户端客户端向CA查询该证书的合法性，确认合法后会记录服务端公钥客户端会将自己的证书和公钥发给服务端，服务端发现客户端的证书也可以通过CA认证，则服务端会记录客户端的公钥然后客户端会与服务端明文通信确认加密方式，但服务端会用客户端的公钥将加密方式进行加密客户端使用自己的私钥解密得到加密方式，会生成随机码作为对称加密密钥，以服务端的公钥对对称加密密钥进行加密，告知服务端，服务端以自己的私钥解密得到对称加密密钥，之后， 客户端与服务端之间使用对称加密密钥进行加密通信。那么，我们如果要开放自己的https服务，或者给kubelet创建可用的客户端证书，就需要： 生成密钥对生成使用方的信息使用ca对使用方的公钥和其他信息进行审核，签发，生成一个使用方证书。这里使用方可以是客户端（kubelet）或服务端（比如一个我们自己开发的webhook server） 手动签发证书k8s集群部署时会自动生成一个CA（证书认证机构），当然这个CA是我们自动生成的，并不具有任何合法性。k8s还提供了一套api，用于对用户自主创建的证书进行认证签发。 准备安装k8s集群安装cfssl工具，从这里下载cfssl和cfssljson创建你的证书执行下面的命令，生成server.csr和server-key.pem。 cat <<EOF | cfssl genkey - | cfssljson -bare server{ "hosts": [ "my-svc.my-namespace.svc.cluster.local", "my-pod.my-namespace.pod.cluster.local", "192.0.2.24", "10.0.34.2" ], "CN": "my-pod.my-namespace.pod.cluster.local", "key": { "algo": "ecdsa", "size": 256 }}EOF这里你可以修改文件里的内容，主要是： hosts。 服务地址，你可以填入service的域名，service的clusterIP，podIP等等CN 。对于 SSL 证书，一般为网站域名；而对于代码签名证书则为申请单位名称；而对于客户端证书则为证书申请者的姓名key。加密算法和长度。一般有ecdsa算法和rsa算法，rsa算法的size一般是2048或1024这一步生成的server-key.pem是服务端的私钥，而server.csr则含有公钥、组织信息、个人信息(域名)。 创建一个CSR资源执行如下脚本： cat <<EOF | kubectl apply -f -apiVersion: certificates.k8s.io/v1beta1kind: CertificateSigningRequestmetadata: name: my-svc.my-namespacespec: request: $(cat server.csr | base64 | tr -d '\n') usages: - digital signature - key encipherment - server authEOF在k8s集群中创建一个csr资源。注意要将第一步中创建的server.csr内容进行base64编码，去掉换行后填入spec.request中。spec.usages中填入我们对证书的要求，包括数字签名、密钥加密、服务器验证。一般填这三个就够了。 ...

[Acclaim]主页： (https://www.youracclaim.com/u...

建议版本：docker 18.06k8s 1.141. Install安装kubebuilder执行下面的脚本： os=$(go env GOOS)arch=$(go env GOARCH)# download kubebuilder and extract it to tmpcurl -sL https://go.kubebuilder.io/dl/2.0.0-beta.0/${os}/${arch} | tar -xz -C /tmp/# move to a long-term location and put it on your path# (you'll need to set the KUBEBUILDER_ASSETS env var if you put it somewhere else)mv /tmp/kubebuilder_2.0.0-beta.0_${os}_${arch} /usr/local/kubebuilderexport PATH=$PATH:/usr/local/kubebuilder/bin即可 安装kustomize2. Dev创建project使用kubebuilder前，必须要确保本地的go版本为1.11或以上，开启了go module （export GO111MODULE=on） 我们在GOPATH下新建一个目录。并在其中执行kubebuilder init --domain netease.com。 会发现报错： go: sigs.k8s.io/controller-runtime@v0.2.0-beta.4: unrecognized import path "sigs.k8s.io/controller-runtime" (https fetch: Get https://sigs.k8s.io/controller-runtime?go-get=1: dial tcp 35.201.71.162:443: i/o timeout)go: error loading module requirements无法直接clone sigs.k8s.io/controller-runtime，那么我们可以通过对go mod配置proxy，走代理下载： export GOPROXY=https://goproxy.io ...

周末闲逛 Twitter 时，发现一个很有意思的小工具叫 kubeman，野心倒是不小，励志成为 kubectl 的替代品，用于实时监控和管理 kubernetes 集群，还可以调试与 Istio 相关的问题。 如果只使用 kubectl，当网格中的服务出现问题时，可能需要运行很多命令，而且要交叉引用来自多个命令的输出信息，这就会导致问题分析的过程很复杂。kubeman 将这些交叉引用和相关信息分析的复杂逻辑隐藏起来，只暴露一个 UI 界面，针对每一种资源对象封装了一些常用的操作项，这样可以简化很多操作流程。 安装很简单，到 release 页面下载相应的二进制，然后直接运行就好了。下面通过一个完整的示例来演示它的工作流程： 1、运行 kubeman 二进制文件。 2、点击 Select Cluster 菜单选择集群，还可以在 NAMESPACES 对话框中选择一个或多个 namespace，将后面操作项的会话限制在某些 namespace 中。 3、之前选择的集群 context 现在会显示在顶部。 4、左边一栏是菜单面板，操作项被按照不同的资源类型进行分组，你可以从菜单组中选择一个要执行的操作项。 5、由于操作项的数量很庞大，从中寻找我们想要的操作项可能会很费劲，还好顶部有一个搜索框，你可以通过搜索来找到你想要的操作项，搜索结果会显示在 Matching Recipes 菜单中。 6、某些操作项会做更进一步的筛选，例如 namesapce，service，pod 等。 7、右边是输出面板，用来捕获并显示所有操作项的输出。还提供了一些额外的操作： 一旦操作项运行并输出了结果，你就可以在输出面板顶部的搜索框里通过关键词搜索相应的文本。如果想删除搜索的关键词，可以按下键盘上的 esc 键。 每个操作项的输出会按层级进行分组。最顶部的输出行（深蓝色）显示的是输出结果的标题，单击这一行会将整个输出折叠起来，只显示组和子组，这样就可以看到整个输出的概要。再次单击这一行就会显示整个输出。 同理，你可以单击某一个组来折叠这个组的输出，只显示子组。同理适用于子组。不同的子组下的输出都可以展开和折叠，你可以上下滚动来选择感兴趣的子组，然后单击展开输出。 8、有些操作项需要你在搜索框中输入关键词，然后才会显示输出。例如，操作项 Find component by IP 会等待你输入一个或多个 IP 地址，然后输出结果。此时搜索框扮演了两个角色，既作为输出结果的搜索框，也作为操作项的输入框。如果一个操作项支持输入，需要在输入的字符串前面加上 / 以表明这是操作项的输入。多个输入关键词可以用 , 隔开。 ...

本文会指引读者完成minikube及其相关工具的安装，通过一个单节点的kubernetes集群来进行学习和体验。 STEP 1: 安装 kubectl本文仅演示macOS上通过Homebrew安装kubectl的过程，windows和linux用户请移步官方文档寻找最方便的安装方法：通过Homebrew安装kubectl的过程非常简单： $ brew install kubernetes-cli安装完成后，查看版本信息以确认安装成功： $ kubectl versionSTEP 2: 安装 minikubeminikube可以让我们很方便的体验Kubernetes，不过由于一些众所周知的原因，我们在大陆使用起来会有些麻烦，所以我们这次采用阿里云社区里提供的版本。 在开始前，请确保本机装了对应的驱动，我的是VirtualBox，没有的话请先安装一个 minikube在MacOS, Windows和Linux上的安装方法： MacOS: $ curl -Lo minikube http://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v1.3.1/minikube-darwin-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/Linux: $ curl -Lo minikube http://kubernetes.oss-cn-hangzhou.aliyuncs.com/minikube/releases/v1.3.1/minikube-linux-amd64 && chmod +x minikube && sudo mv minikube /usr/local/bin/Windows:下载 minikube-windows-amd64.exe 文件，并重命名为 minikube.exe STEP 3: 初始化环境（可选）如果在之前有安装过官方的minikube，在启动前需要先清除之前的配置： 删除旧集群： $ minikube delete删除配置文件： $ rm -rf ~/.minikubeSTEP 4: 启动 minikube 并打开 dashboard我们需要通过minikube start来创建本地Kubernetes环境，如果不指定驱动，则默认是Virtualbox，我们也可以加上--registry-mirror来提高速度： ...

前言k8s 非常厉害的地方就在于可扩展性，而存储领域，支持flexvolume 和 csi 两种方式来进行扩展。今天主要讲下flexvolume。FlexVolume 是 Kubernetes v1.8+ 支持的一种存储插件扩展方式。类似于 CNI 插件，它需要外部插件将二进制文件放到预先配置的路径中（如 /usr/libexec/kubernetes/kubelet-plugins/volume/exec/），并需要在系统中安装好所有需要的依赖。可以想到，这是一种out-tree的扩展方式，不需要新增加一种存储插件，去更改k8s的源码。 FlexVolume 接口官方提供了一些接口，在我们实现自定义存储插件的时候，需要实现部分接口，之所以说部分，主要是看自己的需求。比如我在实现动态hostpath（主机路径包含podid）的时候，就只实现了init和mount和unmount三个接口而已。 FlexVolume 的接口包括 init：kubelet/kube-controller-manager 初始化存储插件时调用，插件需要返回是否需要要 attach 和 detach 操作attach：将存储卷挂载到 Node 上detach：将存储卷从 Node 上卸载waitforattach： 等待 attach 操作成功（超时时间为 10 分钟）isattached：检查存储卷是否已经挂载mountdevice：将设备挂载到指定目录中以便后续 bind mount 使用unmountdevice：将设备取消挂载mount：将存储卷挂载到指定目录中umount：将存储卷取消挂载Driver outputFlexvolume希望驱动程序以下列格式回复操作状态 { "status": "<Success/Failure/Not supported>", "message": "<Reason for success/failure>", "device": "<Path to the device attached. This field is valid only for attach & waitforattach call-outs>" "volumeName": "<Cluster wide unique name of the volume. Valid only for getvolumename call-out>" "attached": <True/False (Return true if volume is attached on the node. Valid only for isattached call-out)> "capabilities": <Only included as part of the Init response> { "attach": <True/False (Return true if the driver implements attach and detach)> }}与kubelet 的关系前面讲到自定义的存储插件是放到/usr/libexec/kubernetes/kubelet-plugins/volume/exec/下，具体目录是/usr/libexec/kubernetes/kubelet-plugins/volume/exec/<vendor~driver>/<driver>。在pod的spec中申明用到了你自定义的插件后，格式为 <vendor~driver>/<driver>，实际上是kubelet 按照接口规范去调用对应插件。所以需要注意以下几点： ...

K8s 实战之概念、集群部署与服务配置本文是对于 Kubernetes 实战系列文章的提炼。 Kubernetes [koo-ber-nay'-tice] 是 Google 基于 Borg 开源的容器编排调度引擎，其支持多种底层容器虚拟化技术，具有完备的功能用于支撑分布式系统以及微服务架构，同时具备超强的横向扩容能力；它提供了自动化容器的部署和复制，随时扩展或收缩容器规模，将容器组织成组，并且提供容器间的负载均衡，提供容器弹性等特性。作为 CNCF（Cloud Native Computing Foundation）最重要的组件之一，可谓云操作系统；它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态。 设计理念与一般的 PaaS 平台相比，K8s 也是支持服务部署、自动运维、资源调度、扩缩容、自我修复、负载均衡，服务发现等功能，而其独特之处就是其对于基础设施层进行了较好的能力抽象。K8s 并没有处理具体的存储、网络这些差异性极大的部分，而是做云无关，开始实现各类 interface，做各种抽象。比如容器运行时接口（CRI）、容器网络接口（CNI）、容器存储接口（CSI）。这些接口让 Kubernetes 变得无比开放，而其本身则可以专注于内部部署及容器调度。 Kubernetes 有类似于 Linux 的分层架构，如下图所示： 基础设施层：包括容器运行时、网络、存储等。核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境。应用层：部署（无状态、有状态应用、Job 等）和路由（服务发现、负载均衡等）管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等外部生态以及 CRI、CNI、CSI、镜像仓库、Cloud Provider、集群自身的配置和管理等内部生态。Kubernetes 中所有的配置都是通过 API 对象的 spec 去设置的，也就是用户通过配置系统的理想状态来改变系统，这是 Kubernetes 重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为 3 的操作运行多次也还是一个结果，而给副本数加 1 的操作就不是声明式的，运行多次结果就错了。 相对于命令式操作，声明式操作会更稳定且更容易被用户接受，因为该 API 中隐含了用户想要操作的目标对象，而这些对象刚好都是名词性质的，比如 Service、Deployment、PV 等；且声明式的配置文件更贴近“人类语言”，比如 YAML、JSON。声明式的设计理念有助于实现控制闭环，持续观测、校正，最终将运行状态达到用户期望的状态；感知用户的行为并执行。比如修改 Pod 数量，应用升级/回滚等等。调度器是核心，但它只是负责从集群节点中选择合适的 Node 来运行 Pods，显然让调度器来实现上诉的功能不太合适，而需要有专门的控制器组件来实现。 ...

集群安装准备工作请参考https://segmentfault.com/a/11900000201191901.环境介绍一共三台 CentOS Linux release 7.6.1810 (Core) 192.168.1.100 master 192.168.1.101 node1 192.168.1.102 node2 2.Master、Node节点安装、配置Docker# 卸载原来的dockersudo yum remove docker \ docker-client \ docker-client-latest \ docker-common \ docker-latest \ docker-latest-logrotate \ docker-logrotate \ docker-engine# 安装依赖sudo yum update -y && sudo yum install -y yum-utils \ device-mapper-persistent-data \ lvm2 #添加阿里云yum源（官网的源比较慢）sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo # 安装docker的指定版本查看版本$ yum list docker-ce --showduplicates | sort -r$ sudo yum install docker-ce-<VERSION_STRING> docker-ce-cli-<VERSION_STRING> containerd.io例如：yum install docker-ce-18.09.5 docker-ce-cli-18.09.5 containerd.io -y# 查看docker版本docker --version# 开机启动systemctl enable --now docker修改docker cgroup驱动，与k8s一致，使用systemd ...

HarborHarbor核心组件解释Proxy：他是一个nginx的前端代理，代理Harbor的registry,UI, token等服务。db：负责储存用户权限、审计日志、Dockerimage分组信息等数据。UI：提供图形化界面，帮助用户管理registry上的镜像, 并对用户进行授权。jobsevice：jobsevice是负责镜像复制工作的，他和registry通信，从一个registry pull镜像然后push到另一个registry，并记录job_log。Adminserver：是系统的配置管理中心附带检查存储用量，ui和jobserver启动时候回需要加载adminserver的配置。Registry：镜像仓库，负责存储镜像文件。Log：为了帮助监控Harbor运行，负责收集其他组件的log，供日后进行分析。 Harbor简单部署2019年8月搜索网上的方案，都是使用docker容器运行，使用docker-compose编排安装。1.安装docker-compose yum install python-pip;pip install docker-compose2.下载Harbor离线包https://github.com/vmware/har...安装有两种方式，一种是off-line ，一种是on-line，即离线和在线安装，离线安装需要下载的安装包较大，在线安装下载的安装包很小。3.解压，进入安装包 tar -xvf harbor-offline-installer-v1.7.4.tgz ; cd harbor4.修改docker-compose.notary.yml和harbor.cfg文件 [root@node03 harbor]# vim docker-compose.yml[root@node03 harbor]# vim harbor.cfg Harbor仓库介绍与搭建过程 5.执行./prepare,更新一下配置文件 [root@node03 harbor]# ./prepare 6.执行./install.sh，开始安装并启动 [root@node03 harbor]# ./install.sh 7.在火狐浏览器中访问测试，此处的用户名默认为admin，密码在habor.cfg中，可以自己设置。 harbor高可用集群配置https://www.cnblogs.com/breez...

背景目前微店中台团队为了满足公司大部分产品、运营以及部分后端开发人员的尝鲜和试错的需求，提供了一套基于图形化搭建的服务端接口交付方案，利用该方案及提供的系统可生成一副包含运行时环境定义可立即运行的工程代码，最后，通过 “某种serverless平台” 实现生成后代码的部署、CI、运行、反向代理、进程守、日志上报、进程分组扩容等功能。 这样，产品和运营人员可基于此种方式搭建的接口配合常用的cms系统实现简单查询需求如活动大促的自主“研发”上线，代码的可靠性、稳定性由中台研发侧提供的“某种serverless平台”保障，有效支撑了多个业务快速上线，节省后端开发人员的人力与硬件资源的开销（大多数需求下，nodejs业务对虚拟机的资源开销小于java业务）。 接口搭建系统此处并不讲解接口搭建系统的原理与实现，只说明其与上文提到的 “某种serverless平台” 的关系。 ](https://si.geilicdn.com/viewm... 这是系统的全貌，部分细节由于敏感信息而省略。平台使用方可基于每个功能组件搭建出一套复杂的业务流，在搭建阶段，提供在线debug和日志功能，可用于排错；在部署CI阶段，可集成不同的运行时平台，既可以是自主实现的运行时，也可是第三方云平台；在运行阶段，通过使用agentool工具实时监控当前服务的性能，并可通过traceId一览请求在各系统的全貌。 serverless方案本节以资源隔离粒度为度量，介绍了我对三种serverless方案的取舍以及最终为何选择了隔离程度更高的kubeless云平台。 基于函数隔离的Parse Server方案Parse Server提供了基础功能：基于类与对象的权限控制、基于document的nosql存储、简易的用户身份认证、基于hook的自定义逻辑等，但经过笔者的调查与论证，最终并没有采用类似单进程下基于函数隔离的Parse Server及类似方案，这有几点原因： Parse Server方案很重，额外引入了非常多不需要的功能，如权限控制、认证、存储等服务隔离级别低，多个服务在一个进程运行，多个服务会在libuv层互相抢占CPU，互相影响对方的业务处理水平扩容难度大，针对单个服务的扩容无法做到底层基于express框架，无法满足运行时接口调用链路的trace追踪当多个服务同时引入不同的资源如db、es或者服务创建的对象足够多时，会存在Parse Server主进程溢出的风险，毕竟64位机的node堆内存是有1.4GB上限的，尽管这个上限是可配置的Parser Server发布的接口需通过其client调用，这在公司商用情况下需要做许多额外的配置才能满足Parse Server官网基于进程隔离的super-agent方案为了解决多个服务抢占libuv的问题，我选择了自主研发的 super-agent方案，通过其名称便可知它是一个超级代理，但它不仅是代理，还是一个具有极简功能且可靠的发布系统和运行时容器；它是一个分布式应用，节点间功能划分明确；它同时提供实时调试功能。 super-agent是一个多角色分布式系统，它即可以看做node容器，也可看成serverless的node实现，它以进程为粒度管理服务。它分为“协调者”和“参与者”，协调者实现 应用CI部署、启动、进程维护与管理和反向代理功能，参与者实现 业务请求代理、接受协调者调度。 在super-agent架构中，端口是区分服务的唯一标识，端口对客户端而言是透明的，这层端口资源的隔离由super-agent来做掉，因此多个服务可避免在libuv层的互相竞争，提供水平扩容的可能性。 反向代理super-agent最核心的功能在于反向代理。由于每个服务都被包装成有单独端口的独立HTTP应用，因此当用户请求流量经过前端转发层后进入super-agent，由其根据相关规则做二次转发，目前支持基于 “路径、端口”规则的转发。 部署后端应用部署需要进行 “优雅降级、流量摘除、健康检查、应用初始化完毕检查、流量导入、所有参与节点的部署状态查询” 等步骤，需要妥善处理；同时，协调者负责协调众多参与节点全部完成部署操作，这是一个分布式事务，需要做好事务出错后的相关业务补偿。 关于流量上图并未画出节点角色的区别，实际上只有参与者节点才真正接受用户请求。 协调者流量全部来自于内部系统，包括接受 “接口搭建系统”调用或者其他系统实现的dashboard服务；同时其会向参与者发送相关信令信息，如部署、扩容、下线、debug等。 参与者流量来自于内部系统和外部流量，其中大部分来自于外部流量。内部流量则承载协调者的信令信息。 水平扩容服务的水平扩容重要性不言而喻。super-agent方案中，协调者负责管理服务的扩容与逻辑分组。 此处的服务是通过服务搭建平台通过拖拽生成的nodejs代码，它是一个包含复杂业务逻辑的函数，可以是多文件。具体的，super-agent通过将该服务包装成一个HTTP服务在单独的进程中执行。因此，如果要对服务进行水平扩容，提供多种策略的选择： 默认每台虚拟机或物理机一个服务进程，总体上N个机器N个服务进程扩容时默认每台机器再fork一个服务进程，N机器2*N个服务进程为了更充分利用资源，可为每台机器划分为逻辑组，同时选择在某几个组的机器单独扩容这些策略对下游应用透明，只需选择相关策略即可。 水平扩容的缺点：每台虚拟机或物理机资源有上限，一个正常的node进程最多消耗1.4GB内存，计算资源共享，在一台8C16G的虚拟机上，最多可同时运行16个服务。及时通过分组扩容的方式，每当扩展新的虚拟机或物理机，都需要由super-agent根据分组信息实现进程守护，同时每次服务CI部署也同样如此。运维管理上需要配合非常清晰明了的dashboard后台才能快速定位问题，这点在多服务的问题上尤其突出。 在线调试super-agent提供消息机制，由搭建平台中组件开发人员使用提供的serverless-toolkit工具debug相关逻辑，最终可在super-agent的协调者后台查看实时debug结果。 总结super-agent是符合常规的基于业务进程隔离的解决方案，它有效的支撑了微店的几个活动及产品，虽然峰值QPS不高（100左右），但它也论证了super-agent的稳定性及可靠性（线上无事故，服务无重启，平稳升级）。 但是，super-agent仍然存在几个问题，它让我们不得不另觅他法： 日常运维困难，需要开发一系列后台系统辅助运维，这需要不少人力成本这是一个典型的一机多应用场景，当部署super-agent时会对运行其上的服务有所影响（重启），尽管这个影响并不影响用户访问（此时流量已摘除），但仍然是个风险点水平扩容实现繁琐，当下掉某几台参与节点时会带来不少影响基于内核namespace隔离的kubeless方案基于kubeless的方案则是隔离最为彻底的解决方法，kubeless是建立在K8s之上的serverless框架，因此它可以利用K8s实现一些非常有用的特性： 敏捷构建 - 能够基于用户提交的源码迅速构建可执行的函数，简化部署流程；灵活触发 - 能够方便地基于各类事件触发函数的执行，并能方便快捷地集成新的事件源；自动伸缩 - 能够根据业务需求，自动完成扩容缩容，无须人工干预。其中，自动伸缩则解决了 super-agent 的痛点。 kubeless中与我们紧密相关的有两个概念：“function和runtime” ，function是一个统称，它包括运行时代码、依赖以及其他配置文件；runtime则定义运行时依赖的环境，是一个docker镜像。 若要接入kubeless平台，我们需要解决如下几个问题： 开发自定义运行时，满足商用需求，如trace、日志分片、上报采集自定义构建镜像，实现ts编译基于yaml的function创建、更新、删除流程探索，并自动化function部署，包括流量摘除、流量导入、业务健康检查中间件日志、业务日志、trace日志隔离与挂载function运行时用户权限问题水平扩容探索与尝试资源申请规范指定与部署规范约定因此，前进的道路仍然很曲折，而且很多需求需要自己从源码上去寻找解决方法。 一些说明kubeless实现的serverless体系中，function所在pod中的所有容器共享网络和存储namespace，但是默认外网是不可访问k8s集群的所有pods，因此需要通过一层代理实现请求的转发，这就是“Service”。Service负责服务发现及转发（iptables四层），因此在Kubeless或者K8s中不会直接通过pod IP来访问服务，而是通过Service转发四层流量完成。Service有K8s分配的cluserIp，clusterIp是集群内部虚拟IP，无法被外部寻址，而是通过Kube-Proxy在容器网络之上又抽象了一层虚拟网络，Kube-Proxy负责Service的路由与转发(关于kube-proxy细节，请看参考资料)。 Service后端对应是一个或多个pods，这些pods中的一个容器则运行相同的业务代码。那么流量是如何路由至Service上来呢？这就涉及到Service的“发布”，常用的是Ingress。Ingress包括HTTP代理服务器和ingress controller，代理服务器负责将请求按照规则路由至对应Service，这层需要Kube-Proxy实现虚拟网络的路由；ingress controller负责从K8s API拉取最新的HTTP匹配规则。](https://si.geilicdn.com/viewm... 问题解决自定义镜像：这里的镜像包括两部分：构建镜像和运行时镜像。运行时镜像需要解决宿主代码的鲁棒性，以及提供 livenessProbe、readinessProbe、metric接口实现；构建镜像则负责构建阶段的操作，如编译、依赖安装、环境变量注入等操作。具体编写可参考 implement runtime images)。构建镜像参考1关于function的CRUD操作，笔者先通过命令行走通整个流程后，又切换成基于yaml的配置文件启动，使用yaml启动好处在于：a，可使用kubeless自带的流量导入与摘除策略 b，水平扩容简单 c，命令简单 d，配置文件模板化，自动化部署策略由于涉及到业务特点，此处不详细介绍日志的挂载是必要的，否则pod一旦重启，容器内的所有日志全部丢失。尽管会存在日志收集的操作，可是日志收集进程大多数都是异步进行，因此会存在丢失日志的情况。因此，必须通过挂载volumn的形式在K8s node上映射文件。但在这过程中会出现权限的问题，这在下一点说明权限问题在于kubeless将function的执行权限设置为非root。这是安全且符合常理的设定，但有时function需要root权限，这需要修改K8s的security context配置，需要谨慎处理水平扩容基于K8s的HPA组件完成，目前支持基于CPU和QPS等指标进行扩容，目前笔者并未专门测试这项内容，因为它足够可靠资源申请的指定需要符合每个公司的实际情况以及业务特点，以node技术栈为例，pod中每个容器设置1C2GB的内存符合实际情况；而至于部署规范，则要兼顾运行时容器的特点，合理配置K8s的node与pod、function的对应关系总结运行在kubeless 中的函数和运行在super-agent的代码没有什么不同，可是周边的环境准备可大大不同。为了让kubeless中的function可以接入公司内部中间件服务，笔者费了不少功夫，主要集中在日志及收集部分。好在事在人为，解决的办法总是多于失败的方法。 ...

部署K8s应用服务 1 搭建docker registry镜像私服(或者使用Harbor搭建) docker run -d -p 5000:5000 --name registry2 --restart=always --privileged=true -v /var/docker/registry:/var/lib/registry registry2#--restart 标志会检查容器的退出代码，并据此来决定是否要重启容器，默认是不会重启#--restart的参数说明 # always：无论容器的退出代码是什么，Docker都会自动重启该容器# on-failure：只有当容器的退出代码为非0值的时候才会自动重启2 构建镜像并上传到docker registry 配置Dockerfile构建 FROM java EXPOSE 8809 ADD ./app-svc.jar app-svc.jar CMD java -jar ./app-svc.jardocker build -t app-server . 上传应用服务镜像 镜像标记为 192.168.33.11:5000/app-svc:v1 docker tag app-svc 192.168.33.11:5000/app-svc:v1 docker push 192.168.33.11:5000/app-svc:v13 在master节点创建服务 配置K8s文件app-svc.yaml如下： apiVersion: v1 kind: ReplicationController metadata: name: app-svc-rc spec: replicas: 2 selector: name: gw template: metadata: labels: name: app-svc spec: containers: - name: app-svc image: 192.168.33.11:5000/app-svc:v2 ports: - containerPort: 8809配置K8s文件app-svc.yaml如下： ...

本文根据博云在dockerone社区微信群分享内容整理 过去几年博云在企业中落地容器云平台遇到了很多痛点，其中一个比较典型的痛点来自网络方面，今天很高兴跟大家聊聊这个话题并介绍下我们基于OVS自研的CNI插件——内部称之为fabric项目。 01容器平台落地时网络方面的需求 从2013年左右Docker技术在开发者中流行起来，到如今kubernetes已经成为事实上的容器编排引擎，容器、微服务、DevOps互相支持互相促进，容器云平台的实际落地案例开始越来越多。特别是2018年以来，越来越多的企业开始思考如何利用容器云平台支持其生产场景最终提高生产效率。 不同于开发测试场景，生产场景上线一套平台或系统要求会严格很多。安全、监控、流程、现有系统集成、业务暴露等等的建设要求都要匹配上，否则不可能上线。在这个过程中，特别是在传统的金融类企业对监管要求严格的情况下，容器云平台落地时会碰到很多问题，这其中，最典型的一个需求就是容器云平台的网络建设，必须同时满足业务方，运维人员，安全人员，网络人员的诉求。 现在容器云平台大部分都是基于Kubernetes构建，市面上的CNI插件也非常多，各个企业现网的需求也有很大的不同，所以几乎不可能出现一种网络模型适配所有客户场景的情况。现在主流的比较成熟稳定的CNI比如calico在扩展性、稳定性等方面表现优秀，但在传统金融类企业落地时非常困难，经常需要对不同的需求做出妥协。 我们和多家客户进行了深入沟通，虽然需求有所差异，但总结下来主要的诉求包括：在主流的二层组网的数据中心中，受限于硬件能力或管理复杂度，大部分客户不希望引入BGP等三层路由概念。企业业务系统往往会在容器云平台内外同时同时部署，希望平台内外网络能够直接打通。IP地址是业务的身份识别，希望能够具备固定IP的能力，而且是可管理、可审计的IP地址。管理网络和数据网络分离。具备网络隔离能力，硬件隔离的强安全性和软件隔离的灵活性都需要。网络模型应该尽量简单，易于掌控，易于调试。高性能，低抖动的网络吞吐能力。其他的高级特性，如双向限速、DPDK、overlay等。 我们对市面上主流的CNI插件进行了广泛的调研后，发现主流的CNI对以上“国产化”的需求的支持并不理想，主要的不满足点包括： 网络模型差异（三层VS二层，当然L2的方案也很多，OVS有流表等等高级功能，非常适合当今云化的环境），要适配现网环境、安全策略等。 云原生理念。主流的CNI较好的满足了云原生的概念，但客户的实际需求中其实是有些“anti-cloudnative”的，如何在cloudnative和anti-cloudnative之间做到平衡其实普遍缺少实践经验。 简单稳定可靠。这其实是非常重要的要考虑的点，厂商、企业都要有相应的人员能够掌控网络模型，毕竟网络作为云平台的底层，出现问题后影响太大。 我们针对网络建设的核心需求及社区现状综合分析之后，决定启动beyondFabric项目，目前该项目已经作为博云容器云平台重点支持的两个网络模型（calico/beyondFabric）之一，支撑了多家企业的生产系统的稳定运行。 02BeyondFabric BeyondFabric是我们自研的kubernetes CNI插件，利用etcd作为其数据存储单元，内置完善的IPAM能力，能够很好的满足前面提到的客户的核心诉求。因为BeyondFabric是基于二层网络设计的，同时针对特定需求做了很多优化，所以其在一部分场景下（特别是国内高度重视安全的金融类企业数据中心中）表现良好；但同时也决定了BeyondFabric不能适合于所有的场景，具体选择哪种CNI还是要根据自身情况作出评估。（实际上没有任何一种CNI能满足所有的场景需求。） fabric经典模式示意图 从fabric的概念图中可以一目了然的看清楚云平台的网络拓扑，每个计算节点上安装一个OVS，并且作为一个单纯的虚拟交换机使用，容器通过veth pair连接到OVS的端口上从而自然的获得物理环境下的网络身份；在网络的层面上，容器、虚拟机、物理机是完全对等的。不论是网络管理人员还是业务人员都可以简单清晰的了解到网络的拓扑情况。而且在这种简化的部署模型中（同时也是使用度最广的模型）不包括控制器等复杂逻辑，提供了简单、高效、稳定的网络环境。 fabric的组件图 fabric是基于OVS的CNI插件，其具体职能为为POD组建网络并设置IP地址。fabric-ctl负责网络及IP地址管理，通过RESTFUL API提供网络/IP的管理能力，如创建网络， 编辑网络，查找IP等。fabric-ctl本身是无状态的，所有状态信息存储到etcd中。fabric-admin的主要使用人员为平台管理员或BOC运维人员，方便使用人员查看和管理网络及IPAM等。fabric-admin的命令行格式参考Kubectl。 在经典组网模式下，将ovs作为一个基本的虚拟交换机使用即可，非常简单。如果使用networkpolicy等隔离策略，需要在每个节点上引入一个分布式控制器。 网络管理能力fabric项目除了CNI协议规定的组建容器网络的功能之外，还以restful API、annotation等方式额外提供了对网络的管理能力。通过界面集成后可以方便管理人员使用，如下图中的增加网络，查看网络，查看IP地址使用，固定IP等。 增加网络 查看网络 查看IP地址使用 固定IP地址 成熟度接下来看一下fabric项目的成熟度，一个项目的成熟度是由很多方面决定的，除了fabric设计之初的简单网络模型，成熟的组件（无额外复杂组件，即使在做策略控制/overlay等场景下，也只是在每个节点上引入一个分布式控制器）之外，我们还做了以下几个方面的工作。 fabric-admin考虑到软硬件层面的异常情况，例如kubelet或fabric的bug，环境（硬件损坏）等均可能对系统的正常运行造成不同程度的影响，所以提供了一个fabric-admin的工具，位于/opt/cni/bin目录下，其作用类似于文件系统的FSCK能力，为运行时管理提供保障。同时其命令行格式完全匹配kubectl，对熟悉kubernetes的用户非常友好。 例如可以查看pod的IP占用情况（示例输出已被截断） ： 同时，fabric-admin还提供了多种运行时管理能力支持，运行--help后可以提示： 如同FSCK是文件系统成熟的重要标志，fabric-admin是beyondFabric项目成熟的有力保障！（fabric-admin虽然功能强大，但客户现网环境中还从来没有被使用过，也从侧面说明了fabric项目的成熟度） kubernetes社区CNI测试套件因为fabric项目完全满足CNI协议规范，因此可以使用任意的CNI测试工具进行测试。我们的测试团队结合社区提供的CNI测试工具及k8s job对象等对beyondFabric进行了长时间的严格测试，测试结果证明fabric项目具备生产可用能力。 多种平台支持私有云建设中，容器云平台一般运行在物理环境或vmware/openstack等虚拟化环境中。fabric对于这几种部署环境均能完善支持。对于网络环境复杂不易变更的场景下，fabric基于overlay可以显著减少环境依赖。 多个落地案例博云容器云平台基于fabric已经有多个的落地案例，在可管理性、稳定性、性能等多个方面运行良好。 BeyondFabric性能接下来看一下fabric的性能表现。由于fabric采用了稳定可靠的OVS作为其基本单元，所以从原理上讲其性能损耗应该是非常小的，我们在物理环境中基于万兆网络的性能测试也验证了这一点。图中可以看出pod-pod/pod-node的损耗较node-node约在5%左右。 博云容器云平台网络模型选型建议然后我们来看一下选型建议。在客户落地容器云平台的过程中，我们会和客户进行大量沟通，其中一个很重要的沟通就是涉及业务方、安全人员、网络人员、运维人员的网络模型沟通。具体的选型建议如下表所示，最终的选型结果由所有涉及人员共同决定。 fabric项目的小结OK，简单总结一下fabric项目。fabric项目解决了企业落地容器云平台的一些主要的痛点，通过经典网络模式可以很好的满足各个职能部门的诉求。但毕竟没有任何一种网络方案能满足所有的网络诉求，fabric也有其天生的缺点，例如经典网络模式下需要客户真实的IP网络，这些网络资源在容器化的环境下消耗速度很快，需要根据业务需要提前创建好网络资源，然而有些客户的IPV4资源会比较紧张。当然这一点随着VXLAN的支持和IPV6的普及，将会得到很大的改善。fabric核心是二层的解决方案，二层就必然面临扩展性的问题，我们目前的解决方案是通过分区的概念去映射真实的网络分区，然后通过扩展分区的方式扩展Kubernetes集群。 Q：IPAM的固定IP是怎么实现的？IP与Pod UID关联吗？A：管理员录入网络信息后，Fabric会将所有IP地址存储到etcd中统一管理。目前固定IP是通过给deployment等workload对象增加Annotation实现的。IP不与Pod UID关联。 Q：这里面提到的三层网络和二层网络是指七层协议的三层二层吗？A：是的，比如交换机工作在2层，路由器工作在三层。 Q：服务负载均衡怎么实现的呢？A：外部流量导入集群的负载均衡是通过另外一个组件，ingress controller实现的，没有实现在CNI里面。Kubernetes svc的负载均衡是通过iptables实现的，Fabric项目也会往iptables里面加入一些规则，主要是跨节点SNAT。 Q：支持流量限流么？A：支持Ingress/Egress限速，通过给容器加Annotation即可以实现容器的限速。 Q：有和Contiv做过对比吗？A：选型阶段做过，比较早了，那时候貌似Contiv还不太成熟，所以没深入研究。 Q：这些网络方案有什么好的学习方式吗？A：网络虽然很复杂，但万变不离其宗。容器网络这个词最近几年比较流行，是因为网络再容器环境下遇到了一些挑战，但网络本质的概念还是过去非常成熟的那一套。所以首先得学习基本的网络知识，然后去看下容器环境快速弹性等带来的痛点。 Q：TC怎么实现的？A：这个实现的比较久了，早在过去重点支持Calico的时候就已经做了。有些细节模糊了，但基本是通过Linux tc实现的，因为本质是veth pair，所以限速可以在主机侧veth端实现。基本的限速命令可以查找tc机制就可以了，我们碰到限速不太准确，最后也通过调整参数解决了，误差控制在百分之几吧。 Q：与Kube-OVN做过对比吗？A：Kube-OVN是友商开源的产品，我了解过。首先Kube-OVN和Fabric项目都是基于OVS进行研发的，都支持Overylay/underlay模式，都可以实现CNI协议。但其实差别还是比较大。OVN项目源于OpenStack，OpenStack里的网络模型是非常重的，概念、组件都比较多，OVN也在试图统一Kubernetes/OpenStack的网络模型，所以Kube-OVN里有一些能力其实已经不在CNI spec的范围内了，比如负载均衡，DNS等，其实在社区都有对应的实现。而Fabric会简单很多，是一个标准的CNI实现，网络模型也非常清晰，能够把容器直接融入现网环境，企业的网管一般都能掌控，对安全监管等已有体系兼容性比较好。 网络是非常复杂的，很难有一个统一的模型去兼顾所有的场景，个人认为这也是Kubernetes社区聪明的地方，把这些复杂的，不宜标准的东西抽象出来，交给第三方去做。也正是由于CNI协议的简单性和网络的复杂性，现在市场上CNI可以说百家争鸣，各有所长。个人认为这是一个非常好的现象。具体使用哪种CNI，还是要根据企业自身的情况作出决定。

云原生的时代已经到来，云原生技术正在重塑整个软件生命周期，阿里巴巴是国内最早布局云原生技术的公司之一。 容器服务团队在过去的几年时间内帮助很多用户成功把业务云原生化并迁移上云，其中有现在已经是我们TOP10的大客户，也有需要在国内开展业务的海外用户，有些是从其他云厂商迁移过来的用户，有些是从IDC里迁移上云的用户，而且越来越多的用户开始咨询如何对自己的应用做云原生化改造、如何把业务平滑地迁移到云上。每个用户的业务场景都是不同的，有些差异化的业务场景对容器平台也有一些定制化的需求，我们在帮助这些用户落实迁云方案的同时也在不断思考如何把这些案例中共性的东西做一些沉淀，总结出一些优秀的解决方案、最佳实践以及开发一些工具来帮助用户快速完成迁云的这件事情。这些解决方案、最佳实践以及迁云工具就是今天这篇文章想要分享的内容。 在帮助用户落实迁云方案之前，我们首先必须要回答至少3个问题：（1）ACK（阿里云容器服务Kubernetes）如何能保证用户业务的可靠性、稳定性、安全性和灵活性；（2）如何设计迁云方案把业务平滑地迁移到ACK；（3）应用如何做进一步改造来适配ACK提供的更强大的扩展能力。 1. ACK如何保证用户业务的可靠性、稳定性、安全性和灵活扩展性 首先，ACK是以阿里云可靠稳定的IaaS平台为底座的，有最大的弹性化与低廉成本和全球化接入的优势；其次，ACK本身处于阿里云的安全体系架构之下并从基础设施到容器运行时环境对容器集群有全维度的安全加固；过去几年我们很好地支撑了成百上千家大小企业的业务运行，有海量用户经验总结并经过双11验证；除此之外。ACK是在标准的Kubernetes基础上，对与用户息息相关的能力做了大幅提升，用户完全不需要担心会被某一家厂商绑定。 在我们过去帮助用户业务上云的案例中，绝大部分是自建Kubernetes集群迁移到ACK集群，与自建Kubernetes集群相比较，ACK在成本、弹性、IaaS高度融合、性能、安全加固以及实践经验等方面都有非常巨大的优势。 另外，ACK与阿里云的所有region保持一致，除了国内多个区域开服外，在东南亚、中东、欧洲、美东美西都有开服，完全可以满足用户开展全球业务的需求。 2. 整体迁云方案设计用户业务整体迁云的方案设计会涉及到集群规划、数据搬迁、监控切换、日志切换以及最终的生产流量切换或并网操作。 迁云到ACK需要做涉及到哪些组件、搬迁哪些数据、切换哪些服务等，都是需要用户又清晰的概念的。首先需要做集群规划，用户需要根据自己业务场景的不同来选择不同的机器类型，比如CPU机器还是GPU机器，比如虚拟服务器ECS还是神龙裸金属服务器等等，网络规划这部分会涉及到容器集群基础设施选择vpc内网网络还是经典网络，集群内pod之间进行通信模式是flannel模式还是terway模式等，在容量规划这部分，用户可以根据自己的成本以及预算规划一个可满足初期业务正常运行的容量即可，随后可以配置动态扩缩容随时弹缩集群规模；在安全防护提升这部分，有基础架构安全比如设置合理的安全组规则，有镜像安全比如使用私有镜像并定义镜像安全扫描，K8S应用安全管理比如设置不同服务间互相访问的网络安全策略等；监控切换这部分相对于用户自建Kubernetes会更加全维度和立体，从基础设施到容器运行时监控一应俱全，并可根据阈值设定触发报警通知；用户一般也会把自建的日志收集方案切换成阿里云上企业级的日志产品SLS；数据迁移是非常重要的一部分，这些数据包括数据库数据、存储数据、容器镜像等，我们会对接阿里云上企业级的粗出产品以及迁移工具，目的是为了保证数据迁云的可靠性、安全性；应用改造主要涉及的内容包括镜像地址的更新、服务暴露方式的优化以及存储盘挂载方式的更新适配；最后提供一个满足用户快速迭代上线产品的CICD方案。以上各个组件调试完毕后，我们就可以进行一部分生产流量的切换。以上从集群规划到生产流量切换便是用户业务迁移上云所需要涉及到的方方面面。 我们提供了一个企业容器化生命周期模型，这个模型是根据时间阶段和用户侧各个业务角色来划分的，比如业务架构师角色需要关心的是业务上云能给公司带来什么价值，在TCO和场景上会带来哪些优化，云平台在安全性以及计算、存储、网络能力上是否能满足当前业务需求；IT架构师负责规划当前业务需要的集群容量和规模以及网络选型等问题，剩下的就是系统管理员与应用管理员把迁云方案的各个细节落实下来。这个模型的主要核心关注点是让用户的业务上云后能更稳定、成本更低、效率更高。 全栈迁云架构思路分两种，一种是整体迁移，一种是平滑迁移。整体迁移是指用户应用全部迁移上云后，各个组件调试完毕、测试验收通过后，可以整体切换生产流量到线上集群，待线上集群上的业务稳定运行一段时间后再下线原有环境。平滑迁移是指用户可以使用线上ACK集群纳管线下节点，或者线上集群与线下集群混合组网对外提供服务，逐步改造业务组件上云后将原有环境下线。这两种方式相比，整体迁移更简单，平滑迁移响度复杂但对业务影响小，所以也需要根据用户的实际场景做选择。 容器化整体迁云这部分还有两个小场景，一个是用户从自建Kubernetes集群迁移到ACK，此场景下用户的应用已经做了很大一部分的云原生化改造，迁移工作相对来说会简单些，还有一部分用户的应用是传统应用，直接运行在虚拟机或者裸金属服务器上，没有做过任何云原生化的改造，对于这部分场景，我们也提供了相关工具或方案帮助用户进行云原生化的迁云改造，比如使用derrick项目可以自动检测源码项目类型并生成Dockerfile和用于应用部署编排的yaml文件，比如我们正在联合ECS SMC（迁云中心）开发的虚拟机转换容器镜像并运行在ACk集群中的能力。 为了帮助用户提高迁云的效率，我们也在持续积累和开源一些迁云工具。比ack-image-builder为用户提供创建ACK集群节点自定义镜像的模板并通过校验模块检查自定义镜像是否满足ACK集群要求；sync-repo能够帮助用户快速完成容器镜像批量迁移至ACR（容器镜像仓库服务）; velero能够帮助用户快速把其他云厂商后者自建Kubernetes集群下的完整应用迁移至ACK集群。 Velero迁移Kubernetes应用到ACK视频DEMO 在数据搬迁部分，可靠迁移是关键，根据用户数据类型的不同，我们会使用与之匹配的企业级迁移工具，比如数据在线迁移服务DOMS，比如OSS的迁移工具，还有离线海量数据迁移方案闪电立方等。 数据、应用迁云完成后，需要进一步适配监控、日志等组件，待各个组件调试完毕通过验收后，可以使用智能DNS进行生产流量的切割。 3. 应用改造和优化 对于应用改造和优化这部分，K8s到K8s的场景下，需要优化的是去适配自动扩容等自建K8s不具备的那些能力，在传统应用迁移到ACK的场景下，这部分的工作量会更大些，所以我们针对这个场景也输出了一些方案，比如类似于异地多活的方案，我们把用户传统应用环境，通常是虚拟机或者裸机环境集成到线上ACK部署的Istio网格中，逐步改造应用直至业务全部切换到线上ACK集群。 在应用逐步改造的这个过程中，会涉及到应用如何容器化、网络环境如何迁移以及数据迁移的问题，应用容器化这个问题，我们可以使用前面我提到过的一个服务叫做SMC迁云中心来完成虚拟机转换为容器镜像的过程，网络这部分可以通过iptables，External，CoreDNS PrivateZone等方式对IP地址DNS域名做处理，保持原先的逻辑IP和域名不变，并通过Istio实现网络虚拟路由和可观测性的管理。 4. 案例 接下来是部分迁云案例，有对高性能网络有特殊需求的用户，有做深度学习相关业务对大规模GPU机器有需求的用户，有要求裸金属机型服务器的用户等等。 5. 总结不同用户的不同业务场景在云原生化迁云方案的设计和落实上都有各自的差异性，不尽相同，需要结合ACK团队沉淀下来的最佳实践来快速做出评估和计划，并借助已有的一系列迁云工具快速完成业务从线下迁移上云的过程。 本文作者：流生 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

从2013年，云原生（Cloud Native）的概念由 Pivotal 的 MattStine 首次提出，到现在，其技术细节不断得到社区的完善。云原生逐渐演变出包括 DevOps、持续交付、微服务、容器、敏捷基础设施等内容，也形成了一种团队、文化、技术组织形式和管理方法。企业采用云原生来构建应用，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。 那么云原生究竟有哪些神奇的力量？云原生技术的发展又面临着怎样的境况？京东作为CNCF云原生基金会的白金会员，又是如何利用自身业务场景优势来推动开源技术的应用实践？京东云产品研发部专家架构师刘俊辉为大家做出了解答。 云原生是什么？在云原生技术全面爆发之前，我们开发的应用可以被称为非云原生应用，非云原生应用并没有考虑到应用的弹性和规模性，甚至很多都不具备扩展性，当业务规模扩大时，特别依赖硬件的升级，进而带来了巨大的成本问题。 相比于传统开发，云原生的核心优势是： 灵活性，可以随意组合各种应用，通常是基于容器的应用；弹性，可以按需使用云的资源，节约成本；规模性，不再受传统机房物理机的限制，在云上几乎可以做到无限扩展。除了利用云本身的特点外，云原生在成本上、规模上都能更好的适应企业未来发展。 当然，也不排除一些公司上云后并未明显降低成本，这类公司业务通常是非常稳定的，并且可预测在未来不会有爆发性增长的需求，那么企业运维原有的硬件以及维持一个稳定的团队就足够了。而真正的互联网公司，对用户增长的期待一定是指数级的，这样就要尽早考虑云原生的应用。 其实，在国内谈云原生是比较前沿的。 现在的互联网企业领导者，或多或少会意识到云或云原生的价值，但是多和少的程度差别很大，新兴的互联网公司基本上可以100%的拥抱云原生，但老牌企业对传统架构进行转型时就会遇到各种问题。 企业上云可能面临着三方面的需求：应用的技术改造、人员的技能升级、管理者的观念转变。 这三个需求是由易到难的。这其中最困难的就是管理者的观念转变，因为决心难下，决定难做。转变就意味着投入，意味着调整，意味着在短期内可能看不到收益并且会有较大的投入或者是生产力的下降。 如果领导者下定决心去做，还能给企业人员一定的时间去学习、转型新技能，这之后遇到的技术问题将会是最容易解决的问题。 京东为什么做云原生？京东云，作为具有强产业属性的云智能厂商，在云原生技术的大量投入来自于自身业务的需求，在每年的京东618、京东11.11电商促销季的海量数据和洪水般的流量面前，从电商的前端网站、订单、结算、支付、搜索、推荐，到后端的仓储、配送、客服、售后，以及采销人员使用的各种业务系统都面临前所未有的挑战。京东几千个系统，几万个应用，每一个环节正常工作才能保证整体业务顺利运行。 因此，京东云需要一个灵活的、有弹性的、可规模化的平台，这是对云原生的天然需求。同时，京东云也要有自己的架构模式，并向着100%云原生努力着。 目前京东云的实践主要分成三个阶段： 第一阶段，在京东云刚起步时，大量参考了OpenStack的实现，基本上是定制化的OpenStack。之后在使用过程中暴露出的问题比较多，其中一个重大问题是云原生的规模化，当规模迅速提升时，OpenStack已经无法满足需求，会出现各类问题，包括稳定性问题、数据一致性问题等； 第二阶段，京东云用自己研发的组件完全替代了OpenStack，在这个过程中，一部分业务做到了容器化，并在此期间研发了原生容器容器技术。原生容器可以看作使用容器镜像的虚拟机。相对于虚拟机更轻量化，能更快捷的启动；相对于Docker容器，能更好的实现安全性和隔离性。 第三阶段，也是目前正在做的阶段，京东云希望把所有的业务都容器化、Kubernetes化，以便拥有快速、一致性的部署能力。 由于用户规模和业务量庞大，京东云在运行大规模集群方面也积累了不少经验，尤其是在集群的可靠性、稳定性、数据的安全性方面表现突出。 京东在云原生上有哪些技术突破？容器化 · 京东云容器部署 10x 加速 在传统情况下，容器启动时整个容器镜像都要被加载完才能开始启动的过程，但从抽样调研的一些京东容器应用中发现，平均每个容器镜像只有10%会在启动阶段被访问到。京东云所做的工作就是实现一边加载一边启动，优先加载启动所需要的部分，也就是说，典型情况下只要加载10%的镜像的内容就可以完全启动容器。 据了解，10x 加速的说法是从统计意义上定义的，不同业务模式的容器，启动模式不同，加速效果也不同。比如在京东云上运行机器学习的容器，它的镜像的大小可能超过 10G，相应的启动速度加速会更明显。 微服务 · 架构拆分和粒度 企业是否采用微服务、什么时候采用微服务、如何采用微服务的技术路线，一定是从需求出发的。如果企业是面向互联网的，像电商、社交网站等，在用户增长时一定会面临大量问题，如果不用微服务会导致架构到某个阶段被迫重构。但是对于一些客户数量、模式比较固定的应用，就可以选择其中具有弹性和规模性需求的部分应用先进行微服务化。 微服务的一个优点在于相互之间可以使用不同的开发语言，在处理不同的任务上发挥各自的优势。同时，可以根据开发人员的能力，来决定以何种语言开发何种功能，借此来进行整体架构的拆分。 京东云的微服务平台依托于京东的多可用区部署，可以实现跨可用区的分布式部署。用户无需任何运维操作，就可以获得跨机房的高可用性。此外，平台还将微服务框架、弹性部署、日志分析等系统深度集成，一站式满足各类运维需求。 自动化运维 · 云原生& DevOps DevOps和云原生是相对独立的关系，即使没有云原生，DevOps依然是一个非常领先的一个理念。DevOps存在的价值在于帮助互联网公司快速的迭代，能让用户的需求能在第一时间被满足，所以DevOps要求开发环境和运行环境的一致性，以及灰度发布等快速迭代的能力。 现在的互联网公司每天发布几十个变更已是常态，这几十个变更不只在开发环境，还包括在生产环境中。这种发布变更的模式就是由DevOps能力提供的，如果能持续的发布变更，并且不影响用户的使用，那么企业就可以比其他的竞争者更好地满足用户需求。因此在京东云，DevOps和云原生是非常好的协同关系，而并非强绑定的。 为了更好的在云原生的环境下实践 DevOps ，京东云做了什么？京东云的DevOps目前主要能够提供全链路的部署、监控、运维、服务治理等解决方案，提升企业DevOps水平，实现研发、测试、运维高效协同，提升服务效率和整体稳定性。 京东云提供了代码仓库、云编译、云部署等DevOps各关键环节的产品解决方案，同时提供了代码流水线产品将DevOps全流程贯穿起来， 京东云提供的服务管理功能，能够进一步提供基于服务树的角色权限管理和机器、资源管理自动化运维服务，满足各种复杂运维场景一键式作业，实现自动化运维。 在持续交付方面，基于Kubernetes的容器编排方案，提供从代码编译构建、部署、流量接入的持续交付流程，未来还将在网络和调度层进一步进行定制化调优，更切合企业实际场景。 另外，京东云提供从基础资源到服务可用性、服务性能和业务逻辑的全链路监控服务，支持多种类型的监控：基础监控，进程/端口监控，域名监控，死机监控，日志监控，组件监控，方法监控和自定义监控。进一步形成故障发现 – 故障定位 – 故障恢复整个故障生命周期闭环，降低MTTR。 Serverless · 函数计算和原生容器 通常，企业在建一个网站时，至少需要一个虚拟服务器或是物理服务器。但有了无服务器架构的概念后，一些拥抱前沿技术的公司就把网站转移到了无服务器技术上。二者最大的区别是无服务器的网站不再需要外部服务器模块，所有动态的内容、资源、框架类的部分静态内容，都可以通过无服务器提供。因此Serverless能够帮助应用开发者摆脱服务器等底层基础设施管理的负担，专注于业务层的创新。 无服务器技术目前并无公认的定义，京东云认为服务器技术目前有三种实现：第一种是真正的无服务器，就是所谓的函数计算；第二种是类似京东云的原生容器，容器直接呈现给用户，并且背后不需要有虚拟机来支持”。第三种是应用的比较广泛的无服务器，背后的虚拟机由云厂商来提供，但是对用户不可见，仍然是以机的方式来提供容器。 根据现在企业的运作模式不难判断，无服务器未来大部分会迁移到函数计算，至于以分离容器形式存在的无服务器未来会不会保留，目前还没有结论。 京东云在无服务器方面开放了两个层面的服务：函数计算产品和原生容器，其主要考虑因素包括稳定性、可靠性和安全性，其中还包括规模化和快速部署能力。 函数计算方面，京东云和AWS的Lambda 以及Azure的Function类似，都是需要用户提供一段代码，这段代码以HTTP的入口形式可以访问。代码可以用Java等多种语言写出，处理完用户请求后给出一定的反馈，整体代码的生存周期就是请求的处理过程。代码是由函数计算来提供包括CPU、内存、语言平台等运行环境，用户完全不用关心代码运行在什么地方。 ...

2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近千名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。 来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等近20家企业的技术负责人出席了本届ECIC，在大会现场带来了关于企业容器项目实践经验的精彩分享。 大会现场，平安科技CTO及总架构师方国伟提出，近年来在云计算赛道上，容器因为它轻量、灵活、易管理、易迁移等特性被企业广泛采用，如一辆高速前进的方程式赛车脱颖而出，成为了企业云化历程中的大势所趋。在未来3年，平安云将会重点投入容器建设，解决容器快速交付的难题，并且进行微服务的支撑。 以下是平安科技CTO及总架构师方国伟的演讲实录： 大家上午好！谢谢梁胜博士，谢谢Rancher邀请我们在企业容器创新大会上分享。 先和大家介绍一下平安科技的容器应用情况，我们从2014年开始关注容器技术，2015年开始构建容器相关的产品，也从2015年开始和Rancher接触以及合作，是Rancher在国内最早合作的企业之一。刚才梁胜博士在介绍Rancher产品的时候，提到了平安云支持容器服务，可以通过Rancher进行多集群管理。 平安云对外提供“2+1”的云服务。公有云和其他公有云平台是一样的，对外提供服务，用户自己注册，审核之后变成平安云的客户，这就是公有云。第二部分是专有云，专有云和平安整体发展领域有比较大的关系，平安集团专注于五个生态圈，金融、医疗、智慧城市、汽车和房地产，我们针对各个垂直领域建立独立的物理隔离的云平台，这就是我们的专有云。 公有云和专有云在技术架构上基本上是一样的，区别在部署、安全隔离和法规征信方面。比如金融云，央行会有专门的金融云的认证规范，专有云平台要满足这个规范之后才可以将自己称作为金融云。 “2+1”中的2，一个是公有云，另一个是专有云，专有云按不同行业划分，政府客户基本上就会将应用部署在政务云上。那“2+1”中的1就是私有云，国内大企业比较倾向于在自己的数据中心内部署私有云平台，平安则为他们提供解决方案，让客户在自己的数据中心里构建和平安专有云、公有云类似的云平台。 私有云整体架构和公有云、专有云类似，区别在私有云在产品上面公有云的子集，绝大部分客户并不需要一个特别复杂的云平台在企业内部运行。 平安云和其他云的区别在哪里？我们最大的区别在于我们对外提供Full Stack（全栈服务），在我们前面提到的五个生态圈领域，每个生态圈领域有专门的公司构建SaaS服务。有些云平台厂商不提供应用，有些云平台厂商上不碰应用，但是下不碰数据等自己的市场策略。 平安整体的战略思路在于我们整体业务层面能力比较强，我们有大量SaaS应用，比如一账通，这是一款针对金融领域的SaaS平台，我们对外提供的服务Full Stack从底下的IaaS、PaaS到上面的SaaS，以整体的形式为客户提供解决方案。容器在这里面的角色就非常重要了，因为容器可以跨平台，在私有云和专有云上我们可以进行多云管理，这些都是容器在当中的价值。 接下来，我会讲一下我们怎么看到容器在云平台内的作用以及我们做的一些事情。前面也提到，我们从2014年开始关注容器，2015年开始容器相关的产品，当中很重要的原因就是我们觉得容器可以改变云计算的多个方面，尤其是在计算服务提供方式上。我列举了一些容器的特点，它更加灵活，也可以和底层资源进行耦合。 这里面有一个非常值得思考的问题，就是为什么谷歌会花费这么大力去做Kubernetes？并且在整个开源界去推广这个事情？我觉得最重要原因是谷歌整体在云上落后于像AWS这样的云厂商的，但是AWS最重要的服务是计算服务或者是它大部分的收入都与计算相关，它的计算服务是基于虚拟化的云主机来进行的。谷歌作为一个后来者，要想办法追赶AWS，如果还是传统的模式，追赶上的可能性就很小了。如果谷歌要追赶上AWS的话，它一定要改变游戏规则，容器可以帮助它，容器不一定能够超越，但这是一个很好的机会。 对于平安云来讲，我们非常看重容器也是基于类似的原因。我们相信在几年之后，越来越多的应用会变得Cloud Native，越来越多的用户会采用像微服务、Istio这样的方式来进行部署，容器可以很快地满足客户部署上的要求。这就是为什么我们花很多力气在容器服务上，用Kubernetes来构建产品的原因，这是大的背景。 平安云在容器部署方面是怎样的呢？我们是紧紧围绕客户的需求来构建产品的。在梁胜博士演讲的时候也提到，我们实际使用容器的时候，用Docker或者是Kubernetes还是会产生一些问题的。不同的客户需求不一样，有些开发人员对Docker和Kubernetes很熟悉，他可以轻松地管理自己的Kubernetes集群。也有一些开发人员不太喜欢底下的pod、端口等，他觉得只需要了解业务需求，写代码就可以了，无需关心底下容器相关的事情。所以不同的开发人员、不同客户对象需求是不一样的。 我们在平安云上提供了不同级别容器相关的服务，最底层毫无疑问的是I层的一些服务，从底向上我们会有Kubernetes集群，叫EKS，其上面我们会有Container Service，再往上我们会有PaaS平台，最上面是DevOps服务。这就是平安云上容器相关的几大服务。 EKS概念上很简单，这是一个Kubernetes管理服务，梁胜博士也提到，无论我们在公有云还是私有云上，我们都部署一个Kubernetes，当然你可以利用云主机自己去部署一个Kubernetes，但是云上面提供原生的EKS服务，它与云上面的资源，无论是底下的各种资源还是上面的像日志服务、监控服务等，都可以比较快速地通过API把服务利用起来。对Kubernetes比较了解的开发人员或者是运维人员而言EKS是一个比较好的选择，Kubernetes的API完全一样，如果他喜欢用Kubernetes命令来管理K8S服务也是完全一样的，相对而言比自己去安装一个Kubernetes简单一些。这是第一类基于Docker、Kubernetes的服务，你可以快速拿到K8S集群，构建自己的容器服务。 第二个产品我们叫做Container Service，对于很多用户来讲，他不想关心Kubernetes，也不想成为一个Kubernetes专家，他想拿到一个Container，通过Container去部署他的应用。对于这一类客户来讲，我们提供Container as a Service即CaaS服务。你不用关心底下Kubernetes的东西，由平安云的后台服务和运营团队帮你管理集群。你拿到不同Container，就在上面直接部署应用。当然我们也会管理相关的镜像市场，提供快速的镜像上传、下载、推拉等，也会应用编排一些功能，对客户来讲就是Container as a Service。 我们内部在底下换过几次Container Service的技术，现在用的是Kubernetes，这些对客户来说都是透明的。因为客户关心的是Container，拿到的也是Container，底下你用什么样的方式来做编排他都是可以接受的。我们以前用过Mesos，后面把Mesos换成了Kubernetes，这对用户来说也是无所谓的，所以这里面最大的区别在于用户关注的是Container，他不关心编排，这是我们一个第二层级的，对不需要关心Kubernetes的用户来讲，他可以使用CaaS服务来进行应用部署。 第三类服务就是我连容器都不想管理，有没有这样的服务呢？正如梁胜博士在前面提到的，他讲的是Rio，他们想构建一个MicroPaaS平台。这个有点像是平安云构建的PaaS服务，我们目前的产品叫做APaaS，APaaS的概念来自于Gartner，Gartner很多年前有份报告是分析平台层Platform Service里面到底有哪几类服务，它当时就把PaaS分为两大类，一类叫做APaaS，一类叫做IPaaS。APaaS就是我们这边在做的，IPaaS是APaaS之外的一些集成服务比如MQ、认证等。这些服务都是平台层的，它统一放在IPaaS里面。刚才梁胜博士讲的Rancher做的是一个微小的Micro Platform Rio。我最初在微软做Windows Azure，一开始定位在Platform Service，后来发现Platform Service有些问题，后来转到VM重新进入IaaS跟Amazon AWS是一样的。 这是我自己在工作这么多年的体会，为什么APaaS以前不太成功呢？原因在于APaaS构建方都是做技术架构的人，这实际上是一个很大的误区。APaaS真正的用户对象是开发人员，在构建APaaS的时候，如果有开发人员参与的话，构建的成功率会高一些。因为他知道自己的痛点，知道自己想要什么，而不是运维人员、底下技术架构人员拍脑袋构建一个Platform Service。所以平安构建APaaS，我们是由应用架构团队牵头构建一个APaaS，目的在于在你部署应用的过程中，你无须关心Container，你只关心代码，通过代码可以在APaaS平台上进行部署，快速建立应用程序的部署。好处在于进一步降低容器相关服务的使用门槛。 容器我们是2014年开始关注的，现在已经过去了好多年，虽然我们都知道容器应该是指数型发展，但实际上容器整体的发展并没有我们预期的快。当时我认为容器肯定可以快速替换大部分的云主机，但实际上这件事情没有发生。将来容器发展速度肯定非常快，但现在来说，它没有我们预期快速增长的原因是因为在容器的使用上对于开发者而言过于复杂，我们希望通过APaaS平台，进一步降低使用门槛，底下容器更透明一些，让开发人员无需过多关心容器本身的细节。 这一目标应该是可以做到的，最开始我们想在Windows上构建一个Platform Service，当时没有Container，它是基于VM来构建的，这也没有问题，它只需要一个快速的资源分配力度和分配的机制，就可以实现了。在使用容器之后，我们现在回过头来做APaaS，我觉得成功率会大大提升。 在做APaaS的时候，一个非常重要的问题在于对应用本身的服务的管理，对应用管理，对微服务本身的管理，包括对应用配置管理，这是很多时候做底层基础架构技术的人不容易看到的事情。如果我们做底下架构的服务构建的时候，大家会想到CMDB，CMDB可以管理技术架构的很多配置，但是如果你把应用部署起来之后，它也需要应用配置来把应用服务管理起来。这就是在APaaS构建里面非常重要的一个环节。只有把应用配置相关的事情构建好了，整个APaaS、整个应用发布流程才会比较顺畅地构建起来。这是我们构建的第三个层次APaaS。 接下来的PAME也是一个平台层的服务，这个平台层的服务在过去一两年也是非常重要的服务。最近一两年人工智能非常热，人工智能内有大量的机器学习、深度学习的需求。机器学习、深度学习需要大量的GPU，GPU在这方面做得效果还不错，当然如果有专门针对人工智能的芯片也是非常的好，但目前使用比较多的还是GPU的方式。为了解决大量数据训练的需求以及一些推理的需求，我们构建了一个PAME平台。 PAME平台和容器的关系在于它的资源分配是基于容器来进行的，底下是CaaS容器服务，容器服务底下的硬件上面有GPU支持，所以我们构建了PAME平台来简化机器学习使用。除了计算资源之外，在深度学习平台上，非常重要的一点在于怎样去管理数据，这是非常重要的。深度训练的数据从哪里来、怎么存储、怎么进来？模型导进来之后怎么去管理？这一切都是PAME需要解决的问题，所以PAME本身的定位也是PaaS的一种，它不是APaaS平台，它是在平台层的另外一类服务，跟容器有紧密集成的一类服务，叫机器学习平台。 机器学习平台的原理很简单，前面我们讲EKS的时候，里面是个Manage EKS Service。在PAME里面，用户可以选择不同的学习框架，如果用户有Tensorflow，我给他快速构建一个 Tensorflow平台，他可以学习，相当于我们可以快速把机器学习框架包装起来，同时加上在机器学习里面需要用到的数据导入导出模型管理这样的一些需求整合在一起，作为服务提供给客户。 对于用户来讲，不用像以前给GPU的服务器或者GPU的云主机，这些东西申请之后比较庞大。PAME是基于容器的，所以资源用完了，你就可以关掉退出，资源消耗收费就是云计算的pay as you go。这就是我们的第四个服务，叫做PAME服务。 ...

前言监控是保障系统稳定性的重要组成部分，在Kubernetes开源生态中，资源类的监控工具与组件百花齐放。除了社区自己孵化的metrics-server，还有从CNCF毕业的Prometheus等等，开发者可选的方案有很多。但是，只有资源类的监控是远远不够的，因为资源监控存在如下两个主要的缺欠： 监控的实时性与准确性不足大部分资源监控都是基于推或者拉的模式进行数据离线，因此通常数据是每隔一段时间采集一次，如果在时间间隔内出现一些毛刺或者异常，而在下一个采集点到达时恢复，大部分的采集系统会吞掉这个异常。而针对毛刺的场景，阶段的采集会自动削峰，从而造成准确性的降低。 监控的场景覆盖范围不足部分监控场景是无法通过资源表述的，比如Pod的启动停止，是无法简单的用资源的利用率来计量的，因为当资源为0的时候，我们是不能区分这个状态产生的真实原因。 基于上述两个问题，Kubernetes是怎么解决的呢？ 事件监控-监控的新维度Kubernetes作为云原生的平台实现，从架构设计上将接口与实现做到了完整的解耦和插拔，以状态机为整体的设计原则，通过设定期望状态、执行状态转换、检查并补偿状态的方式将资源的生命周期进行接管。 状态之间的转换会产生相应的转换事件，在Kubernetes中，事件分为两种，一种是Warning事件，表示产生这个事件的状态转换是在非预期的状态之间产生的；另外一种是Normal事件，表示期望到达的状态，和目前达到的状态是一致的。我们用一个Pod的生命周期进行举例，当创建一个Pod的时候，首先Pod会进入Pending的状态，等待镜像的拉取，当镜像录取完毕并通过健康检查的时候，Pod的状态就变为Running。此时会生成Normal的事件。而如果在运行中，由于OOM或者其他原因造成Pod宕掉，进入Failed的状态，而这种状态是非预期的，那么此时会在Kubernetes中产生Warning的事件。那么针对这种场景而言，如果我们能够通过监控事件的产生就可以非常及时的查看到一些容易被资源监控忽略的问题。 一个标准的Kubernetes事件有如下几个重要的属性，通过这些属性可以更好地诊断和告警问题。 Namespace：产生事件的对象所在的命名空间。Kind：绑定事件的对象的类型，例如：Node、Pod、Namespace、Componenet等等。Timestamp：事件产生的时间等等。Reason：产生这个事件的原因。Message: 事件的具体描述。其他信息通过事件的机制，我们可以丰富Kuernetes在监控方面的维度和准确性，弥补其他监控方案的缺欠。 kube-eventer v1.0.0的发布与开源针对Kubernetes的事件监控场景，Kuernetes社区在Heapter中提供了简单的事件离线能力，后来随着Heapster的废弃，相关的能力也一起被归档了。为了弥补事件监控场景的缺失，阿里云容器服务发布并开源了kubernetes事件离线工具kube-eventer。支持离线kubernetes事件到钉钉机器人、SLS日志服务、Kafka开源消息队列、InfluxDB时序数据库等等。 在本次正式发布的v1.0.0的版本中，作了如下功能的增强。 钉钉插件支持Namespace、Kind的过滤支持与NPD插件的集成与部署优化SLS插件的数据离线性能修复InfluxDB插件启动参数失效的问题修复Dockerfile的安全漏洞以及其他共11项功能修复典型场景分析： 使用钉钉进行事件告警使用SLS进行事件告警结合NPD进行异常检测与事件告警,此外使用容器服务的开发者可以直接用应用目录中的Helm Chart进行部署。项目开源地址：https://github.com/AliyunContainerService/kube-eventer 本文作者：莫源阅读原文 本文为云栖社区原创内容，未经允许不得转载。

kubectl主要用于与K8s API服务器通信，以在K8s中创建、更新和删除工作负载。不少IT人员通过kubectl与K8s交互。本文将介绍如何安装kubectl、与K8s环境进行通信以及一些常用命令，给您提供管理K8s的良好起点。 对不少IT人员来说，每天与Kubernetes交互的机制一般是通过kubectl——一种命令行工具。kubectl主要用于与Kubernetes API服务器通信，以在Kubernetes中创建、更新和删除工作负载。本教程的目的是概述您可以使用的一些常用命令，并提供管理Kubernetes的良好起点。 我们将介绍如何在您的计算机上安装kubectl，如何与您的Kubernetes环境进行通信并执行一些常见操作。大多数常见的kubectl命令会提供某特定的操作，如创建、删除等。此方法通常需要解释描述Kubernetes中的对象（如POD、服务、资源等）的文件（YAML或JSON）。这些文件通常被用作模板以及环境的持续文档，并有助于保留Kubernetes对声明性配置的关注。命令行上给出的操作将传递给API服务器，然后根据需要与Kubernetes中的后端服务进行通信。 我们将介绍一些最常见的kubectl命令并提供一些示例。有关每个命令的更多详细信息，包括所有支持的标志和子命令，请查看kubectl参考文档： https://kubernetes.io/docs/re...。 安装kubectl kubectl是一个独立的程序，因此不需要复杂的安装过程。它是一个需要位于操作系统PATH中的单个文件。有许多方法可以获得kubectl二进制文件，例如通过操作系统的本机包管理器或通过curl。下表中的一些示例就是如何为各种操作系统安装kubectl： 注意：随着新版本的发布，最佳版本的kubectl for Windows将随着时间的推移而发生变化。要查找当前最佳二进制文件，请点击此链接查找最新的稳定版本，并根据需要调整上述URL：https://storage.googleapis.co...环境中使用的kubectl版本，需要与Kubernetes服务器的版本保持一致。您可以通过键入以下内容来查看正在使用的kubectl客户端的版本： kubectl在各方面都会保持与一个版本的兼容性。其中客户端版本会比服务器版本领先一步。这为服务器版本：v1.13.4中提供的功能和命令提供了支持。如果客户端版本不是服务器版本之后的各版本中的一个，那么在尝试访问相应服务器版本中可用的功能时，可能会遇到错误或不兼容。 kubectl语法 kubectl 的语法使用如下: Command（命令）：指你想要执行的操作（创建、删除等等）Type（类别）：指你正在执行命令的资源类型（Pod、Service等）Name（名称）：对象的名称（需区分大小写）。如果未指定名称，则可以获取有关命令匹配的所有资源的信息（例如Pod）Flags（标志）：这个可以按需选择（非必须），不过它在查找特定资源时非常有用。例如，--namespacespace可以让你指定要在哪个特定的命名空间中执行操作。kubeconfig kubectl使用配置文件来访问Kubernetes集群。默认的kubectl配置文件位于〜/ .kube / config，称为kubeconfig文件。 kubeconfig文件组织有关集群、用户、命名空间和身份验证机制的信息。kubectl命令使用这些文件来查找它在选择集群并与之通信时所需要的信息。 加载顺序遵循以下规则： 如果设置了--kubeconfig标志，则仅加载给定文件。该标志只能设置一次，不会发生合并。如果设置了$ KUBECONFIG环境变量，则根据系统的正常路径分隔规则，将其解析为文件系统路径列表。否则，如果上述两项都未设置，则使用${HOME}/.kube/config 文件，不进行任何合并。如果您看到类似于以下内容的消息，则意味着kubectl配置不正确或无法连接到Kubernetes集群 The connection to the server <server-name: port> was refused - did you specify the right host or port?你可以通过多种方式创建配置文件，具体取决于你使用何种Kubernetes发行版。以下列出的是不同的K8S发行版及其位置： RKE 使用RKE创建Kubernetes集群时，RKE会在本地目录中创建一个kube_config_rancher-cluster.yml文件，该文件包含使用kubectl等工具连接到新集群所需的凭据。 您可以将此文件复制到$ HOME / .kube / config，或者，如果您正在使用多个Kubernetes集群，请将KUBECONFIG环境变量设置为kube_config_rancher-cluster.yml的路径，如下所示： Rancher统一管理的Kubernetes集群 在Rancher中，您可以通过Web UI下载kubeconfig文件，并使用它通过kubectl连接到Kubernetes环境。 在Rancher UI中，单击要通过kubectl连接的集群。在页面的右上角，单击Kubeconfig File按钮： ...

2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近1000名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。 来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人，在大会上带来了关于企业容器项目实践经验的精彩分享。 厦门航空和Rancher的合作可以追溯到2年前。2017年，厦门航空完成了厦航云计算平台项目建设，基于Rancher、IaaS和CMP搭建了三位一体的厦门航空云计算平台。 “航空行业电商的发展催生了大量的业务请求访问，平台需要做到具备极强的稳定性和自动弹性收缩能力，而原有的传统开发模式和软件开发模式早已无法满足现有的需求。” 厦门航空信息部系统工程师、云平台负责人周钊分享道：“在这样的情形下，我们找到了Rancher，通过自主研发及微服务架构与Rancher容器平台完美结合，共同打造出厦航电商战略的支持平台。” 以下是厦门航空信息部系统工程师、云平台负责人周钊的演讲实录： 大家好，我是厦门航空信息部系统工程师周钊，今天和大家分享的主题是厦门航空基于微服务的电商中台构建实践。 厦门航空是一家主基地在厦门的国内中型航空公司。 在今天的演讲中，我将和大家分享厦航的云计算平台。在2014年底，厦航云计算平台项目整体上线试运行，平台包括三个部分。首先是大家熟悉的CMP混合云管理平台，然后是基于Open Stack架构的IaaS云计算平台，最后则是我们今天的主角，Rancher容器云平台。 1. Rancher 1.6 + ELK 我们最初上线的时候，Rancher的版本是1.6，我们第一个容器化的应用是ELK，当时ELK运行在这个项目的另外一部分、也就是OpenStack的IaaS平台上，使用RBD存储实现了整个ELK的数据持久化。我们的ELK不仅仅用在日志分析等方面，我们还把ES在一些查询搜索等业务上做了广泛的推广。 目前，我们的ELK在Rancher的K8S平台上进行迁移，也就是说我们在Rancher和K8S上吃的第一个螃蟹还是ELK。 上图是当初ELK在1.6上的架构图，和社区最佳实践比较类似，在这里就不详细赘述了。 2. 容器化的电商中台 这一部分是我们的重点——厦门航空的容器化的电商中台。 电商中台和厦航的电商战略是息息相关的。它作为支撑平台，可以实现以机票销售为中心，把不同类型的乘客以不同形式的旅程，包括不同内容的附加服务，打包在一起进行全流程服务，提升我们整个航空公司的业务水平。 目前，厦航电商中台对接了公司所有直销渠道、线上OTA渠道，也就是说假如你现在拿起手机或者通过电脑，在官方渠道或其他任何购票渠道上查询厦航的机票、购买厦航的机票，都会经过我们的电商中台。 上图是厦航电商中台的架构图。在这个图里面，除了红色部分的Redis、消息队列以及最下面的公共硬件LB设备，其他组件都运行在Rancher 1.6平台上。 上面这张是厦航电商中台生产环境的截图，包含我们厦航电商中台的所有服务。 这是在整个电商中台第一次迎接比较大的考验，对接阿里飞猪，当时我在Prometheus上截的图，留作纪念。里面有一个处理到的数据，大家可以看一下。 这张是前两天准备PPT的时候截的图，可以侧面看到我们的业务增长量。 讲完厦航电商中台的成果，我想藉这个机会再次感谢Rancher工程师对厦航电商中台以及容器云平台的大力支持。 3. 电商中台上线之路 接下来，我们来回顾厦门电商中台在容器化过程中，以及在测试上线过程中积累的一些经验和体会。Rancher带给我们的提升首当其冲的就是DevOps更新迭代的速度。 我们在整个开发测试环境里实现了全流程的CI/CD流水线，整个电商中台现在有单独一套Harbor镜像仓库。 我在准备PPT的时候简单统计了一下，近期每周镜像的增长速度超过15G，这个数据是最低表现，有时每一周可能会有超过30G的镜像增长量。单个服务在上线半年内有超过100多次的功能更新，当中还不包括BUG的修复。 第二方面，我曾专门统计过容器在基础资源的利用率。如果对比我们整个电商中台，如果用虚拟机做部署，Rancher节省的计算资源比例超过38%，这个和大会上午一位嘉宾分享的40%的数据是比较接近的。 第三方面，众所周知，容器在灵活扩展和横向扩展方面速度提升非常大。 最后一方面，厦航的团队在基于Rancher API的基础上开发了Publish-helper的工具，在Rancher 1.6平台上实现接近无感知，也就是K8S这边的灰度发布的应用更新。这个工具支撑了厦航基本上所有生产环境的版本更新。 下面和大家分享我们踩过的一些坑。刚才我们讲到了容器化的一些好处，但是除此之外我们也不是没有踩过坑，主要是网络、存储和关键应用组件这三类。 首先是网络，我们一开始基础平台相对而言资源并不是十分充裕。在最开始的时候，我们用的是千兆网络，在整个平台里面，我们发现很多容器化的应用集群并不能顺利的初始化。 在排故过程中，我们存在大比例的网络丢包。后来我们分析，老旧的设备包括网卡等支持网络多会话的特性较差。后来我们就更新了整体设备，换到性能较好、特性较多的万兆网络。 但是我们在系统上线前做了一次全链路的压测，又发现单个容器尤其是Rancher 1.6里LB的容器，它的单容器网络IO并不高。 上图是我们内网拿到的数据，万兆网卡在VMWare环境下只有1.33G，在我们的IaaS平台上只有1G每秒的存储。这个数据并不能达到我们上线的需求。 经过和Rancher工程师几次的调优，我们把这个数据提升到大约4G每秒的存储量，基本上和当时K8S Flannel的网络是类似的。 ...

在云原生时代和容器化浪潮中，容器的日志采集是一个看起来不起眼却又无法忽视的重要议题。对于容器日志采集我们常用的工具有filebeat和fluentd，两者对比各有优劣，相比基于ruby的fluentd，考虑到可定制性，我们一般默认选择golang技术栈的filbeat作为主力的日志采集agent。 相比较传统的日志采集方式，容器化下单节点会运行更多的服务，负载也会有更短的生命周期，而这些更容易对日志采集agent造成压力，虽然filebeat足够轻量级和高性能，但如果不了解filebeat的机制，不合理的配置filebeat，实际的生产环境使用中可能也会给我们带来意想不到的麻烦和难题。 整体架构日志采集的功能看起来不复杂，主要功能无非就是找到配置的日志文件，然后读取并处理，发送至相应的后端如elasticsearch,kafka等。 filebeat官网有张示意图，如下所示：针对每个日志文件，filebeat都会启动一个harvester协程，即一个goroutine，在该goroutine中不停的读取日志文件，直到文件的EOF末尾。一个最简单的表示采集目录的input配置大概如下所示： filebeat.inputs:- type: log # Paths that should be crawled and fetched. Glob based paths. paths: - /var/log/*.log不同的harvester goroutine采集到的日志数据都会发送至一个全局的队列queue中，queue的实现有两种：基于内存和基于磁盘的队列，目前基于磁盘的队列还是处于alpha阶段，filebeat默认启用的是基于内存的缓存队列。 每当队列中的数据缓存到一定的大小或者超过了定时的时间（默认1s)，会被注册的client从队列中消费，发送至配置的后端。目前可以设置的client有kafka、elasticsearch、redis等。 虽然这一切看着挺简单，但在实际使用中，我们还是需要考虑更多的问题，例如： 日志文件是如何被filbebeat发现又是如何被采集的？filebeat是如何确保日志采集发送到远程的存储中，不丢失一条数据的？如果filebeat挂掉，下次采集如何确保从上次的状态开始而不会重新采集所有日志？filebeat的内存或者cpu占用过多，该如何分析解决？filebeat如何支持docker和kubernetes，如何配置容器化下的日志采集？想让filebeat采集的日志发送至的后端存储，如果原生不支持，怎样定制化开发？这些均需要对filebeat有更深入的理解，下面让我们跟随filebeat的源码一起探究其中的实现机制。 一条日志是如何被采集的filebeat源码归属于beats项目，而beats项目的设计初衷是为了采集各类的数据，所以beats抽象出了一个libbeat库，基于libbeat我们可以快速的开发实现一个采集的工具，除了filebeat，还有像metricbeat、packetbeat等官方的项目也是在beats工程中。 如果我们大致看一下代码就会发现，libbeat已经实现了内存缓存队列memqueue、几种output日志发送客户端，数据的过滤处理processor等通用功能，而filebeat只需要实现日志文件的读取等和日志相关的逻辑即可。 从代码的实现角度来看，filebeat大概可以分以下几个模块： input: 找到配置的日志文件，启动harvesterharvester: 读取文件，发送至spoolerspooler: 缓存日志数据，直到可以发送至publisherpublisher: 发送日志至后端，同时通知registrarregistrar: 记录日志文件被采集的状态1. 找到日志文件对于日志文件的采集和生命周期管理，filebeat抽象出一个Crawler的结构体，在filebeat启动后，crawler会根据配置创建，然后遍历并运行每个input： for _, inputConfig := range c.inputConfigs { err := c.startInput(pipeline, inputConfig, r.GetStates()) }在每个input运行的逻辑里，首先会根据配置获取匹配的日志文件，需要注意的是，这里的匹配方式并非正则，而是采用linux glob的规则，和正则还是有一些区别。 matches, err := filepath.Glob(path)获取到了所有匹配的日志文件之后，会经过一些复杂的过滤，例如如果配置了exclude_files则会忽略这类文件，同时还会查询文件的状态，如果文件的最近一次修改时间大于ignore_older的配置，也会不去采集该文件。 2. 读取日志文件匹配到最终需要采集的日志文件之后，filebeat会对每个文件启动harvester goroutine，在该goroutine中不停的读取日志，并发送给内存缓存队列memqueue。 在(h *Harvester) Run()方法中，我们可以看到这么一个无限循环，省略了一些逻辑的代码如下所示： for { message, err := h.reader.Next() if err != nil { switch err { case ErrFileTruncate: logp.Info("File was truncated. Begin reading file from offset 0: %s", h.state.Source) h.state.Offset = 0 filesTruncated.Add(1) case ErrRemoved: logp.Info("File was removed: %s. Closing because close_removed is enabled.", h.state.Source) case ErrRenamed: logp.Info("File was renamed: %s. Closing because close_renamed is enabled.", h.state.Source) case ErrClosed: logp.Info("Reader was closed: %s. Closing.", h.state.Source) case io.EOF: logp.Info("End of file reached: %s. Closing because close_eof is enabled.", h.state.Source) case ErrInactive: logp.Info("File is inactive: %s. Closing because close_inactive of %v reached.", h.state.Source, h.config.CloseInactive) default: logp.Err("Read line error: %v; File: %v", err, h.state.Source) } return nil } ... if !h.sendEvent(data, forwarder) { return nil }}可以看到，reader.Next()方法会不停的读取日志，如果没有返回异常，则发送日志数据到缓存队列中。 返回的异常有几种类型，除了读取到EOF外，还会有例如文件一段时间不活跃等情况发生会使harvester goroutine退出，不再采集该文件，并关闭文件句柄。 filebeat为了防止占据过多的采集日志文件的文件句柄，默认的close_inactive参数为5min，如果日志文件5min内没有被修改，上面代码会进入ErrInactive的case，之后该harvester goroutine会被关闭。 这种场景下还需要注意的是，如果某个文件日志采集中被移除了，但是由于此时被filebeat保持着文件句柄，文件占据的磁盘空间会被保留直到harvester goroutine结束。 ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。Kubernetes v1.16 发布周期开始随着前段时间 Kubernetes v1.15 的发布，v1.16 的发布周期开始了。本次的发布周期一如往常，本月底增强功能冻结，下月底代码冻结，9 月初完善文档，计划在 9 月中发布 v1.16 版本。 其实按这个节奏看得话，大家如果需要维护生产中的 Kubernetes 集群的话，还是尽快测试验证并完成升级，以免所用版本 EOL，带来一些其他的问题。 Knative Serving v0.7.x 发布本周 Knative Serving 发布了 v0.7.1 版本，Knative 近期的开发还是比较活跃的。 需要注意的是若使用 v0.7.x 版本中新增的 serving.knative.dev/v1beta1 API 的话，则需要 Kubernetes v1.14 版本以上。具体原因请参考 #4533 Non-root 容器：在这个版本中所有发布的容器均以非 root 用户运行，这使得我们可以使用更严格的 PSP。 当然此版本中也包含一些破坏性变更，比如 status 字段废弃。 关于此版本更多的细节请参考 ReleaseNote Debian 10 buster 正式发布Debian 10 正式发布了，其实按一般的角度来看，Linux 的一个发行版发布不会出现在 K8S 生态周报中的。 但这里有个需要注意的点，对于使用此版本部署 Kubernetes 时，需要注意一下。此版本中使用的 systemd 版本是 241.5 而这个版本中有个对于使用 Kubernetes 而言值得注意的点。 ...

Kubernetes 简称 k8s，是 google 在 2014 年发布的一个开源项目。 Kubernetes 解决了哪些问题？ 真实的生产环境应用会包含多个容器，而这些容器还很可能会跨越多个服务器主机部署。Kubernetes 提供了为那些工作负载大规模部署容器的编排与管理能力。Kubernetes 编排让你能够构建多容器的应用服务，在集群上调度或伸缩这些容器，以及管理它们随时间变化的健康状态。 kubernetes 基础kubernetes 优化kubernetes 实战Kubernetes 基础概念很多，第一次接触容易看晕，如果是新手，建议直接看实战部分，先跑起来再说。 kubernetes 基础k8s 中有几个重要概念。 概念介绍cluster一个 k8s 集群master集群中的一台机器，是集群的核心，负责整个集群的管理和控制node集群中的一台机器，是集群中的工作负载节点podk8s 最小调度单位，每个 pod 包含一个或多个容器label一个 key = value 键值对，可以附加到各种资源对象上，方便其他资源进行匹配controllerk8s 通过 controller 来管理 podservice对外提供统一的服务，自动将请求分发到正确的 pod 处namespace将 cluster 逻辑上划分成多个虚拟 cluster，每个 cluster 就是一个 namespaceClusterCluster 代表一个 k8s 集群，是计算、存储和网络资源的集合，k8s 利用这些资源运行各种基于容器的应用。 Master 节点Master 是 cluster 的大脑，运行着的服务包括 kube-apiserver、kube-scheduler、kube-controller-manager、etcd 和 pod 网络。 kube-apiserver apiserver 是 k8s cluster 的前端接口，提供 restful api。各种客户端工具以及 k8s 其他组件可以通过它管理 cluster 中的各种资源。kube-scheduler ...

中国联通数据中心总经理王志军在Rancher举办的ECIC大会上的演讲实录，分享了中国联通为何开始进行平台容器化并如何运用Kubernetes对9000台的服务器数据节点进行最大化利用和合理调度，进而提升了60%的基础资源利用率。 2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近千名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。 来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人出席了本届ECIC，现场带来关于企业容器项目实践经验的精彩分享，为参会的容器技术爱好者带来企业容器化的经验分享。 大会现场，中国联通数据中心总经理王志军为现场容器爱好者带来了主题为《中国联通容器化大数据云平台探索与实践》 的内容分享。 中国联通是国内三大运营商之一，同时也是国内首批将大数据平台部署在容器云上的企业。关于中国联通在容器化大数据云平台上的发展和探索，王志军分享道：“通过研究、探索和实践，我们发现Kubernetes+Docker的技术路线更契合联通的实际需求，它几乎支持了所有的容器业务类型，也正是基于联通的技术选型，我们引入了Rancher的产品部署和Kubernetes集群管理功能，为联通的容器化大数据云平台提供更强而有力的容器技术及容器服务支撑。” 以下是中国联通集团数据中心总经理王志军的演讲实录： 大家好，非常感谢Rancher邀请我们在企业容器创新大会上进行演讲，我今天演讲的题目是《中国联通容器化大数据云平台探索和实践》，内容是中国联通是怎样将大数据和容器化云平台相连接的。 建设背景 我们一起来简单回顾一下中国联通大数据和云计算的发展历程。大数据和云计算分属于两个不同的领域，大数据主要关注怎么将数据集中起来，挖掘数据的价值。云计算主要关注怎么更高效地使用资源，提升资源的利用效率。当大数据发展到一定阶段的时候，它就会和云计算不期而遇。 在大数据的方面，存在有几个标志性的事件和历程，一是2006年Hadoop的出现，二是2009年CDH发行版的出现，到2012年，大数据出现了新的资源调度管理方式，流式计算技术比如Spark和Flink等。 云计算的标志性事件是从2006年亚马逊提出EC2开始的，EC2的出现标志着云计算时代的开启，2010年出现了OpenStack，这是我们在部署私有云中非常广泛使用的一个技术，2013年是Docker的元年，让容器技术风靡了云计算领域。2014年Kubernetes的出现则将Container as a Service变成了被业界广泛接受的全新理念。大量的我们原先在虚拟机上部署单体应用或者分布式应用的架构逐渐变成了基于容器的微服务加工方式。 我们所提出的ABC融合指的是AI+Bigdate+Cloud的融合。 在Bigdate 2.0时代，Hadoop商业版出现为大家利用Hadoop进行大数据的处理提供了更好的方式。另一方面，SQL on Hadoop逐渐成熟了起来。在我们看来，SQL on Hadoop是一种更为接近人类自然来进行数据处理的语言，它和我们的关系数据库并不是一个非常紧密的耦合关系，我们大量的实时处理是基于SQL on Hadoop去处理的。第三点是最开始我们做大数据的时候，大量采用的是批处理的处理方式，现在我们更多的是采用流失处理和批处理相结合以及交互是分析相结合的方式来进行的。 在Bigdate 3.0时代，大数据云和AI已经融为一体了，客户希望能在一个统一的平台上提供AI、Bigdate和Cloud。 中国联通是整个运营商行业当中实现数据集中的企业，我们拥有企业级全域数据的存储中心、计算中心、能力中心和孵化中心。在运营商行业，他们的系统架构模式基本上都是分省来进行建设的，但是中国联通在建设大数据平台的第一天我们就把数据集中汇集到总部的一个节点，我们坚信数据只有汇聚才能发生化学反应，才能产生最大化的价值。 中国联通拥有百PB级的数据吞吐能力和统一的数据服务能力。我们数据中心的数据量超过100个PB。当然，数据量并不是越大越好，数据本身是有成本的，我们希望数据的成本和数据的价值能达到一个平衡点。另外，我们有超过6500台对内服务的服务器数据节点，以及超过2000台对外服务的服务器数据节点，加起来有9000台左右的节点数量。除此之外，从中国联通的存储能力上看，我们目前的存储能力可能接近200个PB。 全域数据汇聚和管理中心沉淀了海量的计算能力、存储能力和数据能力，导致了中国联通面临着资源智能调度、最大化利用和能力共享的难题。 中国联通有整体的数据中心节点，而在总部底下是中国联通的省分公司和子公司，他们希望利用总部的大数据平台去进行各自的数据处理和数据分析，因此产生了云计算的需求。他们希望总部的节点能够为它提供一个数据处理的平台，省分公司和子公司在平台上进行自身的数据加工和处理。 这是我们自身优化的源动力，就是中国联通自身的节点如何避免计算、存储资源不均衡的调度，创新地为租户提供同样的能力。这时候，中国联通的大数据和云计算就自然而然地走到了一起。 探索历程 我们从2016年开始在中国联通大数据云平台建设上投入很大的力量，也经历了几个不同的发展阶段。 在最初的建设阶段，我们的资源是物理部署、人工划配、系统运维，我们经历了大数据的整体发展历程，在最开始的时候，你要做大数据，必须要通过物理机器来实现，你要部署一个Hadoop机器，如果你需要kafka，你还需要用物理的机器部署一个kafka，这是大数据平台建设必然的发展阶段。 下一个阶段属于优化提升阶段，我们希望通过一个集中工作组统一管理资源，在其他人有资源需求的时候，我们去做半自动化的部署、半人工的划配，还有就是系统运维的简单监控。 第三个阶段就是通过大数据云平台提供一键部署，你需要一个大数据平台，通过一键部署，我为你提供一个大数据平台，你可以在上面去做自身数据的加工和处理。而你的数据可以来源于总部的数据平台，也可以来源于自身的数据。这样就实现了按需自动分配、弹缩，统一监控和统一运维。我们目前已经在第三个阶段了。 在中国联通进行技术路线选型的时候，我们面临着Kubernetes和Mesos二者之间的选择。 我们为什么选择Kubernetes？因为Kubernetes几乎支持所有的容器业务类型，包括长期伺服、批处理、node-deamon以及状态应用等。我们最开始在做容器应用或者是微服务应用的时候，更多的是无状态的应用。但我们提供大数据服务的时候，很多应用是有状态的。 对Kubernetes和Mesos我们进行了非常深入的分析，尤其是生态活跃度，Kubernetes的生态活跃度和社区关注度在急剧上升。我们在进行技术选型的时候，包括它的使用场景、外部应用、中间节点和数据库、有服务状态等都进行了分析。另外，技术的成熟度是否有业界厂商的广泛加持，比如谷歌、亚马逊、Rancher、IBM、阿里、百度等。Kubernetes有非常好的生态，所以我们选择了Kubernetes来解决联通的实际需求。 谈及Kubernetes时，无可避免地一定会提及中国联通和Rancher的合作。 中国联通在搭建Kubernetes和Docker容器化平台的过程当中，我们引入了Rancher的产品去部署和管理多个Kubernetes集群。我们使用Rancher Server，通过图形化和RKE两种方式对多租户的Kubernetes集群进行部署和管理。 另一方面，从我们的角度来看，Rancher有丰富的容器化实施案例经验，这块正好弥补了中国联通的一些不足之处，成为我们在处理和解决问题中的一个坚强后盾。我们更加关注于怎样把服务变成云，然后开放给省分公司和子公司使用，我们怎样才能把数据处理的更好。而针对底层的服务，我们希望借助业界的合作伙伴和我们共同解决。 除此之外，开源的产品经常会有重大安全漏洞，在这一方面Rancher能为中国联通提供一个很好的技术支持，为中国联通的云平台安全保驾护航。 平台实践 中国联通提供几个方面的服务，一是大数据即服务，比如我们的省分公司或者子公司需要一个大数据平台，我们就为它一键提供一个大数据平台，包括Hadoop、Spark、Storm、impala等，一旦我能为省分公司及子公司提供大数据平台，他们就无需自己重新构建大数据平台了。 二是中间件和数据库即服务。对于省分公司和子公司而言，光有大数据平台来进行数据处理是远远不够的，这当中必然要用到很多中间件，所以我们要为他们提供中间件和数据库即服务，这里包括kafka数据库即服务、Redis分布式缓存服务、MySQL关系数据库的服务。 有了以上二者之后，我们还可以提供数据集成工具即服务，比如云化ETL，我可以去做数据抽取转化，来为省分公司和子公司提供调度。 我们前面提到了ABC，进一步扩展，我们可以提供深度学习即服务，比如TensorFlow、Caffe等。 最后一个就是容器云服务，我们可以提供应用托管的环境。 ...

都是走的国内镜像源 -- 鲁迅关闭 selinuxsetenforce 0 #实时动态关闭 selinuxsed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config #禁止重启后自动开启关闭交换分区swapoff -a #实时动态关闭交换分区sed -i '/ swap / s/^/#/' /etc/fstab #禁止重启后自动开启网络配置文件cat <<EOF > /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1net.ipv4.ip_forward = 1vm.swappiness=0EOFmodprobe br_netfilter #执行该命令 如果不执行就会在应用k8s.conf时出现加载错误sysctl -p /etc/sysctl.d/k8s.conf #应用配置文件yum换国内源cd /etc/yum.repos.d && \sudo mv CentOS-Base.repo CentOS-Base.repo.bak && \sudo wget -O CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo && \yum clean all && \yum makecache配置k8s资源的下载地址cat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64enabled=1gpgcheck=0repo_gpgcheck=0gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF安装依赖yum install -y docker kubelet kubeadm kubectl docker换源mkdir -p /etc/dockersudo tee /etc/docker/daemon.json <<-'EOF'{"registry-mirrors": ["https://registry.docker-cn.com"]}EOFservice docker restart开机启动systemctl disable firewalld.service && systemctl stop firewalld.service systemctl enable docker && systemctl start dockersystemctl enable kubelet && systemctl start kubelet下载k8s依赖镜像获取依赖的镜像 ...

通过K8S使用NAS卷，请区分以下场景： 静态存储卷： 使用阿里云ACK，PV、PVC方式，nfs驱动；使用阿里云ACK，PV、PVC方式，Flexvolume驱动；使用阿里云ACK，Volume方式，nfs驱动；使用阿里云ACK，Volume方式，Flexvolume驱动；自建K8S，PV、PVC方式，nfs驱动；自建K8S，Volume方式，nfs驱动；动态存储卷： 使用阿里云ACK使用自建K8S静态卷-使用阿里云Kubernetes(ACK)时1. 使用PV、PVC方式（nfs驱动）首先确认当前的挂载是否配置了noresvport参数，参考NAS团队提供的方式； 例如当前的pv如下面yaml： apiVersion: v1kind: PersistentVolumemetadata: name: pv-nasspec: accessModes: - ReadWriteOnce capacity: storage: 2Gi mountOptions: - vers=3 nfs: path: /default server: 2564f49129-ggu23.cn-shenzhen.nas.aliyuncs.com persistentVolumeReclaimPolicy: Retain编辑PV： kubectl edit pv pv-nas更新mountOptions：mountOptions: - vers=4.0 - noresvport或者： mountOptions: - vers=3 - nolock,tcp,noresvport重启使用这个pv的pod； 需要注意： 由于一个节点上，如果已经有某个挂载点挂载在一个目录下了，其他的挂载(相同挂载点)即使配置了noresvport参数，还是会follow以前的挂载参数。即noresvport不生效；解决方法：方法1：修改pv参数后，把所有使用这个挂载点的pod掉离这个节点，然后再调回来。方法2：使用新的挂载点创建新的pv使用（一个nas文件系统可以有2个挂载点）； 示例方法1： 集群中有2个worker节点，部署一个deploy包含3个Pod；# kubectl get node | grep -v masterNAME STATUS ROLES AGE VERSIONcn-shenzhen.i-wz9c9m0m4oldr6mt89rd Ready <none> 55d v1.12.6-aliyun.1cn-shenzhen.i-wz9gvy73m4qyk03xzg1y Ready <none> 60d v1.12.6-aliyun.1# kubectl get podNAME READY STATUS RESTARTS AGEnas-static-784496fbb9-cqr97 1/1 Running 0 63mnas-static-784496fbb9-gljbq 1/1 Running 0 63mnas-static-784496fbb9-ngzkq 1/1 Running 0 63m编辑pv，添加- nolock,tcp,noresvport Options；编辑deploy，把这个deploy的pod都调度到节点：cn-shenzhen.i-wz9c9m0m4oldr6mt89rd上；> 在deploy中添加 nodeName: cn-shenzhen.i-wz9c9m0m4oldr6mt89rd> 如果您的集群节点较多，可以给一批节点添加label，然后通过nodeSelector把pod调度到这写节点；> 参考：https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-pods-nodes/注意：如果您用的时候statefulset的应用，需要把updateStrategy.type配置为RollingUpdate；然后再把pod调度到其他节点：cn-shenzhen.i-wz9gvy73m4qyk03xzg1y到节点cn-shenzhen.i-wz9gvy73m4qyk03xzg1y 上验证noresport，已经生效。2564f49129-ggu23.cn-shenzhen.nas.aliyuncs.com:/default on /var/lib/kubelet/pods/aa79e380-9bdb-11e9-a545-00163e0eff42/volumes/kubernetes.io~nfs/pv-nas type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,nolock,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.11,mountvers=3,mountport=4002,mountproto=tcp,local_lock=all,addr=192.168.0.11)最后，由于当前使用nas的pod是有nodeName标签的，可以编辑deploy，把nodeName(nodeSelector)去掉。2. 使用PV、PVC方式（Flexvolume驱动）首先确认当前的挂载是否配置了noresvport参数，参考NAS团队提供的方式； ...

或许很多人可能认为资源消耗并非安全问题，但实际上不合理的资源消耗会让黑客有可乘之机，来攻击K8s的组件。本文将介绍如何处理资源消耗或noisy neighbor问题，包括如何管理Pods中的资源以及管理项目和资源配额等。 本文是关于Kubernetes安全系列三篇文章中的最后一篇。在第一篇文章中，我们分享了如何确保企业的Kubernetes集群免受外部攻击；第二篇文章介绍了三种保护Kubernetes免受内部威胁的方法。在本文中，我们将介绍如何处理资源消耗或noisy neighbor问题。 对于那些设置了多租户Kubernetes集群的集群管理员而言，他们十分关注和担心的一个问题是，如何防止共同租户成为“noisy neighbor”，即一个垄断了CPU、内存、存储和其他资源的人。Noisy neighbor会对共享基础设施的其他用户资源的性能产生极坏的影响。 如此一来，跟踪Kubernetes容器和Pod的资源使用情况，对集群管理而言非常重要，因为它不仅可以保持容器编排系统处于最佳运行状态，降低运维成本，还可以加强Kubernetes的整体安全状况。 一些运维团队可能不认为资源消耗是一种重要的安全问题，至少没有保护Kubernetes免受内部和外部网络攻击重要。但这种观点是不正确的。因为厉害的黑客会利用功能不良的基础设施，来找到攻击Kubernetes组件的方法。 “安全不仅仅是‘不要闯进我的房子’，而是‘我怎么能让我的房子一直保持良好的运行状态’，”Rancher Labs的高级解决方案架构师Adrian Goins表示。 运维团队需要最大限度地利用Kubernetes Pods（一组具有共享存储和网络资源的一个或多个容器）所消耗的资源，以确保每个用户都能拥有最佳性能，并且能监控成本分配的使用情况。“使用等于成本，”Goins说，“因为Kubernetes资源都是运行在AWS、谷歌云、阿里云等等云提供商的底层计算基础设施上，一切资源消耗都以为着金钱成本。即使集群是在数据中心的裸机上运行，过多的使用也会花费硬件、电力和其他资源。” 默认情况下，配置容器时，对其可以使用的资源量没有任何限制。如果容器不能高效运行，部署容器的组织必将支付超额费用。值得庆幸的是，Kubernetes具有帮助运维团队管理和优化Kubernetes资源利用能力的功能。 管理Pods中的资源 当管理员定义Pod时，他们可以选择指定每个容器需要多少CPU和内存（RAM）。当容器指定了资源请求时，调度程序可以更好地决定将Pod放在哪个节点上。根据Kubernetes的文档，当容器指定了限制时，可以按指定的方式处理节点上的资源争用。 默认情况下，Kubernetes集群中的所有资源都是在默认的命名空间中创建的。命名空间是一种逻辑地将集群资源进行分组的方法，包括用于指定资源配额的选项。 管理员可以在命名空间上设置资源限制或配额，为在命名空间中运行的工作负载或应用程序分配一定量的CPU、RAM或存储——Kubernetes集群中的三个资源。“如果在命名空间中启动另一个资源会超出预设的配额，那么任何新资源都无法启动，”Goins指出。 “当你应用了资源配额时，意味着你强制在该命名空间中运行的所有内容为其自身设置资源限制。限制有两种类型：预留，和最大限制，”Goins解释说。例如，通过预留，管理员可以让Kubernetes集群为WordPress站点分配128 MB的RAM。对于部署的每个WordPress Pod，服务器本身将保证128 MB的RAM。因此，如果管理员将资源请求与1GB的资源配额相结合，则用户只能在超过其限制之前运行八个WordPress Pod。在那之后，他们将无法再使用RAM了。 资源限制的第二部分是最大限度。管理员可以预留128 MB的资源请求和最多256 MB的RAM。“如果Pod超过256 MB的RAM使用量，Kubernetes会杀死它并重新启动它，”Goins说。“如此以来，用户可以免受失控过程和noisy neighbor的影响。” 项目和资源配额 像Rancher这样的平台，旨在通过提供直观的界面和集中管理任务（如全局层的角色描述）来简化Kubernetes的管理。 正如前一篇关于内部威胁防护的文章所述，Rancher包含一个有助于减轻集群管理负担的“项目（Project）”资源，来超越命名空间。在Rancher中，Project允许管理员将多个命名空间作为单个实体进行管理。因此，Rancher可以将资源配额应用于Projects。 在标准Kubernetes部署中，资源配额只能应用于单独的命名空间。但是，管理员无法通过单次操作，同时将配额应用于命名空间。资源配额必须经过多次操作。 然而在Rancher中，管理员可以将资源配额应用于Project，然后将配额传播到每个命名空间。然后，Kubernetes会使用本机版本的资源配额，来强制执行管理员限制。如果管理员希望更改特定命名空间的配额，则可以覆盖以前的配额。 强化和优化Kubernetes 毋庸置疑，Kubernetes已成为容器编排的标准，这也促使大多数云和虚拟化供应商将其作为标准基础架构来提供。但是，对与Kubernetes环境相关的安全问题的普遍缺乏认识，可能会使各种组件暴露于来自网络集群内外的攻击中。 本系列文章的上两篇中提供了一些可行的步骤，来告诉大家如何通过使用Kubernetes功能和容器管理解决方案（如Rancher），来加强Kubernetes对外部和内部网络威胁的防范。企业应通过基于角色的访问控制（RBAC）和强身份验证从外部保护Kubernetes API访问。对于内部人员保护，由于Kubernetes集群是多用户，因此组织需要通过RBAC、逻辑隔离和NetworkPolicies来保护交叉通信。 为了防止其他租户垄断CPU、内存、存储和其他资源从而拖累整个集群的性能，Kubernetes提供资源限制和配额等功能，以帮助运维团队管理和优化Kubernetes资源利用功能。最后，除了可用的默认设置之外，业界还有一些非常有效的工具可以帮助用户完成Kubernetes集群的管理和保护。例如像Rancher这样的平台就是一种高度优化的容器管理解决方案，专为将多个集群部署到生产环境中的组织而构建，企业用户可以更轻松地管理和运行各地的Kubernetes。它可以保护Kubernetes集群免受外部黑客威胁、内部隐患甚至noisy neighbor。

近日，Rancher Labs宣布在Rancher 2.3 Preview2版本上支持Istio，简化了Istio的安装和配置，让部署和管理Istio的旅程变得简单而快速。 近日，业界领先的容器管理软件提供商Rancher Labs（以下简称Rancher）宣布在Rancher 2.3 Preview 2版本上支持Istio，让部署和管理Istio的旅程变得简单而快速。 为什么选择Istio？ Istio，以及整个Service Mesh技术，是近一两年来Kubernetes生态系统中最亮眼的明星之一。Istio增加了容错、金丝雀部署、A/B测试、监控、跟踪和可观察性、身份认证和授权，开发人员无需再测试或编写特定代码，即可实现上述功能。如此一来，开发人员可以只专注于他们的业务逻辑，将剩下的工作交给Kubernetes和Istio。 上面这些说法其实并不新鲜。早在大约10年前，PaaS供应商们就提出了类似的说法，甚至在一定程度上兑现了这一要求。但问题在于，他们的产品需要特定的语言和框架，并且在大部分情况下只能用于非常简单的应用程序。用户的工作负载也会和供应商独特的方案关联在一起。这就意味着如果您希望应用程序使用PaaS服务，您可能会被锁定相当长的一段时间。 但如今，对于容器和Kubernetes而言，这些限制、这些被锁定的风险都不复存在。只要您将您的应用程序容器化，Kubernetes就可以为您运行它。 Istio在Rancher 2.3 Preview 2中如何工作 大量Rancher用户喜欢Rancher平台的原因，就是Rancher让管理和操作Kubernetes及相关的工具和技术变得极其简单，且用户们不必担心会被特定的云供应商锁定。而如今对于Istio，我们采取了同样的方法，致力于带给用户同样的体验。 在Rancher 2.3 Preview中，我们为用户提供了一个简单而友好的用户界面，在UI中使用工具菜单，即可启动Istio。系统提供了合理的默认配置，用户也可以根据需要进行修改： 为了监控流量，Istio需要注入Envoy sidecar。在Rancher 2.3 Preview当中，用户可以为每个空间名称注入自动sidecar。一旦您勾选了这个选项，Rancher会将sidecar容器注入到每个工作负载当中： Rancher简化了Istio的安装和配置，内置了一个支持Kiali的仪表盘，用于流量和遥测的可视化，然后用Jaeger进行追踪，甚至还有自己的Prometheus和Grafana（与用于高级监控的实例不同）。 在启用自动sidecar注入的命名空间中部署工作负载后，您可以跳转到Istio菜单目录，观察微服务应用程序的流量： 点击Kiali、Jaeger、Prometheus或者Grafana，您将进入每个工具相应的用户界面，您可以在其中找到详细信息和选项： 正如前面所提到的，Istio的强大之处在于它能为您的服务带来诸如容错、断路、金丝雀部署等功能。要启用这些功能，您需要开发和应用适当的YAML文件。目前Windows工作负载还不支持Istio，因此不应在Windows集群中启用它。 结 语 Istio是当前Rancher及Kubernetes社区中最受关注的功能之一。但是，如何最达到Istio部署和管理的最佳实践，前路仍然漫长。在Rancher 2.3 Preview 2中，我们的目标是沿袭Rancher一如既往的理念，让部署和管理Istio的旅程变得简单而快速。 2019年6月20日，在Rancher于北京举办的千人容器技术盛典“2019企业容器创新大会”上，Rancher大中华区研发经理张浩在演讲中分享了Rancher 2.3 Preview的一系列新功能，包括正式支持Windows Kubernetes、镜像仓库、镜像扫描、服务网格、Google登陆、集群模版、集群安全扫描和集群自动扩缩容等等，并且demo了如何在Rancher中使用Istio进行金丝雀发布。您可在Rancher微信公众号后台回复“ECIC”获取大会完整PPT下载，更可文末点击“阅读原文”回看大会视频喔~ 有关发行说明和安装步骤，请访问GitHub： https://github.com/rancher/ra...

在Rancher 2.0和2.1中，Rancher配置集群的自动生成证书的有效期为1年，本文将为您详细介绍如何轮换证书，即使您的证书已经过期也可从文章中获得具体的操作指南。 Kubernetes集群通常使用ssl证书来加密通信，Rancher会自动为集群生成证书。在Rancher v2.0.14、v2.1.9之前的版本，Rancher配置集群的自动生成证书的有效期为1年，这意味着如果您在大约1年前使用这些版本创建了Rancher配置集群，那么您需要尽快开始轮换证书，否则证书过期后集群将进入错误状态。轮换证书是一次性操作，新生成的证书有效期为10年。 本文将为您详细介绍如何进行轮换证书的操作。即使您的证书现在已经过期，您也可以依照以下步骤进行证书的轮换。但请注意先不要升级rancher server，根据本文最后一节【证书已过期导致无法连接k8s】进行处理。 注意在重新启动组件时，轮换Kubernetes证书可能会导致您的群集暂时不可用。此外，对于生产环境，建议在维护窗口期间执行此操作。通过UI轮换证书(业务集群) 注：可用版本 Rancher v2.2.0 +在Rancher v2.2.0以及更高版本，可通过UI的证书轮换功能对集群证书进行更新，此功能适用于【自定义安装的集群】。 证书轮换之后，Kubernetes组件将自动重新启动，重启不影响应用Pod，重启时间需要3到5分钟。 证书轮换可用于下列服务: etcdkubeletkube-apiserverkube-proxykube-schedulerkube-controller-manager通过UI轮换证书，目前支持: 批量更新所有服务证书(CA证书不变)更新某个指定服务(CA证书不变)(重要)集群更新 如果Rancher版本是从v2.x.x升级到2.2.x，则需要先做一次集群更新操作。 1、进入【全局集群视图】； 2、选择【目标集群】右侧的【省略号菜单】，选择升级； 3、点击右侧【显示高级选项】，检查【Etcd快照轮换】功能是否开启，建议开启此功能； 4、在【授权集群访问地址】中，检查功能是否已开启，建议开始此功能，下边的域名可以不用填写； 5、最后点击【保存】，集群将自动进行更新 轮换证书 1、进入【全局集群视图】； 2、选择对应集群右侧的【省略号菜单】,选择更新证书有效期； 3、选择更新所有服务证书，并点击保存 4、集群将自动更新证书 5、因为证书改变，相应的token也会变化，在集群证书更新完成后，需要对连接API SERVER的Pod进行重建，以获取新的token。 cattle-system/cattle-cluster-agentcattle-system/cattle-node-agentcattle-system/kube-api-authingress-nginx/nginx-ingress-controllerkube-system/canalkube-system/kube-dnskube-system/kube-dns-autoscaler其他应用Pod通过UI API轮换证书(业务集群) 注：可用版本 Rancher v2.0.14+ v2.1.9+对于Rancher v2.0.14、v2.1.9以及更高版本，可通过API对集群证书进行更新。API证书轮换将会同时对所有组件证书进行更新，不支持指定组件更新证书。 1、在【全局】视图中，定位到需要更新证书的集群，然后点击右侧省略号菜单，然后点击【API查看】。 2、点击右上方的RotateCertificates 3、点击 Show Request 4、点击 Send Request 5、因为证书改变，相应的token也会变化，在集群证书更新完成后，需要对连接API SERVER的Pod进行重建，以获取新的token。 cattle-system/cattle-cluster-agentcattle-system/cattle-node-agentcattle-system/kube-api-authingress-nginx/nginx-ingress-controllerkube-system/canalkube-system/kube-dnskube-system/kube-dns-autoscaler其他应用PodRKE 证书轮换(local集群和业务集群通用) 注：可用版本 rke v0.2.0+如果以前是通过rke v0.2.0之前的版本创建的Kubernetes集群，在轮换证书前先执行rke up操作，请参考:https://www.cnrancher.com/doc... 通过RKE轮换证书，目前支持: 批量更新所有服务证书(CA证书不变)更新某个指定服务(CA证书不变)轮换CA和所有服务证书1、批量更新所有服务证书(CA证书不变) ...

前言如同Linux操作系统安装完成后，管理员需为应用创建不同的用户，那么，K8S/OKD/Openshift集群同样也需如此，而在OKD/Openshift集群里，我们可集成OpenLDAP目录系统，方法如下所示。 OpenLDAP安装本文使用helm安装openldap，首先将chars下载下来以方便查看： git clone https://github.com/helm/charts可选。镜像可先推送到私有仓库（PS：测试发现latest镜像有问题）： docker pull osixia/openldap:1.2.1docker tag docker.io/osixia/openldap:1.2.1 okd-lr.zyl.io:5001/osixia/openldap:1.2.1docker push okd-lr.zyl.io:5001/osixia/openldap:1.2.1镜像以root用户运行（gosudo切换），赋权： oc new-project auth-openshiftoc adm policy add-scc-to-user anyuid -z default对openldap char参数做定制： cd charts/stable/openldapcp values.yaml values_cs.yamlvi values_cs.yaml...env: # LDAP将创建dc=zyl,dc=io域，组织名称为Zyl Inc. LDAP_ORGANISATION: "Zyl Inc." LDAP_DOMAIN: "zyl.io"...# Ldap域管理员(cn=admin,dc=zyl,dc=io）及config管理员（cn=admin,cn=config）密码adminPassword: adminconfigPassword: config# 持久化存储，本例使用已创建好的glusterfs存储系统，其支持动态提供。persistence: enabled: true storageClass: "glusterfs-app" accessMode: ReadWriteOnce size: 8Gi执行helm命令安装： helm install --name openldap -f values_cs.yaml .Ldap启动后，创建了域dc=zyl,dc=io及hdb管理员账户cn=admin,dc=zyl,dc=io。如下所示，在此域下创建用户与组信息： % oc rsh deploy/openldap% cat > users.ldif <<EOFdn: ou=People,dc=zyl,dc=ioou: PeopleobjectClass: topobjectClass: organizationalUnitdn: ou=Group,dc=zyl,dc=ioou: GroupobjectClass: topobjectClass: organizationalUnitdn: uid=zyl,ou=People,dc=zyl,dc=iouid: zylcn: zylobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountuserPassword: changemeloginShell: /bin/bashuidNumber: 5000gidNumber: 5000homeDirectory: /home/zyldn: uid=admin,ou=People,dc=zyl,dc=iouid: admincn: adminobjectClass: accountobjectClass: posixAccountobjectClass: topobjectClass: shadowAccountuserPassword: changemeloginShell: /bin/bashuidNumber: 5001gidNumber: 5001homeDirectory: /home/admindn: cn=zyl,ou=Group,dc=zyl,dc=iocn: zylobjectClass: topobjectClass: posixGroupgidNumber: 5000memberUid: zyldn: cn=admin,ou=Group,dc=zyl,dc=iocn: adminobjectClass: topobjectClass: posixGroupgidNumber: 5001memberUid: admindn: cn=openshift_user,ou=Group,dc=zyl,dc=iocn: openshift_userobjectClass: topobjectClass: posixGroupgidNumber: 6000memberUid: zyldn: cn=openshift_admin,ou=Group,dc=zyl,dc=iocn: openshift_adminobjectClass: topobjectClass: posixGroupgidNumber: 6001memberUid: adminEOF% ldapadd -x -w $LDAP_ADMIN_PASSWORD -D "cn=admin,dc=zyl,dc=io" -H ldapi:/// -f users.ldif% ldapsearch -x -D "cn=admin,dc=zyl,dc=io" -w $LDAP_ADMIN_PASSWORD \ -b dc=zyl,dc=io# 可使用config管理员检查ldap config配置% ldapsearch -x -D "cn=admin,cn=config" -w $LDAP_CONFIG_PASSWORD \ -b cn=config "olcDatabase=config"配置Master使用Ldap认证OKD初始安装时若未配置openshift_master_identity_providers，则OKD默认使用如下认证，此认证方式允许任何用户登录集群。 ...

本地卷描述如Hadoop、ES等系统，其DataNode需大量存储，且其本身提供了冗余功能，那么我们就没必要让其从存储系统中分配卷，而是像裸机部署一样让其使用本地节点上的存储，local volumes出现之前，我们可使用HostPath挂载卷到容器中，但此方案有很多局限性： The prior mechanism of accessing local storage through hostPath volumes had many challenges. hostPath volumes were difficult to use in production at scale: operators needed to care for local disk management, topology, and scheduling of individual pods when using hostPath volumes, and could not use many Kubernetes features (like StatefulSets). Existing Helm charts that used remote volumes could not be easily ported to use hostPath volumes. The Local Persistent Volumes feature aims to address hostPath volumes’ portability, disk accounting, and scheduling challenges.注意：本地卷仅适用于少量应用，如同HostPath一样Pod被绑定到特定的主机上，若主机异常，则Pod没法调度到其他节点，其适用场景： ...

Docker Hub中有很多好用的Docker镜像，但镜像到底如何工作、能做什么、怎么做值得我们研究，如下所示为MySQL官方镜像的docker-entrypoint.sh脚本分析： #!/bin/bashset -eo pipefailshopt -s nullglob################################################################# 若启动命令时附加了参数，则在参数前添加mysqld，如$0 -f test，则经过此代码处理后，# $@参数变mysqld -f test。其中${1:0:1}从$1参数第0个位置取1字符，如$1为-f，则# 取'-'字符，若条件为真，通过set命令重置$@参数，添加mysqld前缀，即经过处理后$1变# 为mysqld。################################################################# if command starts with an option, prepend mysqldif [ "${1:0:1}" = '-' ]; then set -- mysqld "$@"fi# 解析参数，是否是获取帮助信息参数，并设置wantHelp值###################################################### skip setup if they want an option that stops mysqldwantHelp=for arg; do case "$arg" in -'?'|--help|--print-defaults|-V|--version) wantHelp=1 break ;; esacdone############################## 从文件中读取变量值############################## usage: file_env VAR [DEFAULT]# ie: file_env 'XYZ_DB_PASSWORD' 'example'# (will allow for "$XYZ_DB_PASSWORD_FILE" to fill in the value of# "$XYZ_DB_PASSWORD" from a file, especially for Docker's secrets feature)file_env() { local var="$1" local fileVar="${var}_FILE" local def="${2:-}" if [ "${!var:-}" ] && [ "${!fileVar:-}" ]; then echo >&2 "error: both $var and $fileVar are set (but are exclusive)" exit 1 fi local val="$def" if [ "${!var:-}" ]; then val="${!var}" elif [ "${!fileVar:-}" ]; then val="$(< "${!fileVar}")" fi export "$var"="$val" unset "$fileVar"}############################################################################ 运行mysqld --help --verbose --help 2>&1 >/dev/null命令，# 此命令会检查配置文件，若配置文件没问题，则成功，不成功则输出错误信息，及if中添# 加！取不成功。###########################################################################_check_config() { toRun=( "$@" --verbose --help ) if ! errors="$("${toRun[@]}" 2>&1 >/dev/null)"; then cat >&2 <<-EOM ERROR: mysqld failed while attempting to check config command was: "${toRun[*]}" $errors EOM exit 1 fi}# 1. $1参数为mysqld 以及 wanthelp 参数为空 以及root用户，执行此代码；# 2. _check_config检查配置文件是否正确# 3. 获取DATADIR目录，执行mysqld --verbose --help --log-bin-index=/tmp/tmp.4SyApJWeIo| \# awk '$1 == "'"datadir"'" { print $2; exit }'# 4. 创建并修改目录权限# 5. 执行exec gosu mysql docker-entrypoint.sh "$@"，即重新以mysql用户再次调用脚# 本# allow the container to be started with `--user`if [ "$1" = 'mysqld' -a -z "$wantHelp" -a "$(id -u)" = '0' ]; then _check_config "$@" DATADIR="$(_get_config 'datadir' "$@")" mkdir -p "$DATADIR" chown -R mysql:mysql "$DATADIR" exec gosu mysql "$BASH_SOURCE" "$@"fi# 1. $1参数为mysqld 以及 wanthelp 参数为空，执行此代码，及exec gosu会执行此代码；if [ "$1" = 'mysqld' -a -z "$wantHelp" ]; then# 2. 仍然检查配置文件以及获取datadir目录 # still need to check config, container may have started with --user _check_config "$@" # Get config DATADIR="$(_get_config 'datadir' "$@")"# 3. 若mysql数据库未创建，则执行本段逻辑 if [ ! -d "$DATADIR/mysql" ]; then# 4. 检查是否设置变量，如root密码、允许root密码为空亦或者随机密码 file_env 'MYSQL_ROOT_PASSWORD' if [ -z "$MYSQL_ROOT_PASSWORD" -a -z "$MYSQL_ALLOW_EMPTY_PASSWORD" -a -z "$MYSQL_RANDOM_ROOT_PASSWORD" ]; then echo >&2 'error: database is uninitialized and password option is not specified ' echo >&2 ' You need to specify one of MYSQL_ROOT_PASSWORD, MYSQL_ALLOW_EMPTY_PASSWORD and MYSQL_RANDOM_ROOT_PASSWORD' exit 1 fi# 5. 创建目录 mkdir -p "$DATADIR"# 6. 执行mysqld命令初始化数据库 echo 'Initializing database' "$@" --initialize-insecure echo 'Database initialized'# 7. command -v mysql_ssl_rsa_setup检查命令是否可执行，以及是否存在# server-key.pem文件，若不存在，则生成证书 if command -v mysql_ssl_rsa_setup > /dev/null && [ ! -e "$DATADIR/server-key.pem" ]; then # https://github.com/mysql/mysql-server/blob/23032807537d8dd8ee4ec1c4d40f0633cd4e12f9/packaging/deb-in/extra/mysql-systemd-start#L81-L84 echo 'Initializing certificates' mysql_ssl_rsa_setup --datadir="$DATADIR" echo 'Certificates initialized' fi# 8. 获取socket值并启动mysql SOCKET="$(_get_config 'socket' "$@")" "$@" --skip-networking --socket="${SOCKET}" & pid="$!"# 9. 设置mysql变量（列表形式），而后可以${mysql[@]}调用 mysql=( mysql --protocol=socket -uroot -hlocalhost --socket="${SOCKET}" )# 10. 运行30次，验证mysql是否已经启动完毕 for i in {30..0}; do if echo 'SELECT 1' | "${mysql[@]}" &> /dev/null; then break fi echo 'MySQL init process in progress...' sleep 1 done# 11. 若i为0值，则表明mysql启动失败 if [ "$i" = 0 ]; then echo >&2 'MySQL init process failed.' exit 1 fi# 11. 解决时区bug if [ -z "$MYSQL_INITDB_SKIP_TZINFO" ]; then # sed is for https://bugs.mysql.com/bug.php?id=20545 mysql_tzinfo_to_sql /usr/share/zoneinfo | \ sed 's/Local time zone must be set--see zic manual page/FCTY/' | "${mysql[@]}" mysql fi# 12. 生成root随机密码 if [ ! -z "$MYSQL_RANDOM_ROOT_PASSWORD" ]; then export MYSQL_ROOT_PASSWORD="$(pwgen -1 32)" echo "GENERATED ROOT PASSWORD: $MYSQL_ROOT_PASSWORD" fi# 13. 若MYSQL_ROOT_HOST不为空亦或者不为localhost，则创建root用户 rootCreate= # default root to listen for connections from anywhere file_env 'MYSQL_ROOT_HOST' '%' if [ ! -z "$MYSQL_ROOT_HOST" -a "$MYSQL_ROOT_HOST" != 'localhost' ]; then # no, we don't care if read finds a terminating character in this heredoc # https://unix.stackexchange.com/questions/265149/why-is-set-o-errexit-breaking-this-read-heredoc-expression/265151#265151 read -r -d '' rootCreate <<-EOSQL || true CREATE USER 'root'@'${MYSQL_ROOT_HOST}' IDENTIFIED BY '${MYSQL_ROOT_PASSWORD}' ; GRANT ALL ON *.* TO 'root'@'${MYSQL_ROOT_HOST}' WITH GRANT OPTION ; EOSQL fi# 14. 为'root'@'localhost'重置root密码# 使用$rootCreate创建root "${mysql[@]}" <<-EOSQL -- What's done in this file shouldn't be replicated -- or products like mysql-fabric won't work SET @@SESSION.SQL_LOG_BIN=0; SET PASSWORD FOR 'root'@'localhost'=PASSWORD('${MYSQL_ROOT_PASSWORD}') ; GRANT ALL ON *.* TO 'root'@'localhost' WITH GRANT OPTION ; ${rootCreate} DROP DATABASE IF EXISTS test ; FLUSH PRIVILEGES ; EOSQL# 15. 已设置root密码，故mysql需加上root密码 if [ ! -z "$MYSQL_ROOT_PASSWORD" ]; then mysql+=( -p"${MYSQL_ROOT_PASSWORD}" ) fi# 16. 若配置了MYSQL_DATABASE变量，则创建 file_env 'MYSQL_DATABASE' if [ "$MYSQL_DATABASE" ]; then echo "CREATE DATABASE IF NOT EXISTS \`$MYSQL_DATABASE\` ;" | "${mysql[@]}" mysql+=( "$MYSQL_DATABASE" ) fi# 17. 在数据库内创建用户 file_env 'MYSQL_USER' file_env 'MYSQL_PASSWORD' if [ "$MYSQL_USER" -a "$MYSQL_PASSWORD" ]; then echo "CREATE USER '$MYSQL_USER'@'%' IDENTIFIED BY '$MYSQL_PASSWORD' ;" | "${mysql[@]}" if [ "$MYSQL_DATABASE" ]; then echo "GRANT ALL ON \`$MYSQL_DATABASE\`.* TO '$MYSQL_USER'@'%' ;" | "${mysql[@]}" fi echo 'FLUSH PRIVILEGES ;' | "${mysql[@]}" fi# 18. 执行/docker-entrypoint-initdb.d目录下面的脚本，包含shell、sql echo for f in /docker-entrypoint-initdb.d/*; do case "$f" in *.sh) echo "$0: running $f"; . "$f" ;; *.sql) echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;; *.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;; *) echo "$0: ignoring $f" ;; esac echo done# 19. 设置root密码是否过期 if [ ! -z "$MYSQL_ONETIME_PASSWORD" ]; then "${mysql[@]}" <<-EOSQL ALTER USER 'root'@'%' PASSWORD EXPIRE; EOSQL fi# 20. kill -s TERM "$pid" 杀掉mysql进程，执行成功则返回0，而！kill取反，即kill成# 功后才执行后面的!wait命令 if ! kill -s TERM "$pid" || ! wait "$pid"; then echo >&2 'MySQL init process failed.' exit 1 fi# 21. 初始化成功后，再次启动 echo echo 'MySQL init process done. Ready for start up.' echo fifi# 22. 正式启动数据库exec "$@"

参考： Make a Kubernetes Operator in 15 minutes with Helm；Deploy Monocular on OpenShift；Helm中文指南；使用Helm管理kubernetes应用；https://helm.sh/docs/using_he...；参考官方文档https://docs.helm.sh/using_he...，Openshift环境安装Helm Tiller时其指向Blog：https://blog.openshift.com/ge...： Helm works straightforward on OpenShift Online, OpenShift Dedicated, OpenShift Container Platform (version >= 3.6) or OpenShift Origin (version >= 3.6). To learn more read this blog post.安装helm客户端，版本参考https://github.com/helm/helm/...。如下所示，在m01主机安装当前最新文档版v2.12.3： cd /tmpcurl -s https://storage.googleapis.com/kubernetes-helm/helm-v2.12.3-linux-amd64.tar.gz \ | tar xzsudo mv linux-amd64/helm /usr/local/binsudo chmod a+x /usr/local/bin/helm可选。默认stable仓库为https://kubernetes-charts.sto...，但此网被墙导致无法连接，可删掉并添加其他第三方仓库，如： helm repo remove stable# 将阿里云仓库设置为stable仓库：helm init --client-only --stable-repo-url \ https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts # 或为仓库设置不同的名称：helm repo add ali-stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/chartshelm repo add ali-incubator \ https://aliacs-app-catalog.oss-cn-hangzhou.aliyuncs.com/charts-incubatorhelm repo add bitnami https://charts.bitnami.com/bitnamihelm repo list安装tiller： ...

前言 在K8S集群内部，应用常使用Service互访，那么，了解Service技术优缺点将有利于应用规划与部署，鉴于此，本文将通过简单案例以探索Cluster-Ip类型Service服务的利弊。 为便于讲解，我们先创建如下应用及Service服务： # kubectl run --image=nginx nginx-web-1 --image-pull-policy='IfNotPresent'# kubectl expose deployment nginx-web-1 --port=80 --target-port=80Service探索 作者的K8S环境是1.9版本，其Service内部服务由Kube-Proxy1提供，且默认用iptables技术实现，故本文探索K8S集群Service技术，即研究iptables在K8S上的技术实现。 Service Route（服务路由） 如下可知，通过nginx-web-1服务可实际访问到后端pod： # nginx pod ip地址：# kubectl describe pod nginx-web-1-fb8d45f5f-dcbtt | grep "IP"IP: 10.129.1.22# Service服务，通过172.30.132.253:80则实际访问到10.129.1.22:80# kubectl describe svc nginx-web-1 ...Type: ClusterIPIP: 172.30.132.253Port: <unset> 80/TCPTargetPort: 80/TCPEndpoints: 10.129.1.22:80Session Affinity: None...# 重置nginx web页面：# kubectl exec -it nginx-web-1-fb8d45f5f-dcbtt -- \ sh -c "echo hello>/usr/share/nginx/html/index.html"# curl 10.129.1.22hello# curl 172.30.132.253hello Service服务分配的CLUSTER-IP以及监听的端口均虚拟的，即在K8S集群节点上执行ip a与netstat -an命令均无法找到，其实际上，IP与Port是由iptables配置在每K8S节点上的。在节点上执行如下命令可找到此Service相关的iptables配置，简析如下： 当通过Service服务IP：172.30.132.253:80访问时，匹配第3条规则链（KUBE-SERVICES）后，跳转到第4条子链（KUBE-SVC-...）上；第4条子链做简单注释后，继而跳转到第1、2规则链（KUBE-SEP-...）上；当源Pod通过Service访问自身时，匹配第1条规则，继而跳转到KUBE-MARK-MASQ链中；匹配到第2条规则，此时通过DNAT被重定向到后端Pod：108.29.1.22:80。# iptables-save | grep nginx-web-1-A KUBE-SEP-UWNFTKZFYWNNNTK7 -s 10.129.1.22/32 -m comment --comment "demo/nginx-web-1:" \ -j KUBE-MARK-MASQ-A KUBE-SEP-UWNFTKZFYWNNNTK7 -p tcp -m comment --comment "demo/nginx-web-1:" \ -m tcp -j DNAT --to-destination 10.129.1.22:80-A KUBE-SERVICES -d 172.30.132.253/32 -p tcp -m comment \ --comment "demo/nginx-web-1: cluster IP" -m tcp --dport 80 -j KUBE-SVC-SNP24T7IBBNZDJ76-A KUBE-SVC-SNP24T7IBBNZDJ76 -m comment --comment "demo/nginx-web-1:" \ -j KUBE-SEP-UWNFTKZFYWNNNTK7 详细分析iptables规则，执行iptables-save命令可发现nat的PREROUTING与OUTPUT链中均有KUBE-SERVICES规则链，且处于第一顺位。 ...

2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近千名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。 来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人出席了本届ECIC，现场带来关于企业容器项目实践经验的精彩分享，为参会的容器技术爱好者带来企业容器化的经验分享。 飞贷金融科技副总裁陈定玮 大会现场，飞贷金融科技作为金融行业数据库容器化的典型案例，为现场的容器爱好者带来了题为《金融领域数据库生产容器化及Istio应用》的实践经验分享。 对于飞贷金融科技而言，生产容器化及数据库应用的难点在于，如何针对金融领域生产容器化及数据库容器应用进行实践创新，如何结合研发及业务场景落地，提升资源利用效率、提升产品研发、运维管理效率。 飞贷金融科技副总裁陈定玮表示：“金融行业数据具有相较于其他行业更为严格的安全高标准，在安全合规的情况下用飞贷自研中间件，解决金融领域DB应用场景难题，带来10x的DB交付效率，极致的弹性扩容能力。” 演讲实录 飞贷金融科技成立于2010年，是移动信贷整体技术服务商。我们以科技创新作为企业发展的动力，在科技创新的道路上不断前行。 2011年到2015年，飞贷做的是传统的小微金融业务。2015年，我们决定进行线上互联网化转型。到2017年，我们整个公司进行了战略升级，为金融行业客户提供互联网服务。迄今为止，飞贷为人保、北京银行、华润信托、通联支付等多家金融行业企业提供了全链路的科技服务。 2018年，我们登上了美国《时代周刊》，被《时代周刊》称为“全球金融科技最佳实践”。同年，我们还拿到了世界银行和G20共同推出的首届全球小微金融奖最高荣誉——“年度产品创新”铂金奖。 接下来，我会和大家详细介绍一下，飞贷作为一家互联网金融科技企业，是怎样和容器化相结合，又是怎么在业务上应用容器化的。 飞贷应用容器化与前面分享的企业一致，同样也是基于整个企业的容器化应用。值得一提的是，飞贷做的是金融领域，所以我们对安全、对容错、对高恢复的部分相较于其他行业的企业而言更加在意。我们关注的不仅仅是应用，更多的会关注到如何迅速地进行灾难的恢复。 我们利用容器进行了整体的架构部署，从大家比较熟悉的DevOps，到我稍后会重点介绍的DB Mesh的部分。我们划分了几大平台，包括容器化平台、产品研发平台和数据平台。下面的是应用安全、数据安全、网络安全、容器安全、运维安全等部分。容器对我们而言帮助非常大，现在我们的RD都是基于容器Kubernetes做应用开发。在这一部分，飞贷在金融领域已经达到了领先的水平。 下图是飞贷的容器发展路线图。我们从2015年开始研究容器，2016年开始投产在RD环境上。在当时我们还没能完全选定Kubernetes还是另外一个容器技术，所以暂时停留在RD阶段。2017年，Kubernetes技术越来越成熟、越来越稳定，我们就把整体的方向往Kubernetes方向进行迁移。到了今年，我们的生产环境已经可以大量运用容器技术进行多个方向上的应用了。 刚才Rancher的CEO梁胜博士提到，现在Rancher已经可以做到多K8S集群管理和部署，多数据中心。这是和我们的业务发展比较贴合的。我们提供基于飞贷的金融云服务，同时我们有多租户集群管理的业务需求。目前，我们已经可以针对K8S多集群进行应用服务、中心服务、数据库服务等多个方向的多集群管理，同样，我们也可以做到多租户网络隔离。 从客户的角度来说，在客户和我们合作之前或者是过程当中，他们先前可能并不了解小贷的业务运营是这样的，所以银行会把他们的整体服务放在我们公司，飞贷就变成了一家金融云厂商。而飞贷的特殊之处就在于，我们专注于和我们业务发展相关的内容，我们为客户提供的不是一个整体的平台，而是应用。 刚才提到的所有内容都是和容器息息相关的，容器的特性包括安全审计、动态存储、高可用灰度发布等等，我们把容器的特性应用到了飞贷生产环境上，并且发挥到了极致。 下图是飞贷容器化的平台组件。无论是我们的RD还是外面的人员，飞贷会为他们提供应用商店，他们要做什么事情，就在我们的管理平台点击一下，我们会自动生产一个容器的应用帮他们进行处理。我们镜像仓库的部分是在一起的。 除了这几个部分，我们还有Prometheus和Jenkins，这些体系和我们研发的相关度比较高，现在飞贷能实现自动集成、自动打包、自动发布和自动部署，这是我们研究了两年多的平台组件成果。 飞贷为什么要让DB容器化？因为微服务部分的应用层已经发展得比较好了，但是对于DB而言还有很多的问题。假如DB宕机了，我想要迅速恢复这个DB，让业务生产能够正常运行，我们需要花费多长的时间呢？如果DB非常大，这个启动时间是非常久的。这就是为什么银行或者是大型金融机构没有小型机，不敢用开源的MySQL或者是MangoDB等资料库，因为他们要保证安全和持续运作，这是一个比较大的挑战。 这就是我今天要重点讲述的几个问题，为什么要MySQL容器化？MySQL容器化安全稳定吗？容器化MySQL的具体实现是样的？ 我们刚才介绍了飞贷要做多集群管理的容器，里面存在一些限制以及要求。第一，会涉及非常复杂的网络结构；第二，故障要频繁地切换，我们认为这在金融行业是非常重要的一个部分，因为一旦发生故障，金融行业的业务基本上就会停摆了；第三，要控制容量大小；第四则是要依赖网络存储。 我们之所以要做这个部分，有三个方面的原因。第一，我们需要实现标准化快速部署，因为应用快速部署完之后，如果DB部署很慢的话，对于我们而言，整体效率还是一样地低，这是站在整体效率的部分而言的；第二就是微服务场景，我们现在的系统已经是全部为服务化进行终端的调整，在这种场景下，如果数据场景不能微服务化，那我上层所做的内容毫无意义，我们不希望数据库成为业务弹性伸缩以及管理的短板；第三就是MySQL服务化、自动化、网络化和智能化的需求。 我们进行MySQL容器化的效果很明显。第一，我们可以实现高效弹性伸缩、扩容、备份、导入、导出、恢复、快照、迁移；第二，我们可以实现整体数据库的性能监控和审计；第三，分布式存储、资源、数据多副本可以实现实时同步。我们在大数据应用的部分可能和一般的公司也有所区别，我们生产环境的一些数据和大数据实时数据是拆分开的，但我们做到了实时同步；第四就是计算资源分布式，多节点，技术设施高可用；第五是拥有故障自愈的功能。我的MySQL如果宕机，我们可以迅速恢复。 下图是我们MySQL DB的架构，底下的应用服务对应的是中间件，我们所有的中间件对应每一个单独的库。我们为了实现DB容器，把库做到了非常大的空间压缩，并且把库进行了容量限制，这样才有可能在库故障的时候，可以迅速的启动它。这部分考验了我们整体的业务运作部分，数据分表分库的能力、读写分离的能力。而这部分都是通过我们自行研发的中间件完成的。如果没有我们自行研发的中间件，DB Mesh这部分内容是我们也无法完成的。 以上基本就是飞贷DB的网络发散图，架构特征包括几个部分，一是高并发、低延迟，每秒10000事务处理，延迟小于100毫秒；二是支持IDC多活；三是支持数据路由；四是可以自动化或者人格化决策切换；五是数据多副本。 截至目前，飞贷的DB量级是PB级别的，我们大概是十几个PB这种应用数量，可对外同步实施，故障容器数目大于二分之一可以自动回复，这就是为什么我们要做DB Mesh的原因。 另一部分是关于我们容器化整合Istio的，右边是我们生产应用的图形界面，可以看到注册进去之后，我们就可以进行自动追踪，了解库的健康程度。但是里面还有一些小问题，当DB断掉再恢复之后，这个服务就不见了，需要再次手工注入。关于这个问题，我们研究了Istio的很多文档，但还没有克服这一问题。所以在DB这一部分，我们只做到在生产的时候，一开始可以注入，但是当它挂掉之后，我们还是需要手工处理，暂时没有办法自动恢复。 而在应用和管理服务的部分，我们已经做到了完全自动化，整合Istio实现微服务Service Mesh，实现了微服务访问、安全加固、控制、观察。服务追踪、限速、熔断、调度、负载等部分。 以上是飞贷整体服务的应用部署，从应用服务到中间件，这是我们整体部署的发布图，所以现在我们的RD人员基本上只负责开发，开发之后，所有一切都通过我们的平台去进行集成、发布和管理，上了生产环境之后，也会由我们的运维来处理，不会由RD来处理。在这一点上，我们做的还比较符合银行的要求。 最后，我想介绍一下飞贷容器化带来的成果： 第一是提升飞贷整体生产力。飞贷80%的基础运维都是自动化的；其次，交付能力也有所提升，一小时我们可以交付上百套的服务应用，目前来说有上千台容器在我们整个生产环境上面运作，如果我们没有进行微服务容器化的话，微服务架构部署时间会非常长；最后一个是我们具备生产环境上数百个MySQL的实例，这也是我们的一个容器化成果； 第二就是研发和扩展，可以按照容器的pod、物理主机节点、机柜及数据中心级别做扩展，这块我们也结合了很多CMDB的内容，但在这里就不详表了； 第三是IT成本的投入，这也是我们企业比较关注的一个内容，我们之前的私有云是用CloudStack作为平台去搭建的，现在我们全部换成了容器。这大约节约了我们40%的资源，节省了60%的人力投入。以前我们要部署一个应用还需要提供虚拟主机在RD上面部署，现在容器一键部署就可以完成了。另外项目研发投入时间也节省了40%，因为部署应用之类的内容现在已经不需要RD人员来处理了，都是由我们平台自动化处理的； 第四是安全、敏捷、高效，这部分业余数据的全量备份我们也是分钟级的，我们的库缩得足够小，所以我们可以在几分钟内迅速备份；第二在容灾故障的时候，我们的业务运用一键恢复也是分钟级的，数据快照是秒级的，资源利用率提升10倍，数据库交付能力提升近百倍，我们整个应用有上百个MySQL节点，如果一个个部署非常慢，我们现在已经把镜像做起来了，所以部署是非常迅速的； 最后一点是运维变得非常简单，自动化、极致的、弹性容器的调度，灰度发布、预发布、蓝绿部署、持续交付。

2019年6月24日，KubeCon+CloudNativeCon+Open Source Summit再次登陆中国，在上海世博中心拉开了帷幕。来自亚洲各国的逾3500名研发专家、架构师和技术领袖共同参与了本次盛会，现场分享、普及、探讨和推动Kubernetes生态及云原生技术的发展。 业界领先的容器管理软件提供商Rancher Labs（以下简称Rancher）作为本届活动的铂金赞助商深度参与了此次盛会。大会期间，Rancher展台持续爆满，挤满了前来交流的Kubernetes爱好者及云原生技术领军者。 那么，在本次KubeCon+CloudNativeCon+Open Source Summit，Rancher为现场的Kubernetes爱好者、云原生技术领军者带来了哪些惊喜呢？让我们一起来快速回顾一下吧！ 关注边缘技术创新，拓宽K8S发展新边界 为了更好地向现场的Kubernetes爱好者及云原生技术领军者展示如何通过Rancher推动K8S在云端、数据中心和边缘落地，Rancher大中华区技术总监江鹏在Demo Theater（展示剧场）进行了题为《如何在云端、数据中心和边缘统一管理K8S集群》的Demo演示，内容包括： 如何安装k3s集群：一个仅40MB的轻量级开源Kubernetes发行版在数据中心和边缘管理Kubernetes集群多集群应用程序部署Global DNS集成2019年，Rancher一连发布三个重磅的轻量级新品——史上最轻量级Kubernetes发行版k3s、业内首个Kubernetes操作系统k3OS以及Kubernetes极简MicroPaaS平台Rio，获得了业界的高度关注和一致好评。这些项目均专注于轻量级、简单且灵活的Kubernetes项目，为Kubernetes提供更为广泛的使用场景，真正做到Kubernetes Everywhere。 “多集群Kubernetes管理已经逐渐成为被大众所接受的一个概念，这是Rancher在Kubernetes层面上的创新和尝试。接下来，我们希望更多地去关注边缘节点的技术创新，真正地把K8S带到所有的地方，为边缘计算创造价值。”Rancher联合创始人及CEO梁胜表示：“k3s是Rancher目前比较成功的一个开源项目，但我们非常清楚，在边缘计算这个方向，我们还有很多的工作要做。” 推动企业级K8S落地，深度赋能行业生态 容器技术的发展存在周期性，Kubernetes正从初创期走向成熟期，变成一个被云计算服务提供商及数据中心广泛应用的商品。除了k3s之外，在本次活动，Rancher还为现场的Kubernetes爱好者及云原生技术领军者带来企业级多集群K8S管理平台Rancher的演示。 2019年3月，Rancher发布了Rancher 2.2 GA版本，Rancher 2.2 GA版本是Rancher Labs迄今为止最重要的产品版本，在先前发布过的2.2技术预览版本中，已经释出了诸如支持多集群应用程序、集成的Prometheus高级监控等功能。Rancher 2.2 GA的主要新功能亮点包括： Rancher Global DNS集群的灾备与恢复多集群、多租户的进阶版监控功能单一应用跨多Kubernetes集群的部署与管理多租户应用程序目录“随着Kubernetes的采用呈指数级增长，企业IT人员一直在寻求一种简单、可靠和可重复的方式来配置、管理和支持企业级Kubernetes集群，且越来越多企业的Kubernetes集群是跨本地环境与云环境混合部署的。”梁胜表示：“Rancher 2.2中创造性的新功能，将极大简化IT运维人员对企业级Kubernetes的配置与管理工作，同时让企业IT开发人员对其应用程序拥有更强把控。” 持续创新，一切开源 一直以来，Rancher都是Kubernetes和容器领域的领导者玩家，在Kubernetes和容器生态领域具备相当高的认可度和强大的影响力。Rancher是CNCF的核心成员，也是CNCF的元老级会员。Rancher Labs联合创始人Shannon Williams是CNCF管理委员会的委员。除此之外，Rancher还是全球首批获得CNCF Kubernetes一致性认证的平台。 本届KubeCon+CloudNativeCon+Open Source Summit已圆满落下帷幕，但在未来，Rancher将秉承“只有在企业生产环境中落地的技术和产品才是好技术和好产品”的产品理念，持续为用户提供领先的容器技术和产品，让企业在生产环境中更简单而稳妥地落地。

作者注：联系方式 leontian1024@gmail.com || github.com/XinyaoTian新人入行，非常期待能与各位大牛们讨论，感谢各位的阅读，希望对您有所帮助。一切都要从云计算和容器技术的出现说起...相信每一位老道的开发者和软件工程师们都会有过，曾经( 也许现在仍然 )被庞大且复杂的软件系统所支配的恐惧。随着软件版本的迭代和开发团队人员规模的扩大，曾经那个小巧别致、设计精良的软件或应用一去不返，如今已经变得遍地狼藉，惨不忍睹——混乱的接口、不规范的调用、像贴狗皮膏药一般贴上去的新功能组件……曾经那个赏心悦目的应用，如今看了就反胃。这一切都预示着一个问题：开发软件的方式需要改变。 纵使有那么多种软件开发模式，但如果不能从底层技术上实现对设计的约束，问题将会随着时间的推移，最终暴露出来。譬如“高内聚，低耦合”的设计理念，如果不能从底层就实现模块间的隔离，而依靠开发时的技巧和经验，那么最终这个软件依旧会变得一团糟( 因为团队会有新人的加入、即使经验老道的开发者也会有头脑发昏的时候…… )。因此，“不这么写就无法运行”这样的硬性要求就很有必要了。 云计算和容器技术的出现，非常及时地帮助我们解决了这一难题。云计算的高弹性和按需分配、容器技术的快速启停和隔离，都很好的帮助了我们减少运维开销，且对于不同模块实现操作系统级别的隔离。在这两种关键技术出现前后，软件架构的差别如下图所示： ( 上图: 单体应用 与 微服务应用 )以 Web 应用为例，按照之前的开发方式，我们往往会选用一个功能齐全但相当复杂的开发框架( 比如JAVA开发常用的 SpringBoot )，然后在这个框架的基础上，根据开发经验和框架的功能将整个应用分层( 比如最常用的表示层、业务逻辑层和数据资源层的分层方法 )，之后根据需求分析得出的各个功能，通过不同目录、文件和函数的方式分别开发，最终一个完整的 Web 应用被开发出来。其过程如下图所示。 ( 上图: 基于框架的软件开发架构网格 )通过使用框架，我们把软件在层次上分为三层，而之后的每个功能，就相当于纵向地添加一个新列。如果以这种方式看待一个应用，那么我们就可以将任何基于这种开发方法的应用看作一个3行n列的表格或矩阵了。 然而，这种非常普及的开发方式仍然有一些问题...虽然这种开发方式已经非常普及，非常成熟，但其仍有许多有待改进的地方。比如： 依赖和库过于庞杂。理想情况下，我们希望针对每一个模块，单独管理其相应的依赖和库，而不是以整个应用作为单位来管理。 无法改变层次结构。某种层次结构对于某些业务需求来说很棒，但对于另外一些也许就显得不那么合适了。使用这种方式开发，几乎所有功能都要遵从这种既定的层次开发( 比如写 UI、写业务逻辑、写数据库层 )。而对于目前日渐快速的迭代和敏捷的开发思想，我们需要一种更加灵活轻便的方式进行开发。 无法实现跨语言开发。我们知道，几乎每种编程语言都有自己最擅长的领域。也许某些功能选用其他编程语言的开发效率更高，运行效果更好。然而，使用这种方式我们往往只能使用选定的框架所支持的语言。 模块的独立性不足。单纯通过函数和文件来进行隔离，隔离性仍然不够。一个疏忽或是加急上线就会让之前良好的高内聚低耦合的良好软件结构灰飞烟灭。因此，我们需要更加底层的机制来硬性约束我们实现“高内聚低耦合”，把“应该这么做”变为“必须这么做”。 而伴随着云计算和容器技术的发展，微服务的出现，恰巧将这些问题迎刃而解。 ( 上图: 容器技术的基本层次结构 )先来说说容器技术的代表 —— DockerDocker 可以看作是轻量级的虚拟机——它可以通过“容器镜像”快速启动和停止预先配置好的相应运行环境。每一个容器都可以被看作一个独立的操作系统，相互隔离，互不干扰。因此，借助docker 我们就可以针对一个应用中不同的功能，为其独立定制运行环境，独立装载依赖和工具库，独立运行独立停止，独立升级，每个功能可以使用其最适合的编程语言进行开发，也将整个应用拘泥于一种框架了。利用 docker 将每个模块在操作系统层面进行隔离，对于每个模块都可以独立管理其生命周期了，这就是“微服务”中“微”字的具体含义。 微服务开发的重点基于这种开发方式，每个功能模块可以被独立开发，独立部署，独立运行，独立进行版本控制，等等。而对于规模比较庞大的系统来说，这种利用微服务架构所开发的应用，其天然的优势就更能体现出来了——即每个模块可以独立的团队由单独负责。因此，微服务开发中的第一个重点，就是要有非常明确的需求，以及一个经验丰富的架构师，在设计之初就对各个功能模块进行合理的规划和拆分。 在整个应用设计之初由总设计师或架构师设计好各个功能模块后，第二个重点就来了：设计微服务中各个模块间的调用接口——通常由 Rest API 或者 gRPC 组成——来负责模块之间的交互，这就是微服务的第二个重点。良好的接口设计将会使你的应用结构清晰，开发起来事半功倍。而且每个独立团队在开发时都能感受到明显的模块边界，且可以放心利用模拟数据和测试数据进行开发( 只要符合接口规则的数据就能用，不用操心其他模块是如何实现的 )，从而真正实现每个团队富有效率的并行开发。 利用微服务架构开发除了上述好处之外，在运维方面的优势也非常直观——我们可以清晰地观测到整个系统的资源瓶颈在何处( 哪个容器的资源开销最大 )，从而实现有针对性的“定向扩缩容”。利用微服务架构前后的扩缩容机制如下图所示意。 ( 上图: 单体应用和微服务应用最直观的差别：定向扩缩容 示意图 )将庞大的单体应用逐步改造成微服务应用在看完上面的介绍后，相信饱受单体应用折磨的各位读者已经对微服务开发已经跃跃欲试了。但是，对于一个正在运行并使用的应用来说，完完全全从零开始开发并不现实。对于一个已经成熟并正在使用的单体应用系统来说，我们可以通过自己的努力，将一个单体应用在几次迭代过程中，逐渐改变为微服务应用。如何办到呢？下面放一张图片来帮助您激发灵感： ...

查看版本kubectl version查看节点kubectl get nodes部署app说明： 提供deployment名称和app镜像地址（docker镜像地址） kubectl run kubernetes-bootcamp --image=gcr.io/google-samples/kubernetes-bootcamp:v1 --port=8080再如： run test --image=preparedman/mytomcat:tagname --port=8088查看appkubectl proxy测试：curl http://localhost:8001/version { "major": "1", "minor": "13", "gitVersion": "v1.13.3", "gitCommit": "721bfa751924da8d1680787490c54b9179b1fed0", "gitTreeState": "clean", "buildDate": "2019-02-01T20:00:57Z", "goVersion": "go1.11.5", "compiler": "gc", "platform": "linux/amd64"}获取pod名字 export POD_NAME=$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')测试：echo Name of the Pod: $POD_NAME 使用kubectl进行故障排除主要使用如下命令 kubectl get - list resources 列出资源kubectl describe - show detailed information about a resource 显示资源详情kubectl logs - print the logs from a container in a pod 打印`pod` 中container的日志kubectl exec - execute a command on a container in a pod 在`pod`中的container上执行命令获取应用配置查看应用是否在运行 ...

2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近千名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。 来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人出席了本届ECIC，现场带来关于企业容器项目实践经验的精彩分享，为参会的容器技术爱好者带来企业容器化的经验分享。 贴近容器用户需求，推动中国容器持续创新 Rancher联合创始人及CEO梁胜表示，容器技术的发展存在周期性，Kubernetes正从初创期走向成熟期，变成一个被云计算服务提供商及数据中心广泛应用的商品。然而容器技术的发展而言是永无止境的，用户需求是容器发展的源动力，同时也是保持容器技术持续创新的关键要素。 Rancher联合创始人及CEO梁胜 梁胜以Rancher 2019年3月发布的史上最轻量级Kubernetes发行版k3s为例验证了他的这一观点：“过去的一年间，数十个和Rancher达成合作的企业客户均向我们表达，他们认为Kubernetes是管理边缘基础设施的理想平台，但他们不愿意在他们的边缘设备中投入大量资源来运行一个成熟的Kubernetes平台。K3s为这些团队提供了一个小于512MB RAM的Kubernetes发行版，非常适用于边缘计算的案例。” 大会上，Rancher还为现场的容器爱好者带来了三个惊喜产品，一是新一代容器化分布式存储项目Longhorn，这是一个开源的、基于云和容器部署的分布式快存储新方式；二是发布了Rancher中国企业版Pandaria，Pandaria是Rancher Kubernetes管理平台面向中国区的企业版本，旨在不断满足中国市场的快速灵活多变的需求，主要功能包括Harbor镜像仓库集成、支持Audit log 审计日志、为国内公有云提供更多的优化支持等；三是进行了Rancher 2.3 Preview发布及功能演示，在即将发布的 Rancher 2.3版本中，Rancher将正式支持Windows Kubernetes、镜像仓库、镜像扫描、服务网格、Google登陆、集群模版、集群安全扫描和集群自动扩缩容。 深耕合作伙伴生态，共同赋能云原生产业 阿里云容器服务研发总监易立 阿里云作为国内最大的云计算服务提供商，拥有业内规模最大的云原生应用实战经验，服务了互联网、金融、政务等领域企业和机构。阿里云容器服务研发总监易立强调：“在公共云、混合云，抑或是云、边、端广泛互联的IoT场景中，更加标准化、高效地交付应用，是云原生技术带给企业的重要价值所在。” 值得一提的是，阿里云和Rancher早已在去年便已达成了公有云容器项目的合作，Rancher可以实现阿里云Kubernetes的托管服务。而在本次大会上，易立透露，未来阿里云将和Rancher展开更深层级的合作，共同布道云原生服务，为全球企业提供更简单易用的容器技术。 Rancher&SmartX战略合作与联合解决方案发布 本次大会的另一个亮点是业内领先的超融合厂商 SmartX 和 Rancher 发布了战略合作伙伴关系与联合解决方案。解决方案围绕着用户容器环境“生产就绪”面临的诸多挑战，基于 SmartX 为大规模虚拟化和容器打造的数据中心操作系统SMTX OS，涵盖其功能丰富且经过生产环境检验的虚拟化、分布式存储等模块，既可通过超融合方式在单套系统内提供从容器、编排到虚拟化，存储和管理的全栈解决方案，亦可仅作为持久化存储单独部署与K8s集群配合。 SmartX市场与战略合作总监库依楠表示：“SmartX非常高兴能在容器领域和Rancher形成战略合作，Rancher对于专业的技术和用户需求的深刻理解，和SmartX Make IT Simple的理念是完全一致的，相信这次联合发布的解决方案，将会为用户带来更大的价值。” 除此之外，Rancher在本次大会上还显示了强大的生态合作伙伴能力，百度云、JFrog、Cisco等技术类合作伙伴均与Rancher达成了长期的生态系统合作，Rancher将携手合作伙伴积极推进容器生态系统的建设，共同促进容器技术和云计算领域的创新。 以用户需求为核心，推进企业容器化落地 在大会的企业容器化实践分享上，不同行业的企业技术负责人则分别给出了他们的答案。 平安科技CTO及总架构师方国伟 平安科技CTO及总架构师方国伟提出，近年来在云计算赛道上，容器因为它轻量、灵活、易管理、易迁移等特性被企业广泛采用，如一辆高速前进的方程式赛车脱颖而出，成为了企业云化历程中的大势所趋。所以在未来3年，平安云将会重点投入容器建设，解决容器快速交付的难题，并且进行微服务的支撑。 中国联通集团信息化副总经理王志军 中国联通作为国内三大运营商之一，拥有国内领先的大数据平台，中国联通集团信息化副总经理王志军分享道：“通过研究、探索和实践，我们发现Kubernetes+Docker的技术路线更契合联通的实际需求，它几乎支持了所有的容器业务类型，也正是基于联通的技术选型，我们引入了Rancher的产品部署和Kubernetes集群管理功能，为联通的容器化大数据云平台提供更强而有力的容器技术及容器服务支撑。” 飞贷金融科技副总裁陈定玮 对于飞贷金融科技副总裁陈定玮而言，首先面对的是金融行业数据具有相较于其他行业更为严格的安全高标准要求，同时支撑飞贷金融科技的核心业务也是根本需求，而传统模式系统的DB在运维、研发、产品交付一直无法跟上微服务容器化的步伐，飞贷通过持续创新，结合当前的产品研发体系，飞贷自研中间件，在满足金融领域标准和业务要求状况下，进行生产DB容器化，带来10x的DB交付效率，极致的弹性扩容能力，解决了金融领域DB与应用的服务标准效率差距太大这一难题。 中国人寿开发五部云计算架构师张青南 中国人寿研发中心高级架构师张青南表示，从2017年起，中国人寿正式开始利用容器技术搭建PaaS平台“稻客云”，结合持续集成/交付技术，实现了研发全流程自动化及对应用容器的全面管理，至2019年，“稻客云”已支持中国人寿15个关键系统的生产运行，管理应用容器4800多个。“容器技术的应用促进了中国人寿整个研发流程的优化和可管控，软件的迭代周期大大缩短，并且以容器部署的方式承载了应用，实现弹性伸缩，应用快速构建部署。” 厦门航空信息部系统工程师、云平台负责人周钊 厦门航空和Rancher的合作可以追溯到2年前。2017年，厦门航空完成了厦航云计算平台项目建设，基于Rancher、IaaS和CMP搭建了三位一体的厦门航空云计算平台。“航空行业电商的发展催生了大量的业务请求访问，平台需要做到具备极强的稳定性和自动弹性收缩能力，而原有的传统开发模式和软件开发模式早已无法满足现有的需求。” 厦门航空信息部系统工程师、云平台负责人周钊分享道：“在这样的情形下，我们找到了Rancher，通过自主研发及微服务架构与Rancher容器平台完美结合，共同打造出厦航电商战略的支持平台。” 新东方信息管理部平台架构负责人姜江 同样是2017年，新东方开始了利用容器化手段将中间件业务服务化的探索，基于Rancher 1.6使用ES；2019年，新东方再次开始了扩大了中间件的业务服务化，基于Kubernetes使用Kafka、ES和Redis。新东方信息管理部平台架构负责人姜江总结道：“利用容器化手段将中间件服务化有效提升了运维团队的工作效率，缩短了软件开发流程。” 总的来说，这些企业关于容器化落地的精彩分享充分显示了Rancher在容器领域的巨大影响力，以及对于多个行业的共同推动作用。 展望未来 Rancher成立至今已经有将近5年的时间，在短短数载，Rancher迅速成为了业界领先的容器管理软件提供商，为超过20000家企业用户提供了企业化容器落地解决方案，本次大会中演讲的生态合作伙伴及各行业客户便是最好的证明。而这仅仅只是Rancher的起点。 一如梁胜在演讲中强调的那样： “Rancher在中国的用户以及合作伙伴生态系统都非常活跃，我们时常可以收到中国用户和伙伴对所需功能及支持项目的反馈和需求。在未来，Rancher希望能为中国用户带来更多、更实用的容器技术，推动中国企业容器化的持续创新。” ...

“故障注入 Sidecar“——为您的微服务注入故障以验证集群性能! 由于导师和实验室师兄们的科研需要，本人专门以 Sidecar的模式设计了一个用于错误注入的微服务模块。该模块可以与任何微服务应用共同部署运行，为其模拟cpu、内存等错误。 本项目的 Github地址: https://github.com/iscas-micr...我的联系方式: leontian1024@gmail.com || 或直接留言 欢迎您提出问题批评指点!项目背景目前，本人正在中科院软件所的微服务研究组从事部分研究工作。由于本人所在科研小组的研究内容( 微服务自动扩缩容相关 )，需要经常使微服务应用处于"高 CPU 利用率" 和 "高内存使用"的状态。因此，为了方便导师和实验室的各位师兄进行实验，本人特地开发了一个可以注入进 Pod 中的错误注入容器，来模拟上述的高负载状态。 导师和师兄们使用后对我的工作给予了肯定，因此我准备将开发过程和简单使用方法写成文章做个记录( 也就是本文 )，一来方便自己日后工作学习，二来也方便有类似实验需求的其他同仁们使用这个小项目，为大家的研究节省时间。更具体的安装和使用方法，可以移步本项目 Github 的代码仓库，其中有非常详细的说明。 知识储备什么是微服务中的"Sidecar 运行模式?" 上图: 以 Sidecar 模式部署并运行的微服务单元Sidecar 运行模式是最近两年比较火的一种微服务部署和运行方法，它由目前流行的 ServiceMesh(服务网格) 架构推广而来。 具体而言，Sidecar 运行模式是一种"将不属于业务应用的功能以独立的容器运行于业务容器旁边"，在 K8s 中表现出的样子就是将具有不同功能的模块封装成不同的镜像，并以不同的容器运行在同一个 Pod 中。这种说法非常形象，因为 Sidecar 这个单词的本意就是三轮摩托侧面的"跨斗"，这里形容独立于业务应用但又与业务应用部署在一起非常合适。 上图: Sidecar ，中文意思为摩托车的跨斗，不由赞叹命名的非常生动主要设计思想架构设计本项目的错误注入模块也采用了 Sidecar 这种设计思想，将用于模拟 CPU、内存等故障的模块独立封装成一个镜像，并在 Pod 启动时以 Sidecar 的形式运行在主业务容器旁边。这样，不用它时他就会安安静静地当个美男子，完全不用担心它会影响到正常业务的运行；一旦需要它模拟错误产生，由于与业务容器同处于一个 Pod 之中(而 K8s 又以 Pod 为基本单元)，因此他模拟出的错误亦被 K8s 集群视为业务应用所在 Pod 产生而被监测到。 上图: Pod 中的每个容器都有自己的端口映射到外部主机，因此不会相互影响注入方式设计本项目在设计之初是采用“在容器内修改环境变量”的方式对容器注入故障的，但事实证明这种方法太low，而且非常麻烦。因此在后续设计和实现中采用了目前较为流行的通过 REST API 传递 POST 请求的方式使容器模拟错误，这样就极大地方便了师兄们展开实验，而且也可以模拟出“微服务间调用而产生错误”的场景( 上游服务调用错误注入的 API 而模拟下游服务产生错误 )。 ...

目前，容器服务Windows Kubernetes支持将业务容器产生的stdout输出、日志文件同步到阿里云日志服务（SLS）进行统一管理。 支撑组件安装在Windows Kubernetes集群安装界面勾选使用日志服务，集群会安装支持日志收集的必要组件logtail。 集群安装完毕后，可以在日志服务控制台 查看到按k8s-sls-{Kubernetes 集群 ID}形式命名的工程。收集到的业务容器日志都会放在该工程下。 使用YAML模版部署业务容器YAML 模板的语法同 Kubernetes 语法，但是为了给容器指定采集配置，需要使用 env 来为 container 增加采集配置和自定义 Tag，并根据采集配置，创建对应的 volumeMounts 和 volumns。以下是一个简单的 Deployment 示例： apiVersion: extensions/v1beta1kind: Deploymentmetadata: labels: app: logtail-test name: logtail-testspec: replicas: 1 template: metadata: labels: app: logtail-test name: logtail-test spec: containers: - name: logtail image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/windows-logtail:1809-1.0.0.4 command: ["powershell.exe"] args: [cmd /k "ping -t 127.0.0.1 -w 10000 > C:\log\data.log"] env: ######### 配置 环境变量 ########### - name: aliyun_logs_log-stdout value: stdout - name: aliyun_logs_log-varlog value: C:\log\*.log - name: aliyun_logs_log_tags value: tag1=v1 ################################# ######### 配置vulume mount ####### volumeMounts: - name: volumn-sls-win mountPath: c:\log volumes: - name: volumn-sls-win emptyDir: {} ############################### nodeSelector: beta.kubernetes.io/os: windows其中有三部分需要根据您的需求进行配置，一般按照顺序进行配置。 ...

问题microk8s安装过程中,部分镜像需要从google的镜像仓库拉取,但是国内无法访问其镜像仓库, 故需要手动获取镜像再自行安装(从官方提供的google mirror仓库获取)microk8s不是使用的宿主机器的docker进程, 故不能简单的把自己获取的镜像重新tag来完成安装; 需要导出之后然后使用microk8s提供的镜像管理功能进行导入解决原理获取到你需要的镜像名称和版本之后 (参见后面的排查技巧) docker pull mirrorgooglecontainers/$imageName:$imageVersiondocker tag mirrorgooglecontainers/$imageName:$imageVersion k8s.gcr.io/$imageName:$imageVersiondocker save k8s.gcr.io/$imageName:$imageVersion > $imageName.tarmicrok8s.ctr -n k8s.io image import $imageName.tar示例步骤视你开启的插件而言,需要手动安装需要的镜像, 以我为例, 需要如下这些(注意版本可能不一样) k8s.gcr.io/pause:3.1k8s.gcr.io/heapster-influxdb-amd64:v1.3.3k8s.gcr.io/heapster-grafana-amd64:v4.4.3k8s.gcr.io/heapster-amd64:v1.5.2k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7安装脚本如下(可以根据原理做成通用脚本再传参安装): docker pull mirrorgooglecontainers/pause:3.1docker pull mirrorgooglecontainers/heapster-influxdb-amd64:v1.3.3docker pull mirrorgooglecontainers/heapster-grafana-amd64:v4.4.3docker pull mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.8.3docker pull mirrorgooglecontainers/heapster-amd64:v1.5.2docker pull mirrorgooglecontainers/k8s-dns-dnsmasq-nanny-amd64:1.14.7docker pull mirrorgooglecontainers/k8s-dns-kube-dns-amd64:1.14.7docker pull mirrorgooglecontainers/k8s-dns-sidecar-amd64:1.14.7docker tag mirrorgooglecontainers/pause:3.1 k8s.gcr.io/pause:3.1docker tag mirrorgooglecontainers/heapster-influxdb-amd64:v1.3.3 k8s.gcr.io/heapster-influxdb-amd64:v1.3.3docker tag mirrorgooglecontainers/heapster-grafana-amd64:v4.4.3 k8s.gcr.io/heapster-grafana-amd64:v4.4.3docker tag mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.8.3 k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3docker tag mirrorgooglecontainers/heapster-amd64:v1.5.2 k8s.gcr.io/heapster-amd64:v1.5.2docker tag mirrorgooglecontainers/k8s-dns-dnsmasq-nanny-amd64:1.14.7 gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.7docker tag mirrorgooglecontainers/k8s-dns-kube-dns-amd64:1.14.7 gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.7docker tag mirrorgooglecontainers/k8s-dns-sidecar-amd64:1.14.7 gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.7docker save k8s.gcr.io/pause > pause.tardocker save k8s.gcr.io/heapster-influxdb-amd64 > heapster-influxdb-amd64.tardocker save k8s.gcr.io/heapster-grafana-amd64 > heapster-grafana-amd64.tardocker save k8s.gcr.io/kubernetes-dashboard-amd64 > kubernetes-dashboard-amd64.tardocker save k8s.gcr.io/heapster-amd64 > heapster-amd64.tardocker save gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64 > k8s-dns-dnsmasq-nanny-amd64.tardocker save gcr.io/google_containers/k8s-dns-kube-dns-amd64 > k8s-dns-kube-dns-amd64.tardocker save gcr.io/google_containers/k8s-dns-sidecar-amd64 > k8s-dns-sidecar-amd64.tarmicrok8s.ctr -n k8s.io image import pause.tarmicrok8s.ctr -n k8s.io image import heapster-influxdb-amd64.tarmicrok8s.ctr -n k8s.io image import heapster-grafana-amd64.tarmicrok8s.ctr -n k8s.io image import kubernetes-dashboard-amd64.tarmicrok8s.ctr -n k8s.io image import heapster-amd64.tarmicrok8s.ctr -n k8s.io image import k8s-dns-dnsmasq-nanny-amd64.tarmicrok8s.ctr -n k8s.io image import k8s-dns-kube-dns-amd64.tarmicrok8s.ctr -n k8s.io image import k8s-dns-sidecar-amd64.tar排查技巧遇到问题时先通过 microk8s.kubectr get pods 查看是否是RUNNING状态, 如果不是,先按照上述方法解决镜像问题查看具体的镜像版本时候可以通过 kubectl get pods --namespace=kube-system -o json |grep message直接过滤出错误消息注意namespace的选择, 特别是你自己定义了namespace之后

作者：1.15发布团队 我们很高兴地宣布交付Kubernetes 1.15，这是我们2019年的第二个版本！Kubernetes 1.15包含25个增强：2个升级为稳定，13个升级为beta，10个升级为alpha。这次发布的主题是： 持续改进 项目的可持续性不仅仅是功能。许多SIG一直致力于提高测试覆盖率，确保基本功能保持可靠，确保核心功能集的稳定性，并致力于成熟现有功能和清理积压。可扩展性 社区一直要求继续支持可扩展性，因此这个周期围绕CRD和API Machinery进行更多的工作。这个周期中的大多数增强来自SIG API Machinery和相关领域。让我们深入了解这个版本的主要特性： 围绕核心Kubernetes API的可扩展性围绕customresourcedefinition的新开发的主题是数据一致性和原生行为。用户不应该注意交互是与CustomResource还是与Golang-native资源进行的。随着大的步骤，我们在未来的版本之一正在努力向一个GA版本的CRD和GA的准入webhook。 在这个方向上，我们重新考虑了CRD中基于OpenAPI的验证模式，从1.15开始，我们根据“结构模式（structural schema）”的限制检查每个模式。这基本上强制了CustomResource中每个字段的非多态（ non-polymorphic）和完整类型（complete typing）。将来我们将需要结构模式，特别是对于所有新特性，包括下面列出的特性，以及列出非结构（NonStructural）条件下的违规行为。在v1beta1 API组中，非结构模式（non-structural schema）仍然保持工作状态。但是任何严肃的CRD应用程序都应该在可预见的将来迁移到结构模式。 关于什么使模式结构化的详细信息将在kubernetes.io的博客文章中在本周晚些时候发布，当然Kubernetes的文档中对此有记录。 beta: CustomResourceDefinition Webhook Conversioncustomresourcedefinition自1.14起作为beta支持多个版本。使用Kubernetes 1.15，它们能够实时地在不同版本之间进行转换，就像用户长期习惯于从原生资源进行转换一样。CRD的转换是通过webhook实现的，由集群管理员部署在集群内部。这一特性已在Kubernetes 1.15中升级到beta，将CRD提升到一个全新的水平，用于真正的CRD应用程序。 beta: CustomResourceDefinition OpenAPI Publishingkube-apiserver在/openapi/v2上为原生类型提供OpenAPI规范已经有很长一段时间了，它们被许多组件使用，尤其是kubectl客户端验证、kubectl explain和基于OpenAPI的客户端生成器。 用于CRD的OpenAPI发布将在Kubernetes 1.15作为beta提供，同样只适用于结构模式。 beta: CustomResourceDefinitions Pruning修剪（Pruning）是自动删除发送到Kubernetes API的对象中的未知字段。如果未在OpenAPI验证模式中指定字段，则该字段是未知的。这是一个数据一致性和安全性相关的特性。它强制只将CRD开发者指定的数据结构持久化到etcd。这是原生资源的行为，也将用于CRD，从Kubernetes 1.15的beta版开始。 修剪是通过CustomResourceDefinition中的spec.preserveUnknownFields: false激活。将来的apiextensions.k8s.io/v1 CRD变种将强制执行修剪（可能但明确必要的选择退出）。 修剪要求CRD开发者为CRD的所有版本提供完整的、结构化的验证模式，要么是顶层的，要么是所有版本的。 alpha: CustomResourceDefinition Defaultingcustomresourcedefinition获得默认支持。默认值是使用OpenAPI验证模式中的default关键字指定的。在发送到API的对象中以及从etcd读取时，为未指定字段设置默认值。 default在Kubernetes 1.15中将作为alpha提供，用于结构模式。 beta: Admission Webhook Reinvocation & Improvements对于扩展Kubernetes API的项目来说，变异（mutating）和验证（validating）准入（admission）webhook变得越来越主流。到目前为止，按照字母顺序，只调用了一次变异webhook。早期运行的webhook不能对链中稍后调用的webhook的输出作出反应。随着Kubernetes 1.15的发布，情况将发生变化： 通过指定reinvocationPolicy: ifNeeded，变异webhook可以选择至少一次重新调用。如果后面的变异webhook修改了对象，那么前面的webhook将得到第二次机会。 这要求webhook具有类似幂等（idempotent）的行为，可以处理第二次调用。 不打算添加另一轮调用，这样webhook的作者仍然必须小心对他们实现的已被承认的对象的更改。最后，调用验证webhook来验证所承诺的不变量是否已实现。 对准入webhook有更多更小的更改，特别是objectSelector，它将具有特定标签的对象排除在准入之外，以及webhook服务器的任意端口（不仅仅是443）。 集群生命周期的稳定性和可用性的改进使Kubernetes的安装、升级和配置更加健壮是SIG Cluster Lifecycle在这个周期的主要关注点（请参阅我们的社区近况）。跨裸金属工具的Bug修复和生产就绪的用户场景（如高可用性用例）在1.15中获得优先级。 集群生命周期构建块kubeadm继续接收高效引导生产集群所需的特性和稳定性工作。kubeadm将高可用性（high availability，HA）功能提升到了beta，允许用户使用熟悉的kubeadm init和kubeadm join命令来配置和部署HA控制平面。已经专门创建了一个全新的测试套件，以确保这些特性在一段时间内保持稳定。 ...

目标在阿里云容器服务 Kubernetes 集群上部署 Istio 服务网格实践灰度发布、故障注入、熔断等 Istio 流量管理特性准备工作安装和设置 kubectl 客户端，请参考不同的操作系统，如果已经安装请忽略：macOScurl -LO https://kubectl.oss-cn-hangzhou.aliyuncs.com/macos/kubectlchmod +x ./kubectlsudo mv ./kubectl /usr/local/bin/kubectlkubectl --helpLinuxcurl -LO https://kubectl.oss-cn-hangzhou.aliyuncs.com/linux/kubectlchmod +x ./kubectlsudo mv ./kubectl /usr/local/bin/kubectlkubectl --helpWindows把 https://kubectl.oss-cn-hangzhou.aliyuncs.com/windows/kubectl.exe 放到系统PATH路径下 kubectl --help配置 kubectl 连接 Kubernetes 集群的配置，可参考文档 通过kubectl连接Kubernetes集群 实验步骤部署Istio登录容器服务控制台，在集群列表中选择一个集群，打开更多 - 部署 Istio 保持默认配置，点击"部署 Istio" 等待完成后，Istio 已经成功部署在 Kubernetes 集群中使用 kiali 查看服务网格可视化kubectl port-forward -n istio-system "$(kubectl get -n istio-system pod --selector=app=kiali -o jsonpath='{.items..metadata.name}')" 20001在本地浏览器中访问 http://localhost:20001 ，使用默认账户 admin/admin 登录 灰度发布创建命名空间并开启 Sidecar 自动注入：单击左侧导航栏中的集群 > 命名空间，进入命令空间页面，创建一个名称为 demo 的命名空间，并为其添加一个 istio-injection:enabled 的标签 单击左侧导航栏中服务网格 > 虚拟服务，进入虚拟服务（Virtual Service）页面，点击创建，创建一个简单的示例应用，指定应用名称为istio-app，指定应用版本为v1，选择刚刚创建的命名空间 demo 配置应用容器，使用如下镜像：registry.cn-beijing.aliyuncs.com/test-node/node-server:v1 ...

几个关键点： 把k8s部署需要的镜像从mirrorgooglecontainers下下来，并打上k8s.gcr.io的tag注意部署网段，不要和宿主机的网段冲突注意更改hostname，防止一些不合法的字符如下划线echo "关闭docker 可能要花一点时间"systemctl stop dockerecho "关闭缓存"swapoff -a# 编辑/etf/fstabsed -e '/swap/ s/^#*/#/' -i /etc/fstabmount -a# 查看输出free -hecho "关闭防火墙"# 关闭防火墙systemctl disable firewalldsystemctl stop firewalldsystemctl status firewalldecho "关闭防火墙成功"sleep 1cat << EOF > /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOFsysctl --systemsleep 1# 添加一条规则cat << EOF > /etc/sysctl.confnet.ipv4.ip_forward = 1EOF# 生效配置sysctl -p##################################### 安装docker# 前置需求#yum install -y yum-utils device-mapper-persistent-data lvm2## Add docker repository.#yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo## Install docker.#yum update && yum install docker-ce-17.06.0.ce-1.el7.centos## Create /etc/docker directory.#mkdir -p /etc/docker##cat > /etc/docker/daemon.json <<EOF#{#"log-driver":"json-file",#"log-opts":{"max-size":"1024m","max-file":"2"}#}#EOF##################################### 安装dockercat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64enabled=1gpgcheck=0repo_gpgcheck=0gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpghttp://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF# 修改主机名， 主机名中不能含有下划线，否则会报错。hn=`hostname`# 将原来主机名中的下划线改为-new_hn="${hn//_/-}"hostnamectl set-hostname $new_hn#sed -i "s/$/ $new_hn/" /etc/hostssed -e "s/$/ $new_hn/" -i /etc/hosts# 启动docker服务echo "启动docker服务，可能花费较长时间"systemctl start docker.service# 从镜像拉去Image，并改tagdocker pull mirrorgooglecontainers/kube-apiserver:v1.14.2docker tag mirrorgooglecontainers/kube-apiserver:v1.14.2 k8s.gcr.io/kube-apiserver:v1.14.2docker pull mirrorgooglecontainers/kube-controller-manager:v1.14.2 k8s.gcr.io/kube-controller-manager:v1.14.2docker pull mirrorgooglecontainers/kube-controller-manager:v1.14.2docker tag mirrorgooglecontainers/kube-controller-manager:v1.14.2 k8s.gcr.io/kube-controller-manager:v1.14.2docker pull mirrorgooglecontainers/kube-scheduler:v1.14.2docker tag mirrorgooglecontainers/kube-scheduler:v1.14.2 k8s.gcr.io/kube-scheduler:v1.14.2docker pull mirrorgooglecontainers/kube-proxy:v1.14.2docker tag mirrorgooglecontainers/kube-proxy:v1.14.2 k8s.gcr.io/kube-proxy:v1.14.2docker pull mirrorgooglecontainers/pause:3.1docker tag mirrorgooglecontainers/pause:3.1 k8s.gcr.io/pause:3.1docker pull mirrorgooglecontainers/etcd:3.3.10docker tag mirrorgooglecontainers/etcd:3.3.10 k8s.gcr.io/etcd:3.3.10docker pull coredns/coredns:1.3.1docker tag coredns/coredns:1.3.1 k8s.gcr.io/coredns:1.3.1# Set SELinux in permissive mode (effectively disabling it)setenforce 0sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/configyum install -y kubelet kubeadm kubectl --disableexcludes=kubernetessystemctl enable kubelet && systemctl start kubelet#############################如果是master结点#######################################kubeadm init --pod-network-cidr=10.20.0.0/16 --apiserver-advertise-address=Your_host_address# 设置kubeconfig地址export KUBECONFIG=/etc/kubernetes/admin.conf# 设置rbackubectl apply -f https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml# 下载calico.yamlcurl -O https://docs.projectcalico.org/v3.3/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml# 修改calico.yaml# ！！！！这里很关键，要把原来的CIDR换成一个和宿主机局域网不同的网段！！！！！# - name: CALICO_IPV4POOL_CIDR# value: "192.168.0.0/16" ------------> 10.20.0.0/16# 安装网络组件kubectl apply -f calico.yaml#############################如果是worker节点#######################################kubeadm join 192.168.130.212:6443 --token 3csntd.vebwbj6pcy5nx6uw \ --discovery-token-ca-cert-hash sha256:XXXXX

节点离线后的 pod 状态在 kubernetes 使用过程中，根据集群的配置不同，往往会因为如下情况的一种或几种导致节点 NotReady: kubelet 进程停止apiserver 进程停止etcd 进程停止kubernetes 管理网络 Down当出现这种情况的时候，会出现节点 NotReady，进而当kube-controller-manager 中的--pod-eviction-timeout定义的值，默认 5 分钟后，将触发 Pod eviction 动作。 对于不同类型的 workloads，其对应的 pod 处理方式因为 controller-manager 中各个控制器的逻辑不通而不同。总结如下: deployment: 节点 NotReady 触发 eviction 后，pod 将会在新节点重建(如果有 nodeSelector 或者亲和性要求，会处于 Pending 状态)，故障节点的 Pod 仍然会保留处于 Unknown 状态，所以此时看到的 pod 数多于副本数。statefulset: 节点 NotReady 同样会对 StatefulSet 触发 eviction 操作，但是用户看到的 Pod 会一直处于 Unknown 状态没有变化。daemonSet: 节点 NotReady 对 DaemonSet 不会有影响，查询 pod 处于 NodeLost 状态并一直保持。这里说到，对于 deployment 和 statefulSet 类型资源，当节点 NotReady 后显示的 pod 状态为 Unknown。 这里实际上 etcd 保存的状态为 NodeLost，只是显示时做了处理，与 daemonSet 做了区分。对应代码中的逻辑为: ...

概述External-DNS提供了编程方式管理Kubernetes Service资源的DNS的功能，类似于容器服务kubernetes federation v2实践一：基于External-DNS的多集群Ingress DNS实践，External-DNS会监听LoadBalancer类型的Service，然后与云厂商打通，按照可用区、region和全局三个维度生成独自的域名解析记录，便于服务间调用引导流量。本文简单介绍如何在阿里云容器平台上使用External-DNS管理多集群Service DNS。 环境准备参考容器服务kubernetes federation v2实践一：基于External-DNS的多集群Ingress DNS实践完成【联邦集群准备】、【配置RAM信息】和【部署External-DNS】部分，并配置好kubeConfig，如下所示： kubectl config get-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACE* cluster1 cluster1 kubernetes-admin1 cluster2 cluster2 kubernetes-admin2资源部署创建FederatedDeployment和FederatedServiceyaml如下，注意FederatedService类型为LoadBalancer apiVersion: v1kind: Namespacemetadata: name: test-namespace---apiVersion: types.federation.k8s.io/v1alpha1kind: FederatedNamespacemetadata: name: test-namespace namespace: test-namespacespec: placement: clusterNames: - cluster1 - cluster2---apiVersion: types.federation.k8s.io/v1alpha1kind: FederatedDeploymentmetadata: name: test-deployment namespace: test-namespacespec: template: metadata: labels: app: nginx spec: replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx placement: clusterNames: - cluster1 - cluster2---apiVersion: types.federation.k8s.io/v1alpha1kind: FederatedServicemetadata: name: test-service namespace: test-namespacespec: template: spec: selector: app: nginx type: LoadBalancer ports: - name: http port: 80 placement: clusterNames: - cluster2 - cluster1查看各个集群Service详情： ...

零、3个节点基本信息如下：| ip | hostname | 用途 || 172.16.180.251 | k8s-master | master 节点 || 172.16.180.252 | k8s-node1 | node 节点1 || 172.16.180.253 | k8s-node2 | node 节点2 | 一、系统设置及资源准备这部分三个节点都需要进行配置和准备，当然node节点部分资源可以不下载，将不需要的部分剔除即可。这里为了方便就统一都一样处理吧 0、配置selinux和firewalld# Set SELinux in permissive modesetenforce 0sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config# Stop and disable firewalldsystemctl disable firewalld --now1、系统参数与内核模块# 修改内核参数cat <<EOF > /etc/sysctl.d/k8s.confnet.bridge.bridge-nf-call-ip6tables = 1net.bridge.bridge-nf-call-iptables = 1EOFsysctl --system# 加载内核模块modprobe br_netfilterlsmod | grep br_netfilter2、配置yum源# base repocd /etc/yum.repos.dmv CentOS-Base.repo CentOS-Base.repo.bakcurl -o CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.reposed -i 's/gpgcheck=1/gpgcheck=0/g' /etc/yum.repos.d/CentOS-Base.repo# docker repocurl -o docker-ce.repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo# k8s repocat <<EOF > /etc/yum.repos.d/kubernetes.repo[kubernetes]name=Kubernetesbaseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64enabled=1gpgcheck=0repo_gpgcheck=0gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpgEOF# update cacheyum clean all yum makecache yum repolist3、禁用swapswapoff -aecho "vm.swappiness = 0">> /etc/sysctl.confsysctl -p如果重启后swap又会被挂上，还需要注释掉/etc/fstab中的一行配置： ...

背景假设存在一个容器，提供的服务是 HTTP 或者 RPC 的服务。由于出于简单可维护的目的，这个容器的基础镜像里面没有带上任何和网络抓包相关的功能。那么如何能搞对这样的容器进行抓包，以分析业务上面可能存在的问题呢？ 共享网络Docker 的容器之间可以通过共享网络空间的方式，来让多个容器实现网络互通。这个意思直接一点就是如果你到每个容器内部去访问 localhost 监听的服务，无论这个服务在哪个容器里面，都能够访问成功。这就为网络抓包提供了基础。 专用镜像我们可以使用一个专用的 tcpdump 的镜像来进行抓包。镜像名称为 corfr/tcpdump:latest ，可以使用 docker pull 直接下载。 $ docker pull corfr/tcpdump:latest抓包实践我们现在用一个提供简单 HTTP 服务的镜像来进行测试。 下载测试镜像 $ docker pull jemygraw/echo-go:1.0启动测试容器 $ docker run -p 8080:8080 jemygraw/echo-go:1.0 /home/app/echo-go -port 8080查看测试容器ID $ docker ps5de30e950459 jemygraw/echo-go:1.0 "/home/app/echo-go -…" 10 minutes ago Up 10 minutes 0.0.0.0:8080->8080/tcp dreamy_benz启动抓包镜像，注意使用 --network 参数来共享测试容器的网络。 $ docker run --network container:5de30e950459 corfr/tcpdump:latest -i any -U -w -由于 corfr/tcpdump:latest 镜像构建的时候使用了 ENTRYPOINT 指定了入口命令为 /usr/sbin/tcpdump ，所以这里我们指定命令的选项参数即可。 ...

背景在 Kubernetes 的实际使用中，我们经常需要配合业务调查问题，对于微服务来说，这个问题更多的是查看 API 的调用情况，这些API或者采用 RPC 协议或者是采用 HTTP 的协议。这两种协议都是基于 TCP 的协议，所以一般我们会到容器中使用 tcpdump 工具来抓包，然后就地或者拿出来放到 wireshark 图形化软件里面分析。 这种情况下，需要我们的基础镜像提前把 tcpdump 等排查工具打包进去，否则线上安装 debug 软件，一者违反安全规则，另外如果需要支持的 Pod 过多，安装 debug 工具本身就有不小的工作量。 krew在 Kubernetes 中，有一个插件命令叫做 krew，可以通过这个命令来安装一个叫做 sniff 的插件工具来完成这个工作。下面我们先看看如何安装这个 krew 插件。 krew 的项目地址在：https://github.com/kubernetes-sigs/krew 。如果有兴趣可以自行浏览，我们这里介绍下在 Centos 等 Linux 下面如何安装。 首先，需要确认系统安装了 git 。 其次，复制下面的命令到终端软件中，这段命令会去下载和安装这个 krew 插件。 $( set -x; cd "$(mktemp -d)" && curl -fsSLO "https://storage.googleapis.com/krew/v0.2.1/krew.{tar.gz,yaml}" && tar zxvf krew.tar.gz && ./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" install \ --manifest=krew.yaml --archive=krew.tar.gz)安装好的 krew 命令在目录 ~/.krew/bin 下面，所以我们可以把这个路径加到终端的配置文件中。一般是 ~/.bashrc 或者是 ~/.zshrc。 ...

背景在日常使用中，Kubectl 作为和 Kubernetes 集群进行交互的工具，提供了丰富的功能。但是偶尔也有时候，你想做一些 Kubectl 暂时还不支持的功能。那么在这种情况下，如何不改变 Kubectl 的代码并且重新编译就能引入新的功能呢？ 这个问题的答案就是采用 Kubectl 的 Plugin 机制。 Kubectl 的 Plugin 机制在 v1.8.0 版本的时候就引入了，并且在 v1.12.0 版本中进行了大规模的重构以适应更加复杂多样的场景，并且最终在 v1.14.0 版本中稳定下来。所以你必须使用 Kubectl v1.12.0 及以上版本才可以支持当前的插件命令。 插件命令所谓的插件命令其实很简单，只要符合以下几个特点即可： (1) 该命令是一个可执行的文件； (2) 该命令能够通过 $PATH 搜索到，也就是说如果需要，你必须把这个命令加入到 $PATH 中； (3) 该命令必须以 kubectl- 开头，例如 kubectl-echo 就是一个合法的插件命令名称。 基于以上的要求，我们可以用任何语言去编写这个命令，比如我们最简单的用 C 语言写一个 kubectl-hello 的插件命令尝试下。 #include <stdio.h>intmain(int argc, char *argv[]){ printf("hello, i am a kubelet plugin command\n");}然后我们编译一下： $ gcc -o kubectl-hello kubectl-hello.c然后我们把这个命令所在的目录放到系统的 $PATH 变量中，最后通过 kubectl 命令尝试下。 ...

6月20日，北京，由Rancher Labs主办的【2019企业容器创新大会】限免报名已开启！全天18场演讲，特邀中国人寿、中国联通、平安科技、新东方、阿里云、百度云等著名企业的IT负责人，分享容器技术的企业级落地经验。大会上，Rancher Labs研发经理还将现场Demo即将发布的Rancher 2.3中Istio、Windows容器的功能及使用！还有K3s、Rio等的现场交流。点击http://hdxu.cn/hMsQ8 了解详情及在线报名啦~2019年6月6日，Rancher Labs发布了Rancher全新版本2.2.4，该版本修复了近期发现的两个安全漏洞CVE-2019-12303 和 CVE-2019-12274，项目级别的监控功能也在此版本回归，还有一系列功能与优化。 CVE修复 2.2.4版本包含两个安全漏洞修复 CVE-2019-12303 和 CVE-2019-12274 第一个漏洞会影响v2.0.0到v2.2.3的版本，项目管理员可以在对接日志系统时，通过注入额外的Fluentd配置参数，来读取到Fluentd容器内的文件或执行任意命令，例如其他项目管理员配置的ElasticSearch。 具体链接： https://cve.mitre.org/cgi-bin... 第二个漏洞会影响v1.6.0到v1.6.27（使用Cattle和Kubernetes的用户）以及v2.0.0到v2.2.3的版本。某些内嵌的主机驱动可以配置一个文件路径的参数。通过主机驱动创建主机时，创建者可以通过该漏洞获取Rancher Server内任意容器的内容，例如 /root/.kube/config。这样，主机创建者可以获取Rancher管理平面的访问权限。 具体链接： https://cve.mitre.org/cgi-bin... 功能与优化 项目级别监控回归 AKS集群新增多个区域的支持 RKE AWS集群新增了多个区域的支持 增强了全局DNS对CloudFlare的支持 内置监控新版本，该版本对性能和稳定性进行了增强。 解决了加载含有大规模Kubernetes资源的集群时，Rancher UI加载延迟很大的问题。 https://github.com/rancher/ra... 通过压缩Rancher服务器与Rancher Agent之前的通讯信息，从而优化了性能。 https://github.com/rancher/ra... 其他优化与增强 下面是2.2.4中修复的一些主要的问题，更多详情可以通过下面的链接查看。 https://github.com/rancher/ra... 增强了应用商店稳定性和性能 https://github.com/rancher/ra... https://github.com/rancher/ra... 优化了Rancher性能 https://github.com/rancher/ra... https://github.com/rancher/ra... https://github.com/rancher/ra... 支持激活OTC主机驱动 普通用户可以创建全局DNS OpenStack集成增强 https://github.com/rancher/ra... https://github.com/rancher/ra... etcd快照功能增强 https://github.com/rancher/ra... https://github.com/rancher/ra... https://github.com/rancher/ra... 修复了多集群应用模版删除后无法显示的问题 https://github.com/rancher/ra... ...

1. 跳转原理Jumpserver是个好东西，特别是对于线上设备的管控，基本跳转原理如下图所示。详细的系统设计，可以参考其文档 http ssh [user] <---------> [jumpserver] <----------> [remote machine]然而，随着kubernetes的普及，越来越多的线上服务采用了kubernetes集群部署。如何通过Jumpserver原理进行kubernetes集群管控就是本文要解决的问题。 2. K8S跳转kubernetes的管控原理，和管控远程机器的原理基本类似。只是需要在集群内部部署一个持久的POD, 针对 Jumpserver 该POD能够提供 SSHD 服务，其次该POD内部应该自带 kubectl 工具。 2.1 简单的网络架构图 http ssh /------------------------------------------------\ [user] <---------> [jumpserver] <----------> | [kubectl pod] <=> [ kubernetes resource ] | \------------------------------------------------/ 2.2 构建POD的IMAGE按以上原理，构建中间跳转POD的IMAGE。具体Dockerfile如下: FROM sickp/centos-sshd:latest#安装kubectlRUN curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectlRUN chmod +x ./kubectlRUN mv ./kubectl /usr/local/bin/kubectl#提供默认的ssh keyRUN usermod -p "!" rootADD id_rsa /root/.ssh/id_rsaADD id_rsa.pub /root/.ssh/id_rsa.pubRUN cat /root/.ssh/id_rsa.pub >> /root/.ssh/authorized_keys按此Dockerfile请提前准备好对应的ssh key。并将次IMAGE推送的自己的Docker Registry中。 ...

云厂商托管 Kubernetes 服务的 Pod 域名解析注意事项使用云厂家提供托管式Kubernetes，Pod的域名解析参数，通过界面创建Pod的话，可能厂商界面没有开放dnsConfig配置，采用了一些默认值，在使用时候，需要了解清楚厂商提供的默认配置，否则会存在问题。典型的一个配置是 ndots ，如果你在Pod内访问的域名字符串，点 数量在 ndots 阈值范围内，则被认为是Kubernetes集群内部域名，会被追加 .<namespace>.svc.cluster.local 后缀，这样会导致每次解析域名时候有2次（IP4/IP6）无效解析，在大规模并发场景下存在性能瓶颈。 云厂商一般将Kubernetes的DNS服务（CoreDNS或SkyDNS）与厂商提供的外部DNS级联了，因此这种问题再功能测试阶段不会被暴露，只在性能测试阶段能暴露出来。 DNS查找原理与规则DNS域名解析配置文件 /etc/resolv.conf nameserver 10.247.x.xsearch default.svc.cluster.local svc.cluster.local cluster.localoptions ndots:3参数说明 nameserver 域名解析服务器search 域名的查找后缀规则，查找配置越多，说明域名解析查找匹配次数越多，这里匹配有3个后缀，则查找规则至少6次，因为IPV4,IPV6都要匹配一次options 域名解析选项，多个KV值；其中典型的有 ndots ，访问的域名字符串内的点字符数量超过 ndots 值，则认为是完整域名，直接解析Kubernetes的dnsConfig配置说明Kubernetes官网的dns配置说明 nameservers：将用作Pod的DNS服务器的IP地址列表。最多可以指定3个IP地址。当Pod dnsPolicy 设置为“ None”时，列表必须至少包含一个IP地址，否则此属性是可选的。列出的服务器将合并到从指定的DNS策略生成的基本名称服务器，并删除重复的地址。searches：Pod中主机名查找的DNS搜索域列表。此属性是可选的。指定后，提供的列表将合并到从所选DNS策略生成的基本搜索域名中。删除重复的域名。Kubernetes最多允许6个搜索域。options：可选的对象列表，其中每个对象可以具有name 属性（必需）和value属性（可选）。此属性中的内容将合并到从指定的DNS策略生成的选项中。删除重复的条目dnsPolicy域名解析的几种场景应用对应的容器中的deployment的yaml中的dnsPolicy有三种配置参数ClusterFirst, Default, None Default：Pod从运行pod的节点继承名称解析配置。有关 详细信息，请参阅相关讨论ClusterFirst：任何与配置的群集域后缀不匹配的DNS查询（例如"www.kubernetes.io"）将转发到从该节点继承的上游名称服务器。群集管理员可能配置了额外的存根域和上游DNS服务器。有关 在这些情况下如何处理DNS查询的详细信息，请参阅相关讨论。ClusterFirstWithHostNet：对于使用hostNetwork运行的Pod，您应该明确设置其DNS策略“ ClusterFirstWithHostNet”。None：Kubernetes v1.9（Beta in v1.10）中引入的新选项值。它允许Pod忽略Kubernetes环境中的DNS设置。应使用dnsConfigPod规范中的字段提供所有DNS设置。请参阅下面的DNS配置子部分。1. 场景1-采用自定义DNS采用自己建的DNS来解析Pods中的应用域名配置，可以参考以下代码配置，此配置在Pod中的DNS可以完全自定义，适用于已经有自己建的DNS,迁移后的应用也不需要去修改相关的配置； apiVersion: v1kind: Podmetadata: namespace: default name: dns-examplespec: containers: - name: test image: nginx dnsPolicy: "None" dnsConfig: nameservers: - 1.2.3.4 searches: - ns1.svc.cluster.local - my.dns.search.suffix options: - name: ndots value: "2" - name: edns02. 场景2-采用kubernets的CoreDNS优先使用Kubernetes的DNS服务解析，失败后再使用外部级联的DNS服务解析。 ...

前言Kubernetes（k8s） 凭借着其优良的架构，灵活的扩展能力，丰富的应用编排模型，成为了容器编排领域的事实标准。越来越多的企业拥抱这一趋势，选择 k8s 作为容器化应用的基础设施，逐渐将自己的核心服务迁移到 k8s 之上。 可用性对基础设施而言至关重要。各大云计算厂商纷纷推出了高可用、可扩展的 k8s 托管服务，其中比较有代表性的有 Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine、阿里云容器服务 Kubernetes 版等。 虽然公有云托管的 k8s 服务百花齐放，但很多企业仍有自建集群的需求。正是这样的原因，促进了一大批出色的 k8s 集群部署方案的诞生，他们的特点如下表所示。 部署方案特点Kubeadm1. 官方出品的部署工具，提供了 k8s 集群生命周期管理的领域知识。2. 旨在成为更高级别工具的可组合构建块。 Kubespray1. 支持在裸机和 AWS、GCE、Azure 等众多云平台上部署 k8s。2. 基于 Ansible Playbook 定义 k8s 集群部署任务。3. 支持大部分流行的 Linux 发行版。 || Kops | 1. 仅支持在 AWS、GCE 等少数云平台上部署 k8s。2. 建立在状态同步模型上，用于 dry-run 和自动幂等性。3. 能够自动生成 Terraform 配置。 || Rancher Kubernetes Engine（RKE） | 1. 著名的开源企业级容器管理平台 Rancher 提供的轻量级 k8s 安装工具。2. 支持在裸机、虚拟机、公有云上部署和管理 k8s 集群。 | ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。KubeCon EU 举办2019 年第一个 KubeCon + CloudNativeCon 于 5 月 20 ~ 23 日在巴塞罗那成功举办，这次大会吸引了七千多名参会者远超去年的参会人数。 这也从另一个侧面反映了 Kubernetes 和云原生在大大的普及 在大会上宣布了不少值得关注的信息, 我在此大致列一下我认为值得关注的信息（虽然有些内容之前已经关注到了）： OpenTracing, OpenCensus 合并为 OpenTelemetry；微软推出 Service Mesh Interface（SMI）规范；NGINX Ingress Controller 发布 1.5.0 版本；Google 宣布 GKE 将会支持 Windows Server Container；Helm 3 的发展历程；（推荐阅读我之前写的 初试 Helm 3）当然，大会上公布的信息还有很多，还有一些 CNCF 的计划等，这里暂且不提，感兴趣的朋友可以自行搜索或者参加下个月在上海举办的 KubeCon + CloudNativeCon 微软推出 Service Mesh Interface （SMI）Service Mesh 也是一个趋势，但现在并没有一个统一的规范，各个厂商的实现也都各有不同。微软本次提出的 SMI 主要是为 Kubernetes 服务网格提供通用接口，以便能让 Service Mesh 有更加通用的规范 （就像当初 CNI/CRI 那样子） ...

概要External-DNS提供了编程方式管理Kubernetes Ingress资源的DNS的功能，方便用户从Ingress管理DNS解析记录。而在kubernetes federation v2环境中，使用External-DNS可以快速的管理多个联邦集群的Ingress DNS解析，降低用户的操作成本。下面将简单介绍在阿里云容器服务环境中，如何使用External-DNS管理联邦集群的Ingress DNS解析。 联邦集群准备参考阿里云Kubernetes容器服务上体验Federation v2 搭建两个集群组成的联邦集群（配置好kubeconfig，并完成两个集群的join）。 配置RAM信息选择Kubernetes集群节点列表内任意一个Worker节点，打开对应的节点列表信息页面。 找到对应的 RAM 角色，打开RAM控制台，找到对应的角色名称，添加【AliyunDNSFullAccess】权限。 注意：每个集群都需要配置RAM信息。 部署External-DNS配置RBAC 执行下面yaml： apiVersion: v1kind: ServiceAccountmetadata: name: external-dns---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRolemetadata: name: external-dnsrules:- apiGroups: [""] resources: ["services"] verbs: ["get","watch","list"]- apiGroups: [""] resources: ["pods"] verbs: ["get","watch","list"]- apiGroups: ["extensions"] resources: ["ingresses"] verbs: ["get","watch","list"]- apiGroups: [""] resources: ["nodes"] verbs: ["list"]- apiGroups: ["multiclusterdns.federation.k8s.io"] resources: ["dnsendpoints"] verbs: ["get", "watch", "list"]---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata: name: external-dns-viewerroleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: external-dnssubjects:- kind: ServiceAccount name: external-dns namespace: default部署External-DNS服务 ...

1.概述 Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。 在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理，本文章将介绍Kubernetes平台的安装过程。1.1. 环境准备Kubernetes安装在Ubuntu、CentOS这两个环境上较为稳定，本次安装将以Ubuntu环境为例（CentOS环境也类似），准备两台Ubuntu虚拟机或云服务器，版本为16.04即可。 2.安装Docker&Kubernetes2.1. 安装Docker2.1.1 添加Docker官方源1）更新包索引： apt-get update 2）下载docker官方源的公钥并添加到apt的公钥库中： curl-fsSL https://download.docker.com/l... | apt-key add - 3）添加docker官方源的仓库： add-apt-repository "deb [arch=amd64] https://download.docker.com/l... $(lsb_release -cs) stable" 4）执行完以上命令之后，在/etc/apt/sources.list文件中将添加如下内容 5）再次更新包索引： apt-get update 2.1.1 安装Docker这里以安装docker-ce-17.03.2版本为例：1）执行： apt-get install docker-ce=17.03.2~ce-0~ubuntu-xenial，安装Docker； 2）验证Docker安装结果： dockerversion 3）查看docker后台服务运行的情况： systemctl status docker 至此，Docker安装完成。2.2. 安装Kubernetes2.2.1 Kubernetes相关组件介绍需要下载kubeadm、kubelet、kubectl等组件1） kubeadm：作为安装工具来引导启动集群，kubeadm将kubernetes核心组件以容器化的方式安装和引导启动运行； 2） kubelet：Node组件中的 kubelet依旧以主机后端服务的形式运行kubernetes集群的所有节点上，是主节点与从节点交互的关键组件；3） kubectl：是安装集群后的命令行工具，至少安装在master上，对集群进行管理。 2.2.2 添加Kubernetes的apt源（google官方源）以下将直接添加google的官方源（如果你的服务器不能访问google官方源，请参考2.2.3）1）添加kubernetes apt源的公钥文件： curl-s https://packages.cloud.google... | apt-key add - 2）将官方源列表加入到本地源列表配置目录中： vi /etc/apt/sources.list.d/kubernetes.list，在该文件中加入如下内容： 3）更新本地包缓存：apt-get update 2.2.3 添加Kubernetes的apt源（国内源）1） apt-get update && apt-get install -y apt-transport-https ...

摘要： 将在QCon上分享的《阿里PB级Kubernetes日志平台建设实践》整理出来，分享给大家。阿里PB级Kubernetes日志平台建设实践QCon是由InfoQ主办的综合性技术盛会，每年在伦敦、北京、纽约、圣保罗、上海、旧金山召开。有幸参加这次QCon10周年大会，作为分享嘉宾在刘宇老师的运维专场发表了《阿里PB级Kubernetes日志平台建设实践》，现将PPT和文字稿整理下来，希望和更多的爱好者分享。 计算形态的发展与日志系统的演进 在阿里的十多年中，日志系统伴随着计算形态的发展在不断演进，大致分为3个主要阶段： 在单机时代，几乎所有的应用都是单机部署，当服务压力增大时，只能切换更高规格的IBM小型机。日志作为应用系统的一部分，主要用作程序Debug，通常结合grep等Linux常见的文本命令进行分析。随着单机系统成为制约阿里业务发展的瓶颈，为了真正的Scale out，飞天项目启动：2009年开始了飞天的第一行代码，2013年飞天5K项目正式上线。在这个阶段各个业务开始了分布式改造，服务之间的调用也从本地变为分布式，为了更好的管理、调试、分析分布式应用，我们开发了Trace（分布式链路追踪）系统、各式各样的监控系统，这些系统的统一特点是将所有的日志（包括Metric等）进行集中化的存储。为了支持更快的开发、迭代效率，近年来我们开始了容器化改造，并开始了拥抱Kubernetes生态、业务全量上云、Serverless等工作。要实现这些改造，一个非常重要的部分是可观察性的工作，而日志是作为分析系统运行过程的最佳方式。在这阶段，日志无论从规模、种类都呈现爆炸式的增长，对日志进行数字化、智能化分析的需求也越来越高，因此统一的日志平台应运而生。日志平台的重要性与建设目标 日志不仅仅是服务器、容器、应用的Debug日志，也包括各类访问日志、中间件日志、用户点击、IoT/移动端日志、数据库Binlog等等。这些日志随着时效性的不同而应用在不同的场景： 准实时级别：这类日志主要用于准实时（秒级延迟）的线上监控、日志查看、运维数据支撑、问题诊断等场景，最近两年也出现了准实时的业务洞察，也是基于这类准实时的日志实现。小时/天级别：当数据积累到小时/天级别的时候，这时一些T+1的分析工作就可以开始了，例如用户留存分析、广告投放效果分析、反欺诈、运营监测、用户行为分析等。季度/年级别：在阿里，数据是我们最重要的资产，因此非常多的日志都是保存一年以上或永久保存，这类日志主要用于归档、审计、攻击溯源、业务走势分析、数据挖掘等。在阿里，几乎所有的业务角色都会涉及到各式各样的日志数据，为了支撑各类应用场景，我们开发了非常多的工具和功能：日志实时分析、链路追踪、监控、数据清洗、流计算、离线计算、BI系统、审计系统等等。其中很多系统都非常成熟，日志平台主要专注于智能分析、监控等实时的场景，其他功能通常打通的形式支持。 阿里日志平台现状 目前阿里的日志平台覆盖几乎所有的产品线和产品，同时我们的产品也在云上对外提供服务，已经服务了上万家的企业。每天写入流量16PB以上，对应日志行数40万亿+条，采集客户端200万，服务数千Kubernetes集群，是国内最大的日志平台之一。    为何选择自建                       日志系统存在了十多年，目前也有非常多的开源的方案，例如最典型的ELK(Elastic Search、Logstash、Kibana)，通常一个日志系统具备以下功能：日志收集/解析、查询与检索、日志分析、可视化/告警等，这些功能通过开源软件的组合都可以实现，但最终我们选择自建，主要有几下几点考虑： 数据规模：这些开源日志系统可以很好的支持小规模的场景，但很难支持阿里这种超大规模（PB级）的场景。资源消耗：我们拥有百万规模的服务器/容器，同时日志平台的集群规模也很大，我们需要减少对于采集以及平台自身的资源消耗。多租户隔离：开源软件搭建的系统大部分都不是为了多租户而设计的，当非常多的业务 / 系统使用日志平台时，很容易因为部分用户的大流量 / 不恰当使用而导致打爆整个集群。运维复杂度：在阿里内部有一套非常完整的服务部署和管理系统，基于内部组件实现会具备非常好的运维复杂度。高级分析需求：日志系统的功能几乎全部来源与对应的场景需求，有很多特殊场景的高级分析需求开源软件没办法很好的支持，例如：上下文、智能分析、日志类特殊分析函数等等。 Kubernetes日志平台建设难点围绕着Kubernetes场景的需求，日志平台建设的难点主要有以下几点： 日志采集：采集在Kubernetes中极其关键和复杂，主要因为Kubernetes是一个高度复杂的场景，K8s中有各式各样的子系统，上层业务支持各种语言和框架，同时日志采集需要尽可能的和Kubernetes系统打通，用K8的形式来完成数据采集。资源消耗：在K8s中，服务通常都会拆的很小，因此数据采集对于服务自身的资源消耗要尽可能的少。这里我们简单的做一个计算，假设有100W个服务实例，没个采集Agent减少1M的内存、1%的CPU开销，那整体会减少1TB的内存和10000个CPU核心。运维代价：运维一套日志平台的代价相当之大，因此我们不希望每个用户搭建一个Kubernetes集群时还需再运维一个独立的日志平台系统。因此日志平台一定是要SaaS化的，应用方/用户只需要简单的操作Web页面就能完成数据采集、分析的一整套流程。便捷使用：日志系统最核心的功能是问题排查，问题排查的速度直接决定了工作效率、损失大小，在K8s场景中，更需要一套高性能、智能分析的功能来帮助用户快速定位问题，同时提供一系列简单有效的可视化手段进行辅助。阿里PB级Kubernetes日志平台建设实践Kubernetes日志数据采集 无论是在ITOM还是在未来的AIOps场景中，日志获取都是其中必不可少的一个部分，数据源直接决定了后续应用的形态和功能。在十多年中，我们积累了一套物理机、虚拟机的日志采集经验，但在Kubernetes中不能完全适用，这里我们以问题的形式展开： 问题1：DaemonSet or Sidecar 日志最主要的采集工具是Agent，在Kubernetes场景下，通常会分为两种采集方式： DaemonSet方式：在K8S的每个node上部署日志agent，由agent采集所有容器的日志到服务端。Sidecar方式：一个POD中运行一个sidecar的日志agent容器，用于采集该POD主容器产生的日志。每种采集方式都有其对应的优缺点，这里简单总结如下： DaemonSet方式Sidecar方式采集日志类型标准输出+部分文件文件部署运维一般，需维护DaemonSet较高，每个需要采集日志的POD都需要部署sidecar容器日志分类存储一般，可通过容器/路径等映射每个POD可单独配置，灵活性高多租户隔离一般，只能通过配置间隔离强，通过容器进行隔离，可单独分配资源支持集群规模中小型规模，业务数最多支持百级别无限制资源占用较低，每个节点运行一个容器较高，每个POD运行一个容器查询便捷性较高，可进行自定义的查询、统计高，可根据业务特点进行定制可定制性低高，每个POD单独配置适用场景功能单一型的集群大型、混合型、PAAS型集群在阿里内部，对于大型的PAAS集群，主要使用Sidecar方式采集数据，相对隔离性、灵活性最好；而对与功能比较单一（部门内部/产品自建）的集群，基本都采用DaemonSet的方式，资源占用最低。 问题2：如何降低资源消耗 我们数据采集Agent使用的是自研的Logtail，Logtail用C++/Go编写，相对开源Agent在资源消耗上具有非常大的优势，但我们还一直在压榨数据采集的资源消耗，尤其在容器场景。通常，为了提高打日志和采集的性能，我们都使用本地SSD盘作为日志盘。这里我们可以做个简答的计算：假设每个容器挂载1GB的SSD盘，1个物理机运行40个容器，那每台物理机需要40GB的SSD作为日志存储，那5W物理机则会占用2PB的SSD盘。为了降低这部分资源消耗，我们和蚂蚁金服团队的同学们一起开发了FUSE的日志采集方式，使用FUSE（Filesystem in Userspace，用户态文件系统）虚拟化出日志盘，应用直接将日志写入到虚拟的日志盘中，最终数据将直接从内存中被Logtail采集到服务端。这种采集的好处有： 物理机无需为容器提供日志盘，真正实现日志无盘化。应用程序视角看到的还是普通的文件系统，无需做任何额外改造。数据采集绕过磁盘，直接从内存中将数据采集到服务端。所有的数据都存在服务端，服务端支持横向扩展，对于应用来说他们看到的日志盘具有无线存储空间。问题3：如何与Kubernetes无缝集成 Kubernetes一个非常大的突破是使用声明式的API来完成服务部署、集群管理等工作。但在K8s集群环境下，业务应用/服务/组件的持续集成和自动发布已经成为常态，使用控制台或SDK操作采集配置的方式很难与各类CI、编排框架集成，导致业务应用发布后用户只能通过控制台手动配置的方式部署与之对应的日志采集配置。因此我们基于Kubernetes的CRD（CustomResourceDefinition）扩展实现了采集配置的Operator，用户可以直接使用K8s API、Yaml、kubectl、Helm等方式直接配置采集方式，真正把日志采集融入到Kubernetes系统中，实现无缝集成。 问题4：如何管理百万级Logtail 对于人才管理有个经典的原则：10个人要用心良苦，100个人要杀伐果断，1000个人要甩手掌柜。而同样对于Logtail这款日志采集Agent的管理也是如此，这里我们分为3个主要过程： 百规模：在好几年前，Logtail刚开始部署时，也就在几百台物理机上运行，这个时期的Logtail和其他主流的Agent一样，主要完成数据采集的功能，主要流程为数据输入、处理、聚合、发送，这个时期的管理基本靠手，采集出现问题的时候人工登录机器去看问题。万规模：当越来越多的应用方接入，每台机器上可能会有多个应用方采集不同类型的数据，手动配置的接入过程也越来越难以维护。因此我们重点在多租户隔离以及中心化的配置管理，同时增加了很多控制相关的手段，比如限流、降级等。百万规模：当部署量打到百万级别的时候，异常发生已经成为常态，我们更需要的是靠一系列的监控、可靠性保证机制、自动化的运维管理工具，让这些机制、工具来自动完成Agent安装、监控、自恢复等一系列工作，真正做到甩手掌柜。Kubernetes日志平台架构 上图是阿里Kubernetes日志平台的整体架构，从底到上分为日志接入层、平台核心层以及方案整合层： 平台提供了非常多的手段用来接入各种类型的日志数据。不仅仅只有Kubernetes中的日志，同时还包括和Kubernetes业务相关的所有日志，例如移动端日志、Web端应用点击日志、IoT日志等等。所有数据支持主动Push、被动Agent采集，Agent不仅支持我们自研的Logtail，也支持使用开源Agent（Logstash、Fluentd、Filebeats等）。日志首先会到达平台提供的实时队列中，类似于Kafka的consumer group，我们提供实时数据订阅的功能，用户可以基于该功能实现ETL的相关需求。平台最核心的功能包括： 实时搜索：类似于搜索引擎的方式，支持从所有日志中根据关键词查找，支持超大规模（PB级）。实时分析：基于SQL92语法提供交互式的日志分析方法。机器学习：提供时序预测、时序聚类、根因分析、日志聚合等智能分析方法。流计算：对接各类流计算引擎，例如：Flink、Spark Stream、Storm等。离线分析：对接离线分析引擎，例如Hadoop、Max Compute等。基于全方位的数据源以及平台提供的核心功能，并结合Kubernetes日志特点以及应用场景，向上构建Kubernetes日志的通用解决方案，例如：审计日志、Ingress日志分析、ServiceMesh日志等等。同时对于有特定需求的应用方/用户，可直接基于平台提供的OpenAPI构建上层方案，例如Trace系统、性能分析系统等。下面我们从问题排查的角度来具体展开平台提供的核心功能。 PB级日志查询 排查问题的最佳手段是查日志，大部分人脑海中最先想到的是用 grep 命令查找日志中的一些关键错误信息， grep 是Linux程序员最受欢迎的命令之一，对于简单的问题排查场景也非常实用。如果应用部署在多台机器，那还会配合使用pgm、pssh等命令。然而这些命令对于Kubernetes这种动态、大规模的场景并不适用，主要问题有： 查询不够灵活，grep命令很难实现各种逻辑条件的组合。grep是针对纯文本的分析手段，很难将日志格式化成对应的类型，例如Long、Double甚至JSON类型。grep命令的前提条件是日志存储在磁盘上。而在Kubernetes中，应用的本地日志空间都很小，并且服务也会动态的迁移、伸缩，本地的数据源很可能会不存在。grep是典型的全量扫描方式，如果数据量在1GB以内，查询时间还可以接受，但当数据量上升到TB甚至PB时，必须依赖搜索引擎的技术才能工作。我们在2009年开始在飞天平台研发过程中，为够解决大规模（例如5000台）下的研发效率、问题诊断等问题，开始研支持超大规模的日志查询平台，其中最主要的目标是“快”，对于几十亿的数据也能够轻松在秒级完成。 日志上下文 当我们通过查询的方式定位到关键的日志后，需要分析当时系统的行为，并还原出当时的现场情况。而现场其实就是当时的日志上下文，例如： 一个错误，同一个日志文件中的前后数据一行LogAppender中输出，同一个进程顺序输出到日志模块前后顺序一次请求，同一个Session组合一次跨服务请求，同一个TraceId组合在Kubernetes的场景中，每个容器的标准输出（stdout）、文件都有对应的组合方式构成一个上下文分区，例如Namesapce+Pod+ContainerID+FileName/Stdout。为支持上下文，我们在采集协议中对每个最小区分单元会带上一个全局唯一并且单调递增的游标，这个游标对单机日志、Docker、K8S以及移动端SDK、Log4J/LogBack等输出中有不一样的形式。 为日志而生的分析引擎 ...

k8s中的网络策略主要分为原生 NetworkPolicy 和第三方网络插件提供的网络策略。本文将主要分析原生Networkpolicy的网络策略。 什么是网络策略 网络策略（NetworkPolicy）是一种关于 Pod 间及 Pod 与其他网络端点间所允许的通信规则的规范。NetworkPolicy 资源使用标签选择 Pod，并定义选定 Pod 所允许的通信规则。 k8s中的网络策略由实现了CNI接口的网络插件提供，网络插件监听集群中 NetworkPolicy 资源的创建/删除/更新事件生成对应的规则来控制 Pod 的流量是否放行。 常见的支持 NetworkPolicy 的网络插件有： CalicoCiliumKube-routerRomanaWeave Net默认情况下 Pod 间及 Pod 与其他网络端点间的访问是没有限制的。 如下是一个 NetworkPolicy 定义的例子，该策略的含义是阻止所有流量访问有app=web这个 label 的 Pod。 经常有人会问网络策略要怎么写，或者是这个网络策略代表了什么含义。笔者认为这个问题主要是因为使用者不了解网络策略的省缺行为。 NetworkPolicy 字段含义 NetworkPolicy 这个资源属于命名空间级别的，因此metadata 中的 namespace 不可省略，否则只会对default 命名空间下的满足条件的 Pod 生效。 下面介绍下 NetworkPolicy 中各字段的含义，并说明各字段省缺值及其含义，主要看 Spec 中的字段，podSelector: 必填字段，Pod 的标签选择器，表示该网络策略作用于哪些 Pod。如果为空{}则表示选中本命名空间下所有 Pod。 policyTypes: 可选字段，字符串，策略规则类型， 表示该网络策略中包含哪些类型的策略，可选为"Ingress", "Egress", 或 "Ingress,Egress"。未填时，这个值依据下面的 ingress 和 egress 来定。如果该字段未设置且下面只出现了 ingress，则对 egress 不做限制。如果填了这个值，同时后续没有设定对应的规则，则认为设定的规则对应的流量全部禁止。例如： ...

一.概述cortex：一个支持多租户、水平扩展的prometheus服务。 当时调研cortex其实是因为看到了Weave Cloud这个商业产品中的监控模块介绍，weave也叫weave works，官方地址是：https://cloud.weave.works，是一个专注于容器微服务的paas平台。 WeaveCloud在监控模块最大化利用了Prometheus，并在其基础上添加了很多组件，实现了多租户管理、高可用的监控集群。其使用的核心监控组件就是cortex。 本文主要分享的是cortex的运行机制，关于Weave Cloud的产品定位和功能可以看下后续的文章:[商业方案-weave work]() Cortex是一个CNCF的沙盒项目，目前被几个线上产品使用：Weave Cloud、GrafanaCloud和FreshTracks.io 为什么不直接运行Prometheus，而用Cortex？ ps:来自cortex kubecon大会演讲 作为服务，cortex提供了鉴权和访问控制数据永久保留，状态能够被管理提供持久化、高可用、伸缩性提供更好的查询效率，尤其是长查询二.主要功能针对以上需求，Cortex提供的主要功能或特色如下： 支持多租户：Prometheus本身没有的租户概念。这意味着，它无法对特定于租户的数据访问和资源使用配额，提供任何形式的细粒度控制。Cortex可以从多个独立的prometheus实例中获取数据，并按照租户管理。长期存储：基于远程写入机制，支持四种开箱即用的长期存储系统：AWS DynamoDB、AWS S3、Apache Cassandra和Google Cloud Bigtable。全局视图：提供所有prometheus server 整合后的时间序列数据的单一，一致的“全局”视图。高可用：提供服务实例的水平扩展、联邦集群等最大化利用了Prometheus相似的竞品： Prometheus + InfluxDB：使用InfluxDataPrometheus + Thanos：长期存储、全局视图Timbala：多副本、全局视图，作者是Matt BostockM3DB：自动扩缩容，来自uber产品形态ps:来自weave work上试用监控模块时的截图 1.安装监控的agent: 2.概览视图 3.资源监控面板 4.监控详情页面 5.添加监控 6.配置报警 在k8s集群中部署所需要的yaml列表为： [https://github.com/weaveworks...](https://github.com/weaveworks...) 部署的agent时的脚本内容是： #!/bin/shset -e# Create a temporary file for the bootstrap binaryTMPFILE="$(mktemp -qt weave_bootstrap.XXXXXXXXXX)" || exit 1finish(){ # Send only when this script errors out # Filter out the bootstrap errors if [ $? -ne 111 ] && [ $? -ne 0 ]; then curl -s >/dev/null 2>/dev/null -H "Accept: application/json" -H "Authorization: Bearer $token" -X POST -d \ '{"type": "onboarding_failed", "messages": {"browser": { "type": "onboarding_failed", "text": "Installation of Weave Cloud agents did not finish."}}}' \ https://cloud.weave.works/api/notification/external/events || true fi # Arrange for the bootstrap binary to be deleted rm -f "$TMPFILE"}# Call finish function on exittrap finish EXIT# Parse command-line argumentsfor arg in "$@"; do case $arg in --token=*) token=$(echo $arg | cut -d '=' -f 2) ;; esacdoneif [ -z "$token" ]; then echo "error: please specify the instance token with --token=<TOKEN>" exit 1fi# Notify installation has startedcurl -s >/dev/null 2>/dev/null -H "Accept: application/json" -H "Authorization: Bearer $token" -X POST -d \ '{"type": "onboarding_started", "messages": {"browser": { "type": "onboarding_started", "text": "Installation of Weave Cloud agents has started"}}}' \ https://cloud.weave.works/api/notification/external/events || true# Get distributionunamestr=$(uname)if [ "$unamestr" = 'Darwin' ]; then dist='darwin'elif [ "$unamestr" = 'Linux' ]; then dist='linux'else echo "This OS is not supported" exit 1fi# Download the bootstrap binaryecho "Downloading the Weave Cloud installer... "curl -Ls "https://get.weave.works/bootstrap?dist=$dist" >> "$TMPFILE"# Make the bootstrap binary executablechmod +x "$TMPFILE"# Execute the bootstrap binary"$TMPFILE" "--scheme=https" "--wc.launcher=get.weave.works" "--wc.hostname=cloud.weave.works" "--report-errors" "$@"三.实现原理Cortex与Prometheus的交互图： ...

一.概述Dockbix意为docker+zabbix，即使用zabbix来监控docker容器的插件或者模块，既然有专业的cadvisor、prometheus等容器监控方案，为什么还要用传统的zabbix呢？ 在docker刚出现时，还没有专业的容器监控方案公司已有zabbix的成熟实践，想直接集成到zabbix中(虽然不太优雅)使用zabbix来监控docker有几种方案，比如: 自己写agent，利用docker的api获取stats信息，暴露api接口给zabbix采集使用zabbix的Module，将docker的采集展示集成到现有的zabbix系统中如何使用写APIpython sdk：https://docker-py.readthedocs.io/en/stable/containers.html#docker.models.containers.Container.stats stats(**kwargs)Stream statistics for this container. Similar to the docker stats command.Parameters: decode (bool) – If set to true, stream will be decoded into dicts on the fly. Only applicable if stream is True. False by default.stream (bool) – If set to false, only the current stats will be returned instead of a stream. True by default.Raises: docker.errors.APIError – If the server returns an error.如计算cpu： ...

作者：张文博 Kubernetes（K8s）是一个开源容器编排系统，可自动执行应用程序部署、扩展和管理。它是云原生世界的操作系统。 K8s 或操作系统中的任何缺陷都可能使用户进程存在风险。作为 PingCAP EE（效率工程）团队，我们在 K8s 中测试 TiDB Operator（一个创建和管理 TiDB 集群的工具）时，发现了两个 Linux 内核错误。这些错误已经困扰我们很长一段时间，并没有在整个 K8s 社区中彻底修复。 经过广泛的调查和诊断，我们已经确定了处理这些问题的方法。在这篇文章中，我们将与大家分享这些解决方法。不过，尽管这些方法很有用，但我们认为这只是权宜之策，相信未来会有更优雅的解决方案，也期望 K8s 社区、RHEL 和 CentOS 可以在不久的将来彻底修复这些问题。 Bug #1: 诊断修复不稳定的 Kmem Accounting关键词：SLUB: Unable to allocate memory on node -1 社区相关 Issue: https://github.com/kubernetes/kubernetes/issues/61937https://github.com/opencontainers/runc/issues/1725https://support.mesosphere.com/s/article/Critical-Issue-KMEM-MSPH-2018-0006问题起源薛定谔平台是我司开发的基于 K8s 建立的一套自动化测试框架，提供各种 Chaos 能力，同时也提供自动化的 Bench 测试，各类异常监控、告警以及自动输出测试报告等功能。我们发现 TiKV 在薛定谔平台上做 OLTP 测试时偶尔会发生 I/O 性能抖动，但从下面几项来看未发现异常： TiKV 和 RocksDB 的日志CPU 使用率内存和磁盘等负载信息只能偶尔看到 dmesg 命令执行的结果中包含一些 “SLUB: Unable to allocate memory on node -1” 信息。 问题分析我们使用 perf-tools 中的 funcslower trace 来执行较慢的内核函数并调整内核参数 hung_task_timeout_secs 阈值，抓取到了一些 TiKV 执行写操作时的内核路径信息： ...

Flannel是cereos开源的CNI网络插件，下图flannel官网提供的一个数据包经过封包、传输以及拆包的示意图，从这个图片中可以看出两台机器的docker0分别处于不同的段：10.1.20.1/24 和 10.1.15.1/24 ，如果从Web App Frontend1 pod（10.1.15.2）去连接另一台主机上的Backend Service2 pod（10.1.20.3），网络包从宿主机192.168.0.100发往192.168.0.200，内层容器的数据包被封装到宿主机的UDP里面，并且在外层包装了宿主机的IP和mac地址。这就是一个经典的overlay网络，因为容器的IP是一个内部IP，无法从跨宿主机通信，所以容器的网络互通，需要承载到宿主机的网络之上。 flannel支持多种网络模式，常用的是vxlan、UDP、hostgw、ipip以及gce和阿里云等，vxlan和UDP的区别是：vxlan是内核封包，而UDP是flanneld用户态程序封包，所以UDP的方式性能会稍差；hostgw模式是一种主机网关模式，容器到另外一个主机上容器的网关设置成所在主机的网卡地址，这个和calico非常相似，只不过calico是通过BGP声明，而hostgw是通过中心的etcd分发，所以hostgw是直连模式，不需要通过overlay封包和拆包，性能比较高，但hostgw模式最大的缺点是必须是在一个二层网络中，毕竟下一跳的路由需要在邻居表中，否则无法通行。 在实际的生产环境中，最常用的还是vxlan模式，我们先看工作原理，然后通过源码解析实现过程。 安装的过程非常简单，主要分为两步： 第一步安装flannel yum install flannel 或者通过kubernetes的daemonset方式启动,配置flannel用的etcd地址 第二步配置集群网络 curl -L http://etcdurl:2379/v2/keys/flannel/network/config -XPUT -d value="{\"Network\":\"172.16.0.0/16\",\"SubnetLen\":24,\"Backend\":{\"Type\":\"vxlan\",\"VNI\":1}}"然后启动每个节点的flanned程序。 一、工作原理 1、容器的地址如何分配 Docker容器启动时通过docker0分配IP地址，flannel为每个机器分配一个IP段，配置在docker0上，容器启动后就在本段内选择一个未占用的IP，那么flannel如何修改docker0网段呢？ 先看一下 flannel的启动文件 /usr/lib/systemd/system/flanneld.service [Service]Type=notifyEnvironmentFile=/etc/sysconfig/flanneldExecStart=/usr/bin/flanneld-start $FLANNEL_OPTIONSExecStartPost=/opt/flannel/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/docker文件里面指定了flannel环境变量和启动脚本和启动后执行脚本 ExecStartPost 设置的mk-docker-opts.sh，这个脚本的作用是生成/run/flannel/docker，文件内容如下： DOCKER_OPT_BIP="--bip=10.251.81.1/24"DOCKER_OPT_IPMASQ="--ip-masq=false"DOCKER_OPT_MTU="--mtu=1450"DOCKER_NETWORK_OPTIONS=" --bip=10.251.81.1/24 --ip-masq=false --mtu=1450"而这个文件又被docker启动文件/usr/lib/systemd/system/docker.service所关联， [Service]Type=notifyNotifyAccess=allEnvironmentFile=-/run/flannel/dockerEnvironmentFile=-/etc/sysconfig/docker这样便可以设置docker0的网桥了。 在开发环境中，有三台机器，分别分配了如下网段： host-139.245 10.254.44.1/24 host-139.246 10.254.60.1/24 host-139.247 10.254.50.1/24 2、容器如何通信 上面介绍了为每个容器分配IP，那么不同主机上的容器如何通信呢，我们用最常见的vxlan举例，这里有三个关键点，一个路由，一个arp，一个FDB。我们按照容器发包的过程，逐一分析上面三个元素的作用，首先容器出来的数据包会经过docker0，那么下面是直接从主机网络出去，还是通过vxlan封包转发呢？这是每个机器上面路由设定的。 #ip route show dev flannel.110.254.50.0/24 via 10.254.50.0 onlink10.254.60.0/24 via 10.254.60.0 onlink可以看到每个主机上面都有到另外两台机器的路由，这个路由是onlink路由，onlink参数表明强制此网关是“在链路上”的(虽然并没有链路层路由)，否则linux上面是没法添加不同网段的路由。这样数据包就能知道，如果是容器直接的访问则交给flannel.1设备处理。 flannel.1这个虚拟网络设备将会对数据封包，但下面一个问题又来了，这个网关的mac地址是多少呢？因为这个网关是通过onlink设置的，flannel会下发这个mac地址，查看一下arp表 # ip neig show dev flannel.110.254.50.0 lladdr ba:10:0e:7b:74:89 PERMANENT10.254.60.0 lladdr 92:f3:c8:b2:6e:f0 PERMANENT可以看到这个网关对应的mac地址，这样内层的数据包就封装好了 ...

之前就玩过docker，但是一直不知道怎么把容器运用到生产上。构建一个docker镜像，把他run起来很简单；难的是容器的部署（CICD），容器的网络，数据持久化等。如果我们像之前一样，打包好镜像，通过ssh连接到目标服务器run起来，这和打包成二进制传上去似乎也没多大进步。 k8s就是帮我们解决这些难点的工具。k8s是master-node架构，通过master管理node。首先需要将你的机器组成k8s集群，集群机器的内网应该是连通的，这样你的集群就捆绑成了一个整体由k8s接管了。你只需要准备好配置文件，用k8s的api或cli（命令行）发布镜像即可，k8s会根据你配置的规则来管理容器，应用场景有：一份镜像需要部署多少个容器（replicaSets），服务的升级策略（滚动更新），服务的容灾策略（某个node挂了可以在其他node补上缺失的容器），弹性伸缩（监控CPU等指标达到临界值后自动增加容器）等。 怎么样？是不是觉得很cool，你可能迫不及待的想去把k8s用起来了，可是你打开k8s官方文档大段大段的英文和各种生疏的概念就把你整懵了。你跟着教程敲了一遍，一大堆yaml配置，全是命令行操作，可能你已经被墙给干倒了（天朝ha）；还有一堆概念，什么Pod, Deployment, ReplicaSet, Service都是些啥玩意。可能你花了大半天耐心的把文档过了一遍，觉得这个东西根本落不了地啊，这一大堆配置和命令行，这谁顶得住，k8s这么先进不应该是可视化的点点就完事了吗？我一开始天真的以为k8s dashboard能帮帮我，费了点力气把它装好后，发现只有一些监控数据。 下面我想介绍另一种学习思路，自顶向下的学习。其实你一开始不用了解k8s的各种概念，只需要看看别人是怎么用k8s的就行了（都9102年了，那些很潮的公司都已经玩了很久了）。不是说学东西必须得打好基础吗？自顶向下是个什么鬼？拿学开车举例，你开始只是在路上看到别人开车，很拉风可撩妹，比两轮的安全，不怕风吹雨打的，教练我也要开车；你去报了驾校（看到这里你肯觉得我要忽悠你报培训班），你摸到了车看到别人是咋开的，了解了基本知识你就可以在训练场地慢慢蠕动了（测试环境），你甚至不用了解交规，更不用了解汽车的原理，这些后面可以慢慢补。补好基础了你就可以上路，然后你可能需要了解汽车原理，改装它优化它，再练一练排水渠过弯的技巧，成为一代老司机。 回到正题，我们学k8s同样可以先看看别人是咋用的，再去了解其中细节，掌握它。咋看呢？一大部分公司还没跟上潮流，这时我们可以借助开源和云服务。首先我们的思路没有问题，要便捷的使用k8s我们需要一个可视化管理平台。开源的有rancher、Qihoo360/wayne等，云服务阿里云、腾讯云、AWS都提供容器服务管理后台。 这里就拿rancher开始吧，毕竟开源免费。值得一提的是，阿里云等的容器服务按量积分，master可托管，弄一两天低配node，一天也就几块。 在本地启动rancher容器： sudo docker run -d --restart=unless-stopped -p 8080:80 -p 8443:443 rancher/rancher打开https://127.0.0.1:8443平台，可以看到cluster, node, namespace, member等功能。 下面我们需要准备一个k8s cluster（集群），用minikube可以方便的部署一个本地集群。minikube是通过虚拟机创建集群，支持多种虚拟机，我这里用的virtualBox。启动很简单，一个命令minikube start，困难的是墙，下面贴一下配置代理的脚本： function ministart() { export HTTP_PROXY=http://192.168.99.1:1089 export HTTPS_PROXY=http://192.168.99.1:1089 export NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,192.168.99.0/24,192.168.39.0/24 minikube start \ --docker-env=HTTP_PROXY=$HTTP_PROXY \ --docker-env=HTTPS_PROXY=$HTTPS_PROXY \ --docker-env=NO_PROXY=$NO_PROXY \ --registry-mirror=https://registry.docker-cn.com}注意一下这个ip，不能使用127.0.0.1，因为虚拟机需要使用宿主的代理，虚拟机跟宿主机通讯是使用虚拟网卡创建的网段，默认宿主的ip为192.168.99.1，虚拟机是192.168.99.100。你还得把你的梯子监听的地址改改，127.0.0.1->0.0.0.0，监听所有网卡。同样rancher里的ip也应使用192.168.99.1，这个ip必需是所有集群都能访问到的，如果你是用docker自带的k8s集群，你可以用ifconfig找一个无线网或有线网的ip，反正不能使用127.0.0.1。 minikube下载一些必需镜像后，k8s集群就在虚拟机里启动了，可以使用minikube ssh登录到虚拟机里探查一番。下面我们在rancher里引入集群： 集群引入了之后我们来部署我们第一个app，一个echo-server： 等了一会儿k8s把容器部署好了，上面配置了暴露随机端口值是32192，我们访问192.168.99.100:32192就能看的echo-sever返回的信息了。我们觉得一个pod不够，点击+号，k8s会帮我们做水平扩容启动第二个pod，虽然minikube是但节点的，但是依靠容器的隔离特性，单节点照样能部署多个相同应用。 体验一下rancher的pipline功能，集成了CICD功能，配置好代码仓库后run起来，会启动一个jenkins pod来处理构建，还会建一个内置的镜像仓库，还有个minio存储pod，大概是用来存镜像的。等了好一会儿后，可以看到workloads里example-server部署好了。jenkins和registry都集成了好像挺方便，不过这个镜像如何持久化呢？ ok，下面自行探索一下rancher平台提供的一些页面，有workloads，load blance，service discory，pipline这些部署常用的，还提供报警、日志、监控、用户权限等功能，这就是一个完善的k8s管理平台了，到此你应该了解k8s大概有哪些用处了。 下面你需要再把k8s官方文档捡起来看一看，或者是一本系统介绍k8s的书籍，把你在rancher上用到的功能和k8s的概念对应起来，现在你才能抓住哪些是重点。 一些概念：pod：k8s最小调度单位，可以是一个或多个容器。 service：对内或对外暴露k8s服务。 deployment：pods和replicaSets的控制器，通过deployment配置的规则来管理pods。 三个主要的命令行程序：kubeadm：用了启动k8s集群。 kubelet：需要在所以节点上运行，处理集群内部通讯，类似agent。 ...

Admission Controller介绍Apiserver干的最重要的三个事就是： 认证 : 看是否是合法用户授权 : 看用户具备哪些权限admission controller : 一个调用链，对请求进行控制或修改，比如是否允许这个请求。admission controller非常有用，也是经常会用到的k8s的一个扩展方式，今天在源码级别对其做一下介绍，以及如何自己去开发一个admission controller. 我们的应用场景是：我们希望把所有需要创建的pod都加上一个注解，因为我们早期是通过podpreset给pod注入lxcfs的配置的，但是用户在写yaml文件时很容易忘记加上，所以需要在apiserver上来个自动处理 metadata: name: test-net annotations: initializer.kubernetes.io/lxcfs: "true" # 就是在pod的metadata里加上这个配置默认admission controller已经有很多默认非常有用的admission插件，这里挑几个介绍一下： 名称作用AlwaysPullImages把所有镜像策略都调整成alwaysPull, 多租户安全时比较有用DefaultStorageClass默认存储类型DefaultTolerationSeconds节点notready:NoExecute时的容忍时间，比如有时我们升级kubelet，希望升级时pod不要漂移就会用到DenyEscalatingExec拒绝远程连接容器ExtendedResourceToleration比如我有扩展资源，那么我可以通过它来玷污节点，防止不需要该资源的pod到我的机器上来，如GPULimitRanger在多租户配额时相当有用，如果pod没配额，那么我可以默认给个很低的配额NamespaceAutoProvision这个也非常有用，资源的namespace不存在时就创建一个PodPreset可以对pod进行一些预处理设置ResourceQuota多租户配额时比较重要，看资源是否满足resource quota中的配置alwaysPullImages 介绍多租户时经常会开启这个，强制所有的镜像必须去拉取，因为如果不这样，那么别的租户如果知道了你的镜像名就可以写一个yaml去启动你的镜像，强制拉时犹豫需要image pull secret所以无法拉取你的镜像。 所以这个admission干的事就是把镜像拉取策略都改成alwaysPull： 代码位置： kubernetes/plugin/pkg/admission/alwayspullimages/admission.gofunc (a *AlwaysPullImages) Admit(attributes admission.Attributes, o admission.ObjectInterfaces) (err error) { // 你可以在attibutes里获取到对象的一切信息，用户信息等 if shouldIgnore(attributes) { // 检查一下是不是你关注的object, 比如创建的一个configmap 那么显然可以忽视 return nil } pod, ok := attributes.GetObject().(*api.Pod) // 这里把initContainer和Container的拉取策略都给改了 for i := range pod.Spec.InitContainers { pod.Spec.InitContainers[i].ImagePullPolicy = api.PullAlways } for i := range pod.Spec.Containers { pod.Spec.Containers[i].ImagePullPolicy = api.PullAlways } return nil}# 还提供一个校验接口，看是不是真的都已经被改了func (a *AlwaysPullImages) Validate(attributes admission.Attributes, o admission.ObjectInterfaces) (err error) { pod, ok := attributes.GetObject().(*api.Pod) for i := range pod.Spec.InitContainers { if pod.Spec.InitContainers[i].ImagePullPolicy != api.PullAlways { return admission.NewForbidden(attributes, field.NotSupported(field.NewPath("spec", "initContainers").Index(i).Child("imagePullPolicy"), pod.Spec.InitContainers[i].ImagePullPolicy, []string{string(api.PullAlways)}, ), ) } } ... return nil}然后实现一个注册函数： ...

使用Patch方式更新K8S的 API Objects 一共有三种方式：strategic merge patch, json-patch,json merge patch。关于这三种方式的文字描述区别可看官方文档update-api-object-kubectl-patch。 我在本文中主要会介绍使用client-go的Patch方式，主要包括strategic merge patch和json-patch。不介绍json merge patch的原因，是该方式使用场景比较少，因此不做介绍，如果有同学有兴趣，可做补充。 StrategicMergePatch新增Object值本次示例以给一个node新增一个labels为例，直接上代码： //根据Pod Sn 更新 podfunc UpdatePodByPodSn(coreV1 v1.CoreV1Interface, podSn string, patchData map[string]interface{}) (*apiv1.Pod, error) { v1Pod, err := coreV1.Pods("").Get(podSn, metav1.GetOptions{}) if err != nil { logs.Error("[UpdatePodByPodSn] get pod %v fail %v", podSn, err) return nil, fmt.Errorf("[UpdatePodByPodSn] get pod %v fail %v", podSn, err) } namespace := v1Pod.Namespace podName := v1Pod.Name playLoadBytes, _ := json.Marshal(patchData) newV1Pod, err := coreV1.Pods(namespace).Patch(podName, types.StrategicMergePatchType, playLoadBytes) if err != nil { logs.Error("[UpdatePodByPodSn] %v pod Patch fail %v", podName, err) return nil, fmt.Errorf("[UpdatePodByPodSn] %v pod Patch fail %v", podName, err) } return newV1Pod, nil}注意：上面的PatchData 必须是以 {"metadata":...}的go struct, 如：`map[string]interface{}{"metadata": map[string]map[string]string{"labels": { "test2": "test2", }}}`对应单元测试用例 ...

摘要： 本文整理自talkingdata云架构师徐蓓的分享，介绍了Spark On Kubernetes在TalkingData的实践。众所周知，Spark是一个快速、通用的大规模数据处理平台，和Hadoop的MapReduce计算框架类似。但是相对于MapReduce，Spark凭借其可伸缩、基于内存计算等特点，以及可以直接读写Hadoop上任何格式数据的优势，使批处理更加高效，并有更低的延迟。实际上，Spark已经成为轻量级大数据快速处理的统一平台。Spark作为一个数据计算平台和框架，更多的是关注Spark Application的管理，而底层实际的资源调度和管理更多的是依靠外部平台的支持： Spark官方支持四种Cluster Manager：Spark standalone cluster manager、Mesos、YARN和Kubernetes。由于我们TalkingData是使用Kubernetes作为资源的调度和管理平台，所以Spark On Kubernetes对于我们是最好的解决方案。 如何搭建生产可用的Kubernetes集群部署 目前市面上有很多搭建Kubernetes的方法，比如Scratch、Kubeadm、Minikube或者各种托管方案。因为我们需要简单快速地搭建功能验证集群，所以选择了Kubeadm作为集群的部署工具。部署步骤很简单，在master上执行： kubeadm init在node上执行： kubeadm join --token : --discovery-token-ca-cert-hash sha256:具体配置可见官方文档：https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/。需要注意的是由于国内网络限制，很多镜像无法从k8s.gcr.io获取，我们需要将之替换为第三方提供的镜像，比如：https://hub.docker.com/u/mirrorgooglecontainers/。 网络 Kubernetes网络默认是通过CNI实现，主流的CNI plugin有：Linux Bridge、MACVLAN、Flannel、Calico、Kube-router、Weave Net等。Flannel主要是使用VXLAN tunnel来解决pod间的网络通信，Calico和Kube-router则是使用BGP。由于软VXLAN对宿主机的性能和网络有不小的损耗，BGP则对硬件交换机有一定的要求，且我们的基础网络是VXLAN实现的大二层，所以我们最终选择了MACVLAN。CNI MACVLAN的配置示例如下： { "name": "mynet", "type": "macvlan", "master": "eth0", "ipam": { "type": "host-local", "subnet": "10.0.0.0/17", "rangeStart": "10.0.64.1", "rangeEnd": "10.0.64.126", "gateway": "10.0.127.254", "routes": [ { "dst": "0.0.0.0/0" }, { "dst": "10.0.80.0/24", "gw": "10.0.0.61" } ] }}Pod subnet是10.0.0.0/17，实际pod ip pool是10.0.64.0/20。cluster cidr是10.0.80.0/24。我们使用的IPAM是host-local，规则是在每个Kubernetes node上建立/25的子网，可以提供126个IP。我们还配置了一条到cluster cidr的静态路由10.0.80.0/24，网关是宿主机。这是因为容器在macvlan配置下egress并不会通过宿主机的iptables，这点和Linux Bridge有较大区别。在Linux Bridge模式下，只要指定内核参数net.bridge.bridge-nf-call-iptables = 1，所有进入bridge的流量都会通过宿主机的iptables。经过分析kube-proxy，我们发现可以使用KUBE-FORWARD这个chain来进行pod到service的网络转发： ...

Rancher 2.3.0 Preview 1正式发布，对Kubernetes 1.14 Windows容器提供Preview支持。 近期，Rancher正式宣布提供对Kubernetes 1.14 Windows容器的技术预览等级的支持！ 早在2018年10月Rancher 2.1.0发布时，Rancher就已对Windows容器提供了实验性支持。今年SIG Windows和微软都已经宣布Kubernetes 1.14的Windows Server 2019已生产可用，因此如今，Rancher也马不停蹄发布全新版本Rancher 2.3.0 Preview 1，以支持最新版本的Windows容器（和Kubernetes）！目前该版本仍在技术预览阶段，经历更多的测试和迭代后将正式GA。 业界对Windows容器的需求 不可否认，Windows仍然是数据中心中最受欢迎的操作系统之一。在不同版本的Windows系统上，运行着无数企业的无数工作负载。 随着容器的兴起，DevOps团队已经能够简化并加速其Linux应用程序的交付流程。然而，基于Windows的应用程序仍然需要区别对待。不论是需要快速创建和拆除那些始终在更新着的开发/测试环境，还是将遗留应用程序升级到云端，对Windows容器的支持，一直是近年业界最为需求的技术之一。 Rancher将如何支持Windows容器 在Rancher中创建“自定义”集群的用户，将能看到将Windows或Linux节点添加到其集群的选项。 其中，etcd和控制平面节点只能是Linux节点，Rancher的UI会自动选择该选项。但工作节点可以是Windows或Linux。我们建议用户为其Windows工作负载创建单独的集群。您可能仍需要添加至少一个Linux工作节点（以运行Ingress、Rancher集群代理、metrics server等等）。而Flannel可作为vxlan和主机网关模式的首选网络插件选项。 在Rancher中创建和管理Windows Server 2019容器非常简单。参阅文档的介绍即可快速如何入门。不过，用户仍需注意相关的环境需求以及一些限制： 您需要Docker EE-basic 18.09附带的Windows Server 2019。你还需要Kubernetes 1.14和Rancher 2.3.0 Preview 1版本。对于Windows节点，主机镜像必须与容器基础镜像匹配。这意味着每一次对主机进行大的升级候，都需要您重新创建容器镜像，否则容器可能无法正常运行。Windows容器中的网络通过CNI插件公开。到目前为止，Flannel是唯一支持的网络插件。Rancher内置的基于Prometheus的监控不适用于Windows。Etcd和控制平面节点只能是linux。您还需要至少1个Linux工作程序才能使集群正常运行。结 语 Windows容器的GA，是一个巨大的发展和进步。虽然我们必须承认采用这种技术仍存在许多限制和挑战，但我们也清晰地看到，我们的用户一直在等待其Windows应用程序的容器化和现代化。Rancher 2.3.0对Windows容器的支持，必将让这个旅程更加快速与简单。 Rancher 2.3.0 Preview 1的完整版发行说明和安装步骤，请访问： https://github.com/rancher/ra...

今晚20:30，Kubernetes Master Class在线培训第六期《在Kubernetes中创建高可用应用》即将开播，点击http://live.vhall.com/847710932 即可免费预约注册！ 监控的重要性不言而喻，它让我们能充分了解到应用程序的状况。Kubernetes有很多内置工具可供用户们选择，让大家更好地对基础架构层（node）和逻辑层（pod）有充分的了解。 在本系列文章的第一篇中，我们关注了专为用户提供监控和指标的工具Dashboard和cAdvisor。在本文中，我们将继续分享关注工作负载扩缩容和生命周期管理的监控工具：Probe（探针）和Horizontal Pod Autoscaler（HPA）。同样的，一切介绍都将以demo形式进行。 Demo的前期准备 在本系列文章的上一篇中，我们已经演示了如何启动Rancher实例以及Kubernetes集群。在上篇文章中我们提到过，Kubernetes附带了一些内置的监控工具，包括： Kubernetes dashboard：为集群上运行的资源提供一个概览。它还提供了一种非常基本的部署以及与这些资源进行交互的方法。cAdvisor：一种用于监控资源使用情况并分析容器性能的开源代理。Liveness和Readiness Probe：主动监控容器的健康情况。Horizontal Pod Autoscaler：基于通过分析不同指标所收集的信息，根据需要增加pod的数量。在上篇文章了，我们深度分析了前两个组件Kubernetes Dashboard和cAdvisor，在本文中，我们将继续探讨后两个工具：探针及HPA。 Probe（探针） 健康检查有两种：liveness和readiness。 readiness探针让Kubernetes知道应用程序是否已准备好，来为流量提供服务。只有探针允许通过时，Kubernetes才会允许服务将流量发送到pod。如果探针没有通过，Kubernetes将停止向该Pod发送流量，直到再次通过为止。 当你的应用程序需要花费相当长的时间来启动时，readiness探针非常有用。即使进程已经启动，在探针成功通过之前，该服务也无法工作。默认情况下，Kubernetes将在容器内的进程启动后立即开始发送流量，但是在有readiness探针的情况下，Kubernetes将在应用程序完全启动后再允许服务路由流量。 liveness探针让Kubernetes知道应用程序是否处于运行状态。如果处于运行状态，则不采取任何行动。如果该应用程序未处于运行状态，Kubernetes将删除该pod并启动一个新的pod替换之前的pod。当你的应用程序停止提供请求时，liveness探针非常有用。由于进程仍在运行，因此默认情况下，Kubernetes将继续向pod发送请求。凭借liveness探针，Kubernetes将检测到应用程序不再提供请求并将重新启动pod。 对于liveness和readiness检查，可以使用以下类型的探针： http：自定义探针中最常见的一种。Kubernetes ping一条路径，如果它在200-300的范围内获得http响应，则将该pod标记为健康。command：使用此探针时，Kubernetes将在其中一个pod容器内运行命令。如果该命令返回退出代码0，则容器将标记为健康。tcp：Kubernetes将尝试在指定端口上建立TCP连接。如果能够建立连接，则容器标记为健康。配置探针时，可提供以下参数： initialDelaySeconds：首次启动容器时，发送readiness/liveness探针之前等待的时间。对于liveness检查，请确保仅在应用程序准备就绪后启动探针，否则你的应用程序将会继续重新启动。periodSeconds：执行探针的频率（默认值为10）。timeoutSeconds：探针超时的时间，以秒为单位（默认值为1）。successThreshold：探针成功的最小连续成功检查次数。failureThreshold：放弃之前探针失败的次数。放弃liveness探针会导致Kubernetes重新启动pod。对于liveness探针，pod将被标记为未准备好。Readiness探针的演示 在本节中，我们将使用命令检查来配置readiness探针。我们将使用默认的nginx容器部署两个副本。在容器中找到名为/tmp/healthy的文件之前，不会有任何流量发送到pod。 首先，输入以下命令创建一个readiness.yaml文件： apiVersion: apps/v1kind: Deploymentmetadata: name: readiness-demospec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 readinessProbe: exec: command: - ls - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 ---apiVersion: v1kind: Servicemetadata: name: lbspec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector:> apiVersion: apps/v1kind: Deploymentmetadata: name: readiness-demospec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - image: nginx name: nginx ports: - containerPort: 80 readinessProbe: exec: command: - ls - /tmp/healthy initialDelaySeconds: 5 periodSeconds: 5 ---apiVersion: v1kind: Servicemetadata: name: lbspec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx app: nginx接下来，应用YAML文件： ...

kubeadm部署的kubernets证书一直都是个诟病，默认都只有一年有效期，kubeadm 1.14.x安装后有部分证书还是一年有效期，但个别证书已修改为10年有效期，但对我们使用来说，一年有效期还是一个比较的坑，需要进行调整。修改kubeadm 1.14.x源码，调整证书过期时间kubeadm1.14.x 安装过后crt证书如下所示/etc/kubernetes/pki/apiserver.crt/etc/kubernetes/pki/front-proxy-ca.crt #10年有效期/etc/kubernetes/pki/ca.crt #10年有效期/etc/kubernetes/pki/apiserver-etcd-client.crt/etc/kubernetes/pki/front-proxy-client.crt #10年有效期/etc/kubernetes/pki/etcd/server.crt/etc/kubernetes/pki/etcd/ca.crt #10年有效期/etc/kubernetes/pki/etcd/peer.crt #10年有效期/etc/kubernetes/pki/etcd/healthcheck-client.crt/etc/kubernetes/pki/apiserver-kubelet-client.crt如上所示，除了标注说明的证书为10年有效期，其余都是1年有效期，我们查看下原先调整证书有效期的源码，克隆kubernetes 源码，切换到1.14.1 tag 查看：代码目录： staging/src/k8s.io/client-go/util/cert/cert.go const duration365d = time.Hour * 24 * 365func NewSelfSignedCACert(cfg Config, key crypto.Signer) (*x509.Certificate, error) { now := time.Now() tmpl := x509.Certificate{ SerialNumber: new(big.Int).SetInt64(0), Subject: pkix.Name{ CommonName: cfg.CommonName, Organization: cfg.Organization, }, NotBefore: now.UTC(), //这里已经调整为10年有效期 NotAfter: now.Add(duration365d * 10).UTC(), KeyUsage: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature | x509.KeyUsageCertSign, BasicConstraintsValid: true, IsCA: true, } certDERBytes, err := x509.CreateCertificate(cryptorand.Reader, &tmpl, &tmpl, key.Public(), key) if err != nil { return nil, err } return x509.ParseCertificate(certDERBytes)}如上所示，通过NewSelfSignedCACert这个方法签发的证书都默认为10年有效期了，但这个只影响部分证书，但这样还没满足我们的需求，个别证书的有效期调整，在经过对源码的分析后，找到了如下的逻辑： ...

近日，灵雀云发布了基于OVN的Kubernetes网络组件Kube-OVN，并正式将其在Github上开源。Kube-OVN提供了大量目前Kubernetes不具备的网络功能，并在原有基础上进行增强。通过将OpenStack领域成熟的网络功能平移到Kubernetes，来应对更加复杂的基础环境和应用合规性要求。目前Kube-OVN项目代码已经在Github 上开源，项目地址为：https://github.com/alauda/kub...。项目使用宽松的Apache 2.0 协议，欢迎更多技术开发者和爱好者前去试用和使用。 网络插件那么多，为什么还需要Kube-OVN？ 网络插件千千万，为什么还要开发Kube-OVN？从当前Kubernetes网络现状来看，Kubernetes 网络相关的组件非常分散。例如，CNI 负责基础容器网络，它本身只是个接口标准，社区和市场上都有很多各自的实现；集群内的服务发现网络需要依赖 kube-proxy，而 kube-proxy 又有 iptables 和 ipvs 两种实现；集群内的 DNS 需要依赖额外组件kube-dns 或coredns；集群对外访问的负载均衡器服务需要依赖各个云厂商提供的Cloud-Provider；网络策略的 NetworkPolicy 本身只是一个标准接口，社区中也有各自不同的实现。此外还有 ingress，Kubernetes提供的只是一个标准接口，社区中同样有各自的实现。 分散的网络组件导致容器网络流量被分散到了不同的网络组件上，一旦出现问题需要在多个组件间游走逐个排查。在实际运维过程中网络问题通常是最难排查的，需要维护人员掌握全链路上所有组件的使用、原理以及排查方式。因此，如果有一个网络方案能够将所有数据平面统一，那么出现问题时只需要排查一个组件即可。 其次，现有网络插件种类繁多，但是在落地时会发现，每个网络插件由于覆盖的功能集合不同，很难在所有场景使用同一套方案。为了满足不同的客户需求，很多厂商一度同时支持多种网络方案，给自身带来很大负担。在落地过程中，还发现很多传统的网络方案在容器网络中是缺失的。一些高级功能是所有网络插件都无法满足的，比如：子网划分、vlan 绑定、nat、qos、固定 IP、基于acl的网络策略等等。 现有 Kubernetes网络能力是否足够？答案很明显，如果真的已经做够强大落地的时候就不会出现这么多的问题。从更大格局来看，Kubernetes本质上是提供了一层虚拟化网络。而虚拟化网络并不是一个新问题。在OpenStack社区，虚拟网络已经有了长足的发展，方案成熟，OVS 基本已经成为网络虚拟化的标准。于是，灵雀云开始把目光投向OVS 以及 OVS 的控制器OVN。 OVN 简介 OVS 是一个单机的虚拟网络交换机，同时支持 OpenFlow 可以实现复杂的网络流量编程，这也是网络虚拟化的基础。通过OVS 和 OpenFlow 可以实现细粒度的流量控制。如果做个类比，OVS 相当于网络虚拟化里的 Docker。OVS 只是个单机程序，想生成一个集群规模的虚拟网络就需要一个控制器，这就是 OVN。OVN 和 OVS 的关系就好比 Kubernetes 和 Docker 的关系。OVN 会将高层次的网络抽象转换成具体的网络配置和流表，下发到各个节点的OVS上，实现集群网络的管理。由于 OVN 最初是为 OpenStack 网络功能设计的，提供了大量 Kubernetes 网络目前不存在的功能：L2/L3 网络虚拟化包括：• 分布式交换机，分布式路由器• L2到L4的ACL• 内部和外部负载均衡器• QoS，NAT，分布式DNS• Gateway• IPv4/IPv6 支持此外 OVN 支持多平台，可以在Linux，Windows，KVM，XEN，Hyper-V 以及 DPDK 的环境下运行。综上可以看出 OVN 可以覆盖 CNI, Kube-Proxy, LoadBalancer, NetworkPolicy, DNS 等在内的所有 Kubernetes 网络功能，并在原有基础上有所增强。将之前在OpenStack领域内成熟的网络功能往 Kubernetes 平移，也就诞生了灵雀云的开源项目 Kube-OVN. ...

关于GitOps的介绍，可以参考 GitOps:Kubernetes多集群环境下的高效CICD实践 1. 在 容器服务控制台 创建kubernetes集群1.1 新建Kubernetes集群： 1.2 新建命名空间gitops 我们将会把gitlab和jenkins全部部署到此命名空间下 2. 创建GitLab应用 （可选项，可以对接已有GitLab环境）容器服务控制台上依次点击 市场 -> 应用目录 -> gitlab-ce : 在 参数 中设置externalUrl和gitlabRootPassword后选择gitops命名空间并创建应用，本次实践中 externalUrl 设置为 http://ls-gitlab.example.com/, 如果没有dns解析的话，可以在创建成功后直接使用ip 容器服务控制台上依次点击 路由与负载均衡 -> 服务 查看gitlab应用的访问地址，大约2分钟后可访问gitlab并登陆： 3. 设置GitLab并上传示例源码项目3.1 新建private group application 创建private group application： 3.2 新建并上传private project application-demo 创建private project application-demo， 示例源码地址： https://code.aliyun.com/haoshuwei/application-demo.git 从master新建一个分支latest： 设置master和latest分支只有管理员才能merge和push代码的操作： 3.3 新建private group builds 3.4 新建并上传private project preview-pipeline staging-pipeline production-pipeline preview-pipeline示例源码地址为： https://code.aliyun.com/haoshuwei/preview-pipeline.gitstaging-pipeline示例源码地址为： https://code.aliyun.com/haoshuwei/staging-pipeline.gitproduction-pipeline示例源码地址为： https://code.aliyun.com/haoshuwei/production-pipeline.git上传3个构建项目之前需要替换以下字段：IMAGE_REPO:  应用容器镜像要上传到哪个镜像仓库，镜像仓库地址dingTalkToken： 钉钉通知所使用的钉钉机器人accessTokenFetch Git Repo -> credentialsId : 用于Jenkins拉取git项目的证书名称，需要在Jenkins中创建名为gitlab的证书Fetch Git Repo -> url : Jenkins拉取git repo的url ...

Tekton 是一个功能强大且灵活的 Kubernetes 原生开源框架，用于创建持续集成和交付（CI/CD）系统。通过抽象底层实现细节，用户可以跨多云平台和本地系统进行构建、测试和部署。 本文是基于阿里云Kubernetes服务部署Tekton Pipeline，并使用它完成源码拉取、应用打包、镜像推送和应用部署的实践过程。 Tekton Pipeline中有5类对象,核心理念是通过定义yaml定义构建过程.构建任务的状态存放在status字段中。 其中5类对象分别是：PipelineResouce、Task、TaskRun、Pipeline、PipelineRun。 Task是单个任务的构建过程,需要通过定义TaskRun任务去运行Task。 Pipeline包含多个Task,并在此基础上定义input和output,input和output以PipelineResource作为交付。 PipelineResource是可用于input和output的对象集合。 同样地,需要定义PipelineRun才会运行Pipeline。 1. 在阿里云Kubernetes集群中部署Tekton Pipelinekubectl apply --filename https://storage.googleapis.com/tekton-releases/latest/release.yaml查看Tekton Pipelines组件是否运行正常： $ kubectl -n tekton-pipelines get poNAME READY STATUS RESTARTS AGEtekton-pipelines-controller-6bcd7ff5d6-vzmrh 1/1 Running 0 25htekton-pipelines-webhook-6856cf9c47-l6nj6 1/1 Running 0 25h2. 创建Git Resource， Registry Resource编辑 git-pipeline-resource.yaml : apiVersion: tekton.dev/v1alpha1kind: PipelineResourcemetadata: name: git-pipeline-resourcespec: type: git params: - name: revision value: tekton - name: url value: https://code.aliyun.com/haoshuwei/jenkins-demo.gitgit repo的分支名称为 tekton 。 编辑 registry-pipeline-resource.yaml : apiVersion: tekton.dev/v1alpha1kind: PipelineResourcemetadata: name: registry-pipeline-resourcespec: type: image params: - name: url value: registry.cn-hangzhou.aliyuncs.com/haoshuwei/tekton-demo容器镜像仓库地址为 registry.cn-hangzhou.aliyuncs.com/haoshuwei/tekton-demo， 标签为 latest ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。Docker Hub 只读维护在上周的推送中，有写到 Docker Hub 用户隐私数据泄漏。受此事件影响，5 月 4 日 Docker Hub 进行升级维护，在此期间 Docker Hub 有一段时间处于只读模式，包括自动构建等服务不可用；在最后有小于 15 分钟的完全宕机时间，服务完全不可用。 如果只是看事情表面的话，可能这就是一个由于发现“安全问题”而进行的升级/维护；但如果仔细考虑下，作为云原生服务，升级为何会有宕机的情况，为何会有服务完全不可用的时候？ 摘录一段来自本次维护的公告内容： Q: Is this maintenance related to recent Docker Hub data breach?A: While we discovered unauthorized access to a single Hub database storing a subset of non-financial user data last week, which has since been remediated, we are always looking at ways to improve and enhance our security practices to protect our customers and their data. The planned maintenance for Docker Hub on Saturday May 4 is a proactive step we are taking to provide the best possible customer experience and highest level of security ...

在Mac上安装Minikube 1.0最近这几年，软件开发翻天覆地的变化，当个软件行业从业者，不学习新东西肯定是不行的。从微服务到容器化服务开发，其实并没有多长时间，随着Docker和Kubenetes的大热，还必须要跟上脚步才行，做一个程序员真不容易，做一个老程序员更难。 Docker和Kubenetes是什么，我这里就不介绍了，比我了解这玩意的的人，大有人在，如果你想了解，请自我学习，本文结尾也推荐了《IBM微讲堂 Kubenetes》系列，一共十个视频，看一遍基本也就都懂了。如果你开发微服务想控制和容器编排工具有互动，比如调用K8s的API之类，或者你想本Mac地装一个单机版本的K8s，我也走了一些弯路，没少浪费时间。K8s安装是一个不小的工程，但是我并不是一个很好的运维，也仅仅在开发层面了解K8s，所以装一个单机版本非常有必要，这里推荐你去安装Minikube，这就是一个单机版本的单节点K8s。其实本来就想一个安装记录，但是估计也有不少人会遇到安装的问题，那我就稍微写详细一点，帮助大家稍微少走一点弯路。 安装Minikube第一步，你先要越过GFW，至于什么是GFW怎么越过去这里就不详细说了。Minikube需要你本地装有VirtualBox，推荐你下载一个比较新的版本，因为要在上面运行一个虚拟机来跑K8s的节点。 修改网络配置我用的软件是ShadowsocksX-NG这个软件，早期版本并不支持代理，后期版本使用了privoxy实现了HTTP和Socks，但是本文只需要使用HTTP代理就好了。 首先修改进入Performance中，把Advance中的Socks5地址和HTTP中的监听地址都改为0.0,0,0就Ok了，这样你就能接收非本地的请求代理访问ss了。 安装Mac下安装太容易了，别告诉我你没有brew。 brew cask install minikube大功告成。 下载安装kubectl ，需要手工该权限，这是K8s的命令行控制工具 curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.14.0/bin/darwin/amd64/kubectlsudo mv kubectl /usr/local/bin/chmod +x /usr/local/bin/kubectl安装完Minikube 先测试下网络环境，下面命令正常说明代理服务没问题 curl -x 192.168.99.1:1087 http://baidu.com启动用下面命令，让K8s节点的docker，使用下面代理访问，insecure-registry详解见本文末尾扩展阅读 minikube start --docker-env HTTP_PROXY=http://192.168.99.1:1087 --docker-env HTTPS_PROXY=http://192.168.99.1:1087 --docker-env NO_PROXY=127.0.0.1/24 --insecure-registry=192.168.99.1:5000见到下面log为启动成功。 ???? minikube v1.0.0 on darwin (amd64)???? Downloading Kubernetes v1.14.0 images in the background ...???? Creating virtualbox VM (CPUs=2, Memory=2048MB, Disk=20000MB) ...???? "minikube" IP address is 192.168.99.105???? Configuring Docker as the container runtime ... ▪ env HTTP_PROXY=http://192.168.99.1:1087 ▪ env HTTPS_PROXY=http://192.168.99.1:1087 ▪ env NO_PROXY=127.0.0.1/24???? Version of container runtime is 18.06.2-ce⌛ Waiting for image downloads to complete ...E0503 17:26:45.170139 5798 start.go:209] Error caching images: Caching images for kubeadm: caching images: caching image /Users/freewolf/.minikube/cache/images/k8s.gcr.io/k8s-dns-dnsmasq-nanny-amd64_1.14.13: fetching remote image: Get https://k8s.gcr.io/v2/: dial tcp 74.125.203.82:443: i/o timeout✨ Preparing Kubernetes environment ...❌ Unable to load cached images: loading cached images: loading image /Users/freewolf/.minikube/cache/images/gcr.io/k8s-minikube/storage-provisioner_v1.8.1: stat /Users/freewolf/.minikube/cache/images/gcr.io/k8s-minikube/storage-provisioner_v1.8.1: no such file or directory???? Pulling images required by Kubernetes v1.14.0 ...???? Launching Kubernetes v1.14.0 using kubeadm ... ⌛ Waiting for pods: apiserver proxy etcd scheduler controller dns???? Configuring cluster permissions ...???? Verifying component health .....???? kubectl is now configured to use "minikube"???? Done! Thank you for using minikube!中间的错误信息说明本地的cache中没有所需文件都要连接互联网拉取。中间时间很长需要20分钟，因为要下载1g的内容。 ...

Kubernetes 自带了一个默认调度器kube-scheduler，其内置了很多节点预选和优选的调度算法，一般调度场景下可以满足要求。但是在一些特殊场景下，默认调度器不能满足我们复杂的调度需求。我们就需要对调度器进行扩展，以达到调度适合业务场景的目的。 背景 中间件redis容器化后，需要两主不能在同一个节点上，一对主从不能在同一节点上；elasticsearch容器化后，两个data实例不能在同一节点上。在这类场景下，默认调度器内置的预选、优选算法不能满足需求，我们有以下三种选择： 将新的调度算法添加到默认调度程序中，并重新编译镜像，最终该镜像运行的实例作为kubernetes集群调度器； 参考kube-scheduler实现满足自己业务场景的调度程序，并编译镜像，将该程序作为独立的调度器运行到kubernetes集群内，需要用该调度器调度的pod实例，在spec.schedulerName里指定该调度器； image实现“调度扩展程序“：默认调度器kube-scheduler在进行预选时会调用该扩展程序进行过滤节点；在优选时会调用该扩展程序进行给节点打分，或者在bind操作时，调用该扩展器进行bind操作。 对上述三种方式进行评估： 第一种：将自己的调度算法添加到默认调度器kube-scheduler中，对原生代码侵入性较高，而且随着kubernetes版本升级，维护成本也较高； 第二种：默认调度器里内置了很多优秀调度算法，如：检查节点资源是否充足；端口是否占用；volume是否被其他pod挂载；亲和性；均衡节点资源利用等，如果完全使用自己开发的调度器程序，可能在达到了实际场景调度需求同时，失去更佳的调度方案，除非集成默认调度器中的算法到自己独立调度程序中，但这无疑是不现实的； 第三种：通过启动参数的policy配置，选用某些默认调度器中的预选、优选调度算法的同时，也可以调用外部扩展调度程序的算法，计算得到最优的调度节点，无需修改kube-scheduler代码，只需要在启动参数中增加配置文件即可将默认调度程序和扩展调度程序相互关联。 可以参考： https://github.com/kubernetes... 故采用第三种：实现扩展调度程序的方案。 整体架构 imagekube-scheduler在调度pod实例时，首先获取到Node1、Node2、Node3三个节点信息，进行默认的预选阶段，筛选满足要求的节点，其次再调用扩展程序中的预选算法，选出剩下的节点，假设预选阶段Node3上资源不足被过滤掉，预选结束后只剩Node1和Node2；Node1和Node2进入kube-scheduler默认的优选阶段进行节点打分，其次再调用扩展调度程序中的优选算法进行打分，kube-scheduler会将所有算法的打分结果进行加权求和，获得分数最高的节点作为pod最终bind节点，然后kube-scheduler调用apiserver进行bind操作。 实现步骤 实现扩展调度程序代码 编写扩展调度器程序代码，根据实际业务调度场景编写预选逻辑、优选逻辑： image实现预选接口，入参为schedulerapi.ExtenderArgs，出参为schedulerapi.ExtenderFilterResult： image实现优选接口，入参为schedulerapi.ExtenderArgs，出参为schedulerapi.HostPriorityList： image暴露http接口： image参考： https://github.com/ll83744879... 默认调度器部署 由于kubernetes集群内已经有了一个名为default-scheduler的默认调度器，为了不影响集群正常调度功能，下面会创建一个名为my-kube-scheduler的调度器，这个调度器和default-scheduler除了启动参数不一样外，镜像无差别。 1、创建一个名为my-scheduler-config的configmaps，data下的config.yaml文件指定了调度器的一些参数，包括leader选举，调度算法策略的选择（指定另一个configmaps），以及指定调度器的名称为my-kube-scheduler。 相应的创建一个my-scheduler-policy的configmaps，里面指定了选择哪些预选、优选策略，以及外部扩展调度程序的urlPrefix、扩展预选URI、扩展优选URI、扩展pod优先级抢占URI、扩展bind URI、扩展优选算法的权重等。 以保证my-kube-scheduler和扩展调度程序的通信。 apiVersion: v1kind: ConfigMapmetadata: name: my-scheduler-config namespace: kube-systemdata: config.yaml: | apiVersion: kubescheduler.config.k8s.io/v1alpha1kind: KubeSchedulerConfigurationschedulerName: my-kube-scheduleralgorithmSource: policy: configMap: namespace: kube-system name: my-scheduler-policyleaderElection: leaderElect: false lockObjectName: my-kube-scheduler lockObjectNamespace: kube-systemapiVersion: v1kind: ConfigMapmetadata: name: my-scheduler-policy namespace: kube-systemdata: policy.cfg : | { "kind" : "Policy","apiVersion" : "v1","predicates" : [ {"name" : "PodFitsHostPorts"}, {"name" : "PodFitsResources"}, {"name" : "NoDiskConflict"}, {"name" : "MatchNodeSelector"}, {"name" : "HostName"}],"priorities" : [ {"name" : "LeastRequestedPriority", "weight" : 1}, {"name" : "BalancedResourceAllocation", "weight" : 1}, {"name" : "ServiceSpreadingPriority", "weight" : 1}, {"name" : "EqualPriority", "weight" : 1}],"extenders" : [{ "urlPrefix": "http://10.168.107.12:80/scheduler", "filterVerb": "predicates/always_true", "prioritizeVerb": "priorities/zero_score", "preemptVerb": "preemption", "bindVerb": "", "weight": 1, "enableHttps": false, "nodeCacheCapable": false}],"hardPodAffinitySymmetricWeight" : 10}2、在my-kube-scheduler yaml文件中将configmaps：my-scheduler-config以文件的形式挂载到容器内/my-scheduler目录下，并在启动参数中指定--config=/my-scheduler/config.yaml，使用和默认调度器一样的镜像。 ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。Docker Hub 用户隐私数据泄漏2019 年 4 月 25 日，Docker Hub 团队发现了对存储非财务用户数据子集的单个 Hub 数据库的未授权访问。 在发现异常后官方团队迅速采取行动并保护网站免受攻击。 经过官方团队的调查，目前大概有 190000 帐号的敏感信息（小于总用户数的 5% ）包括用户名和哈希后的用户密码，当然也包括 GitHub 及 Bitbucket 等的用于自动构建的 Token 。 当前的主要措施是对可能被泄漏信息的用户发送了邮件通知，对于可能泄漏哈希密码的用户发送了重置密码的邮件，并且 主动 将密码失效，以及自动构建的 Token 也都被失效。( 所以如果你收到了 Docker Hub 团队关于此次事件的直接报告邮件，很大概率是因为你的信息已经被泄漏了 ) 附上官方声明中关于此次事件的处理声明： During a brief period of unauthorized access to a Docker Hub database, sensitive data from approximately 190,000 accounts may have been exposed (less than 5% of Hub users). Data includes usernames and hashed passwords for a small percentage of these users, as well as GitHub and Bitbucket tokens for Docker autobuilds. ...

美国时间2019年4月24日，业界领先的容器软件提供商Rancher Labs（以下简称Rancher）正式发布k3OS，这是业界首个专为Kubernetes而生的极轻量操作系统，资源消耗极低，操作极简，秒级启动，能大大简化在低资源计算环境中的Kubernetes操作，提高Kubernetes运维的安全性，全面赋能边缘计算场景。 k3OS 与 k3s，完美搭档 k3OS，和Rancher不久前发布的k3s（史上最轻量Kubernetes发行版）是完美搭档。Rancher于今年2月底发布的k3s，是史上最轻量的Kubernetes发行版，专为在资源有限的环境中运行Kubernetes的研发和运维人员设计，满足在边缘计算环境中运行在x86、ARM64和ARMv7处理器上的小型、易于管理的Kubernetes集群日益增长的需求。K3S极简、轻便、易用，自发布之日起便受到了大量的关注，短短不到2个月时间，GitHub已有近6500颗星。 本次发布的k3OS，则是k3s在易用性及安全性上的更进一步，为k3s的用户提供更简洁有效的交互方式和操作体验。在k3OS中，Kubernetes集群配置和底层的OS配置都使用同样的语法方式，这种方式类似Kubernetes中的CRD。如此一来，研发人员和运维人员将可以同时安装和升级k3s及底层操作系统。与此同时，k3OS还将让研发人员和运维人员能真正从“基础设施即代码（infrastructure-as-code）”模式当中受益，从而实现可靠的、可重复的集群部署。这种操作方法将大大简化管理员的使用体验，同时也让k3s在低配的计算环境中保持安全性。 “虽然Kubernetes可以安装在任何的Linux发行版上，但将Kubernetes与底层操作系统分开进行系统补丁或升级的话，操作会很复杂。系统服务中的错误配置或安全漏洞，可能会危及到整个Kubernetes集群。而k3OS的用户永远不必担心计划外的操作系统升级，只需一步即可将安全补丁应用于整个软件堆栈。”Rancher联合创始人及CEO梁胜表示：“作为Linux系统和Kubernetes发行版的组合，相较于业界所有Kubernetes安装，在k3OS上运行的k3s拥有最小的攻击面，以及最简单的升级过程。” 首个Kubernetes操作系统，为边缘计算而生 k3OS可以用于公有云和虚拟化集群，但除此之外，它在以边缘计算为代表的计算资源极其有限的环境中，尤其具有巨大的价值。 金风慧能作为全球第二大风力发电机制造商，自去年起，一直与Rancher在全新轻量级Kubernetes发行版k3s的开发上密切合作。我们相信如今发布的k3OS，是技术发展的下一步，它有助于我们在全球数千个边缘位置实现全自动和高度安全的Kubernetes集群的愿景。——金风慧能副总经理 张伟k3OS的主要功能包括： 快速安装：k3OS只需10秒即可启动，且与此同时k3s是无需时间、立即可用的。简化配置：Cloud-init支持在系统引导启动期间自动配置k3s，将其从通用镜像快速轻松地转换为已配置的k3s实例。简化系统补丁和升级：管理员可以通过一组通用的YAML文件管理Kubernetes发行版和Linux发行版，并利用Kubernetes协调部署操作系统升级。内置k3s：k3OS中内置了k3s，必要的一些系统服务（如ssh、udev、bash和iptables等）都已内置于分发镜像中，无需包管理器。Ubuntu内核：Rancher借助Canonical的Ubuntu Server Kernel团队的出色工作，确保及时的安全更新和全面的设备支持。多架构支持：k3OS现已支持x86_64，对ARM的支持也将很快完成。GitLab为整个DevOps生命周期提供了完整的解决方案。通过与k3OS和k3s合作，GitLab将持续投身云原生技术，使用户通过单一操作流程即可控制Kubernetes和Linux的部署和配置。GitLab无比期待和更多客户一起实现k3OS和k3s的落地部署。——GitLab联盟副总裁 Brandon Jung一切开源，欢迎使用 k3OS官网主页现已上线，您可以访问 https://k3os.io了解k3OS项目的...。 同时，欢迎通过GitHub https://github.com/rancher/k3...。 需要协助部署和管理k3OS的企业请邮件联系 info@rancher.com。 About Rancher Labs Rancher Labs由硅谷云计算泰斗、CloudStack之父梁胜创建，致力于打造创新的开源软件，帮助企业在生产环境中运行容器与Kubernetes。旗舰产品Rancher是一个开源的企业级Kubernetes平台，是业界首个且唯一可以管理所有云上、所有发行版、所有Kubernetes集群的平台。解决了生产环境中企业用户可能面临的基础设施不同的困境，改善Kubernetes原生UI易用性不佳以及学习曲线陡峭的问题，是企业落地Kubernetes的不二之选。 Rancher在全球拥有超过一亿的下载量，超过20000家企业客户。全球知名企业如中国人寿、华为、中国平安、民生银行、兴业银行、上汽集团、海尔、米其林、天合光能、丰田、本田、霍尼韦尔、金风科技、普华永道、海南航空、厦门航空、恒大人寿、中国太平、巴黎银行、美国银行、HSCIS恒生指数、中国水利、暴雪、CCTV等均是Rancher的付费客户。

Kubernetes 证书配置大全证书是网络通信的安全的要素，是现代网络通信的基本配置。各种远程调用的安全都离不开非对称加密提供的保障。 下载证书工具cfssl 是 CloudFlare 开源的一款PKI/TLS工具。 CFSSL 包含一个命令行工具(cfssl, cfssljson)用于签名，验证并且捆绑TLS证书的 HTTP API 服务。 使用Go语言编写。与 OpenSSL 相比，cfssl 使用起来更简单。 Github 地址： https://github.com/cloudflare...官网地址： https://pkg.cfssl.org/ 如果有golang环境，用go安装很简单 $ go get -u github.com/cloudflare/cfssl/cmd/cfssl$ go get -u github.com/cloudflare/cfssl/cmd/cfssljsoncfssljson 实用程序 大部分 cfssl 的输出为 JSON 格式。cfssljson 可以将输出拆分出来为独立的key，certificate，CSR 和 bundle文件。该工具需要指定参数，-f 指定输入文件，后接一个参数，指定生成的文件的基本名称。如果输入文件名是 -（默认值），则 cfssljson 从标准输入读取。它以下列方式将 JSON 文件中的键映射到文件名： 如果指定了cert或certificate， 将生成basename.pem。如果指定了key 或private_key，则将生成basename-key.pem。如果指定了csr 或certificate_request，则将生成basename.csr。如果 指定了bundle， 则将生成basename-bundle.pem。如果指定了ocspResponse， 则将生成basename-response.der。 您可以传递-stdout输出编码内容到标准输出，而不是保存到文件。验证证书有效期cfssl certinfo -cert /etc/kubernetes/ssl/ca.pem |grep not_aftercfssl certinfo -cert /etc/kubernetes/ssl/admin.pem |grep not_aftercfssl certinfo -cert /etc/kubernetes/ssl/kubernetes.pem |grep not_aftercfssl certinfo -cert /etc/kubernetes/ssl/kube-proxy.pem |grep not_after生成新证书证书分四类 ...

简述Kubernetes 是一种用于在一组主机上运行和协同容器化应用程序的系统，提供应用部署、规划、更新维护的机制。应用运行在 kubernetes 集群之上，实现服务的扩容、缩容，执行滚动更新以及在不同版本的应用程序之间调度流量以测试功能或回滚有问题的部署。Kubernetes 实现管理服务的各项功能是通过定义各种类型的资源来实现的，如 deployment、pod、service、volume 等。下面通过该文章来简述 pod 的基础信息并详述 pod 的生命周期。 Pod简介Pod 是 kubernetes 系统的基础单元，是由用户创建或部署的最小组件，也是 kubernetes 系统上运行容器化应用的资源对象。Kubernetes 集群中其他资源对象都是为 pod 这个资源对象做支撑来实现 kubernetes 管理应用服务的目的。 Kubernetes 集群组件主要包括主节点组件API Server、Controller Manager、Scheduler 以及子节点组件 kubelet、container Runtime（如docker）、kube-proxy 等。从与集群各组件交互角度讲述 pod 的创建、运行、销毁等生命周期，Pod 生命周期中的几种不同状态包括pending、running、succeeded、failed、Unknown。 与API Server交互API Server 提供了集群与外部交互的接口，通过 kubectl 命令或者其他 API 客户端提交 pod spec 给 API Server 作为pod创建的起始。 Pod 与 API Server 交互的主要流程如下： API Server 在接收到创建pod的请求之后，会根据用户提交的参数值来创建一个运行时的pod对象。根据 API Server 请求的上下文的元数据来验证两者的 namespace 是否匹配，如果不匹配则创建失败。Namespace 匹配成功之后，会向 pod 对象注入一些系统数据，如果 pod 未提供 pod 的名字，则 API Server 会将 pod 的 uid 作为 pod 的名字。API Server 接下来会检查 pod 对象的必需字段是否为空，如果为空，创建失败。上述准备工作完成之后会将在 etcd 中持久化这个对象，将异步调用返回结果封装成 restful.response，完成结果反馈。至此，API Server 创建过程完成，剩下的由 scheduler 和 kubelet 来完成，此时 pod 处于 pending 状态。与scheduler交互当提交创建 pod 的请求与 API Server 的交互完成之后，接下来由 scheduler 进行工作，该组件主要是完成 pod 的调度来决定 pod 具体运行在集群的哪个节点上。注意，此处声明一点，API Server 完成任务之后，将信息写入到 etcd 中，此时 scheduler 通过 watch 机制监听到写入到 etcd 的信息然后再进行工作。 ...

今晚20:30，Kubernetes Master Class在线培训第四期《企业如何构建CI/CD流水线》即将开播，点击链接：http://live.vhall.com/729465809 即可免费预约注册！ 介 绍 Kubernetes在GitHub上拥有超过48,000颗星，超过75,000个commit，拥有以Google为代表的科技巨头公司为主要贡献者。可以说，Kubernetes已迅速掌管了容器生态系统，成为容器编排平台的真正领导者。 Kubernetes提供了诸如部署的滚动和回滚、容器健康检查、自动容器恢复、基于指标的容器自动扩展、服务负载均衡、服务发现（适用于微服务架构）等强大功能。在本文中，我们将讨论Kubernetes重要的基本概念、master节点架构，并重点关注节点组件。 理解Kubernetes及其抽象 Kubernetes是一个开源的编排引擎，用于自动部署、扩展、管理和提供托管容器化应用程序的基础架构。在基础架构级别，Kubernetes集群由一组物理或虚拟机组成，每个机器都以特定角色运行。 Master机器就像是所有业务的大脑，负责编排所有运行在节点机器上的容器。每个节点都配有一个容器运行时。节点接收来自master的指令，然后执行操作来创建pod、删除pod或调整网络规则。 Master组件负责管理Kubernetes集群。它们管理pod的生命周期，pod是Kubernetes集群内部署的基本单元。Master Server运行以下组件： kube-apiserver - 主要组件，为其他master组件公开API。etcd - 分布式密钥/值存储库，Kubernetes使用它来持久化存储所有集群信息。kube-scheduler – 依照pod规范中的信息，来决定运行pod的节点。kube-controller-manager - 负责节点管理（检测节点是否出现故障）、pod复制和端点创建。cloud-controller-manager - 守护进程，充当API和不同云提供商工具（存储卷、负载均衡器等）之间的抽象层。节点组件是Kubernetes中的worker机器，受到master的管理。节点可以是虚拟机（VM）或物理机器——Kubernetes在这两种类型的系统上都能良好运行。每个节点都包含运行pod的必要组件： kubelet – 为位于那个节点上的pod监视API服务器，确保它们正常运行cAdvisor - 收集在特定节点上运行着的pod的相关指标kube-proxy - 监视API服务器，实时获取pod或服务的变化，以使网络保持最新容器运行时 - 负责管理容器镜像，并在该节点上运行容器Kubernetes节点组件详解 总而言之就是，节点上运行着两个最重要的组件——kubelet和kube-proxy，除此之外还有一个负责运行应用容器化应用程序的容器引擎。 kubelet kubelet处理着master和在其上运行的节点之间的所有通信。它以manifest的形式接收来自主设备的命令，manifest定义着工作负载和操作参数。它与负责创建、启动和监视pod的容器运行时进行接合。 kubelet还会周期性地对配置的活跃度探针和准备情况进行检查。它会不断监视pod的状态，并在出现问题时启动新实例。kubelet还有一个内部HTTP服务器，在端口10255上显示一个只读视图。除此之外，在/healthz上还有一个健康检查端点，以及一些其他状态端点。例如，我们可以在/pods获取正在运行的pod的列表。我们还可以在/spec获取kubelet正在运行的机器的详情。 kube-proxy kube-proxy组件在每个节点上运行，负责代理UDP、TCP和SCTP数据包（它不了解HTTP）。它负责维护主机上的网络规则，并处理pod、主机和外部世界之间的数据包传输。它就像是节点上运行着的pod的网络代理和负载均衡器一样，通过在iptables使用NAT实现东/西负载均衡。 kube-proxy过程位于连接到Kubernetes的网络和在该特定节点上运行的pod之间。它本质上是Kubernetes的核心网络组件，负责确保跨集群的所有元素有效地进行通信。当用户创建Kubernetes服务对象时，kube-proxy实例会负责将该对象转换为位于worker节点的、本地iptables规则集上的有意义的规则。iptables用于将分配给服务对象的虚拟IP转换为服务映射的所有pod IP。 容器运行时 容器运行时负责从公有或私有镜像仓库中拉取镜像，并根据这些镜像运行容器。当下最流行的容器引擎无疑是Docker，不过Kubernetes还支持诸如rkt、runc等的其他容器运行时。正如我们在上文中提到过的，kubelet会直接与容器运行时交互，以启动、停止或删除容器。 cAdvisor cAdvisor是一个开源代理，它能够监视资源使用情况并分析容器的性能。cAdvisor最初由谷歌创建，现在已与kubelet集成。 位于每个节点上的cAdvisor实例，会收集、聚合、处理和导出所有正在运行的容器的指标，如CPU、内存、文件和网络使用情况等。所有数据都将发送到调度程序，以确保调度程序了解节点内部的性能和资源使用情况。这些信息会被用于执行各种编排任务，如调度、水平pod扩展、管理容器资源限制等。 从动手实操了解节点组件端点 接下来，我们将安装一个Kubernetes集群（在Rancher的帮助下），以此来开始探索节点组件公开的一些API。要完成下面的操作，我们需要： Google Cloud Platform帐户（任何公有云也都是一样的）一台主机，后续Rancher会运行在它上面（可以是个人PC / Mac或公有云中的VM）在同一主机上，安装kubectl和 Google Cloud SDK。验证好您的相关credential（gcloud init和gcloud auth login），确保gcloud能正常访问您的Google Cloud账户在GKE上运行的Kubernetes集群（运行EKS或AKS也是相同的）启动Rancher实例 首先，启动Rancher实例。这一过程非常简单，参考快速上手指南即可： https://rancher.com/quick-start/ 使用Rancher部署GKE集群 使用Rancher设置和配置Kubernetes集群，同样是按指南进行操作即可： https://rancher.com/docs/ranc... ...

排查完全陌生的问题，完全不熟悉的系统组件，是售后工程师的一大工作乐趣，当然也是挑战。今天借这篇文章，跟大家分析一例这样的问题。排查过程中，需要理解一些自己完全陌生的组件，比如systemd和dbus。但是排查问题的思路和方法基本上还是可以复用了，希望对大家有所帮助。 问题一直在发生I'm NotReady 阿里云有自己的Kubernetes容器集群产品。随着Kubernetes集群出货量的剧增，线上用户零星的发现，集群会非常低概率地出现节点NotReady情况。据我们观察，这个问题差不多每个月，就会有一两个客户遇到。在节点NotReady之后，集群Master没有办法对这个节点做任何控制，比如下发新的Pod，再比如抓取节点上正在运行Pod的实时信息。 需要知道的Kubernetes知识 这里我稍微补充一点Kubernetes集群的基本知识。Kubernetes集群的“硬件基础”，是以单机形态存在的集群节点。这些节点可以是物理机，也可以是虚拟机。集群节点分为Master和Worker节点。Master节点主要用来负载集群管控组件，比如调度器和控制器。而Worker节点主要用来跑业务。Kubelet是跑在各个节点上的代理，它负责与管控组件沟通，并按照管控组件的指示，直接管理Worker节点。 当集群节点进入NotReady状态的时候，我们需要做的第一件事情，肯定是检查运行在节点上的kubelet是否正常。在这个问题出现的时候，使用systemctl命令查看kubelet状态，发现它作为systemd管理的一个daemon，是运行正常的。当我们用journalctl查看kubelet日志的时候，发现下边的错误。 什么是PLEG 这个报错很清楚的告诉我们，容器runtime是不工作的，且PLEG是不健康的。这里容器runtime指的就是docker daemon。Kubelet通过直接操作docker daemon来控制容器的生命周期。而这里的PLEG，指的是pod lifecycle event generator。PLEG是kubelet用来检查容器runtime的健康检查机制。这件事情本来可以由kubelet使用polling的方式来做。但是polling有其成本上的缺陷，所以PLEG应用而生。PLEG尝试以一种“中断”的形式，来实现对容器runtime的健康检查，虽然实际上，它同时用了polling和”中断”两种机制。 基本上看到上边的报错，我们可以确认，容器runtime出了问题。在有问题的节点上，通过docker命令尝试运行新的容器，命令会没有响应。这说明上边的报错是准确的. 容器runtimeDocker Daemon调用栈分析 Docker作为阿里云Kubernetes集群使用的容器runtime，在1.11之后，被拆分成了多个组件以适应OCI标准。拆分之后，其包括docker daemon，containerd，containerd-shim以及runC。组件containerd负责集群节点上容器的生命周期管理，并向上为docker daemon提供gRPC接口。 在这个问题中，既然PLEG认为容器运行是出了问题，我们需要先从docker daemon进程看起。我们可以使用kill -USR1 <pid>命令发送USR1信号给docker daemon，而docker daemon收到信号之后，会把其所有线程调用栈输出到文件/var/run/docker文件夹里。 Docker daemon进程的调用栈相对是比较容易分析的。稍微留意，我们会发现大多数的调用栈都类似下图中的样子。通过观察栈上每个函数的名字，以及函数所在的文件（模块）名称，我们可以看到，这个调用栈下半部分，是进程接到http请求，做请求路由的过程；而上半部分则进入实际的处理函数。最终处理函数进入等待状态，等待的是一个mutex实例。 到这里，我们需要稍微看一下ContainerInspectCurrent这个函数的实现，而最重要的是，我们能搞明白，这个函数的第一个参数，就是mutex的指针。使用这个指针搜索整个调用栈文件，我们会找出，所有等在这个mutex上边的线程。同时，我们可以看到下边这个线程。 这个线程上，函数ContainerExecStart也是在处理具体请求的时候，收到了这个mutex这个参数。但不同的是，ContainerExecStart并没有在等待mutex，而是已经拿到了mutex的所有权，并把执行逻辑转向了containerd调用。关于这一点，我们可以使用代码来验证。前边我们提到过，containerd向上通过gRPC对docker daemon提供接口。此调用栈上半部分内容，正是docker daemon在通过gRPC请求来呼叫containerd。 Containerd调用栈分析 与输出docker daemon的调用栈类似，我们可以通过kill -SIGUSR1 <pid>命令来输出containerd的调用栈。不同的是，这次调用栈会直接输出到messages日志。 Containerd作为一个gRPC的服务器，它会在接到docker daemon的远程请求之后，新建一个线程去处理这次请求。关于gRPC的细节，我们这里其实不用关注太多。在这次请求的客户端调用栈上，可以看到这次调用的核心函数是Start一个进程。我们在containerd的调用栈里搜索Start，Process以及process.go等字段，很容易发现下边这个线程。 这个线程的核心任务，就是依靠runC去创建容器进程。而在容器启动之后，runC进程会退出。所以下一步，我们自然而然会想到，runC是不是有顺利完成自己的任务。查看进程列表，我们会发现，系统中有个别runC进程，还在执行，这不是预期内的行为。容器的启动，跟进程的启动，耗时应该是差不对的，系统里有正在运行的runC进程，则说明runC不能正常启动容器。 什么是DbusRunC请求Dbus 容器runtime的runC命令，是libcontainer的一个简单的封装。这个工具可以用来管理单个容器，比如容器创建，或者容器删除。在上节的最后，我们发现runC不能完成创建容器的任务。我们可以把对应的进程杀掉，然后在命令行用同样的命令尝试启动容器，同时用strace追踪整个过程。 分析发现，runC停在了向带有org.free字段的dbus写数据的地方。那什么是dbus呢？在Linux上，dbus是一种进程间进行消息通信的机制。 原因并不在Dbus 我们可以使用busctl命令列出系统现有的所有bus。如下图，在问题发生的时候，我看到客户集群节点Name的编号非常大。所以我倾向于认为，dbus某些相关的数据结构，比如Name，耗尽了引起了这个问题。 Dbus机制的实现，依赖于一个组件叫做dbus-daemon。如果真的是dbus相关数据结构耗尽，那么重启这个daemon，应该是可以解决这个问题。但不幸的是，问题并没有这么直接。重启dbus-daemon之后，问题依然存在。 在上边用strace追踪runC的截图中，我提到了，runC卡在向带有org.free字段的bus写数据的地方。在busctl输出的bus列表里，显然带有这个字段的bus，都在被systemd使用。这时，我们用systemctl daemon-reexec来重启systemd，问题消失了。所以基本上我们可以判断一个方向：问题可能跟systemd有关系。 Systemd是硬骨头Systemd是相当复杂的一个组件，尤其对没有做过相关开发工作的同学来说，比如我自己。基本上，排查systemd的问题，我用到了四个方法，（调试级别）日志，core dump，代码分析，以及live debugging。其中第一个，第三个和第四个结合起来使用，让我在经过几天的鏖战之后，找到了问题的原因。但是这里我们先从“没用”的core dump说起。 没用的Core Dump 因为重启systemd解决了问题，而这个问题本身，是runC在使用dbus和systemd通信的时候没有了响应，所以我们需要验证的第一件事情，就是systemd不是有关键线程被锁住了。查看core dump里所有线程，只有以下一个线程，此线程并没有被锁住，它在等待dbus事件，以便做出响应。 ...

介 绍在这篇文章中，我们将介绍如何将GitLab的Auto DevOps功能与Rancher管理的Kubernetes集群连接起来，利用Rancher v2.2.0中引入的授权集群端点的功能。通过本文，你将能全面了解GitLab如何与Kubernetes集成，以及Rancher如何使用授权集群端点简化这一集成工作的流程。本文非常适合Kubernetes管理员、DevOps工程师，或任何想将其开发工作流与Kubernetes进行集成的人。 背 景什么是GitLab Auto DevOps？Auto DevOps是在GitLab 10.0中引入的功能，它让用户可以设置自动检测、构建、测试和部署项目的DevOps管道。将GitLab Auto DevOps与Kubernetes集群配合使用，这意味着用户可以无需配置CI / CD资源和其他工具，即可以部署应用程序。 什么是Rancher的授权集群端点？从v2.2.0开始，Rancher引入了一项名为Authorized Cluster Endpoint的新功能，用户可以直接访问Kubernetes而无需通过Rancher进行代理。在v2.2.0之前，如果要直接与下游Kubernetes集群通信，用户必须从各个节点手动检索kubeconfig文件以及API服务器地址。这不仅增加了操作的复杂度，而且还没有提供一种机制来控制通过Rancher管理集群时可用的细化权限。 从Rancher v2.2.0开始，部署Rancher管理的集群时，默认情况下会启用授权群集端点（ACE）功能。ACE将部分Rancher身份验证和授权机制推送到下游Kubernetes集群，允许Rancher用户直接连接到这些集群，同时仍遵守安全策略。 如果您已为某些项目中的某个用户明确授予了权限，则当该用户使用授权集群端点进行连接时，这些权限能自动生效应用。现在，无论用户是通过Rancher还是直接连接到Kubernetes集群，安全性都能得到保障。 授权集群端点功能的相关文档对此有更详细的说明： https://rancher.com/docs/ranc... 注意目前，授权集群端点功能暂时仅适用于使用Rancher Kubernetes Engine（RKE）启动的下游Kubernetes进群。 前期准备要将GitLab Auto DevOps与Rancher管理的Kubernetes集群进行对接，您需要实现准备好： 一个GitLab.com帐户，或一个自托管GitLab实例上的帐户（需已启用AutoDevOps）：GitLab.com帐户需要已经配置好了AutoDevOps。如果您使用的是自托管GitLab实例，则可以参考这一GitLab文档了解如何启用AutoDevOps：https://docs.gitlab.com/ee/to...运行版本v2.2.0或更高版本的Rancher实例：您可以以单节点模式启动Rancher（https://rancher.com/quick-start/），也可以创建HA安装（https://rancher.com/docs/ranc...）。Rancher管理的Kubernetes集群：您还需要一个通过RKE配置的、Rancher上管理的集群。此外，集群中需要有一个管理员用户，如果您使用的是GitLab.com，则需要通过公共网络访问控制平面节点。设置Rancher和Kubernetes首先，我们需要先将Rancher和Kubernetes设置好。该过程的第一部分主要涉及收集信息。 注意为简单起见，这些步骤使用的是Rancher中默认的admin帐户。最佳实践要求您使用独立用户执行此类过程，并限制该用户对正在集成GitLab的集群的权限。 登录Rancher并导航到要集成的下游集群。在本演示中，我们将在EC2实例上创建一个名为testing的集群，该集群在Amazon中运行： 在集群的仪表板上，单击顶部的Kubeconfig File按钮。这将打开kubeconfig集群的文件，其中包括授权集群端点的信息。 kubeconfig文件中的第一个条目是通过Rancher服务器的集群端点。向下滚动以标识此集群的授权群集端点，该集群列为单独的集群条目： 在我的示例中，此集群的名称是testing-testing-2，并且端点server是AWS提供的公共IP。 复制server和certificate-authority-data字段的值，不包括引号，并保存它们。 在kubeconfig文件中进一步向下滚动并找到您的用户名和token： 复制token字段（不包括引号）并保存。 接下来解码证书授权机构数据的base64版本，将其转换回原始版本并保存。根据您的工具，一些可行的选项包括： 设置GitLab项目通过我们从Rancher收集的信息，我们现在可以配置GitLab了。我们将首先在GitLab中创建一个新项目，该项目将使用Auto DevOps功能与我们的Kubernetes集群集成。 首先，登录GitLab，然后选择New Project。 在“新建项目”页面上，选择“从模板创建”选项卡。这将为您提供要使用的模板项目列表。选择NodeJS Express，然后单击“Use template”： 为项目命名，并将“可见性级别”设置为“ 公共”。完成后单击“ 创建项目”。 注意在我撰写本文时，可见性级别可以设为“私密”，不过这是GitLab的Auto DevOps实验性功能。 在项目页面左侧的菜单窗格中，选择“设置”>“CI / CD”。展开“ 环境变量”部分，并设置以下变量： 我们这次会禁用下图这些功能，因为我们的简单示例暂时不需要它们，并且它们会延长部署所需的时间。在实际项目中，您可以根据您的实际需求启用其中一些选项： 单击“ 保存变量”以完成GitLab项目配置。 连接GitLab和Rancher现在，我们已准备好将我们的GitLab项目与Rancher管理的Kubernetes集群集成。 ...

转发请注明出处：https://www.cnblogs.com/guang... 1. 介绍最近，因为需要对 Kubernetes 进行二次开发，接触了 client-go 库。client-go 作为官方维护的 go 语言实现的 client 库，提供了大量的高质量代码帮助开发者编写自己的客户端程序，来访问、操作 Kubernetes 集群。 在学习过程中我发现，除了官方的几个 examples 和 README 外，介绍 client-go 的文章较少。因此，这里有必要总结一下我的学习体会，分享出来。 访问 Kubernetes 集群的方式有多种（见 Access Clusters Using the Kubernetes API ），但本质上都要通过调用 Kubernetes REST API 实现对集群的访问和操作。比如，使用最多 kubernetes 命令行工具 kubectl，就是通过调用 Kubernetes REST API 完成的。当执行 kubectl get pods -n test 命令时， kubectl 向 Kubernetes API Server 完成认证、并发送 GET 请求： GET /api/v1/namespaces/test/pods---200 OKContent-Type: application/json{ "kind": "PodList", "apiVersion": "v1", "metadata": {"resourceVersion":"10245"}, "items": [...]}那么如何编写自己的 http 客户端程序呢？ 这就需要 Kubernetes 提供的 Golang client 库。 ...

本周三晚20:30，Kubernetes Master Class在线培训第四期《企业如何构建CI/CD流水线》即将开播，点击 http://live.vhall.com/729465809 即可免费预约注册！ 3月26日，Rancher 2.2正式GA，这是Rancher Labs迄今为止最重要的产品版本，Rancher 2.2中创造性的新功能，包括用于灾备和恢复的etcd自动备份和恢复，用于提高敏感项目隐私的多租户应用程序目录，以及为跨多个集群的应用程序提供高可用性的Global DNS功能等等，将极大简化IT运维人员对企业级Kubernetes的配置与管理工作，同时让企业IT开发人员对其应用程序拥有更强把控。 在过去的20多天里，Rancher Labs的研发及测试团队对Rancher 2.2的性能、稳定性、安全性等进一步进行了大量的测试，修复开源社区用户在GitHub提的重要issue，本周正式发布了Rancher 2.2.2版本，这是2.2.x第一个带上stable标签的版本，意味着它是Rancher 官方推荐所有用户用于生产环境的稳定版！ Rancher 2.2功能亮点 Rancher Global DNS 用户可以将应用程序部署到任意数量的集群，而Rancher Global DNS将自动配置和维护与应用程序的Kubernetes Ingress的IP地址对应的外部DNS记录，从而完成DNS记录的自动添加或更改。Rancher 2.2 GA版支持Route53、AliDNS以及CloudFlare。 用于灾备和恢复的etcd自动备份和恢复 Rancher会从Rancher UI/API或Kubernetes API执行etcd的预定和临时备份，写入本地存储、NFS或任何与S3兼容的对象库。出现意外情况时，用户通过UI，即可简单快速地将这些备份直接还原到集群当中。 对Kubernetes多集群、多租户的进阶版监控 Rancher 2.2是业界唯一一个在多集群、多租户环境中支持Prometheus和Grafana的解决方案，集成好的Prometheus和Grafana让用户可以通过简单的UI操作，即可让监控覆盖从每个项目中的集群节点到Pod的所有内容。 单一应用跨多Kubernetes集群的部署与管理 用户可以将某个应用无缝部署到任意数量的多个Kubernetes集群中，并进行统一的管理、升级、回滚和版本控制等，并可以和CI/CD系统或其他任何自动配置程序一起开箱即用。 多租户应用程序目录 为应用目录程序提供了特定于集群和项目的配置，用户可以按集群或项目对应用程序目录进行精细的隔离。 Rancher 2.2.2的重点关注 Rancher CVE-2019-11202修复 我们发现过一个问题：Rancher首次启动时创建的默认管理员帐户将在Rancher的后续重新启动时重新创建，即使Rancher管理员明确删除了该帐户，也仍会如此。这会带来一定的安全风险，因为帐户是使用Rancher的默认用户名和密码重新创建的。因此，攻击者可以使用这些默认账号密码来获取对Rancher Server的管理员访问权限。 此问题会影响以下版本的Rancher：v2.0.0-v2.0.13，v2.1.0-v2.1.8和v2.2.0-2.2.1。 现在，Rancher v2.2.2中提供了CVE-2019-11202的修复程序。Rancher v2.2.2中，Rancher在重新启动时将不会再重新创建一个管理员帐户。针对版本v2.1.x和v2.0.x的修复程序将在不久后发布。不过不用担心的是，对于所有的Rancher版本，只要通过禁用默认管理员帐户而不是完全删除它，就可以不受此漏洞影响。 通过UI轮换集群证书 在Rancher 2.2.2中，用户通过UI操作即可完成集群证书轮换了！在Rancher 2.0和2.1中，Rancher配置集群的自动生成证书的有效期为1年。这意味着如果您在大约1年前创建了Rancher配置集群，那么1年后需要轮换证书，否则证书过期后集群将进入错误状态。现在，2.2.2的用户在UI上即可完成轮换工作，再也无需过去繁复的操作了。 Rancher研发团队也将尽快为Rancher 2.0和2.1用户提供后端端口解决方案，这样2.0和2.1的用户也可以在现有集群上轮换证书了。 对Kubernetes v1.14.1的实验性支持 Rancher v2.2.2中实现了对Kubernetes v1.14.1的实验性支持。这也为我们在后期更新版本中对Windows的支持提供了途径。上个月Kubernetes的最新版本v1.14发布，是第一个对Windows节点正式提供生产级别支持的Kubernetes版本。 UI和API的性能提升 Rancher v2.2.2中，UI和API的性格都得到了大幅优化。项目相关的资源API调用（特别是pod）所需的加载时间大幅减短，页面在极短的时间内即可用。 其他的修复或更新 修复了无法为AWS中国区域添加节点模板的问题。出于稳定性考虑，暂时移除了项目级别的监控，将在下一个版本中重新添加；集群级别的监控不受此影响。修复了发布目录模板可能因证书错误而失败的问题。修复了用于与独立Rancher服务器通信的自签名证书可能过期的情况。修复了Rancher配置集群状态在带有前缀补丁的集群中被错误提取的问题。结 语 更多关于Rancher v2.2.2中问题修复、升级与回滚等等的内容，请参考GitHub上Rancher v2.2.2的完整Release Note： ...

要使用和维护Kubernetes集群，最常用且直接的方式，就是使用自带的命令行工具Kubectl。这里梳理下常用的子命令及参数，方便查找参考。 参考文档：Overview of kubectlkubectl.docskubernetes-handbookkubectl概述祭出一张图，转载至kubernetes-handbook/kubectl命令概述，可以对命令族有个整体的概念。 环境准备kubectl安装后，默认是没有比如自动补全等功能的，频繁使用比较不方便。目前已经有各类kubectl小工具可以提高效率，还有kubectl专用的shell了。个人感觉比较好用有以下这些： 自动补全kubectl 命令在bash中默认是没有自动补全的，需要安装bash_completion，添加自动补全脚本。这里以CentOS为例，其他操作系统配置可以参看Install and Set Up kubectl # 安装bash-completionyum install -y epel-release.noarchyum install -y bash_completion# 添加补全脚本kubectl completion bash >/etc/bash_completion.d/kubectl重新登录shell，可以发现kubectl的子命令，包括资源名称都可以用Tab键自动补全了: 快速切换集群和Namespace生产环境一般是多集群，至少也是多NS的环境，免不了经常在不同集群和不同NS间切换。切换集群要修改环境变量、切换NS要在命令跟上 -n namespace，都不是太方便。而用kubectx和kubens两个小工具可以实现快速切换。这俩在同一项目里：ahmetb/kubectx # 安装sudo git clone https://github.com/ahmetb/kubectx /opt/kubectxsudo ln -s /opt/kubectx/kubectx /usr/local/bin/kubectxsudo ln -s /opt/kubectx/kubens /usr/local/bin/kubens# 使用kubectx# kubectx : 列出所有上下文# kubectx <NAME> : 切换到某个上下文$ kubectx minikubeSwitched to context "minikube".# kubectx - : 切换回上一个上下文$ kubectx -Switched to context "oregon".# kubectx <NEW_NAME>=<NAME> : 重命名一个集群上下文$ kubectx dublin=gke_ahmetb_europe-west1-b_dublinContext "dublin" set.Aliased "gke_ahmetb_europe-west1-b_dublin" as "dublin".# kubectx <NEW_NAME>=. : 重命名当前上下文# kubectx -d <NAME> : 删除上下文# 使用kubens# kubens : 列出所有的NS# kubens <NS-NAME> : 切换当前NS$ kubens kube-systemContext "test" set.Active namespace is "kube-system".# kubens - : 切换回上一个NS$ kubens -Context "test" set.Active namespace is "default".关于多集群切换的配置和上下文的概念可以参看官方文档，有中文。 ...

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。Prometheus v2.9.0 正式发布Prometheus 是 CNCF 毕业项目，可用于监控系统及服务状态。它整体是使用 Pull 的模式，在周期时间内采集目标的 metrics ，并且提供了 PromQL 的查询语言，以供对监控数据进行查询过滤等操作。并且可以通过配置规则来触发报警等。我首次接触 Prometheus 大概是在 2015 年 0.15.0 版本左右，当时 Prometheus 还处于比较早期的阶段，不过在进入 CNCF 后，Prometheus 基本就成为了 K8S 监控的实施标准了，并且多数软件也都增加了对 Prometheus metrics 的支持。 v2.9.0 的主要更新： 从 2.8 开始引入了的从 WAL 读取进行 remote write 有时候会丢数据的问题已经得到修复；Kubernetes 和 OpenStack 在服务发现时候增加了更多元数据；Consul 现在支持多 tag；添加了一个 honor_timestamps 的选项；TLS 证书会自动从磁盘加载；日志也变的更易读；其他更新请阅读 ReleaseNote Linkerd 2.3 正式发布Linkerd 是一个 service mesh 旨在提供平台范围的可观察性，可靠性和安全性，而无需用户更改代码。在本月初的周报推送中，推荐了一篇关于 Linkerd v2 从产品中吸取的教育和经验的文章，Linkerd v2 使用 Go 和 Rust 进行了重写，并因此获得了巨大的收益。 ...

在2019年2月“ China Summary Translation: 'Market Guide for Container Management Software'”的报告中，Gartner认为，在中国市场，容器技术的使用是近期的热点。本地厂商由于能够贴近客户实际需求，而在选择中占据优势，例如阿里云、灵雀云等中国本地厂商。 Gartner容器市场指南 报告中Gartner指出，到2020年，全球50%以上的企业将在生产环境中运行容器。容器的普及程度将在未来18到24个月内持续上升。 随着容器技术的日渐成熟，客户在部署微服务平台时，往往会考虑容器落地。但是，由于其快速敏捷的特点，容器的数量会在快速扩展时急剧上升，大大增加了技术管理的复杂度。原来虚拟机的管理方式已经无法应对容器管理，很多客户使用容器管理软件来协助管理大规模的容器集群。 在中国市场，容器技术的使用是近期的热点。目前，主要是互联网公司在大规模部署使用容器技术，但在生产环境中部署超过50个容器的大型企业案例并不多见。Gartner认为，本地厂商由于能够贴近客户实际需求，而在选择中占据优势，例如，阿里云、灵雀云等中国本地厂商。 Gartner给出几个关键结论： 应用开发者是容器技术的主要使用者，但容器管理软件供应商越来越多地将基础设施和运营（I&O） 作为目标领域，以开发企业级市场机会。 容器编排能力十分关键，需要重点考虑，但是选择解决方案时也须考虑其他方面的能力，如应用生命周期集成、策略管理、监控、安全、存储、网络、治理以及应用编程接口（API）和管理用户界面（UI）功能。 很多供应商强调多云的主要优势，尝试将软件作为支持多云环境部署和工作负载可移动性的层结构来提供，以减少公有云锁定。现在判断这种部署模式是否会成功，还为时尚早。 应用开发和运营领域的发展日益完善，这些领域与容器技术有很大的互补性，包括： 应用开发——DevOps将不断推动面向CI / CD模型的交付最佳实践。应用架构——组件化云原生设计, 包括网格应用和服务架构(MASA)，miniservices和microservices，正在不断发展。基础设施管理——作为最佳实践的不可变的基础设施发展。云计算的采用还在继续，自服务、自动化和水平可伸缩组件将成为标准。 Gartner指出，针对内部定制开发的容器技术兴趣在不断增加，市场上将出现更多的供应商。其中许多供应商都有一些“遗产”，如应用程序发布自动化，持续配置自动化或PaaS。ISV也将增加对容器的使用，这要求企业具有支持容器的基础设施。一些早期采用的企业已经拥有了自己的容器堆栈。但是，大多数组织没有广泛或深度的专业知识来自己做。他们需要解决方案层面的意见。例如，用本地容器工具，还是从PaaS发展而来的工具？这没有好坏之分，取决于开发人员所希望的抽象级别。 关于容器的未来 为了解容器当前和未来的状态，国外研究分析师 Tom Smith近期收集了30余位积极使用容器技术的IT高管的见解。大家一致的观点认为：容器继续成熟，采用率上升，复杂度下降，Serverless兴起。 成熟 我们期待与AI，AR和VR一起使用更多的技术，随着人们使用AI轻松地开发、部署和管理容器，容器将会被大量采用和创新，会有更多的计算能力来更快地完成任务。 预计会有越来越多的人采用，容器在企业中已经被高度渗透。CNCF表示容器已经有60%-70%的部署，但是运行在Kubernetes上的计算工作负载占比要低得多。因此，Kubernetes还有巨大的增长机会。 越来越多的公司将会发现容器的好处，不仅因为可以使用容器来构建新的应用程序，而且真正开始重构现有的应用程序，并有效利用底层平台提供的水平可伸缩性等功能。企业从谈论云和容器转向在生产中使用容器，容器的使用成为主流。与此同时，围绕安全性和合规性的思考也将改变。 容器在容器编排和调度环境中提供了更好的状态管理，以及更好的执行时间，以支持无服务器的用例。 容器使用率将继续增长。推动新技术快速部署的能力不容忽视，容器的快速部署、管理和短生命周期的快速发展将推动新功能的开发。公司不得不跟上容器技术环境的快速变化，安全、编排和开发等领域都充斥着破坏的机会! 未来，容器将作为企业应用部署和管理的关键基础设施。随着技术的成熟，它会变得更加稳定、标准化和便携。希望成熟的容器技术能够带来更多的用例，诸如应用程序智能、性能表现等。 就像所有优秀的技术一样，容器变得“Boring”。解决方案提供商在包装和分销方面做得更好，将会有更多关于如何在容器周围加入信任，确保不是恶意以及防止臃肿的知识。 围绕Kubernetes的编排正在标准化，这将加速开源和商业生态系统的发展，并推动工具开发。还将看到，随着云供应商提供一致的产品，这个堆栈也将成熟起来。甚至微软、亚马逊和IBM都支持Kubernetes。五年后，不运行Kubernetes和Docker的企业将成为少数。 清晰 容器将像任何优秀的技术一样继续消失于背景中，工具使得利用技术变得更容易，容器的部署和使用将有更大的简化。 容器是一种在本地或云中构建类云应用程序的机制，容器变得更容易处理和扩展，没有单点故障，也没有单一供应商。 容器使事情变得不那么复杂，成为新的常态。开发人员希望在容器中构建所有新应用程序，人们需要改变构建的方式，首先分析应用程序，以便在发布时，可以监控从构建到生产到建设和扩展的全流程。 1)今天Kubernetes不是以app开发者为核心角色而构建的。需要让Kubernetes更易于开发人员快速启动和运行。 2)我们看到了在Knative和OpenFast等Kubernetes之上构建抽象的趋势，在Kubernetes之上部署了无服务器功能，抽象了the knobs of Kubernetes。随着越来越多的项目成熟并以原生方式运行，更多开发人员可以更轻松地使用该技术。只有28％的应用程序在容器上运行，它还处于早期阶段，我们有机会让这项技术变得更加平易近人和实用。 容器仍然太复杂。如果比较一下现在开发人员所需要的知识量，就会发现间接需要的能力比五六年前要复杂得多。五年前，如果想构建一个Python应用程序，有一些众所周知的标准。现在开发人员不仅要学习如何生成Docker镜像，还要学习如何在编排系统上部署，如何将配置传递到容器，以及所有关于安全性的细节。最终，开发人员将不必处理容器，因为更高级别的抽象是构建在容器之上的。 无服务器和FaaS已经在路上 在开发人员体验和开发速度方面，容器的价值得到坚实地证明。然而，在容器安全性方面肯定会有所改进。未来，我们设想一个更安全的容器，运行沙箱在Nano VMs，就像Kata容器或AWS Firecracker一样。Serverless函数将代替传统API应用程序的大量工作。 在运营框架和如何描述自动化之间有两个巨大的机会。Kubernetes已经成为标准。快速脚本工作。运营者有可能在非常强大的环境中实现这一目标。我们一直在寻找可以使用的80/20工具。当使用标准化的YAML语言进入Kubernetes时，标准化的应用程序自动化将为我们提供一个功能强大的地方，在这里我们可以看到一个真正的服务目录。无服务器FaaS也非常令人兴奋，因为它允许您只专注于应用程序的逻辑。 容器使每个人都可以轻松实现无服务器。没有必要依赖虚拟机，虚拟机正在消失。它更容易转向Serverless，容器随着时间的推移会有所改善。将有更多选项可以在容器内运行更多应用程序。他们将继续改变，改善，变得更加稳定，更快地从失败中恢复，同时省下大笔资金。 无服务器和FaaS已经在路上。更高级别的抽象有助于在系统中获得更小的组件。随着颗粒越来越小，必须弄清楚如何管理和知道在哪里运行，这时候 Istio作为一种服务网格产品，可以帮助跟踪所有组件。 1)在去年的KubeCon上，“Serverless”计算的概念是指向容器创新未来的一个重要话题和热点——即构建和部署几乎任何类型的应用程序，而无需配置或管理运行这些应用程序的服务器。此外，用户将根据使用模式付费，只支付所消耗的计算时间，不运行时不收费。 2) 容器最终将取代虚拟机。与vm相比，容器提供了显著的优势，如降低了部署成本、显著降低了启动性能、减少了机器占用空间，且具备易用性。随着越来越多的公司和IT组织使用容器，将会出现应用程序从虚拟机到容器的大规模迁移。 3) 容器的采用幅度将远远超出仅以Docker为主要容器类型的情况。竞争产品将被更广泛地接受和使用。Docker作为市场领导者，已经偏离了标准容器技术的开发，而是更加专注于开发和营销一个全面的应用程序开发平台。导致其他容器产品的普及和使用的大幅增长。 参考资料： Gartner “China Summary Translation: 'Market Guide for Container Management Software'“，by Kevin Ji & Dennis Smith, Published on 18 February 2019， ID: G00382483.2.The Future of Containers ...

原文地址：Prometheus Operator — How to monitor an external service本实践指南中我们将看到如何部署Prometheus Operator到Kubernetes集群中，以及如何增加一个外部服务到Prometheus的targets列表。 在我的上个项目中，我们决定使用Prometheus Operator作为我们的监控和报警工具。我们的应用运行于Kubernetes集群中，但是除此我们还有个外部应用 — 一个GPU机器。 Kubernetes根本感知不到这个服务，相关服务通过HTTP请求连接该服务。我想跟你们分享下我使用Prometheus Operator的经验以及如何定制它来监控外部服务。 什么是PrometheusPrometheus是最早由SoundCloud开发的一个开源系统监控及报警工具。自从它2012年创建以来，许多公司和组织使用。Prometheus及其社区有一个非常活跃的开发者群体和用户社区。它现在是一个独立的开源项目，独立于任何公司进行维护。company.Prometheus已经成为Kubernetes和Docker领域监控和报警的事实标准。它提供了到目前为止最详细和可操作的监控指标和分析。在最新的主要版本2.0版本（访问下载页面查看当前最新版）Prometheus的性能有了显著提升，并且现在它在高负载和并发下表现良好。除此以外你可以获得世界领先的开源项目的所有好处。Prometheus可以免费使用，并可以轻松覆盖很多使用场景。 Prometheus Operator2016年年末，CoreOs引入了Operator 模式，并发布了Prometheus Operator 作为Operator模式的工作示例。Prometheus Operator自动创建和管理Prometheus监控实例。 Prometheus Operator的任务是使得在Kubernetes运行Prometheus仅可能容易，同时保留可配置性以及使Kubernetes配置原生。 https://coreos.com/operators/...Prometheus Operator使我们的生活更容易——部署和维护。 它如何工作为了理解这个问题，我们首先需要了解Prometheus Operator得工作原理。 Prometheus Operator架构图. 来源：prometheus-operator 我们成功部署 Prometheus Operator后可以看到一个新的CRDs(Custom Resource Defination): Prometheus，定义一个期望的Prometheus deployment。ServiceMonitor，声明式指定应该如何监控服务组；Operator根据定义自动创建Prometheusscrape配置。Alertmanager，定义期望的Alertmanager deployment。当服务新版本更新时，将会常见一个新Pod。Prometheus监控k8s API，因此当它检测到这种变化时，它将为这个新服务(pod)创建一组新的配置。 ServiceMonitorPrometheus Operator使用一个CRD，叫做ServiceMonitor将配置抽象到目标。下面是是个ServiceMonitor的示例： apiVersion: monitoring.coreos.com/v1alpha1kind: ServiceMonitormetadata: name: frontend labels: tier: frontendspec: selector: matchLabels: tier: frontend endpoints: - port: web # works for different port numbers as long as the name matches interval: 10s # scrape the endpoint every 10 seconds这仅仅是定义一组服务应该如何被监控。现在我们需要定义一个包含了该ServiceMonitor的Prometheus实例到其配置： ...

PS2018年Agile是什么情况？巴黎圣母院注定要着火？“米"字为什么是012345678? Go成为企业级编程语言新宠？Read on…The Listhttps://martinfowler.com/arti…Martin Fowler做的The State of Agile in 2018。是根据 https://www.infoq.com/present… 这个视频整理的。划重点： Raise the importance of technical excellence, and never forget that when writing software, the technology side is really vital, and organize around products. 通篇没有一次提scrum。现在的scrum，已经被项目经理绑架，偏离了Agile的初心https://drewdevault.com/2019/…Rust is not a good C replacement金句：_Go is the result of C programmers designing a new programming language, and Rust is the result of C++ programmers designing a new programming language_我尝试过学Rust，真是不好学啊。是不是除了Haskel之外最难学的语言？Webassembly on the server is the future of computing.最近Mozilla发布了WASI。Docker创始人Solomon Hykes发帖说了上面的话。我有点懵bi。这是肿么肥私？只能表示密切关注一下????https://github.com/LingDong-/…用RRPL来描述中文字符你不知道RRPL是啥？俺也不知道。全拼是Recursive Radical Packing Language。清楚了吗？没有？只能帮你到这里了。剩下的自己看项目。。。反正我知道“米”这个字是 {0, 1, 2, 3, 4, 5, 6, 7, 8} 1 2 3 |/ 8 -+- 4 /|\ 7 6 5https://drewdevault.com/2018/…Anatomy of a Shell用C语言实现一个Shell。解释了parsing，AST, execution等等。对底层有兴趣的值得一读。大神Guido star了996.icu。发文的时候，所有人都知道了吧。但还是贴一下https://github.com/kubernetes…Kubernetes Perl client! 这是进一步证明Kubernetes一统江湖还是一部分人闲得蛋疼呢？我选后者????。但是开源人就是这么任性。还好只有8颗星。这是说明还有8个人在等Perl 6吗????？https://www.infoq.com/article…Simplicity, Please - A Manifesto for Software Development金句：_A large code base (Google’s is some 2 billion lines) need not be complex, and a small code base may not exhibit simplicity._文章写的有些不好懂，读一下前面的几个bullet也就行了。https://medium.com/netflix-te…Full Cycle Developers at Netflix — Operate What You Build跟着Netflix不仅能追神剧，还能学习软件工程????。记住这个词：Full Cycle Development，也许以后会火。https://github.com/vugu/vuguVugu: A modern UI library for Go+WebAssembly (experimental)对Go程序猿来说，这是Go进一步统治世界的证明。但是。。。还早吧。https://www.infoq.com/present…▶️ Go - A Key Language in Enterprise Application Development?Go会成为企业应用的关键语言吗？我认为会。除非web被什么东西替代了。https://www.nytimes.com/inter…Why Notre-Dame Was a TinderboxNYT认为圣母院注定要着火。论防火墙的重要性。这样的文章真好啊，图文并茂。PPS这篇拖了一段时间。一来忙，二来懒，三来写这个时间成本变高了。又是一个在咖啡馆里面充实的早上☕️。且写且珍惜 ...

本周三晚20:30，Kubernetes Master Class在线培训第三期《Kubernetes应用商店：Harbor与Istio》即将开播，进入http://live.vhall.com/231749318 即可免费预约注册！美国著名的企业生产力解决方案领先供应商Workiva，投入使用开源的企业级Kubernetes管理平台Rancher，通过无缝连接到Rancher，指数级减少了构建和部署容器及Kubernetes服务所需的时间和精力。本文将分享Workiva的需求与痛点、以及他们的经验。Workiva是美国著名的互联数据、报告和合规解决方案的领先云提供商（纽约证券交易所上市代码 NYSE: WK）。Workiva提供直观的云平台Wdesk，帮助全球超过3000家企业实现工作方式的现代化，其中包括70％以上的财富500强(FORTUNE 500®)公司。需求与痛点Wdesk建立在数据管理引擎上，提供受控协作、数据连接、细化权限和完整的审计轨迹，有助于降低风险，提高生产力，让用户对数据驱动的决策充满信心。通过Rancher协调管理多个Kubernetes集群，使Wdesk能够快速满足客户日益增长的规模需求。 在选择容器管理平台时，Workiva需要一个可靠的解决方案来管理他们大量的生产工作负载，并且要求100%的零停机。同时，Workiva也需要具有复杂的、基于角色的访问控制功能的企业解决方案，以满足政府和监管机构的复杂要求。除此之外，Workiva还希望减少内部开发团队在Kubernetes中构建和部署新服务所需的时间和精力。解决方案“在选择容器管理平台前，我们使用了Docker将近4年的时间，已经充分了解了容器化微服务的优势所在”，Workiva的高级产品开发经理Steven Osborne表示：“随着我们将容器环境迁移到Kubernetes，我们需要一个工业级的编排层。Rancher为我们提供了将微服务容器部署到多个Kubernetes集群的编排，并让我们随时可以查看这些环境的健康状况。”使用Rancher之后，Workiva在两周内就建立了一个预生产安装的Kubernetes集群，具有基于角色的访问控制和单点登录支持。在开发团队采用Rancher后，Rancher为Workiva提供了一个可靠的解决方案，它具有与之前为管理集群而构建的内部平台同样友好的用户体验。Rancher还为多个用户提供了企业级基于角色的访问控制，以便在多个环境中运行Kubernetes，最为关键的是，Rancher为开发团队节省了时间，让开发团队可以更聚焦并加速他们的软件开发。为客户增值，步履不停Workiva的安全架构师Matthew Sullivan强调：“采用Rancher对于我们来说是一个轻松的决定。Rancher能够与大多数主要的单点登录提供商合作，这对我们有极大地吸引力，能为我们省去大量的跑腿工作。我安装了Rancher，点击了三个按钮，就完成了部署，Rancher所带来的增值是立竿见影的。” “让像Workiva这样的企业能够轻松管理在生产中运行Kubernetes所需的方方面面，是Rancher一如既往的目标”，Rancher的联合创始人Shannon Williams说：“一次又一次地，我们的解决方案得到了客户的认可，也是客户认可的Rancher给他们带去的价值，驱动着Rancher开发更好的产品并一路向前。”

kubernetes集群三步安装概述本文教你如何用一条命令构建k8s高可用集群且不依赖haproxy和keepalived，也无需ansible。通过内核ipvs对apiserver进行负载均衡，并且带apiserver健康检测。快速入门sealos项目地址准备条件装好docker并启动docker把离线安装包 下载好拷贝到所有节点的/root目录下, 不需要解压，如果有文件服务器更好，sealos支持从一个服务器上wget到所有节点上安装sealos已经放在离线包中，解压后在kube/bin目录下(可以解压一个，获取sealos bin文件)sealos init \ –master 192.168.0.2 \ –master 192.168.0.3 \ –master 192.168.0.4 \ # master地址列表 –node 192.168.0.5 \ # node地址列表 –user root \ # 服务用户名 –passwd your-server-password \ # 服务器密码，用于远程执行命令 –pkg kube1.14.1.tar.gz \ # 离线安装包名称 –version v1.14.1 # kubernetes 离线安装包版本，这渲染kubeadm配置时需要使用然后，就没有然后了其它参数: –kubeadm-config string kubeadm-config.yaml local # 自定义kubeadm配置文件，如有这个sealos就不去渲染kubeadm配置 –pkg-url string http://store.lameleg.com/kube1.14.1.tar.gz download offline pakage url # 支持从远程拉取离线包，省的每个机器拷贝，前提你得有个http服务器放离线包 –vip string virtual ip (default “10.103.97.2”) # 代理master的虚拟IP，只要与你地址不冲突请不要改清理sealos clean \ –master 192.168.0.2 \ –master 192.168.0.3 \ –master 192.168.0.4 \ # master地址列表 –node 192.168.0.5 \ # node地址列表 –user root \ # 服务用户名 –passwd your-server-password增加节点新增节点可直接使用kubeadm， 到新节点上解压cd kube/shell && init.shecho “10.103.97.2 apiserver.cluster.local” >> /etc/hosts # using vipkubeadm join 10.103.97.2:6443 –token 9vr73a.a8uxyaju799qwdjv \ –master 10.103.97.100:6443 \ –master 10.103.97.101:6443 \ –master 10.103.97.102:6443 \ –discovery-token-ca-cert-hash sha256:7c2e69131a36ae2a042a339b33381c6d0d43887e2de83720eff5359e26aec866安装dashboard prometheus等离线包里包含了yaml配置和镜像，用户按需安装。cd /root/kube/confkubectl taint nodes –all node-role.kubernetes.io/master- # 去污点，根据需求看情况，去了后master允许调度kubectl apply -f heapster/ # 安装heapster, 不安装dashboard上没监控数据kubectl apply -f heapster/rbac kubectl apply -f dashboard # 装dashboardkubectl apply -f prometheus # 装监控是不是很神奇，到底是如何做到这点的？那就需要去看下面两个东西关于超级kubeadm我们定制了kubeadm，做了两个事情：在每个node节点上增加了一条ipvs规则，其后端代理了三个master在node上起了一个lvscare的static pod去守护这个 ipvs, 一旦apiserver不可访问了，会自动清理掉所有node上对应的ipvs规则， master恢复正常时添加回来。通过这样的方式实现每个node上通过本地内核负载均衡访问masters： +———-+ +—————+ virturl server: 127.0.0.1:6443 | mater0 |<———————-| ipvs nodes | real servers: +———-+ |+—————+ 10.103.97.200:6443 | 10.103.97.201:6443 +———-+ | 10.103.97.202:6443 | mater1 |<———————+ +———-+ | | +———-+ | | mater2 |<———————+ +———-+这是一个非常优雅的方案其实sealos就是帮你执行了如下命令：super-kubeadm在你的node上增加了三个东西：cat /etc/kubernetes/manifests # 这下面增加了lvscare的static podipvsadm -Ln # 可以看到创建的ipvs规则cat /etc/hosts # 增加了虚拟IP的地址解析关于lvscare这是一个超级简单轻量级的lvs创建与守护进程，支持健康检查，底层与kube-proxy使用的是相同的库，支持HTTP的健康检测。清理机器上的IPVS规则ipvsadm -C启动几个nginx作为ipvs代理后端的realserverdocker run -p 8081:80 –name nginx1 -d nginxdocker run -p 8082:80 –name nginx2 -d nginxdocker run -p 8083:80 –name nginx3 -d nginx启动lvscare守护它们lvscare care –vs 10.103.97.12:6443 –rs 127.0.0.1:8081 –rs 127.0.0.1:8082 –rs 127.0.0.1:8083 --health-path / –health-schem http可以看到规则已经被创建ipvsadm -Ln[root@iZj6c9fiza9orwscdhate4Z ~]# ipvsadm -LnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.103.97.12:6443 rr -> 127.0.0.1:8081 Masq 1 0 0 -> 127.0.0.1:8082 Masq 1 0 0 -> 127.0.0.1:8083 Masq 1 0 0 curl vip:[root@iZj6c9fiza9orwscdhate4Z ~]# curl 10.103.97.12:6443 <!DOCTYPE html><html><head><title>Welcome to nginx!</title><style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; }</style></head>删除一个nginx,规则就少了一条[root@iZj6c9fiza9orwscdhate4Z ~]# docker stop nginx1nginx1[root@iZj6c9fiza9orwscdhate4Z ~]# ipvsadm -LnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.103.97.12:6443 rr -> 127.0.0.1:8082 Masq 1 0 0 -> 127.0.0.1:8083 Masq 1 0 1 再删除一个:[root@iZj6c9fiza9orwscdhate4Z ~]# docker stop nginx2nginx2[root@iZj6c9fiza9orwscdhate4Z ~]# ipvsadm -LnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.103.97.12:6443 rr -> 127.0.0.1:8083 Masq 1 0 0 此时VIP任然可以访问:[root@iZj6c9fiza9orwscdhate4Z ~]# curl 10.103.97.12:6443 <!DOCTYPE html><html><head><title>Welcome to nginx!</title><style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; }</style></head>全部删除, 规则就自动被清除光了, curl也curl不通了，因为没realserver可用了[root@iZj6c9fiza9orwscdhate4Z ~]# docker stop nginx3nginx3[root@iZj6c9fiza9orwscdhate4Z ~]# ipvsadm -LnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.103.97.12:6443 rr[root@iZj6c9fiza9orwscdhate4Z ~]# curl 10.103.97.12:6443 curl: (7) Failed connect to 10.103.97.12:6443; 拒绝连接再把nginx都启动起来,规则就自动被加回来[root@iZj6c9fiza9orwscdhate4Z ~]# docker start nginx1 nginx2 nginx3nginx1nginx2nginx3[root@iZj6c9fiza9orwscdhate4Z ~]# ipvsadm -LnIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.103.97.12:6443 rr -> 127.0.0.1:8081 Masq 1 0 0 -> 127.0.0.1:8082 Masq 1 0 0 -> 127.0.0.1:8083 Masq 1 0 0 所以sealos中，上面apiserver就是上面三个nginx，lvscare会对其进行健康检测。当然你也可以把lvscare用于一些其它场景，比如代理自己的TCP服务等 ...

前言在使用aws的托管k8s–eks过程中，避免不了使用aws的LB和块存储。AWS公有云所有的资源都可以自定义tags,这样的好处就是可以根据tag具体含义来对资源进行不同维度的审计和统计。比如按照部门，按照项目，环境(test,prod,uat)等维度。在设置service的类型为Loadbanlance的时候，可以通过以下annotations来自定义tag。apiVersion: v1kind: Servicemetadata: annotations: service.beta.kubernetes.io/aws-load-balancer-type: nlb # service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 service.beta.kubernetes.io/aws-load-balancer-additional-resource-tags: “sgt:env=prod,sgt:group=SGT,sgt:project=hawkeye” labels: app: prometheus-server name: prometheus-server namespace: kube-systemspec: ports: - name: http port: 9090 protocol: TCP targetPort: 9090 selector: app: prometheus-server type: LoadBalancer但是可惜的是，k8s当中的块存储(ebs)并不支持这样的方式。可能aws觉得存储比较便宜，不值得进行审计吧。但是本身ebs是支持打tag的。所以为了满足我们司在k8s落地过程中对存储的审计，设计了add-ebs-tags-controller这个组件。add-ebs-tags-controller 详解设计思路大家都知道k8s中对于存储是通过pv和pvc来实现的。因而add-ebs-tags-controller监听所有新建的pvc,然后获取到新建pvc的annotations(volume.beta.kubernetes.io/aws-block-storage-additional-resource-tags)，最后调用aws的接口sdk，完成打tag的工作。代码实现具体代码参见 github。代码相对比较简单，大家可以自行研究。总体实现思路和其他的controller类似。都是监听指定资源，然后分别对Update和add和delete三种事件，做出处理。当然这里不得不提一下，k8s controller设计的核心理念，controller通过监听实际的状态(status) ，不断做出具体调整，向期望的状态(spec) 靠轮。部署具体部署的yaml如下:apiVersion: apps/v1kind: Deploymentmetadata: name: add-ebs-tags-controller namespace: kube-systemspec: replicas: 1 selector: matchLabels: k8s-app: add-ebs-tags-controller task: tool template: metadata: labels: task: tool k8s-app: add-ebs-tags-controller annotations: scheduler.alpha.kubernetes.io/critical-pod: ’’ spec: serviceAccount: cluster-admin containers: - name: add-ebs-tags-controller image: iyacontrol/add-ebs-tags-controller:0.0.1 imagePullPolicy: IfNotPresent 注意serviceAccount: cluster-admin，加入集群中不存在admin角色，可以自行进行rbac授权。demo例如：kind: PersistentVolumeClaimapiVersion: v1metadata: name: prometheus-claim namespace: kube-system annotations: volume.beta.kubernetes.io/aws-block-storage-additional-resource-tags: “sgt:env=prod,sgt:group=SGT,sgt:project=hawkeye"spec: accessModes: - ReadWriteOnce resources: requests: storage: 50Gi 创建成果以后，去aws的ui查看如下： ...

4月8日-10日，中国信息通信研究院云计算标准和开源推进委员会（TC608）第三次全体会员大会在成都隆重召开。大会旨在对多项云计算标准进行讨论，进一步推动云计算技术的发展、标准的落地和产业共性问题的解决。本次会议由中国信息通信研究所云大所所长何宝宏、云计算标准和开源推进委员会常务副主席栗蔚领衔指导，灵雀云CEO左玥被任命为云原生联盟平台架构组副组长，出席了大会授牌仪式并被颁发证书。在10日上午的工作组会议中，云计算开源产业联盟（OSCAR）下设的子联盟——“云原生产业联盟（Cloud Native Industry Alliance，简称CNIA）”正式通过了TC608全体会员审议。栗蔚主任对联盟的成立背景、组织架构、联盟宗旨和愿景等进行了介绍。联盟下设技术专家委员会与平台架构组、DevOps工作组、用户工作组和生态伙伴工作组等四个工作组。其中平台架构工作组包含容器项目、微服务项目、Serverless项目及更多云原生与其他领域融合的项目组，承担了云原生平台技术与实践经验标准化制定与推广的重任。灵雀云CEO左玥被提名为联盟平台架构组副组长。与此同时，招商银行苏贝、浦发银行杨欣捷提名为用户工作组组长；东华软件王昕提名为生态伙伴工作组组长。随后，何宝宏所长颁发证书，对联盟各工作组的组长予以委任。云原生产业联盟（CNIA）前身为云原生技术实践联盟（CNBPA），系由灵雀云牵头，行业顶尖平台提供商，行业解决方案与服务商，行业云原生典型用户联合发起的机构，CNBPA旨在促进国内云原生行业间交流，加强企业和行业用户之间的沟通，推进云原生技术在国内的发展和落地，是国内首个以云原生技术应用实践为核心的组织。CNIA沿用了原CNBPA部分章程制度及工作规划，并平移了原CNBPA成员。首批吸引了腾讯云、阿里云、华为、灵雀云、金山云、浪潮、中油瑞飞、东华软件、北明软件、中科软、深信服等18家理事会员单位与数十家普通会员单位加入。作为联盟首批创始成员，以及国内云原生技术及实践落地的推动者，灵雀云积极参与了国内云原生平台标准的制定与及未来研究方向的探讨。在CNIA发起的国内首个“云原生技术实践白皮书“和首个”无服务架构技术白皮书“中，灵雀云分别承担了核心的编写任务，将自身的云原生技术能力和解决方案能力进行了输出。至此，云原生产业联盟CNIA的筹备工作全部结束。 4月24日， CNIA将在云原生产业大会上正式宣布成立。以灵雀云为代表的企业将在CNIA的带领下持续推进云原生技术产业化落地，推进行业标准化工作，推广领先解决方案，构建技术带动实践、实践反哺技术的良性生态，进一步推动我国云原生技术的成熟发展！

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。CRI-O 成为 CNCF 托管项目CRI-O 是基于 OCI 的 Kubernetes CRI 实现，旨在提供符合 OCI 运行时和 kubelet 之间的集成。简单来说就是完全符合 OCI 标准的 CRI 实现。（比如之前介绍的 runc 便是 OCI 标准的参考实现）在 2016 年的时候 Kubernetes 就推出了容器运行时接口（CRI），这给了 kubelet 一种使用各种不同容器运行时的能力，现在最常用的当然还是 Docker，当然也有人使用 containerd、runc、CRI-O 等各类运行时。CRI-O 最初由 Red Hat 和 Google 开发，现在已达到稳定状态，且已有大量的贡献者，本次成为 CNCF 托管项目，也算是给容器运行时提供一个更大的可能。附一张官方图：详细信息请阅读 CNCF 官方新闻Helm 子项目 chart-testing 发布 v2.3.0 版本chart-testing v2.3.0 版本正式发布，该项目的主要目标是用于 Helm Chart 的测试，使用该项目可更方便的检查 Chart 中是否有错误，以及定位错误位置等。本次发布主要在于覆盖更多异常情况，详细内容建议阅读 ReleaseNoteCoreDNS v1.5.0 版本发布CoreDNS 是一个 CNCF 毕业的灵活且快速的 DNS server 项目，包含了众多插件。1.5.0 的主要更新：增加了两个 plugin: grpc 和 ready;使用 grpc 插件可转发 gRPC;使用 ready 插件，可为每个后端配置一个 ready 探针，类似于 Kubernetes 中的 Readiness 探针的作用；其他更新请阅读 ReleaseNoteDocker CE v18.09.5 发布v18.09.5 的主要更新：修复了一个当 systemd-resolve 且使用主机网络（network=host）时，resolv.conf 使用错误的问题（之前都默认使用 /etc/resolv.conf）；其他修复和更新请阅读 ReleaseNotefluentd 从 CNCF 毕业fluentd 是 CNCF 中毕业的第 6 个项目，在 Kubernetes 生态中，fluentd 被广泛用于日志采集，而且项目经过 CNCF 孵化，也发展迅速。详细信息请阅读 恭喜 fluentd 毕业DockerHub 将完全禁用 v1 APIDockerHub 将在今年 6 月份禁止通过 v1 API 进行 Pull 操作，实际上我们现在用到的接口基本都是 v2 API，而早在 2015 年 11 月 DockerHub 就已经禁止了通过 v1 API 进行 Push 操作了。如果你还在使用特别老旧的客户端，请注意升级，否则 6 月之后就无法正常通过 DockerHub Pull 镜像使用了。详情请阅读 Registry v1 API Deprecation可以通过下面二维码订阅我的文章公众号【MoeLove】 ...

今年新闻不断，多数早期进入 CNCF 的项目都相继宣布毕业。CNCF（云原生计算基金会）在美国时间 2019 年 4 月 11 日宣布 fluentd 今天正式毕业了。这是 CNCF 中毕业的第 6 个项目，之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 、CoreDNS 和 containerd 。fluentd 自 2011 年由 Treasure Data 公司的联合创始人 Sadayuki “Sada” Furuhashi 创建，作为构建统一记录层的开源数据收集器，统一记录层统一收集采集和消费，以便更好的使用和理解数据。在 2016 年 11 月，fluentd 也是第 6 个成为 CNCF 托管项目的。fluentd 可以从多种数据源采集事件，并将它写入文件, RDBMS, NoSQL, IaaS, SaaS, Hadoop等等各类的目标地址。截至目前，fluentd 在 GitHub 上有 7629 个 star ，895 个 fork，以及 166 位贡献者，超过 4k+ commit 。做日志相关的小伙伴基本都玩过 ELK ，我们都知道在大规模使用 Logstash 时的痛苦（还记得被 Logstash 配置文件支配的恐惧吗？ 2333） 而 fluentd 的事件路由是通过 tag 来做，相比 Logstash 使用管道将所有数据路由到单个流里再通过配置将它发送到对应的目标而言这将大大简化配置的复杂度。(是的，这里是吐槽)再一个，便是需要考虑部署和插件生态，首先来说部署：fluentd 使用 C + Ruby 编写（Ruby 写起来蛮舒服的，早先写过一段时间），只要有 Ruby 的环境，可以很方便的进行部署。而大多数的 Linux 发行版是默认带着 Ruby 环境的，这也非常方便。Logstash 使用 JRuby 编写（JRuby 就是使用 Java 实现的 Ruby 解释器），部署时需要有 JDK 和 JRuby 的环境。这里只做陈述，不再展开。回到插件生态上：两者都有丰富的插件，并且编写插件也很简单。不过插件这种东西，按需使用，日常需要的基本都能找的到。唯一需要注意的就是选择插件时，需要仔细甄别。“Fluentd has earned its place as the industry standard for log collection and shipping, and I am excited to see it as a graduated CNCF project,” said Gabe Monroy, Lead Program Manager for Containers, Microsoft Azure. “At Microsoft, we are proud to use Fluentd to power our cloud native logging subsystems and we look forward to working with the growing the open source community around Fluentd.”引用一段话，fluentd 是否成为整个日志收集的行业标准，这个我不确定， 但在它托管至 CNCF 后，在云原生领域它确实发展迅速，多数公司都会采用 EFK 的方式进行云原生时代下的日志方案。附一张 fluentd 的图，有空会写下 fluentd 的使用姿势 （flag++）再次恭喜 fluentd 毕业。可以通过下面二维码订阅我的文章公众号【MoeLove】 ...

今天， Google Cloud NEXT 2019大会召开，在这场规模三万人的盛会上，Google宣布推出Anthos作为多云服务新方案，提供跨云（目前仅支持AWS和Azure）管理Kubernetes集群。Anthos（前身为Cloud Service Platform）让用户可以跨环境构建和管理现代混合应用程序，用户可以在Anthos之上交付和管理容器、Kubernetes、微服务架构和Service Mesh等。据Google CEO Sundar Pichai在大会发布时的介绍，Google自身作为公有云提供商，产品Anthos平台甚至可以支持部分竞争对手的云，如目前支持AWS和Azure，但除这二者之外的其他公有云如阿里云、Oracle、IBM等的云都尚不支持。技术前瞻性和持续创新得到证明Anthos的发布，对Rancher来说是一则十足的好消息。在Google Anthos中，我们看到了它与Rancher的愿景的完美契合。因为Rancher始终相信Kubernetes将成为所有公有云和私有云都会提供的、标准化的基础架构，企业Kubernetes平台必须提供多集群、多云管理的功能。早在两年前，Rancher就预见到企业将需要跨不同的公有云和私有数据中心管理多个Kubernetes集群。正是怀着这种理念，我们构建了Rancher 2.0，它可以与所有Kubernetes集群协同工作，包括Google GKE、Amazon EKS、Azure AKS、华为云、阿里云、腾讯云等等，是业界第一个、也是目前唯一一个与所有主流公有云厂商完成官方合作及对接的Kubernetes平台。在过去的12个月里，已有成千上万的具有前瞻性思维的企业在生产环境中应用了Rancher 2.0。但是在初期，当我们向用户阐释Rancher能够管理多Kubernetes服务（如GKE、AKS、EKS等）的这一功能的优势时，有用户虽然对这一创新特性兴奋与好奇，却仍忍不住问我们，“管理多Kubernetes集群与服务？Rancher是对的吗？”如今，Google正式推出Anthos足以强力地证明，Rancher对多集群多云Kubernetes的坚信和前瞻性，是对的。Container和Kubernetes技术均正处于采用的早期阶段。我们相信创新的产品和服务是实现大规模采用的关键。我们喜欢Google Anthos和Google Cloud Run（同样是今天全新发布的）等新服务，同时也为Rancher团队开发的创新技术感到自豪。Rancher 2.0是业界第一个多集群、多云Kubernetes管理平台。除此之外，Rancher Labs的创新步伐从未放缓，如最近推出的轻量级Kubernetes发行版K3s、多Kubernetes集群网络框架Submariner、对单一应用程序跨多Kubernetes集群的部署与管理等等，都广受客户和用户称赞。Anthos：竞争者？推动者？那Google会成为Rancher的竞争对手吗？答案是否定的。首先，Rancher是一个开源的平台，而Anthos是一种云服务。我们甚至相信，Anthos的发布将毫无疑问加速Rancher被更大规模地采用。正如Google发布GKE而极大地帮助普及了Kubernetes技术一样，我们也相信Anthos将促进将多集群、多云Kubernetes管理带入更主流的阶段。其次，作为一个完全开源的Kubernetes管理平台，Rancher自身并非公有云提供商，因而一如既往的是所有公有云提供商、包括他们提供的托管Kubernetes服务的合作伙伴而非竞争对手。Rancher也才更能中立地提供对其他厂商Kubernetes服务的最一流支持。因为公有云厂商之间天然的竞争关系，我们很难想象AWS乐意致力于把运行在EKS上的应用无缝迁移到Google GKE或者其他云服务商提供的Kubernetes服务上，反之亦然。从世界范围内包含Google GKE、Amazon EKS、Azure AKS、华为云、阿里云、腾讯云以及正在加入Rancher合作伙伴列表的众多主流公有云与Rancher一直以来的紧密合作中可见，Rancher也始终是所有第三方公有云厂商普遍最为信任的统一管理平台。宠物与牛的故事听过那个云计算时代“宠物”与“牛”的故事吗？传统的物理机时代，物理机（及它所代表的计算资源）被工程师称为“宠物”，它们价格高昂，需要精心维护和保养。而在云计算时代，工程师可以把服务器当成牛，一头牛倒下没关系，只要放牧人活着就行，服务器价格便宜，就像一次性工具，即时它们倒下，一台设备上的任务也能转移到另一台，对公司业务不会造成任何影响。我们将公司及产品命名为“Rancher（放牧人）”，就是因为我们愿景中的未来里，企业可以自由选择并搭配着从他们喜欢的云提供商那里获得计算资源，而Rancher会开发一个软件平台来完美实现这种统一体验。随着Anthos的发布，我们相信整个行业又向实现这一愿景迈进了一步！本文基于Rancher Labs联合创始人及CEO梁胜所写博客删改编辑而成：https://rancher.com/blog/2019…

K3s是一个轻量的K8s，主要面向IOT、Edge、CI等场景。Lightweight Kubernetes. 5 less than k8s.K3s和K8s的对比，移除了：非默认的、遗留的特性Alpha阶段的特性In-tree的云服务提供商In-tree的存储驱动Docker (可选)带来了：简化安装SQLite3支持，替代etcdTLS管理自动的Manifest和Helm Chart管理containerd, CoreDNS, Flannel快速安装## 下载镜像，避免无网络或访问不了gcr.io$ wget https://github.com/rancher/k3s/releases/download/v0.3.0/k3s-airgap-images-amd64.tar$ sudo mkdir -p /var/lib/rancher/k3s/agent/images/$ sudo cp k3s-airgap-images-amd64.tar /var/lib/rancher/k3s/agent/images/## 安装$ curl -sfL https://get.k3s.io | sh -[INFO] Finding latest release[INFO] Using v0.3.0 as release[INFO] Downloading hash https://github.com/rancher/k3s/releases/download/v0.3.0/sha256sum-amd64.txt[INFO] Downloading binary https://github.com/rancher/k3s/releases/download/v0.3.0/k3s[INFO] Verifying binary download[INFO] Installing k3s to /usr/local/bin/k3s[INFO] Creating /usr/local/bin/kubectl symlink to k3s[INFO] Creating /usr/local/bin/crictl symlink to k3s[INFO] Creating uninstall script /usr/local/bin/k3s-uninstall.sh[INFO] systemd: Creating environment file /etc/systemd/system/k3s.service.env[INFO] systemd: Creating service file /etc/systemd/system/k3s.service[INFO] systemd: Enabling k3s unitCreated symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.[INFO] systemd: Starting k3s完成后就可以用kubectl正常访问k3s： $ kubectl get pods –all-namespaceskubectl get pods –all-namespacesNAMESPACE NAME READY STATUS RESTARTS AGEkube-system coredns-7748f7f6df-phxck 1/1 Running 33 38dkube-system helm-install-traefik-8tjss 0/1 Completed 0 51skube-system svclb-traefik-78cbd58b59-smdf8 2/2 Running 0 51skube-system traefik-5cc8776646-x9bw9 1/1 Running 0 34s$ kubectl get nodesNAME STATUS ROLES AGE VERSIONarchlinux Ready <none> 43m48s v1.13.5-k3s.1注意：K3s默认使用containerd，要使用docker需要设置–docker:curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="–docker" sh -更多的安装方式和配置可以参考文档。 ...