docker+k8s实战

docker

网络构成

k8s集群架构

POD架构

spring cloud微服务架构

Docker三大核心组件：
Docker 镜像 - Docker images
Docker 仓库 - Docker registeries
Docker 容器 - Docker containers

容器的三大组成要素：
名称空间 namespace
1. pid 名字空间
2. net 名字空间
3. ipc 名字空间
4. mnt名字空间
5. uts 名字空间
6. user 名字空间
资源限制 cgroups
文件系统 overlay2(UnionFS)

---

k8s 4种volume
1.secret：用来保存小片敏感数据的k8s资源
2.ConfigMap与 Secret 类似，用来存储配置文件的kubernetes资源对象，所有的配置内容都存储在etcd中。
与 Secret 的区别：
ConfigMap 保存的是不需要加密的、应用所需的配置信息。
ConfigMap 的用法几乎与 Secret 完全相同：可以使用 kubectl create configmap 从文件或者目录创建 ConfigMap，也可以直接编写 ConfigMap 对象的 YAML 文件。
3.Downward API
用于在容器中获取 POD 的基本信息，kubernetes原生支持
Downward API提供了两种方式用于将 POD 的信息注入到容器内部：
环境变量：
用于单个变量，可以将 POD 信息和容器信息直接注入容器内部。
Volume挂载：
将 POD 信息生成为文件，直接挂载到容器内部中去。
4.ServiceAccountToken：默认在 pod 中使用自动挂载的 service account 凭证来访问 API

RBAC：role角色：存储权限 bash基础 ac 访问控制） 账号—》角色-----》权限
在RABC API中，通过如下的步骤进行授权：
1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
2）绑定角色：将主体与角色进行绑定，对用户进行访问授权

Probe：健康检查"探针"（Probe）。kubelet 就会根据这个 Probe 的返回值决定这个容器的状态

Pod 的恢复策略：
可以通过设置 restartPolicy，改变 Pod 的恢复策略。一共有3种：
1. Always： 在任何情况下，只要容器不在运行状态，就自动重启容器；
2. OnFailure: 只在容器 异常时才自动重启容器；
3. Never: 从来不重启容器。

k8s deployment资源创建流程：

1. 用户通过 kubectl 创建 Deployment。
2. Deployment 创建 ReplicaSet。
3. ReplicaSet 创建 Pod。

转发K8S后端服务的四种方式
ClusterIP： 【集群内部的转发】
LoadBlancer Service：基于Nodeport
NodePort Service：【要做负载均衡的借助第三方nginx】
Ingress：【不需要部署第三方负载均衡，并且自动感知后端服务情况，改配置】

私有云 ceph主流
存储插件：不用手动部署rook-ceph 学习成本高
nfs

Spring-Cloud核心组件及底层原理

服务注册/服务发现——Netflix Eureka
Client —》server(注册中心) 服务注册
server —》client 服务发现
客服端负载均衡——Netflix Ribbon
通过创建动态代理来调用服务接口——Feign
接口定义注解–》动态代理—》构造服务器地址
对这个地址，发起请求、解析响应
【基于 Feign 的动态代理机制，根据注解和选择的机器，拼接请求 URL 地址，发起请求】

【首先通过ribbon负载均衡到Eureka client获取服务注册表（服务器IP，端口），
然后ribbon使用默认轮询算法，选择机器
feign对该机器，构造并发起请求】

断路器——Netflix Hystrix
隔离、熔断以及降级
【解决雪崩问题】
1.存在多个小线程池
2.每个线程就仅仅用于请求一台固定的服务器
3.请求超时，请求就不再请求【熔断】
4.未处理的请求会在数据库里记录一条消息【降级】，等待手动处理

【发起请求是通过 Hystrix 的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。】

服务网关——Netflix Zuul
所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务
做统一的降级、限流、认证授权、安全

分布式配置——Spring Cloud Config

SpringBoot和SpringCloud的关系与区别
一、SpringBoot和SpringCloud简介

1、SpringBoot：是一个快速开发框架，通过用MAVEN依赖的继承方式，帮助我们快速整合第三方常用框架，完全采用注解化（使用注解方式启动SpringMVC），简化XML配置，内置HTTP服务器（Tomcat，Jetty），最终以Java应用程序进行执行。

2、SpringCloud： 是一套目前完整的微服务框架，它是是一系列框架的有序集合。它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用SpringBoot的开发风格做到一键启动和部署。

二、SpringBoot和SpringCloud的关系与区别

1、SpringBoot只是一个快速开发框架，使用注解简化了xml配置，内置了Servlet容器，以Java应用程序进行执行。

2、SpringCloud是一系列框架的集合，可以包含SpringBoot。

三、SpringBoot是微服务框架吗？

1、SpringBoot只是一个快速开发框架，算不上微服务框架。

2、SpringCloud+SpringBoot 实现微服务开发。具体的来说是，SpringCloud具备微服务开发的核心技术：RPC远程调用技术；SpringBoot的web组件默认集成了SpringMVC，可以实现HTTP+JSON的轻量级传输，编写微服务接口，所以SpringCloud依赖SpringBoot框架实现微服务开发。

四、SpringMVC在3.0开始支持采用注解方式启动，所以可以不再配置传统的XML配置文件。