k8s 环境搭建 二进制方式

声明:所有文章只作为学习笔记用,转载非原创
官方文档

https://kubernetes.io/docs/tasks/tools/install-kubectl/#install-kubectl-binary-via-curl
k8s 网络爬坑
学习笔记https://www.huweihuang.com/kubernetes-notes/concepts/object/understanding-kubernetes-objects.html 
k8s
https://www.cnblogs.com/harlanzhang/p/10114484.html 
https://blog.sealyun.com/views/container/2020/kube-cert.html#service-account%E5%AF%86%E9%92%A5%E5%AF%B9-sa-key-sa-pub  #类型和原理


#证书爬坑 ---------
 https://www.cnblogs.com/guogangj/p/4118605.html  理清概念
https://blog.sealyun.com/views/container/2020/kube-cert.html#%E4%BB%8Ersa%E8%AF%B4%E8%B5%B7
https://www.jianshu.com/p/4932cb1499bf  #通俗理解
https://zhuanlan.zhihu.com/p/123858320 #很好
#Kubernetes 之 二进制安装(二) 证书详解
[https://blog.51cto.com/13210651/2361208](https://blog.51cto.com/13210651/2361208)
[http://dockone.io/article/10187](http://dockone.io/article/10187)


#权限问题
https://blog.csdn.net/BigData_Mining/article/details/88529157 
 https://blog.csdn.net/u010859650/article/details/89555413 
中ca-key.pem是ca的私钥,ca.csr是一个签署请求,ca.pem是CA证书,是后面kubernetes组件会用到的RootCA。

密钥对:sa.key sa.pub  根证书:ca.crt etcd/ca.crt  私钥:ca.key 等 其它证书
注意:CSR并不是证书。而是向权威证书颁发机构获得签名证书的申请。

#摘要&数字签名
1.A先对这封Email执行哈希运算得到hash值简称“摘要”,取名h1
2.然后用自己私钥对摘要加密,生成的东西叫“数字签名”
总结:公钥和私钥是成对的,它们互相解密。
      公钥加密,私钥解密。
      私钥数字签名,公钥验证。

RSA算法基于一个十分简单的数论事实:将两个大素数相乘十分容易,但那时想要对其乘积进行因式分解却极其困难,因此可以将乘积公开作为加密密钥。

SSL - Secure Sockets Layer,现在应该叫"TLS"
OpenSSL - 简单地说,OpenSSL是SSL的一个实现,SSL只是一种规范
证书标准
X.509 - 这是一种证书标准,主要定义了证书中应该包含哪些内容.
kube-scheduler 源码分析
编码格式
同样的X.509证书,可能有不同的编码格式,目前有以下两种编码格式.

PEM - Privacy Enhanced Mail,打开看文本格式,以"-----BEGIN..."开头, "-----END..."结尾,内容是BASE64编码.
查看PEM格式证书的信息:openssl x509 -in certificate.pem -text -noout
Apache和*NIX服务器偏向于使用这种编码格式.

DER - Distinguished Encoding Rules,打开看是二进制格式,不可读.
查看DER格式证书的信息:openssl x509 -in certificate.der -inform der -text -noout
Java和Windows服务器偏向于使用这种编码格式.
相关的文件扩展名
这是比较误导人的地方,虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫"PEM"或者"DER",常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.

kube-proxy ipvs 原理 
可以认为Kubernetes的Service就是一个四层负载均衡,Kubernetes对应的还有七层负载均衡Ingress
Kubernetes为了实现在集群所有的节点都能够访问Service,kube-proxy默认会在所有的Node节点都创建这个VIP并且实现负载,所以在部署Kubernetes后发现kube-proxy是一个DaemonSet。
 https://www.jianshu.com/p/aa01b569fd42 
 https://mp.weixin.qq.com/s?__biz=MzI1MDI3NDE1Mg==&mid=2247483931&idx=1&sn=bbfbf5221f86457ec089b02276afb6d9&chksm=e9858a1cdef2030af694b640b7c6569f937cfe0d1ce98c597816a229eae86aff3f546fba3371&scene=21#wechat_redirect 

浅聊几种容器网络
 https://mp.weixin.qq.com/s?__biz=MzI1MDI3NDE1Mg==&mid=2247483889&idx=1&sn=53a64865e5e9fd9ad8c16ffe36d7075f&chksm=e98589f6def200e0f19fd2c91a77de59bc86d3edd6ee7e8db3f2da716ffbedb2dad4d27b0921&scene=21#wechat_redirect 

#ospf AS 区域问题
https://blog.csdn.net/qq_43482132/article/details/97518741 
https://blog.csdn.net/hrl7752/article/details/77832983 



overlay https://blog.csdn.net/zhaihaifei/article/details/74340428 
 Overlay 在网络技术领域,指的是一种网络架构上叠加的虚拟化技术模式
Overlay网络与物理网络的依存关系。由于VXLAN(Virtual eXtensible LAN)技术是当前最为主流的Overlay标准,以下VXLAN技术为代表进行具体描述。
在VXLAN网络中,用于建立VXLAN隧道的端点设备称为VTEP(VXLAN Tunneling End Point,VXLAN隧道终结点),封装和解封装在VTEP节点上进行。

Calico 工作原理 https://blog.csdn.net/jiang_shikui/article/details/85870560 

Calico把每个操作系统的协议栈认为是一个路由器,然后把所有的容器认为是连在这个路由器上的网络终端,在路由器之间跑标准的路由协议——BGP的协议,然后让它们自己去学习这个网络拓扑该如何转发。所以Calico方案其实是一个纯三层的方案,也就是说让每台机器的协议栈的三层去确保两个容器,跨主机容器之间的三层连通性。
 

#Kubernetes-k8s网络模型原理
https://blog.csdn.net/adson1987/article/details/90240106
同节点Pod之间的通信------关键字 一端在主机命名空间 另一端在容器命名空间
在容器启动前,会为容器创建一个虚拟Ethernet接口对,这个接口对类似于管道的两端,其中一端在主机命名空间中,另外一端在容器命名空间中,并命名为eth0。在主机命名空间的接口会绑定到网桥。网桥的地址段会取IP赋值给容器的eth0接口。

https://blog.csdn.net/weixin_42354900/article/details/103221647
underlay overlay 网络虚拟化 原理(Rationale)和思想(Idea) 知其然当然很好,但更好的是知其所以然。毫无疑问,这一原则同样地适用于其他计算机科学领域。

从静态的角度来看,网络可表示为数据结构中的图(Graph),网络的节点(如交换机和路由器,一些文献把他们统称为Datapath)是为图的顶点(Vertex),而链接(Link)就是图的边(Edge),这就是网络的拓扑视图。对于每一个网络节点,其数据(Data Traffic)转发行为由一系列的查询表(Lookup Table)如二层MAC表(L2 MAC Table)、三层路由表(L3 FIB Table),ACL(Access Control Lists)表来定义
 https://cloud.tencent.com/developer/article/1529250 
 https://blog.csdn.net/liukuan73/article/details/48270011 
#相当不错
 https://www.cnblogs.com/x-x-736880382/p/12016914.html  mac表 路由表 概念
在初始构造数据包准备发送时,源主机究竟要如何获得目的主机网络设备MAC地址的呢?这时,就需要使用到ARP协议。在网络拓扑中的每个节点或说主机上,实际都维护有一张ARP表,它记录着主机的IP地址(网络地址)到MAC地址(物理地址)的映射关系。
一个人已经有了手机号(IP地址),为什么还要有身份证号呢(MAC地址)?身份证号是一个人的唯一标识号,只要有这个号码就能找到该人,但是为啥他的朋友们不用身份证号来寻找该人而用手机号呢?对,因为方便。但是如果该人犯罪,警察用手机号呼叫寻找该人,傻子才会接吧…而且换了号码怎么办?那不就得用你的身份证号在全国发布通缉令,利用身份证号在全国各种系统范围(消费、社交、医疗)内搜索该人的记录,才能最终定位该人实施有效逮捕嘛。

#mac 唯一吗
 https://blog.csdn.net/renlonggg/article/details/78435986 


 https://blog.csdn.net/zhonglinzhang/article/details/77197834 
#运行机制
https://www.cnblogs.com/linuxk/p/10291178.html
 https://blog.51cto.com/junwang/1439428  lvs 运行原理
#netfilter 机制
https://www.cnblogs.com/lms0755/p/9009587.html 
https://www.cnblogs.com/liushaodong/archive/2013/02/26/2933593.html 
http://blog.chinaunix.net/uid-23871250-id-5825936.html
https://blog.csdn.net/Hello_MyDream/article/details/85096070  协议栈



基础概念总结:
pod 只是最基础的对象,pod 上面有更高层
什么是service 

关于resource 
#三个ip  cluster  pod service 
 https://www.cnblogs.com/jason0529/p/9146724.html 








 #https://www.cnblogs.com/chenli90/p/10311655.html 
#查看ns的pod
kubectl get pod --all-namespaces -o wide
kubectl get pod -n kube-system

https://www.cnblogs.com/shuiguizi/p/10923841.html 
https://zhuanlan.zhihu.com/p/65566171
kube-proxy 模式 相关还有七层https://www.jianshu.com/p/7dd8546e71c1 
cni cnm 概念 https://www.jianshu.com/p/ea77ece7158d 

#k8s Pod,Deployment,ReplicaSet,Service之间关系分析
 https://www.cnblogs.com/Bjwf125/p/12779685.html #清晰的讲解

https://blog.csdn.net/ucsheep/article/details/81781509 https://www.cnblogs.com/Andya/p/12425793.html
https://blog.csdn.net/qq_29648159/article/details/85473833 

#docker 
Endpoint(IP+Port)访问点
但Kubernetes 能够让我们通过Service虚拟Cluster IP+Service Port连接到指定的Service上
docker system df
https://www.cnblogs.com/guigujun/p/10556508.htmlPause容器 全称infrastucture container(又叫infra)基础容器。
我们看下在node节点上都会起很多pause容器,和pod是一一对应的。

每个Pod里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷,因此他们之间通信和数据交换更为高效,在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中。同一个Pod里的容器之间仅需通过localhost就能互相通信。
 https://blog.csdn.net/wanglei_storage/article/details/50299491 
 https://www.jianshu.com/p/1a7ab3e02455 
 https://www.cnblogs.com/insist-forever/p/11739207.html  #docker 目录迁移


容器虚拟化网络方案,总体分为2种截然不同的发展路线:
 基于隧道
 基于路由
#flannel 是coreos 团队设计的针对k8s 网络规划的一个服务,让集群中不同节点主机创建的docker 容器都具有全集群唯一的虚拟ip地址
1 同一个pod 内多个容器之间 : pause lo 
2 各pod 之间通信: overlay network
3 pod 与service 之间通讯: 各节点的iptables 规则 
   向外网发送请求 snat 

节点网络 (真实的) pod    service(ipvs 或者 iptables ) 都是虚拟网络


etcd与flannel 关系
1存储了flannel 可分配的ip地址段资源
2监控etcd 中每个pod 实际地址,并在内存中建立维护pod节点的路由表


flannel vxlan和calico ipip模式都是隧道方案,但是calico的封装协议IPIP的header更小,所以性能比flannel vxlan要好一点点。
优势就是对物理网络环境没有特殊要求,只要宿主机IP层可以路由互通即可。
劣势就是性能差,这需要从2方面看:
 封包和解包耗费CPU性能
 额外的封装导致带宽浪费,大约有30%左右的带宽损耗

基于路由
路由方案性能最好,原因是该方案不需要封包和解包,所以没有隧道方案的劣势,网络性能很好。
常见的路由方案包括了flannel的host-gw模式,以及calico的bgp模式。
下面以calico bpg模式为例,分析基于路由的方案原理,其包含了3个部分。




#flannel calico  都涉及到了网络覆盖的内容,也就是跨主机容器之间的通信
https://juejin.im/entry/599d33ad6fb9a0247804d430 白话Kubernetes网络
https://www.cnblogs.com/shuiguizi/p/10922049.html


Docker也设计了一套网络标准,称为CNM(即Libnetwork)。Kubernetes采用CNI而非CNM,这背后有很长的一段故事,核心的原因就是CNI对开发者的约束更少,更开放,不依赖于Docker工具,而CNM对Docker有非常强的依赖,无法作为通用的容器网络标准。
https://github.com/coreos/flannel/releases
https://github.com/kubernetes
https://docs.projectcalico.org/v3.11/release-notes/
#calico原理
 https://blog.csdn.net/ganpuzhong42/article/details/77853131 

搭建Kubernetes集群环境有以下三种方式:

  1. Minikube安装方式
    Minikube是一个工具,可以在本地快速运行一个单点的Kubernetes,尝试Kubernetes或日常开发的用户使用。但是这种方式仅可用于学习和测试部署,不能用于生产环境。

  2. Kubeadm安装方式
    kubeadm是一个kubernetes官方提供的快速安装和初始化拥有最佳实践(best practice)的kubernetes集群的工具,提供kubeadm init和kubeadm join,用于快速部署Kubernetes集群。目前kubeadm还处于beta 和alpha状态,不推荐用在生产环境,但是可以通过学习这种部署方法来体会一些官方推荐的kubernetes最佳实践的设计和思想。
    kubeadm的目标是提供一个最小可用的可以通过Kubernetes一致性测试的集群,所以并不会安装任何除此之外的非必须的addon。kubeadm默认情况下并不会安装一个网络解决方案,所以用kubeadm安装完之后,需要自己来安装一个网络的插件。所以说,目前的kubeadm是不能用于生产环境的
    https://www.cnblogs.com/edisonchou/p/aspnet_core_on_k8s_deepstudy_part1.html

  3. 二进制包安装方式(生产部署的推荐方式)

https://blog.csdn.net/nklinsirui/article/details/80581286#%E4%B8%8B%E8%BD%BD%E5%AE%89%E8%A3%85%E5%8C%85

centos7 
https://www.cnblogs.com/spll/p/10033316.html 

从官方下载发行版的二进制包,手动部署每个组件,组成Kubernetes集群,这种方式符合企业生产环境标准的Kubernetes集群环境的安装,可用于生产方式部署。

1. 由于之前用kubeadmin 安装过所以先清理 环境
https://www.cnblogs.com/net2817/p/10513369.html
https://blog.csdn.net/ccagy/article/details/85845979

软件清单
https://www.cnblogs.com/xinfang520/p/11608701.html

二进制部署参考:
重点参考 
https://github.com/easzlab/kubeasz  #重点中的重点
https://www.cnblogs.com/bixiaoyu/p/11720864.html #重点部署描述
https://blog.com/wzli.51ctonux/2451105 #参考数据
https://www.cnblogs.com/galengao/p/11957989.html #参考
http://www.codedog.fun/2020/04/12/Kubernetes(k8s)%E4%B8%AA%E4%BA%BA%E7%AC%94%E8%AE%B0(%E6%9B%B4%E6%96%B0%E4%B8%AD)/   #重点参考
 https://blog.csdn.net/john_f_lau/article/details/78217490 
证书之间的转换

 https://blog.csdn.net/qq_37049781/article/details/84837342 
 https://www.cnblogs.com/rouqinglangzi/p/10832751.html 清晰明了
https://blog.csdn.net/henrydlwang/article/details/77547339
[https://blog.csdn.net/lcxhjg/article/details/80968548?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase
 https://blog.csdn.net/liumiaocn/article/details/103556952  #证书基本概念

PKCS 全称是 Public-Key Cryptography Standards 
.cer/.crt是用于存放证书,它是2进制形式存放的,不含私钥。
.pem跟crt/cer的区别是它以Ascii来表示。
pfx/p12用于存放个人证书/私钥,他通常包含保护密码,2进制方式
csr : certificate signing request 
申请者的公钥信息
使用申请者私钥所生成的数字签名
申请者机构相关的信息


https://www.cnblogs.com/JetpropelledSnake/p/10612763.html#_label2
https://i4t.com/4253.html 
https://www.cnblogs.com/loong576/p/12218524.html #集群

参考: 图很好
https://www.cnblogs.com/xiaoyuxixi/p/12532584.html 

https://www.jianshu.com/p/8067912667f1](https://www.jianshu.com/p/8067912667f1
https://blog.csdn.net/qq_42987484/article/details/104046748
https://blog.csdn.net/weixin_34378045/article/details/93822950
https://www.cnblogs.com/kevingrace/p/10961264.html
https://blog.csdn.net/dream_ya/article/details/81108939
https://www.jianshu.com/p/16c0c2b90e34

其它:
集成calico
https://www.cnblogs.com/puroc/p/6361733.html
kube-dns 
https://www.cnblogs.com/fuyuteng/p/11021762.html

实例学习Ansible系列:
K8S离线安装:二进制文件下载  https://blog.csdn.net/liumiaocn/article/details/96421940




----------------------     部署开始    ------------------------


二进制软件包下载及组件 : 

# kubernetes和calico集成  (基础安装好再集成)
https://www.cnblogs.com/puroc/p/6361733.html
#helm 是类似于yum rpm 的软件管理工具
https://www.jianshu.com/p/4bd853a8068b

从网址中选择相应的版本,本文以1.9.1版本为例,从 CHANGELOG页面 下载二进制文件。
https://github.com/kubernetes/kubernetes/releases

#基础软件包版本
wget https://storage.googleapis.com/kubernetes-release/release/v1.17.2/kubernetes-server-linux-amd64.tar.gz
wget https://dl.k8s.io/v1.17.4/kubernetes-server-linux-amd64.tar.gz
wget https://github.com/coreos/flannel/releases/download/v0.11.0/flannel-v0.11.0-linux-amd64.tar.gz
wget https://github.com/etcd-io/etcd/releases/download/v3.3.18/etcd-v3.3.18-linux-amd64.tar.gz 

#docker  已经通过yum 安装好
wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/containerd.io-1.2.0-3.el7.x86_64.rpm
wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-cli-18.09.0-3.el7.x86_64.rpm
wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-18.09.0-3.el7.x86_64.rpm
wget https://download.docker.com/linux/centos/7/x86_64/stable/Packages/docker-ce-selinux-17.03.3.ce-1.el7.noarch.rpm

#未下载    docker-compose-Linux-x86_64
https://github.com/docker/compose/releases/tag/1.24.0 

wget https://get.helm.sh/helm-v2.14.3-linux-amd64.tar.gz
Helm 是 Kubernetes 的包管理器。包管理器类似于我们在 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样,能快速查找、下载和安装软件包。Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。

coredns:https://github.com/kubernetes/kubernetes/edit/master/cluster/addons/dns/coredns/coredns.yaml.sed

# [centos7添加bridge-nf-call-ip6tables出现No such file or directory] https://www.cnblogs.com/zejin2008/p/7102485.html 

#未配置 请查看centos7 常用设置里的链接
设置rsyslogd 和systemd journald

安装包总结

本套Kubernetes集群环境版本
-  Kubernetes 1.17.2
-  Docker 19.03.5-ce
-  Etcd  v3.3.18
-  Flanneld 0.11.0 

插件:
-  Coredns
-  Dashboard
-  Metrics-server

镜像仓库:
 harbor(两个仓库相互同步,对外提供统一入口VIP地址)

主机名与IP规划及基础配置:

#主机名
hostnamectl set-hostname k8s-master
hostnamectl set-hostname k8s-node1
hostnamectl set-hostname k8s-node2
                                            
#/etc/hosts 解析
192.168.204.22 k8s-master
192.168.204.23 k8s-node1
192.168.204.24 k8s-node2

#关闭防火墙
systemctl stop firewalld.service
systemctl disable firewalld.service

#关闭 selinux 
setenforce 0  #临时关闭
sed -i 's#SELINUX=disabled#SELINUX=enforcing#g' /etc/selinux/config

#关闭swap 
/etc/fstab 删除swap 相关条目
echo "vm.swappiness = 0">> /etc/sysctl.conf  
swapoff -a  #临时关闭
sysctl -p
free -m
关系:  total = used + free +Buffers/cached

#免密登
[root@etcd-1 ~]# ssh-keygen -t rsa
[root@etcd-1 ~]# ssh-copy-id root@k8s-master
[root@etcd-1 ~]# ssh-copy-id root@k8s-node1
[root@etcd-1 ~]# ssh-copy-id root@k8s-node2

#时间服务 chrony 需要添加以下三行
/etc/chrony.conf   #server端口
server 127.0.0.1 iburst
local stratum 10
allow

/etc/chrony.conf 
server 192.168.174.201 iburst
local stratum 10
allow

▪查看时间同步源:
chronyc sources
chronyc sources -v

▪查看时间同步源状态:
chronyc sourcestats -v
可以通过运行chronyc命令来修改设置。

accheck:检查NTP访问是否对特定主机可用。
activity:该命令会显示有多少NTP源在线/离线。
add server:手动添加一台新的NTP服务器。
clients:在客户端报告已访问到服务器。
delete:手动移除NTP服务器或对等服务器。
settime:手动设置守护进程时间。
tracking:显示系统时间信息。


#openssl cfssl 证书官网
http://pkg.cfssl.org/ 
原理 https://blog.csdn.net/qq_26566331/article/details/88185652 
         https://www.cnblogs.com/MicroHeart/p/9057189.html 
    数字证书简称CA,它由权威机构给某网站颁发的一种认可凭证。颁发证书机构它也有一对公钥和私钥。证书机构用它的私钥将 A的公钥 和 一些A的信息 加密得到数字证书。然后A发送数据给B时,包含了三个部分:原文+数字签名+数字证书  ,注意,现在B不持有A的公钥,B持有的是证书机构的公钥,通过证书机构的公钥解密数字证书拿到A的公钥,然后在重复之前的过程计算数字签名,跟发来的数字签名比对。但是有同样的一个问题:如果B现在持有的证书机构的公钥被别人替换呢?这个过程是建立在被大家所认可的证书机构之上得到的公钥,所以这是一种安全的方式。
#证书概要
etcd 节点需要标识自己服务的server cert,也需要client cert与etcd集群其他节点交互,当然可以分别指定2个证书,也可以使用一个对等证书
master 节点需要标识 apiserver服务的server cert,也需要client cert连接etcd集群,这里也使用一个对等证书
kubectl calico kube-proxy 只需要client cert,因此证书请求中 hosts 字段可以为空
kubelet证书比较特殊,不是手动生成,它由node节点TLS BootStrap向apiserver请求,由master节点的controller-manager 自动签发,包含一个client cert 和一个server cert

https://www.jianshu.com/p/4c870654200e
#openssl pem 生成公钥和私钥及文件
https://blog.csdn.net/m0_38080126/article/details/77609304 
#证书和秘钥的内容
http://www.360doc.com/content/13/1001/18/13493714_318414906.shtml 



配置 https://www.cnblogs.com/agang-php/p/12724218.html 
cfssl 证书https://blog.csdn.net/DXZCZH/article/details/86388869 
 https://blog.csdn.net/wuxiaolongah/article/details/90727920 

#下载cfssl 开始生成证书
wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64

chmod +x cfssl_linux-amd64 cfssljson_linux-amd64 cfssl-certinfo_linux-amd64

scp -r cfssl/ root@192.168.174.202:/workshare/
mv cfssl_linux-amd64 /usr/local/bin/cfssl
mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
mv cfssl-certinfo_linux-amd64 /usr/bin/cfssl-certinfo

mv  cfssl /usr/local/bin/cfssl
mv cfssljson /usr/local/bin/cfssljson
mv cfssl-certinfo /usr/bin/cfssl-certinfo
#
ln -s /opt/etcd/bin/etcdctl  /usr/bin/

#生成证书  
所有文件放到这个目录下:
mkdir -p /usr/local/kubernetes/ca
#证书文件
https://www.cnblogs.com/centos-python/articles/11043570.html
其中ca-key.pem是ca的私钥,ca.csr是一个签署请求,ca.pem是CA证书,是后面kubernetes组件会用到的RootCA。

密钥对:sa.key sa.pub  根证书:ca.crt etcd/ca.crt  私钥:ca.key 等 其它证书
#摘要&数字签名
1.A先对这封Email执行哈希运算得到hash值简称“摘要”,取名h1
2.然后用自己私钥对摘要加密,生成的东西叫“数字签名”
总结:公钥和私钥是成对的,它们互相解密。
 --     公钥加密,私钥解密。
 --     私钥数字签名,公钥验证。
看完这个过程,是不是觉得数字签名不过如此。其实就是利用算法(不一定是非对称算法)对原文hash值加密,然后附着到原文的一段数据。数字签名的作用就是验证数据来源以及数据完整性!解密过程则称为数字签名验证。

 

#创建根证书 (CA)
CA 证书是集群所有节点共享的,只需要创建一个 CA 证书,后续创建的所有证书都由它签名。

#ca 配置文件 配置证书生成策略,让CA软件知道颁发什么样的证书。
cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ],
        "expiry": "87600h"
      }
    }
  }
}
EOF
#######################
signing 表示该证书可用于签名其它证书,生成的ca.pem证书找中CA=TRUE
server auth 表示client可以用该证书对server提供的证书进行验证
client auth 表示server可以用该证书对client提供的证书进行验证

