Kubernetes

Kubernetes TLS bootstrap引导程序

按照 kubernetes-handbook 安装 kubernetes 集群的第一步是什么?没错,创建 TLS 证书和秘钥!作为第一步已经这么繁琐和容易出错,很多人就望而却步了,单纯的按照说明执行命令而不了解这样做的目录和命令的含义无法帮助我们进行问题排查和纠错。 Bootstrap 是很多系统中都存在的程序,比如 Linux 的bootstrap,bootstrap 一般都是作为预先配置在开启或者系统启动的时候加载,这可以用来生成一个指定环境。Kubernetes 的 kubelet 的启动时同样可以加载一个这样的配置文件,这个文件的内容类似如下形式: 02b50b05283e98dd0fd71db496ef01e8,kubelet-bootstrap,10001,"system:kubelet-bootstrap" 下面将为您详细解释 TLS bootstrap 是如何配置和生成的(下文是 kubernetes 官方文档的中文版)。 TLS Bootstrap 本文档介绍如何为 kubelet 设置 TLS 客户端证书引导(bootstrap)。 Kubernetes 1.4 引入了一个用于从集群级证书颁发机构(CA)请求证书的 API。此 API 的原始目的是为 kubelet 提供 TLS 客户端证书。可以在 这里 找到该提议,在 feature #43 追踪该功能的进度。 kube-apiserver 配置 您必须提供一个 token 文件,该文件中指定了至少一个分配给 kubelet 特定 bootstrap 组的 “bootstrap token”。 该组将作为 controller manager 配置中的默认批准控制器而用于审批。随着此功能的成熟,您应该确保 token 被绑定到基于角色的访问控制(RBAC)策略上,该策略严格限制了与证书配置相关的客户端请求(使用 bootstrap token)。使用 RBAC,将 token 范围划分为组可以带来很大的灵活性(例如,当您配置完成节点后,您可以禁用特定引导组的访问)。 Token 认证文件 Token 可以是任意的,但应该可以表示为从安全随机数生成器(例如大多数现代操作系统中的 /dev/urandom)导出的至少128位熵。生成 token 有很多中方式。例如:

Linkerd 使用指南

前言 该文章已归档到 kubernetes-handbook 第五章【领域应用】中,一切内容以 kubernetes-handbook 为准,该文档可能不会及时更新。 以下内容参考:A Service Mesh for Kubernetes Linkerd 作为一款 service mesh 与kubernetes 结合后主要有以下几种用法: 作为服务网关,可以监控 kubernetes 中的服务和实例 使用 TLS 加密服务 通过流量转移到持续交付 开发测试环境(Eat your own dog food)、Ingress 和边缘路由 给微服务做 staging 分布式 tracing 作为 Ingress controller 使用 gRPC 更方便 以下我们着重讲解在 kubernetes 中如何使用 linkerd 作为 kubernetes 的 Ingress controller,并作为边缘节点代替 Traefik的功能,详见 边缘节点的配置。 准备 安装测试时需要用到的镜像有: buoyantio/helloworld:0.1.4 buoyantio/jenkins-plus:2.60.1 buoyantio/kubectl:v1.4.0 buoyantio/linkerd:1.1.2 buoyantio/namerd:1.1.2 buoyantio/nginx:1.10.2 linkerd/namerctl:0.8.6 openzipkin/zipkin:1.20 tutum/dnsutils:latest 这些镜像可以直接通过 Docker Hub 获取,我将它们下载下来并上传到了自己的私有镜像仓库 sz-pg-oam-docker-hub-001.

适用于kubernetes的应用开发与部署流程详解

(题图:风和日丽@野三坡 Jul 14,2017) 本文已归档在kubernetes-handbook中的第3章【用户指南】中,一切更新以kubernetes-handbook中为准。 为了详细说明,我特意写了两个示例程序放在GitHub中,模拟应用开发流程: k8s-app-monitor-test:生成模拟的监控数据,发送http请求,获取json返回值 K8s-app-monitor-agent:获取监控数据并绘图,访问浏览器获取图表 API文档见k8s-app-monitor-test中的api.html文件,该文档在API blueprint中定义,使用aglio生成,打开后如图所示: 关于服务发现 K8s-app-monitor-agent服务需要访问k8s-app-monitor-test服务,这就涉及到服务发现的问题,我们在代码中直接写死了要访问的服务的内网DNS地址(kubedns中的地址,即k8s-app-monitor-test.default.svc.cluster.local)。 我们知道Kubernetes在启动Pod的时候为容器注入环境变量,这些环境变量在所有的 namespace 中共享(环境变量是不断追加的,新启动的Pod中将拥有老的Pod中所有的环境变量,而老的Pod中的环境变量不变)。但是既然使用这些环境变量就已经可以访问到对应的service,那么获取应用的地址信息,究竟是使用变量呢?还是直接使用DNS解析来发现? 答案是使用DNS,详细说明见Kubernetes中的服务发现与Docker容器间的环境变量传递源码探究。 打包镜像 因为我使用wercker自动构建,构建完成后自动打包成docker镜像并上传到docker hub中(需要现在docker hub中创建repo)。 构建流程见:https://app.wercker.com/jimmysong/k8s-app-monitor-agent/ 生成了如下两个docker镜像: jimmysong/k8s-app-monitor-test:latest jimmysong/k8s-app-monitor-agent:latest 启动服务 所有的kubernetes应用启动所用的yaml配置文件都保存在那两个GitHub仓库的manifest.yaml文件中。 分别在两个GitHub目录下执行kubectl create -f manifest.yaml即可启动服务。 外部访问 服务启动后需要更新ingress配置,在ingress.yaml文件中增加以下几行: - host: k8s-app-monitor-agent.jimmysong.io http: paths: - path: / backend: serviceName: k8s-app-monitor-agent servicePort: 8080 保存后,然后执行kubectl replace -f ingress.yaml即可刷新ingress。 修改本机的/etc/hosts文件,在其中加入以下一行: 172.20.0.119 k8s-app-monitor-agent.jimmysong.io 当然你也可以加入到DNS中,为了简单起见我使用hosts。 详见边缘节点配置。 在浏览器中访问http://k8s-app-monitor-agent.jimmysong.io 刷新页面将获得新的图表。

记一本关于kubernetes management design patterns的书

书名: Kubernetes Management Design Patterns: With Docker, CoreOS Linux, and Other Platforms Amazon购买链接:链接 作者:Deepak Vohra 发行日期:2017年1月20日 出版社:Apress 页数:399 简介 Kubernetes引领容器集群管理进入一个全新的阶段;学习如何在CoreOS上配置和管理kubernetes集群;使用适当的管理模式,如ConfigMaps、Autoscaling、弹性资源使用和高可用性配置。讨论了kubernetes的一些其他特性,如日志、调度、滚动升级、volume、服务类型和跨多个云供应商zone。 Kubernetes中的最小模块化单位是Pod,它是拥有共同的文件系统和网络的系列容器的集合。Pod的抽象层可以对容器使用设计模式,就像面向对象设计模式一样。容器能够提供与软件对象(如模块化或包装,抽象和重用)相同的优势。 在大多数章节中使用的都是CoreOS Linux,其他讨论的平台有CentOS,OpenShift,Debian 8(jessie),AWS和Debian 7 for Google Container Engine。 使用CoreOS主要是因为Docker已经在CoreOS上开箱即用。CoreOS: 支持大多数云提供商(包括Amazon AWS EC2和Google Cloud Platform)和虚拟化平台(如VMWare和VirtualBox) 提供Cloud-Config,用于声明式配置OS,如网络配置(flannel),存储(etcd)和用户帐户 为容器化应用提供生产级基础架构,包括自动化,安全性和可扩展性 引领容器行业标准,并建立了应用程序标准 提供最先进的容器仓库,Quay Docker于2013年3月开源,现已称为最流行的容器平台。kubernetes于2014年6月开源,现在已经成为最流行的容器集群管理平台。第一个稳定版CoreOS Linux于2014年7月发行,现已成为最流行的容器操作系统之一。 你将学到什么 使用docker和kubernetes 在AWS和CoreOS上创建kubernetes集群 应用集群管理设计模式 使用多个云供应商zone 使用Ansible管理kubernetes 基于kubernetes的PAAS平台OpenShift 创建高可用网站 构建高可用用的kubernetes master集群 使用volume、configmap、serivce、autoscaling和rolling update 管理计算资源 配置日志和调度 谁适合读这本书 Linux管理员、CoreOS管理员、应用程序开发者、容器即服务(CAAS)开发者。阅读这本书需要Linux和Docker的前置知识。介绍Kubernetes的知识,例如创建集群,创建Pod,创建service以及创建和缩放replication controller。还需要一些关于使用Amazon Web Services(AWS)EC2,CloudFormation和VPC的必备知识。 关于作者 Deepak Vohra is an Oracle Certified Associate and a Sun Certified Java Programmer.

Kubernetes中的服务发现与docker容器间的环境变量传递源码探究

(题图:雷雨@野三坡 Jul 13,2017) 前言 今天创建了两个kubernetes示例应用: k8s-app-monitor-test:启动server用来产生metrics k8s-app-monitor-agent:获取metrics并绘图,显示在web上 注:相关的kubernetes应用manifest.yaml文件分别见以上两个应用的GitHub 。 当我查看Pod中的环境变量信息时,例如kubernetes中的service k8s-app-monitor-test注入的环境变量时,包括了以下变量: K8S_APP_MONITOR_TEST_PORT_3000_TCP_ADDR=10.254.56.68 K8S_APP_MONITOR_TEST_PORT=tcp://10.254.56.68:3000 K8S_APP_MONITOR_TEST_PORT_3000_TCP_PROTO=tcp K8S_APP_MONITOR_TEST_SERVICE_PORT_HTTP=3000 K8S_APP_MONITOR_TEST_PORT_3000_TCP_PORT=3000 K8S_APP_MONITOR_TEST_PORT_3000_TCP=tcp://10.254.56.68:3000 K8S_APP_MONITOR_TEST_SERVICE_HOST=10.254.56.68 K8S_APP_MONITOR_TEST_SERVICE_PORT=3000 我们知道Kubernetes在启动Pod的时候为容器注入环境变量,这些环境变量将在该Pod所在的namespace中共享。但是既然使用这些环境变量就已经可以访问到对应的service,那么获取应用的地址信息,究竟是使用变量呢?还是直接使用DNS解析来发现?下面我们从代码中来寻求答案。 如果不想看下面的文字,可以直接看图。 探索 docker的docker/engine-api/types/container/config.go中的Config结构体中有对环境变量的定义: // Config contains the configuration data about a container. // It should hold only portable information about the container. // Here, "portable" means "independent from the host we are running on". // Non-portable information *should* appear in HostConfig. // All fields added to this struct must be marked `omitempty` to keep getting // predictable hashes from the old `v1Compatibility` configuration.

