Kube

一、Pod简介 Pod是k8s系统中可以创建和管理的最小单元，是资源对象模型中由用户创建或部署的最小资源对象模型，也是在k8s上运行容器化应用的资源对象，其他的资源对象都是用来支撑或者扩展Pod对象功能的，比如控制器对象是用来管控Pod对象的，Service或者Ingress资源对象是用来暴露Pod引用对象的，PersistentVolume资源对象是用来为Pod提供存储等等， k8s不会直接处理容器，而是Pod ，Pod是由一个或者多个container组成的。 每个Pod都是运行应用的单个实例，如果需要水平扩展应用（例如，运行多个实例），则应该使用多个Pods，每个实例一个Pod。在Kubernetes中，这样通常称为Replication。Replication的Pod通常由Controller创建和管理。 1.1、为什么需要pod 我们先谈谈为什么k8s会使用pod这个最小单元，而不是使用docker的容器，k8s既然使用了pod，当然有它的理由。 1、更利于扩展 k8s不仅仅支持Docker容器，也支持rkt甚至用户自定义容器，为什么会有这么多不同的容器呢，因为容器并不是真正的虚拟机，docker的一些概念和误区总结，此外，Kubernetes不依赖于底层某一种具体的规则去实现容器技术， 而是通过CRI这个抽象层操作容器 ，这样就会需要pod这样一个东西

作者：王庆璨 张凯 进击的Kubernetes调度系统（一）：Scheduling Framework 进击的Kubernetes调度系统（二）：支持批任务的Coscheduling/Gang scheduling 前言 首先我们来了解一下什么是Coscheduling和Gang scheduling。Wikipedia对 Coscheduling 的定义是“在并发系统中将多个相关联的进程调度到不同处理器上同时运行的策略”。在Coscheduling的场景中，最主要的原则是保证所有相关联的进程能够同时启动。防止部分进程的异常，导致整个关联进程组的阻塞。这种导致阻塞的部分异常进程，称之为“碎片（fragement）”。 在Coscheduling的具体实现过程中，根据是否允许“碎片”存在，可以细分为Explicit Coscheduling，Local Coscheduling和Implicit Coscheduling。 其中Explicit Coscheduling就是大家常听到的 Gang Scheduling 。Gang Scheduling要求完全不允许有“碎片”存在， 也就是“All or Nothing”。 我们将上述定义的概念对应到Kubernetes中，就可以理解Kubernetes调度系统支持批任务Coscheduling的含义了。 一个批任务（关联进程组

简介 目前生产部署kubernetes集群主要两种方式 kubeadm Kubeadm是一个K8s部署工具，提供kubeadm init和kubeadm join，用于快速部署Kubernetes集群。 二进制包 从github下载发行版的二进制包，手动部署每个组件，组成Kubernetes集群。 Kubeadm降低部署门槛，但屏蔽了很多细节，遇到问题很难排查。如果想更容易可控，推荐使用二进制包部署Kubernetes集群，虽然手动部署麻烦点，期间可以学习很多工作原理，也利于后期维护。 二进制部署K8s List CentOS7.3 cni-plugins-linux-amd64-v0.8.6.tgz etcd-v3.4.9-linux-amd64.tar.gz kube-flannel.yml kubernetes-server-linux-amd64.tar.gz 角色 IP 组件 master 192.168.31.71 kube-apiserver，kube-controller-manager，kube-scheduler，etcd Node1 192.168.31.74 kube-apiserver，kube-controller-manager，kube-scheduler Node2 192.168.31.72 kubelet，kube-proxy，docker

导出配置文件 kubeadm config print init-defaults > kubernetes-config.yaml 修改配置文件 vim kubernetes-config.yaml #配置信息 apiVersion: kubeadm.k8s.io/v1beta2 bootstrapTokens: groups: system:bootstrappers:kubeadm:default-node-token token: abcdef.0123456789abcdef ttl: 24h0m0s usages: signing authentication kind: InitConfiguration localAPIEndpoint: advertiseAddress: 192.168.100.10 bindPort: 6443 nodeRegistration: criSocket: /var/run/dockershim.sock name: master01 taints: effect: NoSchedule key: node-role.kubernetes.io/master apiServer: timeoutForControlPlane: 4m0s apiVersion: kubeadm.k8s.io/v1beta2