#创建 CA 证书签名请求
cat > ca-csr.json <<EOF
{
  "CN": "kubernetes",
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "ST": "BeiJing",
      "L": "BeiJing",
      "O": "k8s",
      "OU": "4Paradigm"
    }
  ],
  "ca": {
    "expiry": "876000h"
 }
}
EOF

#######################
CN CommonName,kube-apiserver从证书中提取该字段作为请求的用户名(User Name),浏览器使用该字段验证网站是否合法
O Organization,kube-apiserver 从证书中提取该字段作为请求用户和所属组(Group)
kube-apiserver将提取的User、Group作为RBAC授权的用户和标识

TLS作用:就是对通讯加密,防止中间人窃听;同时如果证书不信任的话根本就无法与 apiserver 建立连接,更不用提有没有权限向 apiserver 请求指定内容。
RBAC作用:
RBAC 中规定了一个用户或者用户组(subject)具有请求哪些 api 的权限;在配合 TLS 加密的时候,实际上 apiserver 读取客户端证书的 CN 字段作为用户名,读取 O 字段作为用户组。

# 生成CA证书和CA私钥和CSR(证书签名请求):
初始化ca
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -


# ls ca*
ca-config.json  ca.csr  ca-csr.json  ca-key.pem  ca.pem
(#ca-key.pem(私钥)和ca.pem(证书),还会生成ca.c上面命令执行结果是一堆字符串,可以用 cfssljson------------把它们导入文件中:
./cfssl gencert -initca cert/ca-csr.json | ./cfssljson -bare ca
执行结束后得到三个文件:ca-key.pem、ca.csr、ca.pem。
csr(证书签名请求)

#根据CA创建etcd证书
cat > etcd-csr.json << EOF
 {
 "CN": "etcd",
 "hosts": [
"192.168.204.22",
"192.168.204.23",
"192.168.204.24"
],
"key": {
"algo": "rsa",
 "size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing"
}
]
}
EOF

