ControlPlane

参考资料： 官方文档 一、虚拟机安装 配置说明： windows下使用vbox，centos17.6 min版，kubernetes的版本是1.14.1, 安装如下三台机器： 192.168.56.15 k15 192.168.56.16 k16 192.168.56.17 k17 其中k15作为master，k16和k17作为node，虚拟机的安装重点关注网卡设置，设置两个网卡，第一个网卡（ifcfg-enp0s3）Host Only模式，第二个网卡（ifcfg-enp0s8）NAT模式，参见下图 二、虚拟机基本设置 本章节三台机器都执行，这里以k15为例 1.配置hostname hostnamectl --static set-hostname k15 2. 网卡设置 红色字体部分是需要修改和新增的配置 #网卡1 Local Bridge vi /etc/sysconfig/network-scripts/ifcfg- enp0s3 TYPE = Ethernet PROXY_METHOD = none BROWSER_ONLY = no BOOTPROTO = static DEFROUTE = yes IPV4_FAILURE_FATAL = no IPV6INIT = yes IPV6_AUTOCONF = yes IPV6_DEFROUTE = yes IPV6

目录 [toc] 什么是Kubeadm?   大多数与 Kubernetes 的工程师，都应该会使用 kubeadm 。它是管理集群生命周期的重要工具，从创建到配置再到升级; kubeadm 处理现有硬件上的生产集群的引导，并以最佳实践方式配置核心 Kubernetes 组件，以便为新节点提供安全而简单的连接流程并支持轻松升级。   在 Kubernetes 的文档 Creating a single master cluster with kubeadm 中已经给出了目前kubeadm的主要特性已经处于 Beta 状态了，在 2018 年就会转换成正式发布 (GA) 状态态，说明 kubeadm 离可以在生产环境中使用的距离越来越近了。    什么是容器存储接口(CSI)?   容器存储接口最初于 1.9 版本中作为 alpha 测试功能引入，在 1.10 版本中进入 beta 测试，如今终于进入 GA 阶段正式普遍可用。在 CSI 的帮助下， Kubernetes 卷层将真正实现可扩展性。通过 CSI ，第三方存储供应商将可以直接编写可与 Kubernetes 互操作的代码，而无需触及任何 Kubernetes 核心代码。事实上，相关规范也已经同步进入 1.0 阶段。    什么是CoreDNS?   在1.11中，官方宣布 CoreDNS

根据CNCF的最新年度调查，很多组织对Service Mesh表现出很高的兴趣，并且有一部分已经在生产环境中使用它们。你可能不知道Linkerd是市场上第一个Service Mesh，但是Istio使Service Mesh更受欢迎。这两个项目都是最前沿的项目，而且竞争非常激烈，因此很难选择一个项目。 在本篇文章中，我们将和你一起了解Istio和Linkerd架构，组件，并比较它们的产品以帮助你做出明智的决定。 Service Mesh简介 在过去的几年中，微服务架构已成为软件设计中流行的样式。在这种架构中，我们将应用程序分解为可独立部署的服务。这些服务通常是轻量级的，多语言的，并且通常由各种职能团队进行开发部署。 当某些服务数量增加，难以管理且越来越复杂时，微服务架构将一直有效。但这也在管理安全性，网络流量控制和可观察性等各个方面带来了挑战。 Service Mesh可以很好地帮助应对这些挑战。 Service Mesh 用于描述组成应用程序的微服务及其之间的交互。随着服务数量的增加和复杂性的增加，扩展和管理变得越来越困难。Service Mesh可以为微服务架构提供服务发现，负载均衡，故障恢复，指标和监视。 Service Mesh 通常还能够满足更复杂的需求，例如A/B测试，金丝雀发布，速率限制，访问控制和端到端身份验证。 Service Mesh

