Kube

作者介绍 陈金窗， 资深运维技术专家，从事IT基础设施建设、运维与技术管理20多年。 刘政委， 资深运维技术与管理人员，大型在线游戏和手游自动化运维老兵。 长期从事云计算相关产品、研发、运维工作，具备丰富理论及实践经验。 中国电信云公司软件工程师，主要负责私有容器云平台的研发工作。 在过去的几年中，云计算已经成为及分布式计算最火热的技术之一，其中Docker、Kubernetes、Prometheus等开源软件的发展极大地推动了云计算的发展。本文首先从Prometheus是如何监控Kubernetes入手，介绍Prometheus Operator组件。接着详细介绍基于Kubernetes的两种Prometheus部署方式，最后介绍服务配置、监控对象以及数据展示和告警。通过本文，大家可以在Kubernetes集群的基础上学习和搭建完善的Prometheus监控系统。 一、Prometheus与Kubernetes完美结合 Kubernetes使用Docker进行容器管理，如果说Docker和kubernetes的搭配是云原生时代的基石，那么Prometheus为云原生插上了飞翔的翅膀。随着云原生社区的不断壮大，应用场景越来越复杂，需要一套针对云原生环境的完善并且开放的监控平台。在这样的环境下，Prometheus应运而生，天然支持Kubernetes。 1、Kubernetes

操作环境 rbac 划分（HA高可用双master部署实例） 本文穿插了ha 高可用部署的实例，当前章节设计的是ha部署双master 部署 内网ip 角色 安装软件 192.168.0.10 master01 etcd,kube-apiserver,kube-controller-manager,kube-scheduler 192.168.0.12 master02 etcd,kube-apiserver,kube-controller-manager,kube-scheduler 192.168.0.7 node01 docker,kubelet,kube-proxy,flannel 192.168.0.8 node02 docker,kubelet,kube-proxy,flannel 192.168.0.4 slb master etcd，nginx 192.168.0.9 192.168.0.200 keepalived上的VIP 注意 flannel可以只安装node上，flannel只是跨机器宿主机和容器通讯使用 docker可以只安装node上，master上可以不安装 etcd 键值对的数据库，是独立三台机器。不要复用。 192.168.0.200是keepalived上的vip 自签SSL证书 k8s安装包下载 https://github.com

一、概述 手工搭建 Kubernetes 集群是一件很繁琐的事情，为了简化这些操作，就产生了很多安装配置工具，如 Kubeadm ，Kubespray，RKE 等组件，我最终选择了官方的 Kubeadm 主要是不同的 Kubernetes 版本都有一些差异，Kubeadm 更新与支持的会好一些。Kubeadm 是 Kubernetes 官方提供的快速安装和初始化 Kubernetes 集群的工具，目前的还处于孵化开发状态，跟随 Kubernetes 每个新版本的发布都会同步更新, 强烈建议先看下官方的文档了解下各个组件与对象的作用。 https://kubernetes.io/docs/concepts/ https://kubernetes.io/docs/setup/independent/install-kubeadm/ https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/ 在创建Kubernetes集群时，阿里云容器服务提供两种网络插件：Terway和Flannel。 Flannel：使用的是简单稳定的社区的Flannel CNI 插件，配合阿里云的VPC的高速网络，能给集群高性能和稳定的容器网络体验，但功能偏简单，支持的特性少，例如：不支持基于Kubernetes标准的Network

Dubbo-go k8s注册中心设计方案与实现 随着云原生的推广，越来越多的公司或组织将服务容器化，并将容器化后的服务部署在k8s集群中。 今天这篇文章将会介绍dubbo-go将k8s作为服务注册中心的方案设计，以及具体实现。到目前为止该方案的实现已经被合并到dubbo-go的master分支。具体实现为关于Kubernetes的PullRequest。 k8s管理资源的哲学 k8s作为容器集群化管理方案可以将管理资源的维度可主观的分为服务实例管理和服务接入管理。 服务实例管理，主要体现方式为Pod设计模式加控制器模式。控制器保证具有特定标签（Label）的Pod保持在恒定的数量（多删，少补）。 服务接入管理，主要为Service，该Service默认为具有特定标签（Label）的一批Pod提供一个VIP（ClusterIP）作为服务的接入点，默认会按照round-robin的负载均衡策略将请求转发到真正提供服务的Pod。并且CoreDNS为该Service提供集群内唯一的域名。 k8s服务发现模型 为了明确k8s在服务接入管理提供的解决方案，我们以kube-apiserver 提供的API(HTTPS)服务为例。k8s集群为该服务分配了一个集群内有效的ClusterIP，并通过CoreDNS为其分配了唯一的域名 kubernetes

使用kubeadm安装部署kubernetes集群 难点 ：kubeadm部署kubernetes集群 是把kubernetes的各个组件(kube-apiserver kube-controller-manager kube-scheduler kube-proxy etcd coredns)作为容器运行在docker中，安装部署相对简单很多。 由于某些不可描述的原因，国内无法从k8s.gcr.io拉取所需镜像，因此很多人无法用这种方式完成安装。 准备 每台机器2 GB或更多的RAM 2个或更多CPU 192.168.19.11 Master 192.168.19.12 Node01 192.168.19.13 Node02 关闭防火墙 systemctl status firewalld.service systemctl stop firewalld.service systemctl disable firewalld.service 禁用Swap swapoff -a vi /etc/fstab 注释swap 让iptables查看桥接流量 cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call