#根据CA 证书生成 etcd的文件
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes etcd-csr.json | cfssljson -bare etcd

查看cert(证书信息):
# cfssl certinfo -cert ca.pem
查看CSR(证书签名请求)信息:
# cfssl certinfo -csr ca.csr


#api -server 
cat > server-csr.json <<EOF
{
    "CN": "etcd",
    "hosts": [
    "192.168.204.22",
    "192.168.204.23",
    "192.168.204.24"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "BeiJing",
            "ST": "BeiJing"
        }
    ]
}
EOF

#生成server证书及其它
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes server-csr.json | cfssljson -bare server


加载内核模块 (添加ipvsadm)

#内核模块的介绍
#模块目录
/lib/modules/4.19.7-1.el7.elrepo.x86_64/kernel
http://c.biancheng.net/view/1039.html  
模块的添加删除

(简单的包含以下目录,有没列出的)
arch           #与硬件相关的模块
crypto         #内核支持的加密技术的相关模块
drivers       #硬件的驱动程序模块,如显卡、网卡等
fs         #文件系统模块,如 fat、vfat、nfs等
lib        #函数库
net      #网络协议相关模块
sound #音效相关模块
#模块相关命令
depmod [选项]  
#不加选项,depmod命令会扫描系统中的内核模块,并写入modules.dep文件
# lsmod    #列出安装的模块
# modinfo 模块名  # 查看模块信息
#添加删除模块
模块的扩展名一般是 *.ko;然后需要执行 depmod 命令扫描这些新模块,并写入 modules.dep 文件;最后就可以利用 modprobe 命令安装这些模块了。命令格式如下:
# modprobe [选项] 模块名

选项:
-I:列出所有模块的文件名,依赖 modules.dep 文件;
-f:强制加载模块;
-r:删除模块;
[root@localhost ~]# modprobe -r vfat
[root@localhost ~]# lsmod | grep vfat    #删除后查找确认

首先我们要检查是否存在所需的内核模块