Kubernetes中的数据持久化问题的一个案例讨论与解决方案探究

本文已归档到kubernetes-handbook中的【最佳实践—运维管理】章节中,一切内容以kubernetes-handbook为准。 数据落盘问题的由来 这本质上是数据持久化问题,对于有些应用依赖持久化数据,比如应用自身产生的日志需要持久化存储的情况,需要保证容器里的数据不丢失,在Pod挂掉后,其他应用依然可以访问到这些数据,因此我们需要将数据持久化存储起来。 数据落盘问题解决方案 下面以一个应用的日志收集为例,该日志需要持久化收集到ElasticSearch集群中,如果不考虑数据丢失的情形,可以直接使用kubernetes-handbook中【应用日志收集】一节中的方法,但考虑到Pod挂掉时logstash(或filebeat)并没有收集完该pod内日志的情形,我们想到了如下这种解决方案,示意图如下: 首先需要给数据落盘的应用划分node,即这些应用只调用到若干台主机上 给这若干台主机增加label 使用deamonset方式在这若干台主机上启动logstash的Pod(使用nodeSelector来限定在这几台主机上,我们在边缘节点启动的treafik也是这种模式) 将应用的数据通过volume挂载到宿主机上 Logstash(或者filebeat)收集宿主机上的数据,数据持久化不会丢失 Side-effect 首先kubernetes本身就提供了数据持久化的解决方案statefulset,不过需要用到公有云的存储货其他分布式存储,这一点在我们的私有云环境里被否定了。 需要管理主机的label,增加运维复杂度,但是具体问题具体对待 必须保证应用启动顺序,需要先启动logstash 为主机打label使用nodeSelector的方式限制了资源调度的范围

Kubernetes kubectl cheat sheat——Kubectl命令参考图

参考 https://kubernetes.io/docs/user-guide/kubectl/v1.6/ 绘制。 通过该图可以对kubernetes的客户端命令kubectl有个感性和大体的了解,具体使用方法请参考官方文档。 图片归档在kubernetes-handbook,以GitHub中的图片为准。 注:在移动设备上打开该链接后会提示图片太大无法查看请选择Desktop version方可查看原图。 今后我将陆续推出其他object的cheat sheet,敬请关注。

使用Jenkins进行持续构建与发布应用到kubernetes集群中

(题图:正午@东直门 Jun 27,2017) 本文已归档到kubernetes-handbook中的【最佳实践—使用Jenkins进行持续构建与发布】章节中,一切内容以kubernetes-handbook为准。 我们基于Jenkins的CI/CD流程如下所示。 流程说明 应用构建和发布流程说明。 用户向Gitlab提交代码,代码中必须包含Dockerfile; 将代码提交到远程仓库; 用户在发布应用时需要填写git仓库地址和分支、服务类型、服务名称、资源数量、实例个数等,确定后触发Jenkins自动构建; Jenkins的CI流水线自动编译代码并打包成docker镜像推送到Harbor镜像仓库; Jenkins的CI流水线中包括了自定义脚本,根据我们已准备好的kubernetes的YAML模板,将其中的变量替换成用户输入的选项; 生成应用的kubernetes YAML配置文件; 更新Ingress的配置,根据新部署的应用的名称,在ingress的配置文件中增加一条路由信息 更新PowerDNS,向其中插入一条DNS记录,IP地址是边缘节点的IP地址。关于边缘节点,请查看kubernetes-handbook中的【最佳实践——边缘节点配置】章节; Jenkins调用kubernetes的API,部署应用到kubernetes集群中。 关于应用的更新、滚动升级、灰度发布请留意博客中的后续文章或关注kubernetes-handbook的更新。

Kubernetes Pod Cheat Sheet——Pod数据结构参考图

昨天晚上构思,今天花了一上午的时间翻阅了下kubernetes api reference,画了一个Kubernetes Pod Cheat Sheet。 从Pod的数据结构和API入手,管中窥豹,可见一斑。通过该图基本可以对kubernetes中这个最基本的object——Pod的功能和配置有一个感性的认识了,也许具体的某个组件的实现你不了解,但是从high level的视角来看待Pod整体有助于今后深入研究某个feature。 该图是根据kubernetes 1.6版本的Pod v1 core API绘制。 图片归档在kubernetes-handbook,请以GitHub中的图片为准。 注:在移动设备上打开该链接后会提示图片太大无法查看请选择Desktop version方可查看原图。 今后我将陆续推出其他object的cheat sheet,敬请关注。

kubernetes client-go包使用示例

(题图:青岛栈桥 May 26,2017) 前言 本文将归档到kubernetes-handbook的【开发指南—client-go示例】章节中,最终版本以kubernetes-handbook中为准。 本文中的代码见:https://github.com/rootsongjc/kubernetes-client-go-sample client-go示例 访问kubernetes集群有几下几种方式: 方式 特点 支持者 Kubernetes dashboard 直接通过Web UI进行操作,简单直接,可定制化程度低 官方支持 kubectl 命令行操作,功能最全,但是比较复杂,适合对其进行进一步的分装,定制功能,版本适配最好 官方支持 client-go 从kubernetes的代码中抽离出来的客户端包,简单易用,但需要小心区分kubernetes的API版本 官方支持 client-python python客户端,kubernetes-incubator 官方支持 Java client fabric8中的一部分,kubernetes的java客户端 redhat 下面,我们基于client-go,对Deployment升级镜像的步骤进行了定制,通过命令行传递一个Deployment的名字、应用容器名和新image名字的方式来升级。代码和使用方式见 https://github.com/rootsongjc/kubernetes-client-go-sample 。 kubernetes-client-go-sample 代码如下: package main import ( "flag" "fmt" "os" "path/filepath" "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/clientcmd" ) func main() { var kubeconfig *string if home := homeDir(); home !

kubernetes管理的容器命名规则解析

本文将归档到kubernetes-handbook的【运维管理-监控】章节中,最终版本以kubernetes-handbook中为准。 当我们通过cAdvisor获取到了容器的信息后,例如访问${NODE_IP}:4194/api/v1.3/docker获取的json结果中的某个容器包含如下字段: "labels": { "annotation.io.kubernetes.container.hash": "f47f0602", "annotation.io.kubernetes.container.ports": "[{\"containerPort\":80,\"protocol\":\"TCP\"}]", "annotation.io.kubernetes.container.restartCount": "0", "annotation.io.kubernetes.container.terminationMessagePath": "/dev/termination-log", "annotation.io.kubernetes.container.terminationMessagePolicy": "File", "annotation.io.kubernetes.pod.terminationGracePeriod": "30", "io.kubernetes.container.logpath": "/var/log/pods/d8a2e995-3617-11e7-a4b0-ecf4bbe5d414/php-redis_0.log", "io.kubernetes.container.name": "php-redis", "io.kubernetes.docker.type": "container", "io.kubernetes.pod.name": "frontend-2337258262-771lz", "io.kubernetes.pod.namespace": "default", "io.kubernetes.pod.uid": "d8a2e995-3617-11e7-a4b0-ecf4bbe5d414", "io.kubernetes.sandbox.id": "843a0f018c0cef2a5451434713ea3f409f0debc2101d2264227e814ca0745677" }, 这些信息其实都是kubernetes创建容器时给docker container打的Labels。 你是否想过这些label跟容器的名字有什么关系?当你在node节点上执行docker ps看到的容器名字又对应哪个应用的Pod呢? 在kubernetes代码中pkg/kubelet/dockertools/docker.go中的BuildDockerName方法定义了容器的名称规范。 这段容器名称定义代码如下: // Creates a name which can be reversed to identify both full pod name and container name. // This function returns stable name, unique name and a unique id. // Although rand.Uint32() is not really unique, but it's enough for us because error will // only occur when instances of the same container in the same pod have the same UID.

Kubernetes配置最佳实践

(题图:青岛 May 26,2017) 前言 本文档旨在汇总和强调用户指南、快速开始文档和示例中的最佳实践。该文档会很很活跃并持续更新中。如果你觉得很有用的最佳实践但是本文档中没有包含,欢迎给我们提Pull Request。 本文已上传到kubernetes-handbook中的第四章最佳实践章节,本文仅作归档,更新以kubernetes-handbook为准。 通用配置建议 定义配置文件的时候,指定最新的稳定API版本(目前是V1)。 在配置文件push到集群之前应该保存在版本控制系统中。这样当需要的时候能够快速回滚,必要的时候也可以快速的创建集群。 使用YAML格式而不是JSON格式的配置文件。在大多数场景下它们都可以作为数据交换格式,但是YAML格式比起JSON更易读和配置。 尽量将相关的对象放在同一个配置文件里。这样比分成多个文件更容易管理。参考guestbook-all-in-one.yaml文件中的配置(注意,尽管你可以在使用kubectl命令时指定配置文件目录,你也可以在配置文件目录下执行kubectl create——查看下面的详细信息)。 为了简化和最小化配置,也为了防止错误发生,不要指定不必要的默认配置。例如,省略掉ReplicationController的selector和label,如果你希望它们跟podTemplate中的label一样的话,因为那些配置默认是podTemplate的label产生的。更多信息请查看 guestbook app 的yaml文件和 examples 。 将资源对象的描述放在一个annotation中可以更好的内省。 裸奔的Pods vs Replication Controllers和 Jobs 如果有其他方式替代“裸奔的pod”(如没有绑定到replication controller 上的pod),那么就使用其他选择。在node节点出现故障时,裸奔的pod不会被重新调度。Replication Controller总是会重新创建pod,除了明确指定了restartPolicy: Never 的场景。Job 也许是比较合适的选择。 Services 通常最好在创建相关的replication controllers之前先创建service(没有这个必要吧?)你也可以在创建Replication Controller的时候不指定replica数量(默认是1),创建service后,在通过Replication Controller来扩容。这样可以在扩容很多个replica之前先确认pod是正常的。 除非时分必要的情况下(如运行一个node daemon),不要使用hostPort(用来指定暴露在主机上的端口号)。当你给Pod绑定了一个hostPort,该pod可被调度到的主机的受限了,因为端口冲突。如果是为了调试目的来通过端口访问的话,你可以使用 kubectl proxy and apiserver proxy 或者 kubectl port-forward。你可使用 Service 来对外暴露服务。如果你确实需要将pod的端口暴露到主机上,考虑使用 NodePort service。 跟hostPort一样的原因,避免使用 hostNetwork。 如果你不需要kube-proxy的负载均衡的话,可以考虑使用使用headless services。 使用Label 定义 labels 来指定应用或Deployment的 semantic attributes 。例如,不是将label附加到一组pod来显式表示某些服务(例如,service:myservice),或者显式地表示管理pod的replication controller(例如,controller:mycontroller),附加label应该是标示语义属性的标签, 例如{app:myapp,tier:frontend,phase:test,deployment:v3}。 这将允许您选择适合上下文的对象组——例如,所有的”tier:frontend“pod的服务或app是“myapp”的所有“测试”阶段组件。 有关此方法的示例,请参阅guestbook应用程序。 可以通过简单地从其service的选择器中省略特定于发行版本的标签,而不是更新服务的选择器来完全匹配replication controller的选择器,来实现跨越多个部署的服务,例如滚动更新。