设置系统主机名以及 Host 文件的相互解析 hostnamectl set-hostname k8s-master01 hostnamectl set-hostname k8s-master02 hostnamectl set-hostname k8s-master03 vi /etc/hosts 10.10.21.8 k8s-master01 10.10.21.28 k8s-master02 10.10.21.38 k8s-master03 10.10.21.100 k8s-vip 安装依赖包 yum install -y conntrack ntpdate ntp ipvsadm ipset jq iptables curl sysstat libseccomp wget net-tools git 设置防火墙为 Iptables 并设置空规则 systemctl stop firewalld && systemctl disable firewalld yum -y install iptables-services && systemctl start iptables && systemctl enable iptables&& iptables -F && service iptables save 关闭 SELINUX swapoff -a && sed -i '/

阅读本文大概需要 6.5 分钟。 转自：https://www.sdnlab.com/11368.html 作者：SDNLAB 君 什么叫网络虚拟化? 为了解释这个问题，先上两张简单粗暴的图。 所有的通信应用无非就是两部分组成： 计算和网络 。这两者关系密不可分，但两者关系 严重缺乏对称性，网络一直拖累着计算 。 4G 网络 RAN 将会不断进化，据说，未来的 4G 网络空口速率将是现在的 10 倍。随着智能硬件的爆发，大量的应用接入 4G 网络，人们的流量需求如同海啸般汹涌而至，我们似乎赶上了好时代。不过， 传统的通信网络里，每一类服务对应基于专用集成电路的带有专用处理器的专用服务器 。网络里的设备很多，但是，这些家伙就像霸道总裁的办公室，仅供总裁专用，不管他在与不在，位置都占在那里，谁也不敢冒然挪用。 这样下去，网络会严重拖计算的后腿。 于是，有人想到了虚拟化 。 或者，可以这么理解， 服务器觉得老这样拖着网络跑不是办法，迟早会被累死 ，就开始向网络扔砖头了! 专用的硬件对应专用的服务，这样的花费是昂贵的 ，为了节省成本，我们得想想物尽其用。 想想你有一栋超级大的空置的公寓，你想出租， 但是每一位租客的需求是不一样的 。这个时候，你想到了 “虚拟化” 。根据租客的需求，把这栋公寓虚拟化成不同的建筑风格。于是，你对租客1说，“我有两栋公寓要出租，你喜欢红色那一栋还是蓝色那一栋?”

Master高可用安装 VIP负载均衡可以使用haproxy+keepalive实现，云上用户可以使用对应的ULB实现 准备kubeadm-init.yaml文件 1 apiVersion: kubeadm.k8s.io/v1beta2 2 bootstrapTokens: 3 - groups: 4 - system:bootstrappers:kubeadm:default-node-token 5 token: k60p22.go0fadibgqm2xcx8 6 ttl: 24h0m0s 7 usages: 8 - signing 9 - authentication 10 kind: InitConfiguration 11 localAPIEndpoint: 12 advertiseAddress: 10.8.31.84 13 bindPort: 6443 14 nodeRegistration: 15 criSocket: /var/run/dockershim.sock 16 name: k8s-test-master-1 17 taints: 18 - effect: NoSchedule 19 key: node-role.kubernetes.io/master 20 --- 21 apiServer: 22 timeoutForControlPlane:

实验目的 一般情况下，k8s集群中只有一台master和多台node，当master故障时，引发的事故后果可想而知。 故本文目的在于体现集群的高可用，即当集群中的一台master宕机后，k8s集群通过vip的转移，又会有新的节点被选举为集群的master，并保持集群的正常运作。 因本文体现的是master节点的高可用，为了实现效果，同时因资源条件限制，故总共采用4台服务器完成本次实验，3台master，1台node。 看到这也需有人有疑惑，总共有4台机器的资源，为啥不能2台master呢？这是因为通过kubeadm部署的集群，当中的etcd集群默认部署在master节点上，3节点方式最多能容忍1台服务器宕机。如果是2台master，当中1台宕机了，直接导致etcd集群故障，以至于k8s集群异常，这些基础环境都over了，vip漂移等高可用也就在白瞎。 环境说明 基本信息 # 主机列表 10.2.2.137 master1 10.2.2.166 master2 10.2.2.96 master3 10.2.3.27 node0 # 软件版本 docker version：18.09.9 k8s version：v1.16.4 架构信息 本文采用kubeadm方式搭建集群，通过keepalived的vip策略实现高可用，架构图如下： 　　 # 主备模式高可用架构说明 a