find  /lib/modules/`uname -r`/ -name "ip_vs_rr*"
find  /lib/modules/`uname -r`/ -name "br_netfilter*"
1.加载内核,加入开机启动 (2选1即可)

cat > /etc/rc.local  << EOF
modprobe ip_vs_rr
modprobe br_netfilter
EOF
2.使用systemd-modules-load加载内核模块

cat > /etc/modules-load.d/ipvs.conf << EOF
 ip_vs_rr
 br_netfilter
EOF
systemctl enable --now systemd-modules-load.service
验证模块是否加载成功

lsmod |egrep " ip_vs_rr|br_netfilter"
为什么要使用IPVS,从k8s的1.8版本开始,kube-proxy引入了IPVS模式,IPVS模式与iptables同样基于Netfilter,但是采用的hash表,因此当service数量达到一定规模时,hash查表的速度优势就会显现出来,从而提高service的服务性能。
ipvs依赖于nf_conntrack_ipv4内核模块,4.19包括之后内核里改名为nf_conntrack,1.13.1之前的kube-proxy的代码


#时间服务配置 各节点需要配置时间同步服务
本次选了chrony 还有ntpd 可以配置
https://www.cnblogs.com/lizhaoxian/p/11260041.html 
https://www.aboutyun.com/thread-11395-1-1.html 
#ntpd 配置
https://www.aboutyun.com/thread-11395-1-1.html 

#开启ipvs  可选,当服务器达到一定数量时,hash 的性能会更好
https://www.jianshu.com/p/9b4b700c7765 
yum -y install ipvsadm  ipset

#docker 安装
 daemon.json 的作用 https://blog.csdn.net/u013948858/article/details/79974796 

https://blog.csdn.net/qq_29999343/article/details/78294604 
#dockerd dockerd 是docker daemon
https://blog.csdn.net/davidliuzkw/article/details/83987595 
--bip=""    使用 CIDR 地址来设定网络桥的 IP。此参数和 -b 不能一起使用。

#docker 网络的四种模式
https://www.jianshu.com/p/22a7032bb7bd 
网桥适用于在同一个Docker守护程下的容器。对于在不同Docker守护进程下运行的容器之间的通信,可以在宿主机上添加路由,也可以使用overlay网络。

Docker 安装时会创建一个 命名为 docker0 的 linux bridge。如果不指定--network,创建的容器默认都会挂到 docker0 上。

#实验测试
当数据数据链路层传输的时候叫做“帧”,当一个帧被接受并提交到第二次处理:剥开帧头帧尾,获得数据包(对于第二层来说它只认识帧头和帧尾,其他包括包头等都是帧承载的普通数据);然后这个包被提交到第三层:它能识别包头,得到被包在里面的信息(信息包含第四层TCP数据报头,对于第三层来说也是报头也是它承载的普通数据),第三层结束以后把去掉报头的数据给第四层,这些数据就是报文。

https://www.jianshu.com/p/d414865a4bfd 
https://blog.csdn.net/u011537073/article/details/82685586 #iptables 表和链

https://www.cnblogs.com/sammyliu/p/5760125.html  #重点参考
多节点 Docker 网络
  Docker 多节点网络模式可以分为两类,一类是 Docker 在 1.19 版本中引入的基于 VxLAN 的对跨节点网络的原生支持;另一种是通过插件(plugin)方式引入的第三方实现方案,比如 Flannel,Calico 等等。
https://www.cnblogs.com/sammyliu/p/5894191.html 

 1 创建my_net2 命名空间   
ip netns add mynet2 创建名称为 ‘myspace’ 的 linux network namespace
ip link add my_veth1 type veth peer name my_veth2   创建一个 veth 设备,一头为 veth1,另一头为 veth2
ip link list #能看到刚才添加的配对网卡
ip link set my_veth2 netns myspace #把my_veth2 放入myspace 中
brctl addbr testbr #增加一个网桥 和docker0 相同 ,容器与宿主机

docker network create --driver bridge --subnet 10.1.0.0/24 --gateway 10.1.0.1 my_net2 
docker network ls
c72d81dd333e        my_net2             bridge              local
veth 设备 同样有实验操作
https://blog.csdn.net/sld880311/article/details/77650937 

 Linux container 中用到一个叫做veth的东西,这是一种新的设备,专门为 container 所建。veth 从名字上来看是 Virtual ETHernet 的缩写,它的作用很简单,就是要把从一个 network namespace 发出的数据包转发到另一个 namespace。veth 设备是成对的,一个是 container 之中,另一个在 container 之外,即在真实机器上能看到的。


 2 ip a s 
6: br-c72d81dd333e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:d8:a5:14:ef brd ff:ff:ff:ff:ff:ff
    inet 10.1.0.1/24 brd 10.1.0.255 scope global br-c72d81dd333e
    valid_lft forever preferred_lft forever
3 指定运行的容器
docker run -itd --network my_net2 busybox
4  ip a s
   6: br-c72d81dd333e: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:d8:a5:14:ef brd ff:ff:ff:ff:ff:ff
    inet 10.1.0.1/24 brd 10.1.0.255 scope global br-c72d81dd333e
       valid_lft forever preferred_lft forever
    8: vethf55908a@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-c72d81dd333e state UP 
    link/ether 7a:20:f7:df:e9:09 brd ff:ff:ff:ff:ff:ff link-netnsid 0
5 brctl show #看到vethf55908a 连接在了 创建的my_net2 上,网卡名称为br-c72d81dd333e

br-c72d81dd333e         8000.0242d8a514ef       no              vethf55908a

6 容器内的ip 
docker exec -it 209fd6809402 /bin/sh
br-c72d81dd333e         8000.0242d8a514ef       no              veth9e54bd1
ip a
  7: eth0@if8: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc 
     noqueue 
    link/ether 02:42:0a:01:00:02 brd ff:ff:ff:ff:ff:ff
    inet 10.1.0.2/24 brd 10.1.0.255 scope global eth0
       valid_lft forever preferred_lft forever
#网络实验
ip netns exec net001 route -n #容器内路由
ip netns exec netns0 ip link set lo up
ip route add 10.89.255.0/24 via 10.89.255.254 dev eth0



所有来目的地址是10.89.255.0/24的数据包,自其下一跳地址(gateway)为10.89.255.254,并且知从本机eth0 接口发送出去道。

当创建一个Docker容器的时候,就会新建一个PID名空间。容器启动进程在该名空间内PID为1。当PID1进程结束之后,Docker会销毁对应的PID名空间,并向容器内所有其它的子进程发送SIGKILL。






如果想更改docker ip
[root@server1 ~]# vim /etc/docker/daemon.json
{
        "bip": "172.17.0.1/24"
}
# systemctl restart docker
# ip addr show docker0
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 02:42:23:2d:56:4b brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/24 brd 172.17.0.255 scope global docker0
    valid_lft forever preferred_lft forever

创建安装目录
mkdir -p /usr/local/kubernetes/{bin,config}

配置环境变量,安装etc
vim /etc/profile               #为了方便能够直接执行命令,加入声明 
export PATH=$PATH:/usr/local/kubernetes/bin
. /etc/profile 或 source /etc/profile
     
未做 mkdir -p /var/lib/etcd/        #建立工作目录--WorkingDirectory(3台)

解压etcd,移动命令到对应位置
tar xf /root/etcd-v3.3.18-linux-amd64.tar.gz
mv /root/etcd-v3.3.18-linux-amd64/etcd* /usr/local/kubernetes/bin/   

#etc.service
编写 https://blog.csdn.net/yuesichiu/article/details/51485147 

配置etcd.service 
[Unit]
Description=Etcd Server
After=network.target
#After=network-online.target
#Wants=network-online.target

[Service]
#Type=notify
Type=simple

WorkingDirectory=/usr/local/kubernetes/etc/data
EnvironmentFile=-/usr/local/kubernetes/config/etcd.conf
#User=etcd

# set GOMAXPROCS to number of processors
ExecStart=/bin/bash -c "GOMAXPROCS=$(nproc) /usr/local/kubernetes/bin/etcd \
--name=\"${ETCD_NAME}\" \
--data-dir=\"${ETCD_DATA_DIR}\" \
--listen-peer-urls=\"${ETCD_LISTEN_PEER_URLS}\" \
--advertise-client-urls=\"${ETCD_ADVERTISE_CLIENT_URLS}\" \
--initial-cluster-token=\"${ETCD_INITIAL_CLUSTER_TOKEN}\" \
--initial-cluster=\"${ETCD_INITIAL_CLUSTER}\"  \
--initial-cluster-state=\"${ETCD_INITIAL_CLUSTER_STATE}\" \
--listen-client-urls=\"${ETCD_LISTEN_CLIENT_URLS}\""
--cert-file=/usr/local/kubernetes/ca/etcd.pem \
--key-file=/usr/local/kubernetes/ca/etcd-key.pem \
--peer-cert-file=/usr/local/kubernetes/ca/etcd.pem \
--peer-key-file=/usr/local/kubernetes/ca/etcd-key.pem \
--trusted-ca-file=/usr/local/kubernetes/ca/ca.pem \
--peer-trusted-ca-file=/usr/local/kubernetes/ca/ca.pem
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target


编辑etcd配置文件   
cat /usr/local/kubernetes/config/etcd.conf 

#master 节点
[member]
ETCD_NAME=etcd_1
ETCD_DATA_DIR="/usr/local/kubernetes/etc/data"
ETCD_LISTEN_CLIENT_URLS="http://192.168.204.22:2379,http://127.0.0.1:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.204.22:2379"

[cluster]
ETCD_LISTEN_PEER_URLS="http://192.168.204.22:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.204.22:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.204.22:2380"
ETCD_INITIAL_CLUSTER="etcd_1=http://192.168.204.22:2380,etcd_2=http://192.168.204.23:2380,etcd_3=http://192.168.204.24:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="k8s-etcd-cluster"