微服务管理框架Istio简介

(题图:威海朱口 May 29,2017) 前言 本文已上传到kubernetes-handbook中的第五章微服务章节,本文仅作归档,更新以kubernetes-handbook为准。 Istio是由Google、IBM和Lyft开源的微服务管理、保护和监控框架。Istio为希腊语,意思是”起航“。 简介 使用istio可以很简单的创建具有负载均衡、服务间认证、监控等功能的服务网络,而不需要对服务的代码进行任何修改。你只需要在部署环境中,例如Kubernetes的pod里注入一个特别的sidecar proxy来增加对istio的支持,用来截获微服务之间的网络流量。 目前版本的istio只支持kubernetes,未来计划支持其他其他环境。 特性 使用istio的进行微服务管理有如下特性: 流量管理:控制服务间的流量和API调用流,使调用更可靠,增强不同环境下的网络鲁棒性。 可观测性:了解服务之间的依赖关系和它们之间的性质和流量,提供快速识别定位问题的能力。 策略实施:通过配置mesh而不是以改变代码的方式来控制服务之间的访问策略。 服务识别和安全:提供在mesh里的服务可识别性和安全性保护。 未来将支持多种平台,不论是kubernetes、Mesos、还是云。同时可以集成已有的ACL、日志、监控、配额、审计等。 架构 Istio架构分为控制层和数据层。 数据层:由一组智能代理(Envoy)作为sidecar部署,协调和控制所有microservices之间的网络通信。 控制层:负责管理和配置代理路由流量,以及在运行时执行的政策。 Envoy Istio使用Envoy代理的扩展版本,该代理是以C++开发的高性能代理,用于调解service mesh中所有服务的所有入站和出站流量。 Istio利用了Envoy的许多内置功能,例如动态服务发现,负载平衡,TLS终止,HTTP/2&gRPC代理,断路器,运行状况检查,基于百分比的流量拆分分阶段上线,故障注入和丰富指标。 Envoy在kubernetes中作为pod的sidecar来部署。 这允许Istio将大量关于流量行为的信号作为属性提取出来,这些属性又可以在Mixer中用于执行策略决策,并发送给监控系统以提供有关整个mesh的行为的信息。 Sidecar代理模型还允许你将Istio功能添加到现有部署中,无需重新构建或重写代码。 更多信息参见设计目标。 Mixer Mixer负责在service mesh上执行访问控制和使用策略,并收集Envoy代理和其他服务的遥测数据。代理提取请求级属性,发送到mixer进行评估。有关此属性提取和策略评估的更多信息,请参见Mixer配置。 混音器包括一个灵活的插件模型,使其能够与各种主机环境和基础架构后端进行接口,从这些细节中抽象出Envoy代理和Istio管理的服务。 Istio Manager Istio-Manager用作用户和Istio之间的接口,收集和验证配置,并将其传播到各种Istio组件。它从Mixer和Envoy中抽取环境特定的实现细节,为他们提供独立于底层平台的用户服务的抽象表示。 此外,流量管理规则(即通用4层规则和七层HTTP/gRPC路由规则)可以在运行时通过Istio-Manager进行编程。 Istio-auth Istio-Auth提供强大的服务间和最终用户认证,使用相互TLS,内置身份和凭据管理。它可用于升级service mesh中的未加密流量,并为运营商提供基于服务身份而不是网络控制的策略的能力。 Istio的未来版本将增加细粒度的访问控制和审计,以使用各种访问控制机制(包括属性和基于角色的访问控制以及授权hook)来控制和监控访问你服务、API或资源的人员。 参考 Istio开源平台发布,Google、IBM和Lyft分别承担什么角色? Istio:用于微服务的服务啮合层 Istio Overview

微服务管理框架istio安装笔记

(题图:威海东部海湾 May 28,2017) 前言 本文已上传到kubernetes-handbook中的第五章微服务章节,本文仅作归档,更新以kubernetes-handbook为准。 本文根据官网的文档整理而成,步骤包括安装istio 0.1.5并创建一个bookinfo的微服务来测试istio的功能。 文中使用的yaml文件可以在kubernetes-handbook的manifests/istio目录中找到,所有的镜像都换成了我的私有镜像仓库地址,请根据官网的镜像自行修改。 安装环境 CentOS 7.3.1611 Docker 1.12.6 Kubernetes 1.6.0 安装 1.下载安装包 下载地址:https://github.com/istio/istio/releases 下载Linux版本的当前最新版安装包 wget https://github.com/istio/istio/releases/download/0.1.5/istio-0.1.5-linux.tar.gz 2.解压 解压后,得到的目录结构如下: . ├── bin │ └── istioctl ├── install │ └── kubernetes │ ├── addons │ │ ├── grafana.yaml │ │ ├── prometheus.yaml │ │ ├── servicegraph.yaml │ │ └── zipkin.yaml │ ├── istio-auth.yaml │ ├── istio-rbac-alpha.yaml │ ├── istio-rbac-beta.yaml │ ├── istio.yaml │ ├── README.

使用filebeat收集kubernetes中的应用日志

(题图:民生现代美术馆 May 14,2017) 前言 本文已同步更新到Github仓库kubernetes-handbook中。 昨天写了篇文章使用Logstash收集Kubernetes的应用日志,发现logstash十分消耗内存(大约500M),经人提醒改用filebeat(大约消耗10几M内存),因此重写一篇使用filebeat收集kubernetes中的应用日志。 在进行日志收集的过程中,我们首先想到的是使用Logstash,因为它是ELK stack中的重要成员,但是在测试过程中发现,Logstash是基于JDK的,在没有产生日志的情况单纯启动Logstash就大概要消耗500M内存,在每个Pod中都启动一个日志收集组件的情况下,使用logstash有点浪费系统资源,经人推荐我们选择使用Filebeat替代,经测试单独启动Filebeat容器大约会消耗12M内存,比起logstash相当轻量级。 方案选择 Kubernetes官方提供了EFK的日志收集解决方案,但是这种方案并不适合所有的业务场景,它本身就有一些局限性,例如: 所有日志都必须是out前台输出,真实业务场景中无法保证所有日志都在前台输出 只能有一个日志输出文件,而真实业务场景中往往有多个日志输出文件 Fluentd并不是常用的日志收集工具,我们更习惯用logstash,现使用filebeat替代 我们已经有自己的ELK集群且有专人维护,没有必要再在kubernetes上做一个日志收集服务 基于以上几个原因,我们决定使用自己的ELK集群。 Kubernetes集群中的日志收集解决方案 编号 方案 优点 缺点 1 每个app的镜像中都集成日志收集组件 部署方便,kubernetes的yaml文件无须特别配置,可以为每个app自定义日志收集配置 强耦合,不方便应用和日志收集组件升级和维护且会导致镜像过大 2 单独创建一个日志收集组件跟app的容器一起运行在同一个pod中 低耦合,扩展性强,方便维护和升级 需要对kubernetes的yaml文件进行单独配置,略显繁琐 3 将所有的Pod的日志都挂载到宿主机上,每台主机上单独起一个日志收集Pod 完全解耦,性能最高,管理起来最方便 需要统一日志收集规则,目录和输出方式 综合以上优缺点,我们选择使用方案二。 该方案在扩展性、个性化、部署和后期维护方面都能做到均衡,因此选择该方案。 我们创建了自己的logstash镜像。创建过程和使用方式见https://github.com/rootsongjc/docker-images 镜像地址:index.tenxcloud.com/jimmy/filebeat:5.4.0 测试 我们部署一个应用对logstash的日志收集功能进行测试。 创建应用yaml文件fielbeat-test.yaml。 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: filebeat-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: filebeat-test spec: containers: - image: sz-pg-oam-docker-hub-001.

使用Logstash收集Kubernetes的应用日志

(题图:798艺术区 May 14,2017) 前言 本文同步更新到Github仓库kubernetes-handbook中。 很多企业内部都有自己的ElasticSearch集群,我们没有必要在kubernetes集群内部再部署一个,而且这样还难于管理,因此我们考虑在容器里部署logstash收集日志到已有的ElasticSearch集群中。 方案选择 Kubernetes官方提供了EFK的日志收集解决方案,但是这种方案并不适合所有的业务场景,它本身就有一些局限性,例如: 所有日志都必须是out前台输出,真实业务场景中无法保证所有日志都在前台输出 只能有一个日志输出文件,而真实业务场景中往往有多个日志输出文件 Fluentd并不是常用的日志收集工具,我们更习惯用logstash 我们已经有自己的ELK集群且有专人维护,没有必要再在kubernetes上做一个日志收集服务 基于以上几个原因,我们决定使用自己的ELK集群。 Kubernetes集群中的日志收集解决方案 编号 方案 优点 缺点 1 每个app的镜像中都集成日志收集组件 部署方便,kubernetes的yaml文件无须特别配置,可以为每个app自定义日志收集配置 强耦合,不方便应用和日志收集组件升级和维护且会导致镜像过大 2 单独创建一个日志收集组件跟app的容器一起运行在同一个pod中 低耦合,扩展性强,方便维护和升级 需要对kubernetes的yaml文件进行单独配置,略显繁琐 3 将所有的Pod的日志都挂载到宿主机上,每台主机上单独起一个日志收集Pod 完全解耦,性能最高,管理起来最方便 需要统一日志收集规则,目录和输出方式 综合以上优缺点,我们选择使用方案二。 该方案在扩展性、个性化、部署和后期维护方面都能做到均衡,因此选择该方案。 我们创建了自己的logstash镜像。创建过程和使用方式见https://github.com/rootsongjc/docker-images 镜像地址:index.tenxcloud.com/jimmy/logstash:5.3.0 测试 我们部署一个应用对logstash的日志收集功能进行测试。 创建应用yaml文件logstash-test.yaml。 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: logstash-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: logstash-test spec: containers: - image: sz-pg-oam-docker-hub-001.

Kubernete概念解析之Deployment

