Kubernetes

kubeadm要求最低配置2c2g，高可用集群一般建议大于等于3台的奇数台,我使用3台master来做高可用。这里也简单说了一下k8s 1.18的新特性，如果只是测试搭建可以考虑1.18，目前这个版本比较新，建议生产环境还是不要使用这么高的版本

在安装Kubernetes集群的过程中并没有注意到pod的时间问题，直到在Tomcat上部署应用后发现pod中的时间与Node上的时间不同步。针对时区不同文章有以下解决方案

Kubernetes集群升级非常简单，小版本基本上是只需要更新二进制文件即可。如果大版本升级需要注意kubelet参数的变化，以及其他组件升级之后的变化。 由于Kubernetes版本更新过快许多依赖并没有解决完善，并不建议生产环境使用较新版本

Service是Kubernetes里最核心的资源对象之一,Service定义了一个服务的访问入口地址,前端的应用(Pod)通过这个入口地址访问其背后的一组由Pod副本组成的集群实力。 Service与其后端Pod副本集群之间则是通过Label Selector来实现"无缝对接"。而RC的作用实际上是保证Service 的服务能力和服务质量处于预期的标准。

Scope构建您的应用程序和基础结构的逻辑拓扑。拓扑是节点和边的集合，其中节点代表对象，例如流程，容器或主机。在范围中，边缘表示节点之间的TCP连接。可以过滤和查看不同的节点类型，并且可以深入查看和检查特定的微服务。节点以特定的顺序与服务器上方的客户端一起呈现。通常，您可以从上到下阅读“ Weave Scope”视图。

首先说一下污点(Taint)，当我们需要将master节点保留给Kubernetes系统组件调用时，或者需要保留master节点的资源时，我们可以标记一个Taint，当节点标记Taint时，除非Pod也被识别为可以容忍(Toleration)污点的节点,否则默认情况下Kubernetes scheduler不会将Pod调度到有污点的节点上

一般情况下我们部署的 Pod 是通过集群的自动调度策略来选择节点的，默认情况下调度器考虑的是资源足够，并且负载尽量平均，但是有的时候我们需要能够更加细粒度的去控制 Pod 的调度，比如我们内部的一些服务 gitlab 之类的也是跑在Kubernetes集群上的，我们就不希望对外的一些服务和内部的服务跑在同一个节点上了，担心内部服务对外部的服务产生影响；但是有的时候我们的服务之间交流比较频繁，又希望…

前面一直介绍了kubernetes各个版本的二进制安装，但是很多情况是我们需要进行扩展。 随着业务的扩大，node节点的扩展也是必不可少的。这篇文章就给大家带来机遇kubernetes 1.14安装的一个扩展教程，其他集群安装的扩展也大概相同。可能相关的路径不对而已

由于traefik 2.x和traefik 1.x的版本配置改动的比较多，这里先介绍1.x版本的配置。目前来说traefik 2.0是2019年12月份发布的，大部分企业还是使用1.x。我们跳槽去人家公司不能说光会2.x不会1.x版本，所以traefik会出2个版本的文档。目前我们使用的版本的1.7.20，为1.x版本的最后一个版本，更新时间为2019年12月10日

服务发现在微服务架构里，服务之间经常进行通信，服务发现就是解决不同服务之间通信的问题。比如一个nginx的pod，要访问一个mysql服务，就需要知道mysql服务的ip和port，获取ip和port的过程就是服务发现。

上面文章我们创建的pv和pvc都是静态的，简单的来说静态的pv和pvc需要我们手动的创建，这种情况很大程度上并不能满足我们的需求，比如我们有一个应用需要对存储的并发度要求比较高，而另外一个应用对读写速度又要求比较高，特别是对于StatefulSet类型的应用。使用静态PV就很不合时了，这里就需要使用StorageClass

在Kubernetes中，因为deployment默认使用的是hostpath，当我们pod重启或删除pod后数据会丢失。这时候我们就需要一个持久化存储来解决这个问题。 本次介绍的是kubernetes pv与pvc，同时使用nfs作为后端存储进行演示。 当然kubernetes pv 支持不同的volume，为了环境快速构建学习本次以NFS为主

RBAC是基于角色的访问控制 (Role-Based Access Control) 在RBAC中，权限与角色相关联。Kubernetes 基于角色的访问控制使用rbac.authorization.k8s.io API组来实现权限控制，RBAC允许管理员通过Kubernetes API动态的配置权限策略。如果需要开启RBAC授权需要在apiserver组件中指定--authorization-m…

Init容器与普通容器的不同之处是支持应用容器的全部字段和特性，包括资源限制、数据卷和安全设置。然后，Init容器对资源请求和容器处理不同，并且它们必须在Pod就绪之前完成运行

在生产环境中使用spring框架，由于服务更新过程中，容器服务被直接停止，部分请求仍被分发到终止的容器(没有配置钩子，熟悉默认环境)，导致服务出现500错误，这部分错误请求数据占用比较少，因为Pod滚动更新都是一对一。因为部分用户会产生服务器错误的情况，考虑使用优雅的终止方式，将错误请求降到最低，直至滚动更新不影响用户

本次环境，是用于k8s集群中的etcd，由于二进制文档对etcd并没有进行详细的介绍安装配置，故抽出时间进行etcd集群深入总结。本次主要是针对etcd静态发现和DNS动态发现两种，并结合自签的TLS证书来创建集群。

kubeadm是官方社区推出的一个用于快速部署kubernetes集群的工具。 这个工具能通过两条指令完成一个kubernetes集群的部署： # 创建一个 Master 节点 kubeadm init # 将一个 Node 节点加入到当前集群中 kubeadm join 1. 安装要求 在开始之前，部署Kubernetes集群机器需要满足以下几个条件： 一台或多台机器，操作系统 CentOS7.…

滚动更新的含义：一次只更新一小部分副本，成功后，再更新更多的副本，最终完成所有副本的更新。 滚动更新的好处：最大好处是零停机，整个更新过程始终有副本在运行，从而保证了业余的连续性。

在大多数情况，构建项目都会占用大量的系统资源，如果让gitlab本身来运行构建任务的话，显然Gitlab的性能会大幅度下降。gitlab ci最大的作用就是管理各个项目的构建状态，因此，运行构建任务这种浪费资源的事情交给一个独立的gitlab runner来做就会好很多，更重要的是gitlab runner可以安装到不同的机器上，甚至是我们本机，这样完全就不会影响Gitlab本身了。从gitlab…

本系列文档将介绍如何使用二进制部署Kubernetes v1.14集群的所有部署，而不是使用自动化部署(kubeadm)集群。在部署过程中，将详细列出各个组件启动参数，以及相关配置说明。在学习完本文档后，将理解k8s各个组件的交互原理，并且可以快速解决实际问题。

本次的安装是按照企业级环境安装，虽然kubeadm在1.13版本已经毕业，但是企业安装目前还是推荐使用1.13.5源码的安装方式。本次的环境就是使用k8s 1.13源码集群安装方式进行搭建

本文章主要介绍如何通过使用官方提供的二进制包安装配置k8s 1.11集群，并且所有的镜像yaml文件都提供了下载地址~