#etcd_2
[member]
ETCD_NAME=etcd_2
ETCD_DATA_DIR="/usr/local/kubernetes/etc/data"
ETCD_LISTEN_CLIENT_URLS="http://192.168.204.23:2379,http://127.0.0.1:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.204.23:2379"

[cluster]
ETCD_LISTEN_PEER_URLS="http://192.168.204.23:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.204.23:2380"
ETCD_INITIAL_CLUSTER="etcd_1=http://192.168.204.22:2380,etcd_2=http://192.168.204.23:2380,etcd_3=http://192.168.204.24:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="k8s-etcd-cluster"

#etcd_3
[member]
ETCD_NAME=etcd_3
ETCD_DATA_DIR="/usr/local/kubernetes/etc/data"
ETCD_LISTEN_CLIENT_URLS="http://192.168.204.24:2379,http://127.0.0.1:2379"
ETCD_ADVERTISE_CLIENT_URLS="http://192.168.204.24:2379"

[cluster]
ETCD_LISTEN_PEER_URLS="http://192.168.204.24:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="http://192.168.204.24:2380"
ETCD_INITIAL_CLUSTER="etcd_1=http://192.168.204.22:2380,etcd_2=http://192.168.204.23:2380,etcd_3=http://192.168.204.24:2380"
ETCD_INITIAL_CLUSTER_STATE="new"
ETCD_INITIAL_CLUSTER_TOKEN="k8s-etcd-cluster"

• ETCD_NAME #节点名称
• ETCD_DATA_DIR #数据目录
• ETCD_LISTEN_PEER_URLS #集群通信监听地址
• ETCD_LISTEN_CLIENT_URLS #客户端访问监听地址
• ETCD_INITIAL_ADVERTISE_PEER_URLS #集群通告地址
• ETCD_ADVERTISE_CLIENT_URLS #客户端通告地址
• ETCD_INITIAL_CLUSTER #集群节点地址
• ETCD_INITIAL_CLUSTER_TOKEN #集群Token
• ETCD_INITIAL_CLUSTER_STATE 加入#集群的当前状态,new是新集群,existing表示加入已有集群

#etcd概念词汇表
Raft:etcd所采用的保证分布式系统强一致性的算法。
Node:一个Raft状态机实例。
Member: 一个etcd实例。它管理着一个Node,并且可以为客户端请求提供服务。
Cluster:由多个Member构成可以协同工作的etcd集群。
Peer:对同一个etcd集群中另外一个Member的称呼。
Client: 向etcd集群发送HTTP请求的客户端。
WAL:预写式日志,etcd用于持久化存储的日志格式。
snapshot:etcd防止WAL文件过多而设置的快照,存储etcd数据状态。
Proxy:etcd的一种模式,为etcd集群提供反向代理服务。
Leader:Raft算法中通过竞选而产生的处理所有数据提交的节点。
Follower:竞选失败的节点作为Raft中的从属节点,为算法提供强一致性保证。
Candidate:当Follower超过一定时间接收不到Leader的心跳时转变为Candidate开始竞选。
Term:某个节点成为Leader到下一次竞选时间,称为一个Term。
Index:数据项编号。Raft中通过Term和Index来定位数据。

#etcdctl 使用
虽然安装了etcd 3.3.18,但是使用etcdctl时还默认使用v2的api

WARNING:
Environment variable ETCDCTL_API is not set; defaults to etcdctl v2.
Set environment variable ETCDCTL_API=3 to use v3 API or ETCDCTL_API=2 to use v2 API.
(默认使用v2,若设置变量则使用v3,都是当前窗口有效,如下:)
windows:set ETCDCTL_API=3
linux:export ETCDCTL_API=3
注意:v3获取不到v2设置的值

VERSION:
3.3.18

#常用命令
增删改查 https://www.jianshu.com/p/a7c5e17b83fb

有一些常用的etc.sh脚本 
https://www.jianshu.com/p/16c0c2b90e34

export ETCDCTL_API=3
#etcdctl member list 
HOST_1=192.168.204.22
HOST_2=192.168.204.23
HOST_3=192.168.204.24
ENDPOINTS=$HOST_1:2379,$HOST_2:2379,$HOST_3:2379
etcdctl --endpoints=$ENDPOINTS member list
等同 etcdctl --endpoints=http://192.168.204.22:2379,http://192.168.204.23:2379,http://192.168.204.24:2379  

#flannel 搭建  
 flannel 原理图 
https://blog.csdn.net/ywq935/article/details/96326680 
https://www.cnblogs.com/yxh168/p/12206368.html 

     子网信息和宿主机的对应关系都保存在etcd中
     必须把docker0网桥的地址范围设置成flannel为宿主机分配的子网
     dockderd --bip=flannel_subnet

#深入理解docker 和k8s 网络 
基础概念CNI插件
https://blog.csdn.net/RancherLabs/article/details/88885539?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase

https://www.cnblogs.com/shuiguizi/p/10922049.html 
Docker会为每一个容器创建属于他自己的namespaces,即各个维度资源都专属这个容器了,此时的容器就是一个孤岛,也可以说是一个独立VM就诞生了。当然他不是VM,网上关于二者的区别和优劣有一对资料.

更进一步,也可以将多个容器共享一个namespace,比如如果容器共享的是network 类型的namespace,那么这些容器就可以通过 localhost:[端口号]  来通信了。因为此时的两个容器从网络的角度看,和宿主机上的两个内核进程没啥区别。

Endpoint是什么?

Endpoint是那些与VM、容器连接的接口(比如veth pair、TAP等),Calico会把那些已经定义好的security profiles应用在endpoint上,可能会同时存在多个profiles。

多进程/多容器可以共享namespace,而k8s的pod里就是有多个容器,他的网络实现原理就是先创建一个共享namespace,然后将其他业务容器加入到该namespace中。
k8s会自动以"合适"的方式为他们创建这个共享namespace,这正是"pause"容器的诞生。
kubelet
#默认的三个命名空间
kubectl create namespace mynamespace
kubectl get namespace
删除一个namespace会自动删除所有属于该namespace的资源。
default和kube-system命名空间不可删除。
default:向集群中添加对象而不提供命名空间,这样它会被放入默认的命名空间中。在创建替代的命名空间之前,该命名空间会充当用户新添加资源的主要目的地,无法删除。

kube-public:kube-public命名空间的目的是让所有具有或不具有身份验证的用户都能全局可读。这对于公开bootstrap组件所需的集群信息非常有用。它主要是由Kubernetes自己管理。

kube-system:kube-system命名空间用于Kubernetes管理的Kubernetes组件,一般规则是,避免向该命名空间添加普通的工作负载。它一般由系统直接管理,因此具有相对宽松的策略。


#Pause容器 全称infrastucture container(又叫infra)基础容器。
pause容器:创建的每一个pod都会随之为其创建一个所谓的"父容器"。其主要由两个功能:

(主要)负责为pod创建容器共享命名空间,pod中的其他业务容器都将被加入到pause容器的namespace中
  (可选) 负责回收其他容器产生的僵尸进程,此时pause容器可以看做是PID为1的init进程,它是所有其他容器(进程)的父进程。但在k8s1.8及以后,该功能缺省是关闭的(可通过配置开启)