(题图:京广桥@北京国贸 Apr 30,2017) 前言 本文同步更新到Github仓库kubernetes-handbook中。 本文翻译自kubernetes官方文档:https://github.com/kubernetes/kubernetes.github.io/blob/master/docs/concepts/workloads/controllers/deployment.md 本文章根据2017年5月10日的Commit 8481c02翻译。 Deployment是Kubernetes中的一个非常重要的概念,从它开始是了解kubernetes中资源概念的一个很好的切入点,看到网上也没什么详细的说明文档,我就随手翻译了一下官方文档(Github中的文档),kubernetes官网上的文档还没有这个新。这篇文章对Deployment的概念解释的面面俱到十分详尽。 Deployment是什么? Deployment为Pod和Replica Set(下一代Replication Controller)提供声明式更新。 你只需要在Deployment中描述你想要的目标状态是什么,Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment。 一个典型的用例如下: 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态,看它是成功还是失败。 然后,通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet,Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。 如果当前状态不稳定,回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。 扩容Deployment以满足更高的负载。 暂停Deployment来应用PodTemplateSpec的多个修复,然后恢复上线。 根据Deployment 的状态判断上线是否hang住了。 清楚旧的不必要的ReplicaSet。 创建Deployment 下面是一个Deployment示例,它创建了一个Replica Set来启动3个nginx pod。 下载示例文件并执行命令: $ kubectl create -f docs/user-guide/nginx-deployment.yaml --record deployment "nginx-deployment" created 将kubectl的 —record 的flag设置为 true可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个Deployment revision中执行了哪些命令。 然后立即执行getí将获得如下结果: $ kubectl get deployments NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx-deployment 3 0 0 0 1s 输出结果表明我们希望的repalica数是3(根据deployment中的.spec.replicas配置)当前replica数( .status.replicas)是0, 最新的replica数(.status.updatedReplicas)是0,可用的replica数(.status.availableReplicas)是0。

Kubernetes中的Rolling Update服务滚动升级

(题图:后海夜色 Apr 30,2017) 前言 本文已同步到gitbook kubernetes-handbook的第8章第1节。 本文说明在Kubernetes1.6中服务如何滚动升级,并对其进行测试。 当有镜像发布新版本,新版本服务上线时如何实现服务的滚动和平滑升级? 如果你使用ReplicationController创建的pod可以使用kubectl rollingupdate命令滚动升级,如果使用的是Deployment创建的Pod可以直接修改yaml文件后执行kubectl apply即可。 Deployment已经内置了RollingUpdate strategy,因此不用再调用kubectl rollingupdate命令,升级的过程是先创建新版的pod将流量导入到新pod上后销毁原来的旧的pod。 Rolling Update适用于Deployment、Replication Controller,官方推荐使用Deployment而不再使用Replication Controller。 使用ReplicationController时的滚动升级请参考官网说明:https://kubernetes.io/docs/tasks/run-application/rolling-update-replication-controller/ ReplicationController与Deployment的关系 ReplicationController和Deployment的RollingUpdate命令有些不同,但是实现的机制是一样的,关于这两个kind的关系我引用了ReplicationController与Deployment的区别中的部分内容如下,详细区别请查看原文。 ReplicationController Replication Controller为Kubernetes的一个核心内容,应用托管到Kubernetes之后,需要保证应用能够持续的运行,Replication Controller就是这个保证的key,主要的功能如下: 确保pod数量:它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod,Replication Controller会创建新的,反之则会删除掉多余的以保证Pod数量不变。 确保pod健康:当pod不健康,运行出错或者无法提供服务时,Replication Controller也会杀死不健康的pod,重新创建新的。 弹性伸缩 :在业务高峰或者低峰期的时候,可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时,配置相应的监控功能(Hroizontal Pod Autoscaler),会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况,做到自动伸缩。 滚动升级:滚动升级为一种平滑的升级方式,通过逐步替换的策略,保证整体系统的稳定,在初始化升级的时候就可以及时发现和解决问题,避免问题不断扩大。 Deployment Deployment同样为Kubernetes的一个核心内容,主要职责同样是为了保证pod的数量和健康,90%的功能与Replication Controller完全一样,可以看做新一代的Replication Controller。但是,它又具备了Replication Controller之外的新特性: Replication Controller全部功能:Deployment继承了上面描述的Replication Controller全部功能。 事件和状态查看:可以查看Deployment的升级详细进度和状态。 回滚:当升级pod镜像或者相关参数的时候发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。 版本记录: 每一次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。 暂停和启动:对于每一次升级,都能够随时暂停和启动。 多种升级方案:Recreate:删除所有已存在的pod,重新创建新的; RollingUpdate:滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。 创建测试镜像 我们来创建一个特别简单的web服务,当你访问网页时,将输出一句版本信息。通过区分这句版本信息输出我们就可以断定升级是否完成。 所有配置和代码见Github上的manifests/test/rolling-update-test目录。 Web服务的代码main.go package main import ( "fmt" "log" "net/http" ) func sayhello(w http.

Kubernetes的边缘节点配置

(题图:南屏晚钟@圆明园 May 6,2017) 前言 为了配置kubernetes中的traefik ingress的高可用,对于kubernetes集群以外只暴露一个访问入口,需要使用keepalived排除单点问题。本文参考了kube-keepalived-vip,但并没有使用容器方式安装,而是直接在node节点上安装。 本文已同步到gitbook kubernetes-handbook的第2章第5节。 定义 首先解释下什么叫边缘节点(Edge Node),所谓的边缘节点即集群内部用来向集群外暴露服务能力的节点,集群外部的服务通过该节点来调用集群内部的服务,边缘节点是集群内外交流的一个Endpoint。 边缘节点要考虑两个问题 边缘节点的高可用,不能有单点故障,否则整个kubernetes集群将不可用 对外的一致暴露端口,即只能有一个外网访问IP和端口 架构 为了满足边缘节点的以上需求,我们使用keepalived来实现。 在Kubernetes集群外部配置nginx来访问边缘节点的VIP。 选择Kubernetes的三个node作为边缘节点,并安装keepalived。 准备 复用kubernetes测试集群的三台主机。 172.20.0.113 172.20.0.114 172.20.0.115 安装 使用keepalived管理VIP,VIP是使用IPVS创建的,IPVS已经成为linux内核的模块,不需要安装 LVS的工作原理请参考:http://www.cnblogs.com/codebean/archive/2011/07/25/2116043.html 不使用镜像方式安装了,直接手动安装,指定三个节点为边缘节点(Edge node)。 因为我们的测试集群一共只有三个node,所有在在三个node上都要安装keepalived和ipvsadmin。 yum install keepalived ipvsadm 配置说明 需要对原先的traefik ingress进行改造,从以Deployment方式启动改成DeamonSet。还需要指定一个与node在同一网段的IP地址作为VIP,我们指定成172.20.0.119,配置keepalived前需要先保证这个IP没有被分配。。 Traefik以DaemonSet的方式启动 通过nodeSelector选择边缘节点 通过hostPort暴露端口 当前VIP漂移到了172.20.0.115上 Traefik根据访问的host和path配置,将流量转发到相应的service上 配置keepalived 参考基于keepalived 实现VIP转移,lvs,nginx的高可用,配置keepalived。 keepalived的官方配置文档见:http://keepalived.org/pdf/UserGuide.pdf 配置文件/etc/keepalived/keepalived.conf文件内容如下: ! Configuration File for keepalived global_defs { notification_email { root@localhost } notification_email_from kaadmin@localhost smtp_server 127.0.0.1 smtp_connect_timeout 30 router_id LVS_DEVEL } vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 172.

在kubernetes中使用glusterfs做持久化存储

(题图:无题@北京奥林匹克森林公园 May 1,2017) 前言 本文章已同步到kubernetes-handbook 7.1章节。 Kubernetes集群沿用跟我一起部署kubernetes1.6集群中的三台机器。 我们复用kubernetes集群的这三台主机做glusterfs存储。 以下步骤参考自:https://www.xf80.com/2017/04/21/kubernetes-glusterfs/ 安装glusterfs 我们直接在物理机上使用yum安装,如果你选择在kubernetes上安装,请参考:https://github.com/gluster/gluster-kubernetes/blob/master/docs/setup-guide.md # 先安装 gluster 源 $ yum install centos-release-gluster -y # 安装 glusterfs 组件 $ yum install -y glusterfs glusterfs-server glusterfs-fuse glusterfs-rdma glusterfs-geo-replication glusterfs-devel ## 创建 glusterfs 目录 $ mkdir /opt/glusterd ## 修改 glusterd 目录 $ sed -i 's/var\/lib/opt/g' /etc/glusterfs/glusterd.vol # 启动 glusterfs $ systemctl start glusterd.service # 设置开机启动 $ systemctl enable glusterd.service #查看状态 $ systemctl status glusterd.service 配置 glusterfs # 配置 hosts $ vi /etc/hosts 172.

Kubernetes网络和集群性能测试

(题图:无题@安贞门 Jun 18,2016) 前言 该测试是为了测试在不同的场景下,访问kubernetes的延迟以及kubernetes的性能。进行以下测试前,你需要有一个部署好的kubernetes集群,关于如何部署kuberentes1.6集群,请参考kubernetes-handbook。 准备 测试环境 在以下几种环境下进行测试: Kubernetes集群node节点上通过Cluster IP方式访问 Kubernetes集群内部通过service访问 Kubernetes集群外部通过traefik ingress暴露的地址访问 测试地址 Cluster IP: 10.254.149.31 Service Port:8000 Ingress Host:traefik.sample-webapp.io 测试工具 Locust:一个简单易用的用户负载测试工具,用来测试web或其他系统能够同时处理的并发用户数。 curl kubemark 测试程序:sample-webapp,源码见Github kubernetes的分布式负载测试 测试说明 通过向sample-webapp发送curl请求获取响应时间,直接curl后的结果为: $ curl "http://10.254.149.31:8000/" Welcome to the "Distributed Load Testing Using Kubernetes" sample web app 网络延迟测试 场景一、 Kubernetes集群node节点上通过Cluster IP访问 测试命令 curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{time_total}' "http://10.254.149.31:8000/" 10组测试结果 No time_connect time_starttransfer time_total 1 0.

运用kubernetes进行分布式负载测试