作者 | 声东 阿里云售后技术专家 **<关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> ** 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是 Kubernetes 成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 **Istio 的现状是，聊的人很多，用的人其实很少。**所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单 Istio 问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了 Istio，并依照官方文档部署 bookinfo 应用来上手 Istio。部署之后，用户执行 kubectl get pods 命令，发现所有的 Pod 都只有二分之一个容器是 READY 的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 接触 Kubernetes 以来，我经常看到 Kubernetes 在不同的地方使用了证书（Certificate），在 Kubernetes 安装和组件启动参数中也需要配置大量证书相关的参数。但是 Kubernetes 的文档在解释这些证书的工作机制方面做得并不是太好。经过大量的相关阅读和分析工作后，我基本弄清楚了 Kubernetes 中证书的使用方式。在本文中，我将试图以一种比官方文档更容易理解的方式来说明 Kubernetes 中证书相关的工作机制，如果你也存在这方面的疑惑，希望这篇文章对你有所帮助。 Kubernetes 组件的认证方式 首先让我们来看一下 Kubernetes 中的组件：在 Kubernetes 中包含多个以独立进程形式运行的组件，这些组件之间通过 HTTP/GRPC 相互通信，以协同完成集群中应用的部署和管理工作。 Kubernetes 组件，图片来源kubernetes.io 从图中可以看到，Kubernetes 控制平面中包含了 etctd，kube-api-server，kube-scheduler，kube-controller-manager 等组件，这些组件会相互进行远程调用，例如 kube-api-server 会调用 etcd

Metrics API 介绍Metrics-Server之前，必须要提一下Metrics API的概念 Metrics API相比于之前的监控采集方式(hepaster)是一种新的思路，官方希望核心指标的监控应该是稳定的，版本可控的，且可以直接被用户访问(例如通过使用 kubectl top 命令)，或由集群中的控制器使用(如HPA)，和其他的Kubernetes APIs一样。 官方废弃heapster项目，就是为了将核心资源监控作为一等公民对待，即像pod、service那样直接通过api-server或者client直接访问，不再是安装一个hepater来汇聚且由heapster单独管理。 假设每个pod和node我们收集10个指标，从k8s的1.6开始，支持5000节点，每个节点30个pod，假设采集粒度为1分钟一次，则： 10 x 5000 x 30 / 60 = 25000 平均每分钟2万多个采集指标 因为k8s的api-server将所有的数据持久化到了etcd中，显然k8s本身不能处理这种频率的采集，而且这种监控数据变化快且都是临时数据，因此需要有一个组件单独处理他们，k8s版本只存放部分在内存中，于是metric-server的概念诞生了。 其实hepaster已经有暴露了api，但是用户和Kubernetes的其他组件必须通过master

控制平面组件（Control Plane Components） 控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod ）。 控制平面组件可以在集群中的任何节点上运行。然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件，并且不会在此计算机上运行用户容器。请参阅 构建高可用性集群 中对于多主机 VM 的设置示例。 kube-apiserver 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。 kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之，通过部署多个实例可以实现扩缩。 参见 构造高可用集群 。 etcd etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。 您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。要了解 etcd 更深层次的信息，请参考 etcd 文档 。 kube-scheduler 主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置

一步一步搞定Kubernetes二进制部署（三）——组件安装（单节点） 前言 ​ 前面两篇文章我们将基础的环境构建完成，包括etcd集群（含证书创建）、flannel网络设置、docker引擎安装部署等，本文将在三台服务器上搞定此次单节点的二进制方式部署的Kubernetes集群。 master节点上进行配置 1、创建工作目录 [root@master01 k8s]# mkdir -p /opt/kubernetes/{cfg,bin,ssl} 2、部署apiserver组件 2.1制作apiserver证书 2.1.1创建apiserver证书目录，编写证书生成脚本 [root@master01 k8s]# mkdir k8s-cert [root@master01 k8s]# cd k8s-cert/ [root@master01 k8s-cert]# cat k8s-cert.sh #先前已经在etcd集群搭建的时候给出该类文本的介绍和相关解释了，这里就不再赘述了主要注意下面的地址部分的规划写入 cat > ca-config.json <<EOF { "signing": { "default": { "expiry": "87600h" }, "profiles": { "kubernetes": { "expiry": "87600h", "usages": [

K8S 二进制集群部署--------单master集群 一、集群环境 在上篇博客介绍过了，我的搭建部署也是在上一篇的基础上做的。 二、部署master节点组件 在 Master 上要部署以下三大核心组件： kube-apiserver：是集群的统一入口，各组件协调者，所有对象资源的增删改查和监听操作都交给 APIServer 处理后再提交给 Etcd 存储； kube-controller-manager：处理群集中常规后台任务，一个资源对应一个控制器，而 controller-manager 就是负责管理这些控制器的； kube-scheduler：根据调度算法为新创建的 Pod 选择一个 Node 节点，可以任意部署，可以部署在同一个节点上，也可以部署在不同节点上。 操作流程：配置文件 -----> systemd 管理组件 -----> 启动 先把master压缩包放在k8s目录下 [root@localhost k8s]# unzip master.zip 解压出来的三个组件脚本我自己编写的，内容在下面操作中展示。 [root@localhost k8s]# chmod +x controller-manager.sh #给controll脚本加上权限 [root@localhost k8s]# mkdir -p /opt/kubernetes/{cfg,ssl,bin}