----- docker 网络实验
https://www.cnblogs.com/sammyliu/p/5894191.html 
使用一个 linux bridge,默认为 docker0
使用 veth 对,一头在容器的网络 namespace 中,一头在 docker0 上
该模式下Docker Container不具有一个公有IP,因为宿主机的IP地址与veth pair的 IP地址不在同一个网段内
MASQUERADE
#实验
[https://www.cnblogs.com/sammyliu/p/5760125.html](https://www.cnblogs.com/sammyliu/p/5760125.html)



Container Networking Model
一句话:sandbox代表容器,network代表容器外的网络驱动形成的网络,endpoint连接了二者
endpoint(那一头 终点)
#查看网关
route -n
ip route show
traceroute www.prudentwoo.com -s 100 第一行就是自己的默认网关
netstat -r

bridge是一个桥作为master,可以往桥上挂很多类型及个数的interface接口,当桥上有一个接口接收到数据后,只要不是给桥所在的宿主机本身,则桥会内部转发,数据会从其余接口同步冒出来

# brctl show  #通过do
  bridge name     bridge id             STP enabled       interfaces
  docker0         8000.0242dee689ea     no                veth25dfcae
                                                                                  vetha470484
解说:docker0 上挂了两块interfaces  veth开头 (容器启动后生成)
总结: 也就是说在host上的veth接口 和容器内的eth接口 正是一对veth pair,至此Endpoint作为容器和nework的连接的任务达成了。而docker0正是名叫bridge的Network的驱动。

# overlay
这个词不是docker家的,一直以来就有overlay类型的网络,意/译为"覆盖"型网络,其中VxLan技术就可以认为是一种overlay类型网络的实现,而在docker的overlay网络,使用的正是Vxlan技术
#创建 overlay
docker  network  create  -d  overlay  ov_testnet1

 爬坑k8s 网络 https://www.cnblogs.com/shuiguizi/p/10931610.html 
                       https://www.cnblogs.com/LouisZJ/articles/11187714.html 

flannel 小规模集群(100台以下)
iptables 四表五链
https://blog.51cto.com/3037673/2070585 
https://blog.51cto.com/191226139/2088108 

http://www.178linux.com/8950


多层
 https://www.jianshu.com/p/7dd8546e71c1 
流量走向分析
https://blog.csdn.net/u011563903/article/details/87904873
IPVS集成在LVS(Linux Virtual Server)中,它在主机中运行,并在真实服务器集群前充当负载均衡器。IPVS可以将对TCP/UDP服务的请求转发给后端的真实服务器,因此IPVS天然支持Kubernetes Service。

kubernetes早在1.6版本就已经有能力支持5000多节点,这样基于iptables的kube-proxy就成为集群扩容到5000节点的瓶颈。举例来说,如果在一个5000节点的集群,我们创建2000个service,并且每个service有10个pod,那么我们就会在每个节点上有至少20000条iptables规则,这会导致内核非常繁忙。


calico 大规模集群 由于Calico是一种纯三层的实现 https://blog.csdn.net/jiang_shikui/article/details/85870560
https://www.jianshu.com/p/8501fb39573a
https://blog.csdn.net/ccy19910925/article/details/82423452
https://blog.csdn.net/ccy19910925/article/details/82423452
Contiv 集合flannel和calico的优点

 从范围上分:
   单机网络:none,host, bridge
   跨主机网络:overlay,macvlan,flannel等

Docker网络驱动
Overlay: 基于VXLAN封装实现Docker原生Overlay网络
Macvlan: Docker主机网卡接口逻辑上分为多个子接口,每个子接口标识一个VLAN。容器接口直接连接Docker主机
网卡接口: 通过路由策略转发到另一台Docker主机

第三方网络项目
        隧道方案
    -- Flannel: 支持UDP和VLAN封装传输方式
               -- Weave: 支持UDP(sleeve模式)和 VXLAN(优先fastdb模式)
               -- OpenvSwitch: 支持VXLAN和GRE协议

             路由方案
                Calico: 支持BGP协议和IPIP隧道。每台宿主机作为虚拟路由,通过BGP协议实现不同主机容器间通信 

#route -n 
https://www.iteye.com/blog/codingstandards-1125312 
 Flags  Possible flags include 标志,常用的是U和G。
              U (route is up) 路由启用      -------
              H (target is a host) 目标是主机
              G (use gateway) 使用网关      -----------
              R (reinstate route for dynamic routing)
              D (dynamically installed by daemon or redirect)
              M (modified from routing daemon or redirect)
              A (installed by addrconf)
              C (cache entry)
              !  (reject route)



需要重点理解: 
https://blog.csdn.net/liukuan73/article/details/78883847 
https://www.cnblogs.com/shuiguizi/p/10922049.html
https://success.docker.com/article/networking

https://feisky.gitbooks.io/kubernetes/content/addons/ip-masq-agent.html
https://www.jianshu.com/p/09f9375b7fa7  #TUN/TAP设备浅析
https://www.jianshu.com/p/82864baeacac  #flannel 原理浅析
https://www.jianshu.com/p/ea77ece7158d  #cni cnm 插件

##Linux虚拟网络设备之tun/tap 讲解了原理
https://segmentfault.com/a/1190000009249039 

二层网络仅仅通过MAC寻址即可实现通讯,三层网络需要通过IP路由实现跨网段的通讯,可以跨多个冲突域。
七层协议越往上越慢,越往下速度越快

#容器实际上是结合了namespace 和 cgroup 的一般内核进程,注意,容器就是个进程
根据前面的描述我们知道,多进程/多容器可以共享namespace,而k8s的pod里就是有多个容器,他的网络实现原理就是先创建一个共享namespace,然后将其他业务容器加入到该namespace中。

 libnetwork是Docker团队将Docker的网络功能从Docker的核心代码中分离出来形成的一个单独的库,libnetwork通过插件的形式为Docker提供网络功能。基于代码层面再升华一下,可以将docker的网络抽象出一个模型来,就叫CNM(Container Networking Model),该模型包含三大块:

 overlay这个词不是docker家的,一直以来就有overlay类型的网络,意/译为"覆盖"型网络

tun和tap的区别
用户层程序通过tun设备只能读写IP数据包,而通过tap设备能读写链路层数据包,类似于普通socket和raw socket的差别一样,处理数据包的格式不一样。

Flannel设计目的就是为集群中所有节点重新规划IP地址的使用规则,从而使得不同节点上的容器能够获得"同属一个内网"且"不重复的"IP地址,并让属于不同节点上的容器能够直接通过内网IP通信。

网卡接口 tunX 所代表的虚拟网卡通过文件 /dev/tunX 与我们的应用程序(App) 相连,应用程序每次使用 write 之类的系统调用将数据写入该文件,这些数据会以网络层数据包的形式,通过该虚拟网卡,经由网络接口 tunX 传递给网络协议栈,同时该应用程序也可以通过 read 之类的系统调用,经由文件 /dev/tunX 读取到协议栈向 tunX 传递的所有数据包。

#写入etcd 中,保证与docker 同网段
ETCDCTL_API=2 etcdctl \
--ca-file=/usr/local/kubernetes/ca/ca.pem --cert-file=/usr/local/kubernetes/ca/server.pem --key-file=/usr/local/kubernetes/ca/server-key.pem \
--endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379" \
set /coreos.com/network/config  '{"Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}'

# api=3 export ETCDCTL_API=3
etcdctl --cacert=/usr/local/kubernetes/ca/ca.pem --cert=/usr/local/kubernetes/ca/server.pem --key=/usr/local/kubernetes/ca/server-key.pem --endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379"  put /coreos.com/network/config  '{"Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}'

#
/usr/local/kubernetes/bin/etcdctl --ca-file=/usr/local/kubernetes/ca/ca.pem --cert-file=/usr/local/kubernetes/ca/server.pem --key-file=/usr/local/kubernetes/ca/server-key.pem --endpoints="http://192.168.204.22:2379,http://192.168.204.23:2379,http://192.168.204.24:2379" get /coreos.com/network/config

#安装flannel
tar -xvf flannel-v0.11.0-linux-amd64.tar.gz 
mv flanneld mk-docker-opts.sh /usr/local/kubernetes/bin/

# 编辑flanned 配置文件 (没有这个启动会报错)
/usr/local/kubernetes/config
FLANNEL_OPTIONS="--etcd-endpoints=http://192.168.204.22:2379,http://192.168.204.23:2379,http://192.168.204.24:2379 -etcd-cafile=/usr/local/kubernetes/ca/ca.pem -etcd-certfile=/usr/local/kubernetes/ca/server.pem -etcd-keyfile=/usr/local/kubernetes/ca/server-key.pem"

#flanned service 
cat >>  /usr/lib/systemd/system/flanneld.service <EOF
[Unit]
Description=Flanneld overlay address etcd agent
After=network-online.target network.target
Before=docker.service

[Service]
Type=notify
    
ExecStart=/usr/local/kubernetes/bin/flanneld --ip-masq $FLANNEL_OPTIONS
ExecStartPost=/usr/local/kubernetes/bin/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/subnet.env
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF


#master 节点 部署
https://www.cnblogs.com/Tempted/p/7737361.html
https://www.jianshu.com/p/60d82b457174  #证书字段解释
https://www.cnblogs.com/smail-bao/p/10052841.html 
https://blog.csdn.net/weixin_34102807/article/details/92184312 

cat > apiserver-csr.json <<EOF
{
    "CN": "kubernetes",
    "hosts": [
      "10.0.0.1",#不要修改
      "127.0.0.1",#不要修改
      "192.168.204.22", #master_ip,LB_ip,vip
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "BeiJing",
            "ST": "BeiJing",
            "O": "k8s",  #不要修改
            "OU": "System"  #不要修改
        }
    ]
}
EOF

BOOTSTRAP_TOKEN=0fb61c46f8991b718eb38d27b605b008         #自定义tokey变量值
cat > token.csv <<EOF
${BOOTSTRAP_TOKEN},kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF
涉及到用户的认证和授权 
https://blog.csdn.net/yan234280533/article/details/75808048 

#查看所有账号
# kubectl -n kube-system get sa

#创建kube-apiserver 
# [Kubernetes中的PodIP、ClusterIP和外部IP 
service-cluster-ip-range
https://www.cnblogs.com/xingxiz/p/10416020.html 



#部署apiserver 配置文件
cat <<EOF >/usr/local/kubernetes/config/kube-apiserver.config
KUBE_APISERVER_OPTS="--logtostderr=false \
--log-dir=/usr/local/kubernetes/logs \
--v=4 \
--etcd-servers=https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379 \
--bind-address=192.168.204.22 \
--secure-port=6443 \
--advertise-address=192.168.204.22 \
--allow-privileged=true \
--service-cluster-ip-range=10.0.0.0/24 \
--admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota,NodeRestriction --authorization-mode=RBAC,Node \
--kubelet-https=true \
--enable-bootstrap-token-auth \
--token-auth-file=/usr/local/kubernetes/config/token.csv \
--service-node-port-range=30000-50000 \
--tls-cert-file=/usr/local/kubernetes/ca/apiserver.pem \
--tls-private-key-file=/usr/local/kubernetes/ca/apiserver-key.pem \ #这个y一开始配置错误
--client-ca-file=/usr/local/kubernetes/ca/ca.pem \
--service-account-key-file=/usr/local/kubernetes/ca/ca-key.pem \
--etcd-cafile=/usr/local/kubernetes/ca/ca.pem \
--etcd-certfile=/usr/local/kubernetes/ca/apiserver.pem \
--etcd-keyfile=/usr/local/kubernetes/ca/apiserver-key.pem"  #这个y一开始配置错误

#---------------------------------------------------------------------------------

参数说明:
–logtostderr 启用日志
—v 日志等级
–etcd-servers etcd集群地址
–bind-address 监听地址
–secure-port https安全端口
–advertise-address 集群通告地址
–allow-privileged 启用授权
–service-cluster-ip-range Service虚拟IP地址段
–enable-admission-plugins 准入控制模块
–authorization-mode 认证授权,启用RBAC授权和节点自管理
–enable-bootstrap-token-auth 启用TLS bootstrap功能,后面会讲到
–token-auth-file token文件
–service-node-port-range Service Node类型默认分配端口范围