(题图:Kubrick Book Store Mar 25,2016) 前言 Github地址https://github.com/rootsongjc/distributed-load-testing-using-kubernetes 该教程描述如何在Kubernetes中进行分布式负载均衡测试,包括一个web应用、docker镜像和Kubernetes controllers/services。更多资料请查看Distributed Load Testing Using Kubernetes 。 注意:该测试是在我自己本地搭建的kubernetes集群上测试的,不需要使用Google Cloud Platform。 准备 不需要GCE及其他组件,你只需要有一个kubernetes集群即可。 如果你还没有kubernetes集群,可以参考kubernetes-handbook部署一个。 部署Web应用 sample-webapp 目录下包含一个简单的web测试应用。我们将其构建为docker镜像,在kubernetes中运行。你可以自己构建,也可以直接用这个我构建好的镜像index.tenxcloud.com/jimmy/k8s-sample-webapp:latest。 在kubernetes上部署sample-webapp。 $ cd kubernetes-config $ kubectl create -f sample-webapp-controller.yaml $ kubectl create -f kubectl create -f sample-webapp-service.yaml 部署Locust的Controller和Service locust-master和locust-work使用同样的docker镜像,修改cotnroller中spec.template.spec.containers.env字段中的value为你sample-webapp service的名字。 - name: TARGET_HOST value: http://sample-webapp:8000 创建Controller Docker镜像(可选) locust-master和locust-work controller使用的都是locust-tasks docker镜像。你可以直接下载gcr.io/cloud-solutions-http://olz1di9xf.bkt.clouddn.com/locust-tasks,也可以自己编译。自己编译大概要花几分钟时间,镜像大小为820M。 $ docker build -t index.tenxcloud.com/jimmy/locust-tasks:latest . $ docker push index.tenxcloud.com/jimmy/locust-tasks:latest 注意:我使用的是时速云的镜像仓库。 每个controller的yaml的spec.template.spec.containers.image 字段指定的是我的镜像:

Kubernetes中的IP和服务发现体系

(题图:路边的野花@朝阳公园 Nov 8,2015) Cluster IP 即Service的IP,通常在集群内部使用Service Name来访问服务,用户不需要知道该IP地址,kubedns会自动根据service name解析到服务的IP地址,将流量分发给Pod。 Service Name才是对外暴露服务的关键。 在kubeapi的配置中指定该地址范围。 默认配置 --service-cluster-ip-range=10.254.0.0/16 --service-node-port-range=30000-32767 Pod IP 通过配置flannel的network和subnet来实现。 默认配置 FLANNEL_NETWORK=172.30.0.0/16 FLANNEL_SUBNET=172.30.46.1/24 Pod的IP地址不固定,当pod重启时IP地址会变化。 该IP地址也是用户无需关心的。 但是Flannel会在本地生成相应IP段的虚拟网卡,为了防止和集群中的其他IP地址冲突,需要规划IP段。 主机/Node IP 物理机的IP地址,即kubernetes管理的物理机的IP地址。 $ kubectl get nodes NAME STATUS AGE VERSION 172.20.0.113 Ready 12d v1.6.0 172.20.0.114 Ready 12d v1.6.0 172.20.0.115 Ready 12d v1.6.0 服务发现 集群内部的服务发现 通过DNS即可发现,kubends是kubernetes的一个插件,不同服务之间可以直接使用service name访问。 通过sericename:port即可调用服务。 服务外部的服务发现 通过Ingress来实现,我们是用的Traefik来实现。 参考 Ingress解析 Kubernetes Traefik Ingress安装试用

Kubernetes中的RBAC支持

(题图:无题 Apr 2,2016) 在Kubernetes1.6版本中新增角色访问控制机制(Role-Based Access,RBAC)让集群管理员可以针对特定使用者或服务账号的角色,进行更精确的资源访问控制。在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。 前言 本文翻译自RBAC Support in Kubernetes,转载自kubernetes中文社区,译者催总,Jimmy Song做了稍许修改。该文章是5天内了解Kubernetes1.6新特性的系列文章之一。 One of the highlights of the Kubernetes 1.6中的一个亮点时RBAC访问控制机制升级到了beta版本。RBAC,基于角色的访问控制机制,是用来管理kubernetes集群中资源访问权限的机制。使用RBAC可以很方便的更新访问授权策略而不用重启集群。 本文主要关注新特性和最佳实践。 RBAC vs ABAC 目前kubernetes中已经有一系列l 鉴权机制。鉴权的作用是,决定一个用户是否有权使用 Kubernetes API 做某些事情。它除了会影响 kubectl 等组件之外,还会对一些运行在集群内部并对集群进行操作的软件产生作用,例如使用了 Kubernetes 插件的 Jenkins,或者是利用 Kubernetes API 进行软件部署的 Helm。ABAC 和 RBAC 都能够对访问策略进行配置。 ABAC(Attribute Based Access Control)本来是不错的概念,但是在 Kubernetes 中的实现比较难于管理和理解,而且需要对 Master 所在节点的 SSH 和文件系统权限,而且要使得对授权的变更成功生效,还需要重新启动 API Server。 而 RBAC 的授权策略可以利用 kubectl 或者 Kubernetes API 直接进行配置。RBAC 可以授权给用户,让用户有权进行授权管理,这样就可以无需接触节点,直接进行授权管理。RBAC 在 Kubernetes 中被映射为 API 资源和操作。 因为 Kubernetes 社区的投入和偏好,相对于 ABAC 而言,RBAC 是更好的选择。

Kubernetes traefik ingress安装试用

(题图:🐟@鱼缸 Sep 15,2016) 前言 昨天翻了下Ingress解析,然后安装试用了下traefik,过程已同步到kubernetes-handbook上,Github地址https://github.com/rootsongjc/kubernetes-handbook Ingress简介 如果你还不了解,ingress是什么,可以先看下我翻译的Kubernetes官网上ingress的介绍Kubernetes Ingress解析。 理解Ingress 简单的说,ingress就是从kubernetes集群外访问集群的入口,将用户的URL请求转发到不同的service上。Ingress相当于nginx、apache等负载均衡方向代理服务器,其中还包括规则定义,即URL的路由信息,路由信息得的刷新由Ingress controller来提供。 理解Ingress Controller Ingress Controller 实质上可以理解为是个监视器,Ingress Controller 通过不断地跟 kubernetes API 打交道,实时的感知后端 service、pod 等变化,比如新增和减少 pod,service 增加与减少等;当得到这些变化信息后,Ingress Controller 再结合下文的 Ingress 生成配置,然后更新反向代理负载均衡器,并刷新其配置,达到服务发现的作用。 部署Traefik 介绍traefik Traefik是一款开源的反向代理与负载均衡工具。它最大的优点是能够与常见的微服务系统直接整合,可以实现自动化动态配置。目前支持Docker, Swarm, Mesos/Marathon, Mesos, Kubernetes, Consul, Etcd, Zookeeper, BoltDB, Rest API等等后端模型。 以下配置文件可以在kubernetes-handbookGitHub仓库中的manifests/traefik-ingress/目录下找到。 创建ingress-rbac.yaml 将用于service account验证。 apiVersion: v1 kind: ServiceAccount metadata: name: ingress namespace: kube-system --- kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: ingress subjects: - kind: ServiceAccount name: ingress namespace: kube-system roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac.

Kubernetes ingress解析

(题图:朝阳门银河SOHO Jan 31,2016) 前言 这是kubernete官方文档中Ingress Resource的翻译,因为最近工作中用到,文章也不长,也很好理解,索性翻译一下,也便于自己加深理解,同时造福kubernetes中文社区。后续准备使用Traefik来做Ingress controller,文章末尾给出了几个相关链接,实际使用案例正在摸索中,届时相关安装文档和配置说明将同步更新到kubernetes-handbook中。 术语 在本篇文章中你将会看到一些在其他地方被交叉使用的术语,为了防止产生歧义,我们首先来澄清下。 节点:Kubernetes集群中的一台物理机或者虚拟机。 集群:位于Internet防火墙后的节点,这是kubernetes管理的主要计算资源。 边界路由器:为集群强制执行防火墙策略的路由器。 这可能是由云提供商或物理硬件管理的网关。 集群网络:一组逻辑或物理链接,可根据Kubernetes网络模型实现群集内的通信。 集群网络的实现包括Overlay模型的 flannel 和基于SDN的OVS。 服务:使用标签选择器标识一组pod成为的Kubernetes服务。 除非另有说明,否则服务假定在集群网络内仅可通过虚拟IP访问。 什么是Ingress? 通常情况下,service和pod仅可在集群内部网络中通过IP地址访问。所有到达边界路由器的流量或被丢弃或被转发到其他地方。从概念上讲,可能像下面这样: internet | ------------ [ Services ] Ingress是授权入站连接到达集群服务的规则集合。 internet | [ Ingress ] --|-----|-- [ Services ] 你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现Ingress,通常使用负载平衡器,它还可以配置边界路由和其他前端,这有助于以HA方式处理流量。 先决条件 在使用Ingress resource之前,有必要先了解下面几件事情。Ingress是beta版本的resource,在kubernetes1.1之前还没有。你需要一个Ingress Controller来实现Ingress,单纯的创建一个Ingress没有任何意义。 GCE/GKE会在master节点上部署一个ingress controller。你可以在一个pod中部署任意个自定义的ingress controller。你必须正确地annotate每个ingress,比如 运行多个ingress controller 和 关闭glbc. 确定你已经阅读了Ingress controller的beta版本限制。在非GCE/GKE的环境中,你需要在pod中部署一个controller。 Ingress Resource 最简化的Ingress配置: 1: apiVersion: extensions/v1beta1 2: kind: Ingress 3: metadata: 4: name: test-ingress 5: spec: 6: rules: 7: - http: 8: paths: 9: - path: /testpath 10: backend: 11: serviceName: test 12: servicePort: 80 如果你没有配置Ingress controller就将其POST到API server不会有任何用处

Kubernetes Handbook发起

(题图:地坛公园 Sep 27,2015) 玩转Kubernetes,我就看kubernetes handbook! GitHub地址:https://github.com/rootsongjc/kubernetes-handbook 文章同步更新到gitbook,方便大家浏览和下载PDF。 说明 文中涉及的配置文件和代码链接在gitbook中会无法打开,请下载github源码后,在MarkDown编辑器中打开,点击链接将跳转到你的本地目录。 如何使用 方式一:在线浏览 访问gitbook:https://www.gitbook.com/book/rootsongjc/kubernetes-handbook/ 方式二:本地查看 将代码克隆到本地 安装gitbook:Setup and Installation of GitBook 执行gitbook serve 在浏览器中访问http://localhost:4000 P.S 本书中也将记录业界动态和经验分享,欢迎分享你的独到见解。 加入Kubernetes交流群,请添加我微信jimmysong。

Kubernetes1.6集群部署完全指南 ——二进制文件部署开启TLS基于CentOS7发布

(题图:清晨@首都机场 Aug 13,2016) 这可能是目前为止最详细的kubernetes安装文档了。 经过几天的安装、调试、整理,今天该文档终于发布了。 你可以在这里看到文档和配置文件和我一步步部署 kubernetes1.6 集群。 或者直接下载pdf版本(2.92M)。 Kubernetes的安装繁琐,步骤复杂,该文档能够帮助跳过很多坑,节约不少时间,我在本地环境上已经安装完成,有问题欢迎在GitHub上提issue。 安装的集群详情 Kubernetes 1.6.0 Docker 1.12.5(使用yum安装) Etcd 3.1.5 Flanneld 0.7 vxlan 网络 TLS 认证通信 (所有组件,如 etcd、kubernetes master 和 node) RBAC 授权 kublet TLS BootStrapping kubedns、dashboard、heapster(influxdb、grafana)、EFK(elasticsearch、fluentd、kibana) 集群插件 私有docker镜像仓库harbor(请自行部署,harbor提供离线安装包,直接使用docker-compose启动即可) 该文档中包括以下几个步骤 创建 TLS 通信所需的证书和秘钥 创建 kubeconfig 文件 创建三节点的高可用 etcd 集群 kubectl命令行工具 部署高可用 master 集群 部署 node 节点 kubedns 插件 Dashboard 插件 Heapster 插件 EFK 插件