下载 HELM_VERSION= ${K8S_VERSION:-"2.11.0"} HELM= "helm-v ${HELM_VERSION}-linux-amd64" curl -L https://storage.googleapis.com/kubernetes-helm/ $HELM.tar.gz -o $HELM.tar.gz tar -xvzf $HELM.tar.gz -C /tmp mv /tmp/linux-amd64/helm /usr/ local/bin/helm 2、验证安装 helm version [apps@mvxl1484 ~]$ helm version Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"} Error: could not find tiller 　　 3、安装tiller。首先搜索tiller docker search tiller [apps@mvxl1484 k8s]$ docker search tiller NAME DESCRIPTION STARS OFFICIAL AUTOMATED sapcc/tiller Mirror of

由于业务需要，近期在研究k8s，故就需要先部署一套。我通过官方文档来部署发现还是有一些坑，故整理了部署中遇到的问题做个记录。本文章主要介绍了在centos7环境下k8s 1.8.2+dashboard+metrics server+ingress的部署。 系统环境 1，k8s的版本为1.8.2 2，docker ce的版本为19.03.8-3 3，五台主机操作系统版本为centos7，kernel版本3.10.0-957 4，使用五台主机部署，机器列表 172.18.2.175 master1 172.18.2.180 master2 172.18.2.181 master3 172.18.2.186 work1 172.18.2.187 work2 172.18.2.182 apiserver-lb 部署HA架构 1，etcd是使用Go语言开发的一个开源的、高可用的强一致性分布式key-value存储系统，可以用于配置共享和服务的注册和发现集群，每个节点都可以提供服务。 2，kubernetes系统组件间只能通过API服务器通信，它们之间不会直接通信，API服务器是和etcd通信的唯一组件。 其他组件不会直接和etcd通信，需要通过API服务器来修改集群状态。 3，controller-manager和scheduler监听API服务器变化，如果API服务器有更新则进行对应的操作

作者 | 王思宇（酒祝） 阿里云技术专家 参与阿里巴巴云原生文末留言互动，即有机会获得赠书福利及作者答疑！ 概念介绍 原地升级 一词中，“升级”不难理解，是将应用实例的版本由旧版替换为新版。那么如何结合 Kubernetes 环境来理解“原地”呢？ 我们先来看看 K8s 原生 workload 的发布方式。这里假设我们需要部署一个应用，包括 foo、bar 两个容器在 Pod 中。其中，foo 容器第一次部署时用的镜像版本是 v1，我们需要将其升级为 v2 版本镜像，该怎么做呢？ 如果这个应用使用 Deployment 部署，那么升级过程中 Deployment 会触发新版本 ReplicaSet 创建 Pod，并删除旧版本 Pod。如下图所示： 在本次升级过程中，原 Pod 对象被删除，一个新 Pod 对象被创建。新 Pod 被调度到另一个 Node 上，分配到一个新的 IP，并把 foo、bar 两个容器在这个 Node 上重新拉取镜像、启动容器。 如果这个应该使用 StatefulSet 部署，那么升级过程中 StatefulSet 会先删除旧 Pod 对象，等删除完成后用同样的名字在创建一个新的 Pod 对象。如下图所示： 值得注意的是，尽管新旧两个 Pod 名字都叫 pod-0，但其实是两个完全不同的 Pod 对象（uid也变了）。StatefulSet 等到原先的

Pod/Pod控制器 Pod 是K8s中能被运行的最小逻辑单元，1个Pod里可以运行多个容器，他们共享UTS+NET+IPC名称 可以把Pod理解为豌豆荚，而同一Pod内的每个容器是一颗颗豌豆 一个Pod运行多个容器，又叫边车(SideCar)模式 Pod控制器 是Pod启动的一种模版，用来保证在K8s里启动的Pod，应始终按照人们的预期运行(副本数，生命周期，健康状态查询) K8s提供了众多Pod控制器，常用的有以下几种： Deployment DaemonSet ReplicaSet StatefulSet Job Cronjob Name/Namespace Name: 由于K8S内部，使用“资源”来定义每一个逻辑概念(功能)，故每种“资源”都应该有自己的“名称” 资源有api版本(apiVersion) 类别(kind),元数据(metadata)，定义清单(spec)，状态(status)等配置信息 “名称”通常定义在“资源”的"元数据"信息中 Namespace: 随着项目增多，人员增加，集群规模的扩大，需要一种能隔离K8S内各种"资源"的方法,这就是名称空间 名称空间可以理解为K8S内部的虚拟集群组 不同名称空间内的“资源”，名称可以相同，相同名称空间内的同种"资源"，“名称”不能相同 合理的使用K8S的名称空间

kubectl -n kube-system describe $(kubectl -n kube-system get secret -n kube-system -o name | grep namespace) | grep token 来源： oschina 链接： https://my.oschina.net/u/4267236/blog/4286043