# apiserver.service
cat /usr/lib/systemd/system/kube-apiserver.service 
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=-/usr/local/kubernetes/config/kube-apiserver
ExecStart=/usr/local/kubernetes/bin/kube-apiserver $KUBE_APISERVER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target

#最早的apiserver.service报错
Error: invalid argument "false--log-dir=/usr/local
/kubernetes/logs" for "--logtostderr" flag: parse error

#部署scheduler组件
cat  /usr/local/kubernetes/config/kube-scheduler 
KUBE_SCHEDULER_OPTS="--logtostderr=true \
--v=4 \
--address=127.0.0.1
--master=127.0.0.1:8080 \
--leader-elect"
#---------------------------------------------------------------------------------
参数说明:
–master 连接本地apiserver
–leader-elect 当该组件启动多个时,自动选举(HA)






#部署 kube-controller-manager
vim   /usr/local/kubernetes/config/kube-controller-manager.conf
KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true \
--v=4 \
--master=127.0.0.1:8080 \
--leader-elect=true \
--address=127.0.0.1 \
--service-cluster-ip-range=10.0.0.0/24 \
--cluster-name=kubernetes \
--cluster-signing-cert-file=/opt/kubernetes/ssl/ca.pem \
--cluster-signing-key-file=/opt/kubernetes/ssl/ca-key.pem  \
--root-ca-file=/opt/kubernetes/ssl/ca.pem \
--service-account-private-key-file=/opt/kubernetes/ssl/ca-key.pem \
--experimental-cluster-signing-duration=87600h0m0s"