在开启TLS的Kubernetes1.6集群上安装EFK

(题图:簋街 Jun 17,2016) 前言 这是和我一步步部署kubernetes集群项目(fork自opsnull)中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,在开启了TLS验证的集群中部署EFK日志收集监控插件。 配置和安装 EFK 官方文件目录:cluster/addons/fluentd-elasticsearch $ ls *.yaml es-controller.yaml es-service.yaml fluentd-es-ds.yaml kibana-controller.yaml kibana-service.yaml efk-rbac.yaml 同样EFK服务也需要一个efk-rbac.yaml文件,配置serviceaccount为efk。 已经修改好的 yaml 文件见:EFK 配置 es-controller.yaml $ diff es-controller.yaml.orig es-controller.yaml 24c24 < - image: gcr.io/google_containers/elasticsearch:v2.4.1-2 --- > - image: sz-pg-oam-docker-hub-001.tendcloud.com/library/elasticsearch:v2.4.1-2 配置 es-service.yaml 无需配置; 配置 fluentd-es-ds.yaml $ diff fluentd-es-ds.yaml.orig fluentd-es-ds.yaml 26c26 < image: gcr.io/google_containers/fluentd-elasticsearch:1.22 --- > image: sz-pg-oam-docker-hub-001.tendcloud.com/library/fluentd-elasticsearch:1.22 配置 kibana-controller.yaml $ diff kibana-controller.yaml.orig kibana-controller.yaml 22c22 < image: gcr.io/google_containers/kibana:v4.6.1-1 --- > image: sz-pg-oam-docker-hub-001.

在开启TLS的Kubernetes1.6集群上安装heapster

(题图:大喵 Aug 8,2016) 前言 这是和我一步步部署kubernetes集群项目(fork自opsnull)中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,在开启了TLS验证的集群中部署heapster,包括influxdb、grafana等组件。 配置和安装Heapster 到 heapster release 页面 下载最新版本的 heapster。 $ wget https://github.com/kubernetes/heapster/archive/v1.3.0.zip $ unzip v1.3.0.zip $ mv v1.3.0.zip heapster-1.3.0 文件目录: heapster-1.3.0/deploy/kube-config/influxdb $ cd heapster-1.3.0/deploy/kube-config/influxdb $ ls *.yaml grafana-deployment.yaml grafana-service.yaml heapster-deployment.yaml heapster-service.yaml influxdb-deployment.yaml influxdb-service.yaml heapster-rbac.yaml 我们自己创建了heapster的rbac配置heapster-rbac.yaml。 已经修改好的 yaml 文件见:heapster 配置 grafana-deployment $ diff grafana-deployment.yaml.orig grafana-deployment.yaml 16c16 < image: gcr.io/google_containers/heapster-grafana-amd64:v4.0.2 --- > image: sz-pg-oam-docker-hub-001.tendcloud.com/library/heapster-grafana-amd64:v4.0.2 40,41c40,41 < # value: /api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/ < value: / --- > value: /api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/ > #value: / 如果后续使用 kube-apiserver 或者 kubectl proxy 访问 grafana dashboard,则必须将 GF_SERVER_ROOT_URL 设置为 /api/v1/proxy/namespaces/kube-system/services/monitoring-grafana/,否则后续访问grafana时访问时提示找不到http://10.

在开启TLS的Kubernetes1.6集群上安装dashboard

(题图:东直门桥 Aug 20,2016) 前言 这是和我一步步部署kubernetes集群项目(fork自opsnull)中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,在开启了TLS验证的集群中部署dashboard。 感谢opsnull和ipchy的细心解答。 安装环境配置信息 CentOS 7.2.1511 Docker 1.12.5 Flannel 0.7 Kubernetes 1.6.0 配置和安装 dashboard 官方文件目录:kubernetes/cluster/addons/dashboard 我们使用的文件 $ ls *.yaml dashboard-controller.yaml dashboard-service.yaml dashboard-rbac.yaml 已经修改好的 yaml 文件见:dashboard 由于 kube-apiserver 启用了 RBAC 授权,而官方源码目录的 dashboard-controller.yaml 没有定义授权的 ServiceAccount,所以后续访问 kube-apiserver 的 API 时会被拒绝,web中提示: Forbidden (403) User "system:serviceaccount:kube-system:default" cannot list jobs.batch in the namespace "default". (get jobs.batch) 增加了一个dashboard-rbac.yaml文件,定义一个名为 dashboard 的 ServiceAccount,然后将它和 Cluster Role view 绑定。 配置dashboard-service $ diff dashboard-service.yaml.orig dashboard-service.

Kubernetes安装之kubedns配置

(题图:雨过天晴@北京定福庄 Aug 27,2016) 前言 这是和我一步步部署kubernetes集群项目(fork自opsnull)中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,使用yaml文件部署kubedns。 安装环境配置信息 CentOS 7.2.1511 Docker 1.12.5 Flannel 0.7 Kubernetes 1.6.0 安装和配置 kubedns 插件 官方的yaml文件目录:kubernetes/cluster/addons/dns。 该插件直接使用kubernetes部署,官方的配置文件中包含以下镜像: gcr.io/google_containers/k8s-dns-dnsmasq-nanny-amd64:1.14.1 gcr.io/google_containers/k8s-dns-kube-dns-amd64:1.14.1 gcr.io/google_containers/k8s-dns-sidecar-amd64:1.14.1 我clone了上述镜像,上传到我的私有镜像仓库: sz-pg-oam-docker-hub-001.tendcloud.com/library/k8s-dns-dnsmasq-nanny-amd64:1.14.1 sz-pg-oam-docker-hub-001.tendcloud.com/library/k8s-dns-kube-dns-amd64:1.14.1 sz-pg-oam-docker-hub-001.tendcloud.com/library/k8s-dns-sidecar-amd64:1.14.1 同时上传了一份到时速云备份: index.tenxcloud.com/jimmy/k8s-dns-dnsmasq-nanny-amd64:1.14.1 index.tenxcloud.com/jimmy/k8s-dns-kube-dns-amd64:1.14.1 index.tenxcloud.com/jimmy/k8s-dns-sidecar-amd64:1.14.1 以下yaml配置文件中使用的是私有镜像仓库中的镜像。 kubedns-cm.yaml kubedns-sa.yaml kubedns-controller.yaml kubedns-svc.yaml 已经修改好的 yaml 文件见:github项目中的manifest/kubedns/目录。 系统预定义的 RoleBinding 预定义的 RoleBinding system:kube-dns 将 kube-system 命名空间的 kube-dns ServiceAccount 与 system:kube-dns Role 绑定, 该 Role 具有访问 kube-apiserver DNS 相关 API 的权限; $ kubectl get clusterrolebindings system:kube-dns -o yaml apiVersion: rbac.

Kubernetes高可用master节点安装

(题图:鬼见愁@北京西山 Sep 14,2015) 前言 这是和我一步步部署kubernetes集群项目((fork自opsnull))中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,部署master节点的kube-apiserver、kube-controller-manager和kube-scheduler的过程。 高可用kubernetes master节点安装 kubernetes master 节点包含的组件: kube-apiserver kube-scheduler kube-controller-manager 目前这三个组件需要部署在同一台机器上。 kube-scheduler、kube-controller-manager 和 kube-apiserver 三者的功能紧密相关; 同时只能有一个 kube-scheduler、kube-controller-manager 进程处于工作状态,如果运行多个,则需要通过选举产生一个 leader; 本文档记录部署一个三个节点的高可用 kubernetes master 集群步骤。(后续创建一个 load balancer 来代理访问 kube-apiserver 的请求) TLS 证书文件 pem和token.csv证书文件我们在TLS证书和秘钥这一步中已经创建过了。我们再检查一下。 $ ls /etc/kubernetes/ssl admin-key.pem admin.pem ca-key.pem ca.pem kube-proxy-key.pem kube-proxy.pem kubernetes-key.pem kubernetes.pem 下载最新版本的二进制文件 有两种下载方式 方式一 从 github release 页面 下载发布版 tarball,解压后再执行下载脚本 $ wget https://github.com/kubernetes/kubernetes/releases/download/v1.6.0/kubernetes.tar.gz $ tar -xzvf kubernetes.tar.gz ... $ cd kubernetes $ .

Kubernetes安装之etcd高可用配置

(题图:北京夜景@西山) 前言 这是和我一步步部署kubernetes集群项目((fork自opsnull))中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,生成kubeconfig文件的过程。 创建高可用 etcd 集群 kuberntes 系统使用 etcd 存储所有数据,本文档介绍部署一个三节点高可用 etcd 集群的步骤,这三个节点复用 kubernetes master 机器,分别命名为sz-pg-oam-docker-test-001.tendcloud.com、sz-pg-oam-docker-test-002.tendcloud.com、sz-pg-oam-docker-test-003.tendcloud.com: sz-pg-oam-docker-test-001.tendcloud.com:172.20.0.113 sz-pg-oam-docker-test-002.tendcloud.com:172.20.0.114 sz-pg-oam-docker-test-003.tendcloud.com:172.20.0.115 TLS 认证文件 需要为 etcd 集群创建加密通信的 TLS 证书,这里复用以前创建的 kubernetes 证书 $ cp ca.pem kubernetes-key.pem kubernetes.pem /etc/kubernetes/ssl kubernetes 证书的 hosts 字段列表中包含上面三台机器的 IP,否则后续证书校验会失败; 下载二进制文件 到 https://github.com/coreos/etcd/releases 页面下载最新版本的二进制文件 $ https://github.com/coreos/etcd/releases/download/v3.1.5/etcd-v3.1.5-linux-amd64.tar.gz $ tar -xvf etcd-v3.1.4-linux-amd64.tar.gz $ sudo mv etcd-v3.1.4-linux-amd64/etcd* /root/local/bin 创建 etcd 的 systemd unit 文件 注意替换 ETCD_NAME 和 INTERNAL_IP 变量的值;

Kubernetes安装之创建kubeconfig文件

