kubernetes----基础1
kubernetes----基础1
kubernetes基础
http://docs.kubernetes.org.cn/251.html
云原生12因素
https://jimmysong.io/kubernetes-handbook/cloud-native/cncf.html
https://blog.csdn.net/liumiaocn/article/details/100713072
云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。
云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式普惠，让这些创新为大众所用
简单来说12种规范，不段进行调整优化
云原生的设计理念
面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
面向配置设计（Configuration）：一个镜像，多个环境配置；
面向韧性设计（Resistancy）：故障容忍和自愈；
面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
面向交付设计（Delivery）：自动拉起，缩短交付时间；
面向性能设计（Performance）：响应式，并发和资源高效利用；
面向自动化设计（Automation）：自动化的 DevOps；
面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
面向安全性设计（Security）：安全端点、API Gateway、端到端加密；
核心：应用仍旧是最终目的。保证应用快速稳定地测试、构建、部署、升级，支持；减少代码开发时间人力成本；快速响应业务需求；降低应用的运维和使用成本……这些目标多久都不会变化
1、基准代码
使用代码库（git或者svn）来管理代码，一个应用一个代码库，可以同时维护多个版本，做多份部署来测试这个应用的不同功能
2、依赖
程序本身的类库和对系统的依赖，以及应用之间的依赖关系要显示的声明，要假定我们的运行环境是空白，普通的应用的话要有依赖清单，就比如python的requirement.bxtt里面写了运行这个应用所需要的所有模块，我们只要在跑这个应用之前先通过pip install安装就可以啦，或者容器的话要把依赖打入镜像中
3、配置
配置和代码进行隔离，这里的配置说的就是像java_opts，mysql的连接，redis的连接等，正常我们是写几个环境的配置文件，和代码一起维护在代码库中，这样其实是不安全的，这个规范就要去我们把配置下沉到环境变量中，docker和k8s就很容器帮助我们实现这些，java_opts这样的参数一般我们可以通过env的方式，直接导入到容器的环境变量中，mysql，redis这样的连接配置可以维护到配置中心（简单来说就是配置文件及环境变量参数）
4、后台服务
后端服务是指应用运行所依赖的各种服务，这些服务包括数据库，redis，rabbitmq等等，把这些服务当作附加服务，就是要实现和应用的解耦，这样可以保证应用责权单一，以保证应用的可靠性和可扩展性质，最好能对后端服务也作显示声明，k8s帮助我们很好实现了这个（endpoint）
5、构建、发布、运行
构建是指把代码转换成可执行体，另外也包括解决代码的依赖关系，就比如我们开发了一个java应用，构建的过程就是把java编译成clss，然后根据显示的依赖，将依赖的jar包等导入进来和我们的应用class组成一个新的jar包，这就是一个可执行体，我们就可以通过java-jar的方式来启动这个jar包，启动的时候还需要传入一些环境变量，这个就是发布的过程啦，发布就是把构建的结果和配置相结合，放在运行环境中，最后一步的运行就是启动这个jar包的步骤。和这个过程相反的是什么呢？就是直接在正在运行的环境中修改编译代码，就是构建和运行是在一起的，这样的操作是万万不可取的
6、进程
一个或多个无状态进程运行应用，什么意思呢，就是我们的应用中不应该保存状态信息，比如说我访问一个网站，需要登录才能看到会员相关的信息，这个时候我相当于是未登录的状态，我要改成已登录的状态，这两个状态保存在哪儿呢？肯定不能保存在我们的应用中，对吧，因为应用是在内存中运行的，万一应用突然挂了，我们的状态就丢失啦，所以这个状态一定是要持久化到存储中的，比如说redis，或者数据库。就算应用不会挂，我们想想，我们一般应用都是放在负载均衡后面的.假如说我们的这个用有两个副本，我们第一次请求到A副本上啦，登录了，第二次又给转发到B副本上，又让登录，是不是很崩溃。（如果需要保存应用状态信息，需要数据持久化）
7、端口锁定
IP+端口的方法进行访问
8、并发
并发大的时候，负载会很高，应用如果不满足要求，就需要扩展，就像我们的服务器一样，服务器资源不够的时候我们怎么办呢？一般有两种方式：给这台服务器加cpu，加内存：另一种是加一台服务器。这个就是纵向扩展和横向扩展，我们的应用用哪种方式好呢？一般都推荐横向扩展，就假如说现在是个java应用，纵向扩展呢就是调大点java_opts，横向扩展呢就是再起一个副本，很明显纵向扩展你需要重启服务，横向就不需要啦。但是要注意的一点就是横向怎么扩，这个时候就说到模型啦。我们横向扩展就像克隆一样。
9、批处理
快速启动很容易理解，在保证5和6原则的前提下，快速启动就很容易啦。重点说下优雅终止，优雅终止需要尽可能降低应用终止对用户造成的不良影响。对于短任务来说，这一般意味着拒绝所有新的请求，并将已经接收的请求处理完毕后再终止；对于长任务来说，这一般意味着应用重启后的客户端重连和为任务设置断点并在重启后继续执行。除此之外，优雅终止还需要释放所有被进程锁定的资源，并对事务的完整性和操作的幂等性做出完备的考虑。
10、环境等价
等价指的是要保证不管是开发环境还是正式环境都使用相同的软件站，就是说不能开发环境用mysal，线上环境用oracle，并且要尽快能的保证开发环境和线上环境使用相同的配置，更深层次的是要尽量缩小开发环境和线上环境中人员和时间上的差异，这个是说什么呢？开发人员只关心开发环境，只关心实现某个功能，而不考虑线上的环境，这样一上线就会出问题，这个就要求开发人员不能只关注自己的代码，更要密切关注代码的部署过程和代码在线上的运行情况
11、日志
应用程序不要自行管理日志文件，要求应用程序将日志以事件流的方式输出到标准输出STDOUT和标准错误输出STDERR，然后由运行环境捕获这些事件流，并转发到专门的日志处理服务进行处理，将日志的分析和应用进行分开
12、管理进程
通过ssh登录应用服务器来对进程进行管理，执行完成之后exit退出
k8s和云原生的关系
云原生其实是一种文化，从宏观概念上讲，云原生是不同思想的集合，集目前各种热门技术之大成，为企业上云，构建云生态，构建PaaS平台，提供了一个可行性的指导。
Kuberentes可以说是乘着Docker和微服务的东风，一经推出便迅速蹿红，它的很多设计思想都契合了微服务和云原生应用的设计法则。现在我们也使用Kubernetes构建云原生架构
Kubernetes 主要由以下几个核心组件组成：
etcd 保存了整个集群的状态；(相当于K8S的键值数据库，相当重要，本身ETCD集群也相当优秀，机器一般构成1.3.5..等)
apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；（外部访问K8S都是通过API，当然多个master节点，可以在前端加入高可用机制haproxy+keepalived）
controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；(控制器，简单来说就是控制监测组件)
scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；（master节点有3个服务，apiserver +controller manager+scheduler ）
kubelet 负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理；（与控制器交互）
Container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；（高可用的服务，其实就是运行环境）
kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；（网络的负载均衡）
除了核心组件，还有一些推荐的 Add-ons：
kube-dns 负责为整个集群提供 DNS 服务（早期skydns，kube-dns，现在使用coredns，目的就是解析域名，通过serivce访问域名，POD删除，IP会变更的，但名称不会改变，DNS服务在K8S中相当重要）
Ingress Controller 为服务提供外网入口（基于nginx开发的，可以实现七层负载均衡）
Heapster 提供资源监控
Dashboard 提供 GUI
Federation 提供跨可用区的集群（跨多个K8S集群跑服务，跨机房，跨云平台）
Fluentd-elasticsearch 提供集群日志采集、存储与查询
分层架构
核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
Kubernetes 外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 应用、ChatOps 等
Kubernetes 内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
设计理念：
https://jimmysong.io/kubernetes-handbook/concepts/concepts.html
http://docs.kubernetes.org.cn/249.html
K8S内部是使用域名的方式访问
用户请求给-->haproxy4层负载均衡-->在转发给POD节点上
这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的 Kube-proxy 就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
简要概念
| APISERVER | 所有服务访问统一入口 |
|---|---|
| CrontrollerManager | 维持副本期望数目 |
| Scheduler | 负责介绍任务，选择合适的节点进行分配任务 |
| ETCD | 键值对数据库 储存K8S集群所有重要信息（持久化） |
| Kubelet | 直接跟容器引擎交互实现容器的生命周期管理 |
| Kube-proxy | 负责写入规则至 IPTABLES、IPVS 实现服务映射访问的 |
| COREDNS | 可以为集群中的SVC创建一个域名IP的对应关系解析 |
| DASHBOARD | 给 K8S 集群提供一个 B/S 结构访问体系 |
| INGRESS CONTROLLER | 官方只能实现四层代理，INGRESS 可以实现七层代理 |
| FEDERATION | 提供一个可以跨集群中心多K8S统一管理功能 |
| PROMETHEUS | 提供K8S集群的监控能力 |
| ELK | 提供 K8S 集群日志统一分析介入平台 |
小结
目前新的版本都是IPVS规则实现，查看是否加载ipvs模块lsmod| grep ip_vs
旧版本是iptables，超过5000条规则会影响性能
新版本操作系统对K8S支持较好，推荐使用ubuntu，ubuntu一般内核较新，当然centos系统也可以升级内核
资源清单：资源 掌握资源清单的语法 编写 Pod 掌握 Pod 的生命周期***
Pod 控制器：掌握各种控制器的特点以及使用定义方式
服务发现：掌握 SVC 原理及其构建方式
存储：掌握多种存储类型的特点 并且能够在不同环境中选择合适的存储方案
调度器：掌握调度器原理 能够根据要求把Pod 定义到想要的节点运行
安全：集群的认证 鉴权 访问控制 原理及其流程
HELM：Linux yum 掌握 HELM 原理 HELM 模板自定义 HELM 部署一些常用插件
运维：修改Kubeadm 达到证书可用期限为 10年 能够构建高可用的 Kubernetes 集群