#参考
[https://www.cnblogs.com/360linux/p/12919521.html](https://www.cnblogs.com/360linux/p/12919521.html)


# 查看报错信息
journalctl -xeu kube-controller-manager
No authentication-kubeconfig provided in order to lookup client-ca-file in configmap/extension-apiserver-authentication in kube-system, so clien

/usr/bin/kube-apiserver --logtostderr=true --v=0 --etcd-servers=http://127.0.0.1:2379 --address=0.0.0.0 -–port=8080 –kubelet_port=10250 allow-privileged=false -–service-cluster-ip-range=10.254.0.0/16 --admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResouceQuota


systemctl restart kube-controller-manager
systemctl restart kube-scheduler
systemctl restart kube-apiserver

systemctl stop kube-controller-manager
systemctl stop kube-scheduler
systemctl stop kube-apiserver


 #etcd 使用
通过etcd集群搭建了解pki安全认证-02
公钥基础设施(Public Key Infrastructure,简称PKI
https://www.jianshu.com/p/3015d514bae3

集群服务中的通信一般包括两种场景:
对外提供服务的通信,发生在集群外部的客户端和集群某个节点之间,etcd默认端口为2379。
集群内部的通信,发生在集群内部的任意两个节点之间,etcd的默认端口为2380。

原理:
etcdctl默认访问的服务端点是http://127.0.0.1:2379, 因此此时访问的是本地的etcd,但是etcd会像客户端广播所有节点的访问端点(ETCD_ADVERTISE_CLIENT_URLS参数)。etcdctl根据这些URL可以获取所有节点的状态。

如果之前在配置文件中的ETCD_LISTEN_CLIENT_URLS不包含http://127.0.0.1:2379, 或者需要访问其他节点上的etcd,可以通过–endpoints参数指定服务端点。


k8s现在使用的是etcd v3,必须提供ca、key、cert,否则会出现Error: context deadline exceeded
不加–endpoint参数时,默认访问的127.0.0.1:2379,而使用–endpoint参数时,必须提供ca,key,cert。
 etcdctl --cacert=/usr/local/kubernetes/ca/ca.pem --cert=/usr/local/kubernetes/ca/server.pem --key=/usr/local/kubernetes/ca/server-key.pem --endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379"  cluster-health

etcdctl --cacert=/usr/local/kubernetes/ca/ca.pem --cert=/usr/local/kubernetes/ca/server.pem --key=/usr/local/kubernetes/ca/server-key.pem --endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379"  endpoint health



FLANNEL_ETCD_PREFIX="/coreos.com/network/config"
FLANNEL_ETCD_PREFIX="-etcd-prefix=/coreos.com/network"

 etcdctl --ca-file=/usr/local/kubernetes/ca/ca.pem --cert-file=/usr/local/kubernetes/ca/server.pem --key-file=/usr/local/kubernetes/ca/server-key.pem --endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379" cluster-health



/usr/local/kubernetes/bin/flanneld --cacert=/usr/local/kubernetes/ca/ca.pem --cert=/usr/local/kubernetes/ca/server.pem --key=/usr/local/kubernetes/ca/server-key.pem -etcd-endpoints=http://192.168.204.2:2379 -iface=eth0 -etcd-prefix=/coreos.com/network





#得到etcd所有键
etcdctl --cacert=/usr/local/kubernetes/ca/ca.pem --cert=/usr/local/kubernetes/ca/server.pem --key=/usr/local/kubernetes/ca/server-key.pem --endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379" get / --prefix --keys-only



#etcd put 版本3 
etcdctl --cacert=/usr/local/kubernetes/ca/ca.pem --cert=/usr/local/kubernetes/ca/server.pem --key=/usr/local/kubernetes/ca/server-key.pem --endpoints="https://192.168.204.22:2379,https://192.168.204.23:2379,https://192.168.204.24:2379" put /coreos.com/network/config  '{ "Network": "172.17.0.0/16", "Backend": {"Type": "vxlan"}}'



#flanneld etcd 版本问题 flanneld 部署要 点 
etcd 2 和 etcd 3 的区别 , 报错key not found 
 https://blog.csdn.net/zhuzhuxiazst/article/details/103887137 

#flanneld 测试
/usr/local/kubernetes/bin/flanneld -etcd-endpoints=https://192.168.204.22:2379  -etcd-prefix=/coreos.com/network -etcd-cafile=/usr/local/kubernetes/ca/ca.pem -etcd-certfile=/usr/local/kubernetes/ca/etcd.pem -etcd-keyfile=/usr/local/kubernetes/ca/etcd-key.pem

curl https://192.168.204.22:2379/health --cacert /usr/local/kubernetes/ca/ca.pem
 #etcd 详细配置参数
https://blog.csdn.net/huwh_/article/details/80226481 
单独查看组件日志
 journalctl -f -u kube-controller-manager
 journalctl -f -u kube-scheduler



#Node 节点部署 

# 创建kubelet 
根据kubeconfig.sh 生成 bootstrapping kubeconfig 两个文件
BOOTSTRAP_TOKEN=0fb61c46f8991b718eb38d27b605b206
KUBE_APISERVER="https://192.168.204.22:6443"

# 设置集群参数
kubectl config set-cluster kubernetes \
  --certificate-authority=./ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=bootstrap.kubeconfig

# 设置客户端认证参数
kubectl config set-credentials kubelet-bootstrap \
  --token=${BOOTSTRAP_TOKEN} \
  --kubeconfig=bootstrap.kubeconfig

# 设置上下文参数
kubectl config set-context default \
  --cluster=kubernetes \
  --user=kubelet-bootstrap \
  --kubeconfig=bootstrap.kubeconfig

# 设置默认上下文
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig

#-------------------------------------------------------------------
#-------------------------------------------------------------------

# 创建kube-proxy kubeconfig文件

kubectl config set-cluster kubernetes \
  --certificate-authority=./ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=kube-proxy.kubeconfig

kubectl config set-credentials kube-proxy \
  --client-certificate=./kube-proxy.pem \
  --client-key=./kube-proxy-key.pem \
  --embed-certs=true \
  --kubeconfig=kube-proxy.kubeconfig

kubectl config set-context default \
  --cluster=kubernetes \
  --user=kube-proxy \
  --kubeconfig=kube-proxy.kubeconfig

kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

scp bootstrap.kubeconfig root@192.168.204.23:/usr/local/kubernetes/config
scp kube-proxy.kubeconfig root@192.168.204.23:/usr/local/kubernetes/config  
scp kube-proxy.kubeconfig root@192.168.204.24:/usr/local/kubernetes/config
scp bootstrap.kubeconfig root@192.168.204.24:/usr/local/kubernetes/config

#192.168.204.23、24节点配置
# cat /opt/kubernetes/cfg/kubelet
KUBELET_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.204.23 \
--kubeconfig=/usr/local/kubernetes/config/kubelet.kubeconfig \
--bootstrap-kubeconfig=/usr/local/kubernetes/config/bootstrap.kubeconfig \
--config=/usr/local/kubernetes/config/kubelet.config \
--cert-dir=/usr/local/kubernetes/ca \
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
#   /usr/local/kubernetes/config/kubelet.config
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: 192.168.204.24
port: 10250
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS: ["10.0.0.2"]
clusterDomain: cluster.local.
failSwapOn: false
authentication:
  anonymous:
  enabled: true

#kubectl 
kubectl get csr
NAME                                                   AGE   REQUESTOR           CONDITION
node-csr-jW-5mVTO4hMYVeTEB7f6XhEJNvt27wxG9tLq4j-Il5k   12s   kubelet-bootstrap   Pending
node-csr-xcJsXx0JM7Vfd-wrMpYHHTAktMoly-NCmOk4K24jdpY   22h   kubelet-bootstrap   Pending

 kubectl certificate approve node-csr-jW-5mVTO4hMYVeTEB7f6XhEJNvt27wxG9tLq4j-Il5k node-csr-xcJsXx0JM7Vfd-wrMpYHHTAktMoly-NCmOk4K24jdpY
certificatesigningrequest.certificates.k8s.io/node-csr-jW-5mVTO4hMYVeTEB7f6XhEJNvt27wxG9tLq4j-Il5k approved
certificatesigningrequest.certificates.k8s.io/node-csr-xcJsXx0JM7Vfd-wrMpYHHTAktMoly-NCmOk4K24jdpY approved


 https://www.cnblogs.com/TSir/p/12242361.html 
注意:clusterIP要和node节点的cat /opt/kubernetes/cfg/kubelet.conf 的clusterDNS一致,否则pod会解析失败

【node节点部署kube-proxy组件】

vim /opt/kubernetes/cfg/kube-proxy

KUBE_PROXY_OPTS="--logtostderr=false \
--log-dir=/usr/local/kubernetes/logs \
--v=4 \
--hostname-override=192.168.204.23 \
--cluster-cidr=10.0.0.0/24 \
--proxy-mode=ipvs \
--kubeconfig=/usr/local/kubernetes/config/kube-proxy.kubeconfig"

#kube-proxy.service
[Unit]
Description=Kubernetes Proxy
After=network.target
 
[Service]
EnvironmentFile=-/usr/local/kubernetes/config/kube-proxy
ExecStart=/usr/local/kubernetes/bin/kube-proxy $KUBE_PROXY_OPTS
Restart=on-failure
 
[Install]
WantedBy=multi-user.target 



提示 : --proxy-mode=ipvs
yum -y install ipvsadm ipset
# rpm -qa ipvsadm 
ipvsadm-1.27-7.el7.x86_64
# rpm -qa ipset
ipset-7.1-1.el7.x86_64


#
kubectl get node
kubectl describe node

$ kubectl version                   # 验证集群版本     
$ kubectl get componentstatus       # 验证 scheduler/controller-manager/etcd等组件状态
$ kubectl get node                  # 验证节点就绪 (Ready) 状态
$ kubectl get pod --all-namespaces  # 验证集群pod状态,默认已安装网络插件、coredns、metrics-server等
$ kubectl get svc --all-namespaces  # 验证集群服务状态
 #搭建
 https://www.cnblogs.com/yinzhengjie/p/12315017.html 


#cat > dashboard-rbac.yaml << EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
  name: kubernetes-dashboard
  namespace: kube-system

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: kubernetes-dashboard-minimal
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    addonmanager.kubernetes.io/mode: Reconcile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: kubernetes-dashboard
    namespace: kube-system
EOF

tee  dashboard-service.yaml << eof
apiVersion: v1
kind: Service
metadata:
  name: kubernetes-dashboard
  namespace: kube-system
  labels:
    k8s-app: kubernetes-dashboard
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile
spec:
  type: NodePort
  selector:
    k8s-app: kubernetes-dashboard
  ports:
  - port: 80
    targetPort: 9090
eof
kubectl apply -f dashboard-rbac.yaml
kubectl apply -f dashboard-deployment.yaml
kubectl apply -f dashboard-service.yaml

RABC(角色访问控制机制)为Kubernetes集群添加用户
 https://zhuanlan.zhihu.com/p/43237959 

#yaml 文件 
[https://www.cnblogs.com/lgeng/p/11053063.html](https://www.cnblogs.com/lgeng/p/11053063.html)


#安装 Kuboard
 https://github.com/easzlab/kubeasz/blob/master/docs/guide/kuboard.md 
#k8s 官方原生版本dashboard  
https://github.com/kubernetes/dashboard/releases 官方地址
https://www.cnblogs.com/caibao666/p/11556034.html
#解决   raw.githubusercontent.com 被墙 无法下载问题
https://www.ioiox.com/archives/62.html

kubectl get secret -n kube-system


cat > dashboard-adminuser.yaml << EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard  
EOF

#修改recommended.yaml
https://blog.cnrainbird.com/index.php/2020/05/04/k8s_mac_xia_k8s_guan_li_zhi_dashboard_de_pei_zhi_shi_yong_er/ 
 https://www.cnblogs.com/binghe001/p/12823763.html  



#开始试验 --------------
 https://www.cnblogs.com/neutronman/p/8047547.html 
 https://www.cnblogs.com/chris-cp/p/6724057.html 
[http://www.data-master.net/84296765](http://www.data-master.net/84296765)




#为什么要执行下面这段
 https://blog.csdn.net/weixin_33872660/article/details/93111064 
kubectl create clusterrolebinding kubelet-bootstrap   --clusterrole=system:node-bootstrapper   --user=kubelet-bootstrap

无类别域间路由(Classless Inter-Domain Routing、CIDR)是一个用于给用户分配IP地址以及在互联网上有效地路由IP数据包的对IP地址进行归类的方法。



证书之间的关系
[https://yq.aliyun.com/articles/728018?type=2](https://yq.aliyun.com/articles/728018?type=2)


#service 实际操作 实验
 http://www.bubuko.com/infodetail-3573620.html?__cf_chl_jschl_tk__=8865ca881b5c6afb3948220825d7327cc0bb386e-1591322793-0-AeM5aB3iAqHDIi56WrgiB7dJs9_srQXt6EXhLK9RMGIj23e94mkvk-yaclb1SoH1ki0D30cuswL-6IT0NMndhuTBXdlc4GmYpgv_bon9EO6L4OsGAFqNJ6_Cm2iQI1G4gOaZhKnAcHIaRjHbAfEiXPDd--E4tMEa-N3xg9_fy4E73xL6PoghdGXpKnrjP0xE8NQmoMSCwsIxTAFF_M7wywKfAU5RCH40hqrLKIlz9Mm6DRudQ8fZRhYCmOPNAEP_MzEHQ7Hmw8INLn7OzOuDgJ22stj1yxGwX419x_0Zw6ktTwwOXkk0rMtBPJxeiB-4OQ 

 




-----------







-----------------------------------------报错
retrying of unary invoker failed


启动服务etc 
systemctl start etcd
如果报错,使用 journalctl -f -t etcd 和 journalctl -u etcd 来定位问题。



出错:
https://blog.csdn.net/zyddj123/article/details/86560921 
https://www.cnblogs.com/golinux/p/12600437.html 

文档: 
https://skyao.gitbooks.io/learning-etcd3/content/installation/ 
https://blog.csdn.net/Michaelwubo/article/details/92659986 

#创建service
https://www.cnblogs.com/pu20065226/p/10647775.html 

错误排查
https://www.cnblogs.com/xiaochina/p/11665893.html 

搭建环境参考:
https://blog.csdn.net/lic95/article/details/55015284 
操作
https://www.jianshu.com/p/478ba38a938e 

附录: environment.sh 配置了所有节点的环境变量
#!/usr/bin/bash
# 生成 EncryptionConfig 所需的加密 key
export ENCRYPTION_KEY=$(head -c 32 /dev/urandom | base64)
# 集群各机器 IP 数组
export NODE_IPS=( 192.168.0.50 192.168.0.51 192.168.0.52 192.168.0.53 )
# 集群各 IP 对应的主机名数组
export NODE_NAMES=(k8s-01 k8s-02 k8s-03 k8s-04)
# 集群MASTER机器 IP 数组
export MASTER_IPS=(192.168.0.50 192.168.0.51 192.168.0.52 )
# 集群所有的master Ip对应的主机
export MASTER_NAMES=(k8s-01 k8s-02 k8s-03)
# etcd 集群服务地址列表
export ETCD_ENDPOINTS="https://192.168.0.50:2379,https://192.168.0.51:2379,https://192.168.0.52:2379"
# etcd 集群间通信的 IP 和端口
export ETCD_NODES="k8s-01=https://192.168.0.50:2380,k8s-02=https://192.168.0.51:2380,k8s-03=https://192.168.0.52:2380"
# etcd 集群所有node ip
export ETCD_IPS=(192.168.0.50 192.168.0.51 192.168.0.52 192.168.0.53 )
# kube-apiserver 的反向代理(kube-nginx)地址端口
export KUBE_APISERVER="https://192.168.0.54:8443"
# 节点间互联网络接口名称
export IFACE="eth0"
# etcd 数据目录
export ETCD_DATA_DIR="/data/k8s/etcd/data"
# etcd WAL 目录,建议是 SSD 磁盘分区,或者和 ETCD_DATA_DIR 不同的磁盘分区
export ETCD_WAL_DIR="/data/k8s/etcd/wal"
# k8s 各组件数据目录
export K8S_DIR="/data/k8s/k8s"
# docker 数据目录
#export DOCKER_DIR="/data/k8s/docker"
## 以下参数一般不需要修改
# TLS Bootstrapping 使用的 Token,可以使用命令 head -c 16 /dev/urandom | od -An -t x | tr -d ' ' 生成
#BOOTSTRAP_TOKEN="41f7e4ba8b7be874fcff18bf5cf41a7c"
# 最好使用 当前未用的网段 来定义服务网段和 Pod 网段
# 服务网段,部署前路由不可达,部署后集群内路由可达(kube-proxy 保证)
SERVICE_CIDR="10.254.0.0/16"
# Pod 网段,建议 /16 段地址,部署前路由不可达,部署后集群内路由可达(flanneld 保证)
CLUSTER_CIDR="172.30.0.0/16"
# 服务端口范围 (NodePort Range)
export NODE_PORT_RANGE="1024-32767"
# flanneld 网络配置前缀
export FLANNEL_ETCD_PREFIX="/kubernetes/network"
# kubernetes 服务 IP (一般是 SERVICE_CIDR 中第一个IP)
export CLUSTER_KUBERNETES_SVC_IP="10.254.0.1"
# 集群 DNS 服务 IP (从 SERVICE_CIDR 中预分配)
export CLUSTER_DNS_SVC_IP="10.254.0.2"
# 集群 DNS 域名(末尾不带点号)
export CLUSTER_DNS_DOMAIN="cluster.local"
# 将二进制目录 /opt/k8s/bin 加到 PATH 中
export PATH=/opt/k8s/bin:$PATH
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,362评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,330评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,247评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,560评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,580评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,569评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,929评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,587评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,840评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,596评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,678评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,366评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,945评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,929评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,165评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,271评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,403评论 2 342

推荐阅读更多精彩内容