(题图:北海公园 May 8,2016) 前言 这是和我一步步部署kubernetes集群项目((fork自opsnull))中的一篇文章,下文是结合我之前部署kubernetes的过程产生的kuberentes环境,生成kubeconfig文件的过程。 kubelet、kube-proxy 等 Node 机器上的进程与 Master 机器的 kube-apiserver 进程通信时需要认证和授权; kubernetes 1.4 开始支持由 kube-apiserver 为客户端生成 TLS 证书的 TLS Bootstrapping 功能,这样就不需要为每个客户端生成证书了;该功能当前仅支持为 kubelet 生成证书。 创建 TLS Bootstrapping Token Token auth file Token可以是任意的包涵128 bit的字符串,可以使用安全的随机数发生器生成。 export BOOTSTRAP_TOKEN=$(head -c 16 /dev/urandom | od -An -t x | tr -d ' ') cat > token.csv <<EOF ${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap" EOF 后三行是一句,直接复制上面的脚本运行即可。 将token.csv发到所有机器(Master 和 Node)的 /etc/kubernetes/ 目录。 $cp token.csv /etc/kubernetes/ 创建 kubelet bootstrapping kubeconfig 文件 $ cd /etc/kubernetes $ export KUBE_APISERVER="https://172.

Kubernetes安装之证书验证

(题图:铜牛@颐和园 Aug 25,2014) 前言 昨晚(Apr 9,2017)金山软件的opsnull发布了一个开源项目和我一步步部署kubernetes集群,下文是结合我之前部署kubernetes的过程打造的kubernetes环境和opsnull的文章创建 kubernetes 各组件 TLS 加密通信的证书和秘钥的实践。之前安装过程中一直使用的是非加密方式,一直到后来使用Fluentd和ElasticSearch收集Kubernetes集群日志时发现有权限验证问题,所以为了深入研究kubernentes。 Kubernentes中的身份验证 kubernetes 系统的各组件需要使用 TLS 证书对通信进行加密,本文档使用 CloudFlare 的 PKI 工具集 cfssl 来生成 Certificate Authority (CA) 和其它证书; 生成的 CA 证书和秘钥文件如下: ca-key.pem ca.pem kubernetes-key.pem kubernetes.pem kube-proxy.pem kube-proxy-key.pem admin.pem admin-key.pem 使用证书的组件如下: etcd:使用 ca.pem、kubernetes-key.pem、kubernetes.pem; kube-apiserver:使用 ca.pem、kubernetes-key.pem、kubernetes.pem; kubelet:使用 ca.pem; kube-proxy:使用 ca.pem、kube-proxy-key.pem、kube-proxy.pem; kubectl:使用 ca.pem、admin-key.pem、admin.pem; kube-controller、kube-scheduler 当前需要和 kube-apiserver 部署在同一台机器上且使用非安全端口通信,故不需要证书。 安装 CFSSL 方式一:直接使用二进制源码包安装 $ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 $ chmod +x cfssl_linux-amd64 $ sudo mv cfssl_linux-amd64 /root/local/bin/cfssl $ wget https://pkg.

使用Fluentd和ElasticSearch收集Kubernetes集群日志

(题图:码头@古北水镇 Apr 30,2016) 前言 在安装好了Kubernetes集群、配置好了flannel网络、安装了Kubernetes Dashboard和配置Heapster监控插件后,还有一项重要的工作,为了调试和故障排查,还需要进行日志收集工作。 官方文档 Kubernetes Logging and Monitoring Cluster Activity Logging Using Elasticsearch and Kibana:不过这篇文章是在GCE上配置的,参考价值不大。 容器日志的存在形式 目前容器日志有两种输出形式: stdout,stderr标准输出 这种形式的日志输出我们可以直接使用docker logs查看日志,kubernetes集群中同样可以使用kubectl logs类似的形式查看日志。 日志文件记录 这种日志输出我们无法从以上方法查看日志内容,只能tail日志文件查看。 Fluentd介绍 Fluentd是使用Ruby编写的,通过在后端系统之间提供统一的日志记录层来从后端系统中解耦数据源。 此层允许开发人员和数据分析人员在生成日志时使用多种类型的日志。 统一的日志记录层可以让您和您的组织更好地使用数据,并更快地在您的软件上进行迭代。 也就是说fluentd是一个面向多种数据来源以及面向多种数据出口的日志收集器。另外它附带了日志转发的功能。 Fluentd收集的event由以下几个方面组成: Tag:字符串,中间用点隔开,如myapp.access Time:UNIX时间格式 Record:JSON格式 Fluentd特点 部署简单灵活 开源 经过验证的可靠性和性能 社区支持,插件较多 使用json格式事件格式 可拔插的架构设计 低资源要求 内置高可靠性 安装 查看cluster/addons/fluentd-elasticsearch插件目录,获取到需要用到的docker镜像名称。 $grep -rn "gcr.io" *.yaml es-controller.yaml:24: - image: gcr.io/google_containers/elasticsearch:v2.4.1-2 fluentd-es-ds.yaml:26: image: gcr.io/google_containers/fluentd-elasticsearch:1.22 kibana-controller.yaml:22: image: gcr.io/google_containers/kibana:v4.6.1-1 需要用到的镜像 gcr.io/google_containers/kibana:v4.6.1-1 gcr.io/google_containers/elasticsearch:v2.4.1-2 gcr.

Kubernetes的ConfigMap解析

(题图:龙形灯笼@古北水镇 Apr 30,2016) 前言 为什么要翻译这篇文章,是因为我在使用Fluentd和ElasticSearch收集Kubernetes集群日志的时候遇到了需要修改镜像中配置的问题,fluent-plugin-kubernetes_metadata里的需要的td-agent.conf文件。 其实ConfigMap功能在Kubernetes1.2版本的时候就有了,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与docker image解耦,你总不能每修改一个配置就重做一个image吧?ConfigMap API给我们提供了向容器中注入配置信息的机制,ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制大对象。 ConfigMap概览 ConfigMap API资源用来保存key-value pair配置数据,这个数据可以在pods里使用,或者被用来为像controller一样的系统组件存储配置数据。虽然ConfigMap跟Secrets类似,但是ConfigMap更方便的处理不含敏感信息的字符串。 注意:ConfigMaps不是属性配置文件的替代品。ConfigMaps只是作为多个properties文件的引用。你可以把它理解为Linux系统中的/etc目录,专门用来存储配置文件的目录。下面举个例子,使用ConfigMap配置来创建Kuberntes Volumes,ConfigMap中的每个data项都会成为一个新文件。 kind: ConfigMap apiVersion: v1 metadata: creationTimestamp: 2016-02-18T19:14:38Z name: example-config namespace: default data: example.property.1: hello example.property.2: world example.property.file: |- property.1=value-1 property.2=value-2 property.3=value-3 data一栏包括了配置数据,ConfigMap可以被用来保存单个属性,也可以用来保存一个配置文件。 配置数据可以通过很多种方式在Pods里被使用。ConfigMaps可以被用来: 设置环境变量的值 在容器里设置命令行参数 在数据卷里面创建config文件 用户和系统组件两者都可以在ConfigMap里面存储配置数据。 其实不用看下面的文章,直接从kubectl create configmap -h的帮助信息中就可以对ConfigMap究竟如何创建略知一二了。 Examples: # Create a new configmap named my-config based on folder bar kubectl create configmap my-config --from-file=path/to/bar # Create a new configmap named my-config with specified keys instead of file basenames on disk kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.

Kubernetes heapster监控插件安装文档

(题图:嗑猫薄荷的白化孟加拉虎@北京动物园 Apr 3,2017) 前言 前面几篇文章中记录了我们安装好了Kubernetes集群、配置好了flannel网络、安装了Kubernetes Dashboard,但是还没法查看Pod的监控信息,虽然kubelet默认集成了cAdvisor(在每个node的4194端口可以查看到),但是很不方便,因此我们选择安装heapster。 安装 下载heapster的代码 直接现在Github上的最新代码。 git pull https://github.com/kubernetes/heapster.git 目前的最高版本是1.3.0。 在heapster/deploy/kube-config/influxdb目录下有几个yaml文件: grafana-deployment.yaml grafana-service.yaml heapster-deployment.yaml heapster-service.yaml influxdb-deployment.yaml influxdb-service.yaml 我们再看下用了哪些镜像: grafana-deployment.yaml:16: image: gcr.io/google_containers/heapster-grafana-amd64:v4.0.2 heapster-deployment.yaml:16: image: gcr.io/google_containers/heapster-amd64:v1.3.0-beta.1 influxdb-deployment.yaml:16: image: gcr.io/google_containers/heapster-influxdb-amd64:v1.1.1 下载镜像 我们下载好了这些images后,存储到私有镜像仓库里: sz-pg-oam-docker-hub-001.tendcloud.com/library/heapster-amd64:v1.3.0-beta.1 sz-pg-oam-docker-hub-001.tendcloud.com/library/heapster-grafana-amd64:v4.0.2 sz-pg-oam-docker-hub-001.tendcloud.com/library/heapster-influxdb-amd64:v1.1.1 我已经将官方镜像克隆到了时速云上,镜像地址: index.tenxcloud.com/jimmy/heapster-amd64:v1.3.0-beta.1 index.tenxcloud.com/jimmy/heapster-influxdb-amd64:v1.1.1 index.tenxcloud.com/jimmy/heapster-grafana-amd64:v4.0.2 需要的可以去下载,下载前需要用时速云账户登陆,然后再执行pull操作。 docker login index.tendcloud.com 配置 参考Run Heapster in a Kubernetes cluster with an InfluxDB backend and a Grafana UI和Configuring Source,需要修改yaml文件中的几个配置。 首先修改三个deployment.yaml文件,将其中的镜像文件地址改成我们自己的私有镜像仓库的 修改heapster-deployment.

Kubernetes Dashboard/Web UI安装全记录

(题图:晒太阳的袋鼠@北京动物园 Apr 3,2017) 前言 前几天在CentOS7.2上安装Kubernetes1.6和安装好flannel网络配置,今天我们来安装下kuberentnes的dashboard。 Dashboard是Kubernetes的一个插件,代码在单独的开源项目里。1年前还是特别简单的一个UI,只能在上面查看pod的信息和部署pod而已,现在已经做的跟Docker Enterprise Edition的Docker Datacenter很像了。 安装Dashboard 官网的安装文档https://kubernetes.io/docs/user-guide/ui/,其实官网是让我们使用现成的image来用kubernetes部署即可。 首先需要一个kubernetes-dashboard.yaml的配置文件,可以直接在Github的src/deploy/kubernetes-dashboard.yaml下载。 我们能看下这个文件的内容: # Copyright 2015 Google Inc. All Rights Reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

Kubernetes基于flannel的网络配置

(题图:西安鼓楼 Oct 4,2014) 书接上文在CentOS中安装Kubernetes详细指南,这是一个系列文章,作为学习Kubernetes的心路历程吧。 本文主要讲解Kubernetes的网络配置,👆文中有一个安装Flannel的步骤,但是安装好后并没有相应的配置说明。 配置flannel 我们直接使用的yum安装的flannle,安装好后会生成/usr/lib/systemd/system/flanneld.service配置文件。 [Unit] Description=Flanneld overlay address etcd agent After=network.target After=network-online.target Wants=network-online.target After=etcd.service Before=docker.service [Service] Type=notify EnvironmentFile=/etc/sysconfig/flanneld EnvironmentFile=-/etc/sysconfig/docker-network ExecStart=/usr/bin/flanneld-start $FLANNEL_OPTIONS ExecStartPost=/usr/libexec/flannel/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/docker Restart=on-failure [Install] WantedBy=multi-user.target RequiredBy=docker.service 可以看到flannel环境变量配置文件在/etc/sysconfig/flanneld。 # Flanneld configuration options # etcd url location. Point this to the server where etcd runs FLANNEL_ETCD_ENDPOINTS="http://sz-pg-oam-docker-test-001.tendcloud.com:2379" # etcd config key. This is the configuration key that flannel queries # For address range assignment FLANNEL_ETCD_PREFIX="/kube-centos/network" # Any additional options that you want to pass #FLANNEL_OPTIONS="" etcd的地址FLANNEL_ETCD_ENDPOINT etcd查询的目录,包含docker的IP地址段配置。FLANNEL_ETCD_PREFIX 在etcd中创建网络配置

在CentOS上安装kubernetes详细指南

(题图:北京圆明园 Aug 25,2014) 作者:Jimmy Song,Peter Ma,2017年3月30日 最近决定从Docker Swarm Mode投入到Kubernetes的怀抱,对Docker的战略和企业化发展前景比较堪忧,而Kubernetes是CNCF的成员之一。 这篇是根据官方安装文档实践整理的,操作系统是纯净的CentOS7.2。 另外还有一个Peter Ma写的在CentOS上手动安装kubernetes的文档可以参考。 角色分配 下面以在三台主机上安装Kubernetes为例。 172.20.0.113 master/node kube-apiserver kube-controller-manager kube-scheduler kubelet kube-proxy etcd flannel 172.20.0.114 node kubectl kube-proxy flannel 172.20.0.115 node kubectl kube-proxy flannel 第一台主机既作为master也作为node。 系统环境 Centos 7.2.1511 docker 1.12.6 etcd 3.1.5 kubernetes 1.6.0 flannel 0.7.0-1 安装 下面给出两种安装方式: 配置yum源后,使用yum安装,好处是简单,坏处也很明显,需要google更新yum源才能获得最新版本的软件,而所有软件的依赖又不能自己指定,尤其是你的操作系统版本如果低的话,使用yum源安装的kubernetes的版本也会受到限制。 使用二进制文件安装,好处是可以安装任意版本的kubernetes,坏处是配置比较复杂。 我们最终选择使用第二种方式安装。 本文的很多安装步骤和命令是参考的Kubernetes官网CentOS Manual Config文档。 第一种方式:CentOS系统中直接使用yum安装 给yum源增加一个Repo [virt7-docker-common-release] name=virt7-docker-common-release baseurl=http://cbs.centos.org/repos/virt7-docker-common-release/x86_64/os/ gpgcheck=0 安装docker、kubernetes、etcd、flannel一步到位 yum -y install --enablerepo=virt7-docker-common-release kubernetes etcd flannel 安装好了之后需要修改一系列配置文件。

Docker v.s Kubernetes part2

(题图:河北承德兴隆县雾灵山京郊最佳星空拍摄点 July 9,2016) 本文是Docker v.s Kubernetes第二篇,续接上文Docker v.s Kuberntes Part1。 Kubernetes是典型的Master/Slave架构模式,本文简要的介绍kubenetes的架构和组件构成。 Kubernetes核心架构 master节点 apiserver:作为kubernetes系统的入口,封装了核心对象的增删改查操作,以RESTFul接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd(一个分布式强一致性的key/value存储)。 scheduler:负责集群的资源调度,为新建的Pod分配机器。这部分工作分出来变成一个组件,意味着可以很方便地替换成其他的调度器。 controller-manager:负责执行各种控制器,目前有两类: endpoint-controller:定期关联service和Pod(关联信息由endpoint对象维护),保证service到Pod的映射总是最新的。 replication-controller:定期关联replicationController和Pod,保证replicationController定义的复制数量与实际运行Pod的数量总是一致的。 node节点 kubelet:负责管控docker容器,如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的Pod,并根据Pod信息启动或停止相应的容器。同时,它也会接收apiserver的HTTP请求,汇报Pod的运行状态。 proxy:负责为Pod提供代理。它会定期从etcd获取所有的service,并根据service信息创建代理。当某个客户Pod要访问其他Pod时,访问请求会经过本机proxy做转发。 Kubernetes组件详细介绍 etcd 虽然不是Kubernetes的组件但是有必要提一下,etcd是一个分布式协同数据库,基于Go语言开发,CoreOS公司出品,使用raft一致性算法协同。Kubernetes的主数据库,在安装kubernetes之前就要先安装它,很多开源下项目都用到,老版本的docker swarm也用到了它。目前主要使用的是2.7.x版本,3.0+版本的API变化太大。 APIServer APIServer负责对外提供kubernetes API服务,它运行在master节点上。任何对资源的增删改查都要交给APIServer处理后才能提交给etcd。APIServer总体上由两部分组成:HTTP/HTTPS服务和一些功能性插件。这些功能性插件又分为两种:一部分与底层IaaS平台(Cloud Provide)相关;另一部分与资源管理控制(Admission Control)相关。 Scheduler Scheduler的作用是根据特定的调度算法将pod调度到node节点上,这一过程也被称为绑定。Scheduler调度器的输入是待调度的pod和可用的工作节点列表,输出则是一个已经绑定了pod的节点,这个节点是通过调度算法在工作节点列表中选择的最优节点。 工作节点从哪里来?工作节点并不是由Kubernetes创建,它是由IaaS平台创建,或者就是由用户管理的物理机或者虚拟机。但是Kubernetes会创建一个Node对象,用来描述这个工作节点。描述的具体信息由创建Node对象的配置文件给出。一旦用户创建节点的请求被成功处理,Kubernetes又会立即在内部创建一个node对象,再去检查该节点的健康状况。只有那些当前可用的node才会被认为是一个有效的节点并允许pod调度到上面运行。 工作节点可以通过资源配置文件或者kubectl命令行工具来创建。Kubernetes主要维护工作节点的两个属性:spec和status来描述一个工作节点的期望状态和当前状态。其中,所谓的当前状态信息由3个信息组成:HostIp、NodePhase和Node Condition。 工作节点的动态维护过程依靠Node Controller来完成,它是Kubernetes Controller Manager下属的一个控制器。它会一直不断的检查Kubernetes已知的每台node节点是否正常工作,如果一个之前已经失败的节点在这个检查循环中被检查为可以工作的,那么Node Controller会把这个节点添加到工作节点中,Node Controller会从工作节点中删除这个节点。 Controller Manager Controller Manager运行在集群的Master节点上,是基于pod API的一个独立服务,它重点实现service Endpoint(服务端点)的动态更新。管理着Kubernetes集群中各种控制节点,包括replication Controller和node Controller。 与APIServer相比,APIServer负责接受用户请求并创建对应的资源,而Controller Manager在系统中扮演的角色是在一旁旁默默的管控这些资源,确保他们永远保持在预期的状态。它采用各种管理器定时的对pod、节点等资源进行预设的检查,然后判断出于预期的是否一致,若不一致,则通知APIServer采取行动,比如重启、迁移、删除等。 kubelet kubelet组件工作在Kubernetes的node上,负责管理和维护在这台主机上运行着的所有容器。 kubelet与cAdvisor交互来抓取docker容器和主机的资源信息。 kubelet垃圾回收机制,包括容器垃圾回收和镜像垃圾回收。 kubelet工作节点状态同步。 kube-proxy kube-proxy提供两种功能: 提供算法将客服端流量负载均衡到service对应的一组后端pod。 使用etcd的watch机制,实现服务发现功能,维护一张从service到endpoint的映射关系,从而保证后端pod的IP变化不会对访问者的访问造成影响。

Docker v.s Kubernetes part1

(题图:杭州西湖 Oct 16,2016) 前言 这一系列文章是对比kubernetes 和docker两者之间的差异,鉴于我之前从docker1.10.3起开始使用docker,对原生docker的了解比较多,最近又正在看Kunernetes权威指南(第二版)这本书(P.S感谢电子工业出版社的编辑朋友赠送此书)。这系列文章不是为了比较孰优孰劣,适合自己的才是最好的。 此系列文章中所说的docker指的是*17.03-ce*版本。 概念性的差别 Kubernetes 了解一样东西首先要高屋建瓴的了解它的概念,kubernetes包括以下几种资源对象: Pod Service Volume Namespace ReplicaSet Deployment StatefulSet DaemonSet Job Docker Docker的资源对象相对于kubernetes来说就简单多了,只有以下几个: Service Node Stack Docker 就这么简单,使用一个*docker-compose.yml*即可以启动一系列服务。当然简单的好处是便于理解和管理,但是在功能方面就没有kubernetes那么强大了。 功能性差别 Kubernetes 资源限制 CPU 100m千分之一核为单位,绝对值,requests 和limits,超过这个值可能被杀掉,资源限制力度比docker更细。 Pod中有个最底层的pause 容器,其他业务容器共用他的IP,docker因为没有这层概念,所以没法共用IP,而是使用overlay网络同处于一个网络里来通信。 Kubernetes在rc中使用环境变量传递配置(1.3版本是这样的,后续版本还没有研究过) Kuberentes Label 可以在开始和动态的添加修改,所有的资源对象都有,这一点docker也有,但是资源调度因为没有kubernetes那么层级,所有还是相对比较弱一些。 Kubernetes对象选择机制继续通过label selector,用于对象调度。 Kubernetes中有一个比较特别的镜像,叫做google_containers/pause,这个镜像是用来实现Pod概念的。 HPA horizontal pod autoscaling 横向移动扩容,也是一种资源对象,根据负载变化情况针对性的调整pod目标副本数。 Kubernetes中有三个IP,Node,Pod,Cluster IP的关系比较复杂,docker中没有Cluster IP的概念。 持久化存储,在Kubernetes中有Persistent volume 只能是网络存储,不属于任何node,独立于pod之外,而docker只能使用volume plugin。 多租户管理,kubernetes中有`Namespace,docker暂时没有多租户管理功能。 总体来说Docker架构更加简单,使用起来也没有那么多的配置,只需要每个结点都安装docker即可,调度和管理功能没kubernetes那么复杂。但是kubernetes本身就是一个通用的数据中心管理工具,不仅可以用来管理docker,*pod*这个概念里就可以运行不仅是docker了。 以后的文章中将结合docker着重讲Kubernetes,基于1.3版本。