《Kubernetes工程师》专题

Kubernetes 架构概述 王渊命 @jolestar Agenda Kubernetes 为何而生 Kubernetes 的架构 Kubernetes 为何而生 - 云发展到一个新阶段 IaaS 云解决了哪些问题 按需购买 接管硬件资源的运维 提供可编程接口来管理资源 提供 SDN，SDS 模拟硬件网络以及存储 特点 对应用无侵入 面向资源 用户从关注资源的运维转向关注应用的开发运维成本 K

本文档介绍 Kubernetes 上 TiDB Binlog drainer 的配置参数。 配置参数 下表包含所有用于 tidb-drainer chart 的配置参数。关于如何配置这些参数，可参阅使用 Helm。 参数 说明 默认值 timezone 时区配置 UTC drainerName Statefulset 名称 "" clusterName 源 TiDB 集群的名称 demo clus

随着 TiDB Operator GA 发布，越来越多用户开始使用 TiDB Operator 在 Kubernetes 中部署管理 TiDB 集群。在本次测试中，我们选择 GKE 平台做了一次深入、全方位的测试，方便大家了解 TiDB 在 Kubernetes 中性能影响因素。 目的 测试典型公有云平台上 TiDB 性能数据 测试公有云平台磁盘、网络、CPU 以及不同 Pod 网络下对 TiDB

本文描述了如何销毁 Kubernetes 集群上的 TiDB 集群。 销毁使用 TidbCluster 管理的 TiDB 集群 要销毁使用 TidbCluster 管理的 TiDB 集群，执行以下命令： kubectl delete tc ${cluster_name} -n ${namespace} 如果集群中通过 TidbMonitor 部署了监控，要删除监控组件，可以执行以下命令： kube

在使用 TiDB 集群的过程中，如果你发现某个 Pod 存在内存泄漏等问题，需要对集群进行重启，本文描述了如何优雅滚动重启 TiDB 集群内某个组件的所有 Pod 或通过优雅重启指令来将 TiDB 集群内某个 Pod 优雅下线然后再进行重新启动。 警告： 在生产环境中，未经过优雅重启而手动删除某个 TiDB 集群 Pod 节点是一件极其危险的事情，虽然 StatefulSet 控制器会将 Pod

基于 Kubernetes 环境部署的 TiDB 集群监控可以大体分为两个部分：对 TiDB 集群本身的监控、对 Kubernetes 集群及 TiDB Operator 的监控。本文将对两者进行简要说明。 TiDB 集群的监控 TiDB 通过 Prometheus 和 Grafana 监控 TiDB 集群。在通过 TiDB Operator 创建新的 TiDB 集群时，可以参考通过 TidbMo

在 Kubernetes 集群内访问 TiDB 时，使用 TiDB service 域名 ${cluster_name}-tidb.${namespace} 即可。 若需要在集群外访问，则需将 TiDB 服务端口暴露出去。在 TidbCluster CR 中，通过 spec.tidb.service 字段进行配置： spec: ... tidb: service: ty

本部分将生成一个用于 admin 用户的 kubeconfig 文件。 注意：在生成 admin 客户端证书的目录来运行本部分的指令。 admin kubeconfig 每一个 kubeconfig 都需要一个 Kuberntes API Server 地址。为了保证高可用，这里将使用 API Servers 前端外部负载均衡器的 IP 地址。 查询 kubernetes-the-hard-way

上节课我们实现了在 Kubernetes 环境中动态生成 Jenkins Slave 的方法，这节课我们来给大家讲解下如何在 Jenkins 中来部署一个 Kubernetes 应用。 Jenkins Pipeline 介绍 要实现在 Jenkins 中的构建工作，可以有多种方式，我们这里采用比较常用的 Pipeline 这种方式。Pipeline，简单来说，就是一套运行在 Jenkins 上的工

上节课我们和大家学习了怎样用 Promethues 来监控 Kubernetes 集群中的应用，但是对于 Kubernetes 集群本身的监控也是非常重要的，我们需要时时刻刻了解集群的运行状态。 对于集群的监控一般我们需要考虑以下几个方面： Kubernetes 节点的监控：比如节点的 cpu、load、disk、memory 等指标 内部系统组件的状态：比如 kube-scheduler、kub

上一节我们和大家介绍了Prometheus的数据指标是通过一个公开的 HTTP(S) 数据接口获取到的，我们不需要单独安装监控的 agent，只需要暴露一个 metrics 接口，Prometheus 就会定期去拉取数据；对于一些普通的 HTTP 服务，我们完全可以直接重用这个服务，添加一个/metrics接口暴露给 Prometheus；而且获取到的指标数据格式是非常易懂的，不需要太高的学习成本

读完本文后您应该可以自己创建chart，并创建自己的私有chart仓库。 Helm是一个kubernetes应用的包管理工具，用来管理charts——预先配置好的安装包资源，有点类似于Ubuntu的APT和CentOS中的yum。 Helm chart是用来封装kubernetes原生应用程序的yaml文件，可以在你部署应用的时候自定义应用程序的一些metadata，便与应用程序的分发。 Helm

我们使用 Giantswarm 开源的 kubernetes-promethues 来监控 kubernetes 集群，所有的 YAML 文件可以在 ../manifests/prometheus 目录下找到。 需要用到的镜像有： harbor-001.jimmysong.io/library/prometheus-alertmanager:v0.7.1 harbor-001.jimmysong.

本文档最初是基于kubenetes1.6版本编写的，对于kuberentes1.8及以上版本同样适用，只是个别位置有稍许变动，变动的地方我将特别注明版本要求。 本系列文档介绍使用二进制部署 kubernetes 集群的所有步骤，而不是使用 kubeadm 等自动化方式来部署集群，同时开启了集群的TLS安全认证，该安装步骤适用于所有bare metal环境、on-premise环境和公有云环境。 如

Kubenretes1.6中使用etcd V3版本的API，使用etcdctl直接ls的话只能看到/kube-centos一个路径。需要在命令前加上ETCDCTL_API=3这个环境变量才能看到kuberentes在etcd中保存的数据。 ETCDCTL_API=3 etcdctl get /registry/namespaces/default -w=json|python -m json.to