RFC 7348 ToR: Top of Rack （一种数据中心的布线方式，就是在机柜的最上面安装接入交换机） VNI: VXLAN Network Identifier(or VXLAN Segment ID), The term is used as a representation of a 24-bit NVO instance identifier,with the understanding that VNI will refer to a VXLAN Network Identifier in VXLAN,or Virtual Netowrk Identifier in GENEVE,etc. （VXLAN网络中的标识符。一个VNI标识一个VXLAN网络？） VTEP: VXLAN Tunnel End Point.An entity that originates and/or terminates VXLAN tunnels. (VXLAN隧道的发起点 和/或 VXLAN隧道的结束点) VXLAN: Virtual eXtensible Local Area Network.（虚拟扩展局域网络） VXLAN Gateway: An entity that forwards traffic between VXLANs. （在VXLAN中转发流量的实体） RFC

简介 MPLS （Multiprotocol Label Switching，多协议标签交换）是目前应用比较广泛的一种骨干网技术。MPLS在无连接的IP网络上引入面向连接的标签交换概念，将第三层路由技术和第二层交换技术相结合，充分发挥了IP路由的灵活性和二层交换的简洁性。 技术特点 在MPLS网络中，设备根据短而定长的标签转发报文，省去了查找IP路由表的繁琐过程，为数据在骨干网络中的传送提供了一种高速高效的方式。 MPLS位于链路层和网络层之间，它可以建立在各种链路层协议（如以太网等）之上，为各种网络层（IPv4、IPv6、IPX等）提供面向连接的服务。 支持多层标签和面向连接的特点，使得MPLS具有良好的扩展性，在MPLS网络基础上可以为客户提供各种服务。目前，MPLS在***、流量工程、QoS等方面得到广泛应用。 基本概念 FEC（Forwarding Equivalence Class，转发等价类）。MPLS将具有相同特征（目的地相同或具有相同服务等级等）的报文归为一类，称为FEC。属于相同FEC的报文在MPLS网络中将获得完全相同的处理。 标签：标签是一个长度固定、只具有本地意义的标识符，用于唯一标识一个报文所属的FEC。一个标签只能代表一个FEC。 LSR（Label Switching Router，标签交换路由器）是具有标签分发能力和标签交换能力的设备

作者：gc(at)sysin.org，主页： www.sysin.org 请访问原文发布链接：< https://sysin.org/article/kind/>，查看最新版 。 是否没有足够的机器运行 Kubernetes 测试环境，个人电脑配置不高的话，运行多个节点的虚拟化有点力不从心，国内公有云主机一般不支持嵌套虚拟化，一套 3M+3N 的群集环境成本太高。VMware Fusion 12.0 发布，将 Kind 带入了我们的视野，这是 Google 官方的一个工具，可能是在单机运行 Kubernetes 群集的最佳方案。笔者在一台 1C 2G 的公有云虚机上运行 Kind，也不会因为计算资源有限而无法完成。 1. 简介 kind 是 Kubernetes in Docker 的简写，是一个使用 Docker 容器作为 Nodes，在本地创建和运行 Kubernetes 群集的工具。适用于在本机创建 Kubernetes 群集环境进行开发和测试。 官网：< https://kind.sigs.k8s.io/> ; kind 由以下组件构成: Go packages implementing cluster creation , image build , etc. A command line interface ( kind ) built on these