目录
简述
之前通过docker部署了Javaweb项目，现在将项目移植到k8s平台
**主要分为五个部分
1.要以镜像作为交付对象，不再以jar包、war包形式
2.在docker可以直接上传镜像运行容器，在k8s需要编写yaml文件，通过控制器去管理镜像
3.进行一些数据的挂载
4.部署完成后要将容器或pod暴露出去
5.对应用pod进行一下日志的采集和监控，方便做数据分析、历史资源利用率检查和告警等
**
一、制作镜像（Master节点）
1.概念
主要是基础镜像制作，服务镜像制作，以及项目镜像制作，将制作好的镜像打包发布到仓库中或者留在本地
2.操作
主要使用Dockerfile
之前需准备好打包好的war包，数据库等，放在同一目录下，进行dockerfile
1.vi Dockerfile
FROM tomcat //这里可以使用本地进行镜像或者进行远程仓库拉取
MAINTAINER 作者名
COPY *.war /usr/local/tomcat/webapps //将war包放到tomcat webapps下
2.docker build . //生成镜像
3.docker tag //打标签
4.docker login --username=阿里用户名 registry.cn-beijing.aliyuncs.com
docker tag [ImageId] registry.cn-beijing.aliyuncs.com/空间名/仓库名:[镜像版本号]
docker push registry.cn-beijing.aliyuncs.com/空间名/仓库名:[镜像版本号]
// 发布到远程仓库 这里使用的阿里云进行镜像仓库 也可以使用dockerhub
注意这里可以之间在node节点上拉取所需镜像
图
二、创建控制器管理pod
用k8s控制器去部署，一般选择有
Deployment：无状态部署
StatefulSet：有状态部署
DaemonSet：守护进程部署
Job & CronJob：批处理
这里选择Deployment 无状态部署
1.pod
1.1概念
最小的部署单元
一组容器的集合
一个Pod中的容器共享网络命名空间和存储
Pod是短暂的
1.2作用
两个应用直接发送文件交互
两个应用需要通过127.0.0.1或者socket通信
两个应用需要发生频发的调用
1.3实现机制
共享网络
多个容器在一个网络命名空间里
共享存储
数据卷中存储临时数据、日志、业务数据emtmyDir，多个容器之间数据共享
2.Deployment 无状态部署
2.1概念
Deployment同样也是Kubernetes系统的一个核心概念，主要职责和RC一样的都是保证Pod的数量和健康，二者大部分功能都是完全一致的，我们可以看成是一个升级版的RC控制器
2.2特点
Deployment具备RC的全部功能
事件和状态查看：可以查看Deployment的升级详细进度和状态
回滚：当升级Pod的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本
版本记录：每一次对Deployment的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础
暂停和启动：对于每一次升级都能够随时暂停和启动
2.3功能
部署"无状态应用"
管理Pod和ReplicaSet
具有上线部署、副本设定、滚动升级、回滚等功能
提供声明式更新，例如只更新一个新的 image
3.Yaml
是一个可读性高，用来表达数据序列化的格式
4.操作
1.vi deployment.yaml
apiVersion: apps/v1 //apiserver 版本
kind: Deployment //指定创建资源的角色/类型 这里使用的是deployment
metadata: //资源的元数据/属性
name: myshop //资源的名字，在同一个namespace中必须唯一
spec: //定该资源的内容
replicas: 2 //指定副本个数
selector:
matchLabels:
app: myshop1.0 //自定义注解名字
template:
metadata:
labels:
app: myshop1.0
spec:
volumes:
- name: myshop
hostPath:
path: "/ca"
containers:
- name: myshop01 //容器的名字
image: registry.cn-beijing.aliyuncs.com/erosion/erosionhub:myshop1.0 //容器镜像地址
imagePullPolicy: IfNotPresent //每次启动时检查和更新（从registery）images的策略
volumeMounts:
- mountPath: /root/app/ca
name: myshop
2.kubectl create -f deployment.yaml //创建pod
图
三、Pod数据持久化
主要是对一个应用程序，比如开发一个项目，这个项目有没有落地到本地文件，如果有落的话，就保证他持久的有了，那就必须要用到pod数据的持久化了
具体详解
https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes
因为这里使用的是静态网站 不需要用到
四、暴露应用
1.Service
Pod的生命是有限的，死亡过后不会复活了。RC和Deployment可以用来动态的创建和销毁Pod。尽管每个Pod都有自己的IP地址，但是如果Pod重新启动了的话那么它的IP很有可能也就变化了。这就会带来一个问题：比如我们有一些后端的Pod的集合为集群中的其他前端的Pod集合提供API服务，如果我们在前端的Pod中把所有的这些后端的Pod的地址都写死了，然后去某种方式去访问其中一个Pod的服务，这样看上去是可以正常工作的，但是如果这个Pod挂掉了，然后重新启动起来了，IP地址非常有可能就变了，这个时候前端就极大可能访问不到后端的服务了。这就需要用到Service
1.1概念
Service是一种抽象的对象，它定义了一组Pod的逻辑集合和一个用于访问它们的策略，这个概念和微服务非常类似
1.2作用
防止Pod失联（服务发现）
定义一组Pod的访问策略（负载均衡）
1.3服务类型
ClusterIP：通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的服务类型。
NodePort：通过每个 Node 节点上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 ，可以从集群的外部访问一个 NodePort 服务。
LoadBalancer：使用公有云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务，这个需要结合具体的云厂商进行操作。
ExternalName：不常用， 是 Service 的特例，它没有 selector，也没有定义任何的端口和 Endpoint。 对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容
2.操作
创建一个service.yaml
1.vi service.yaml
apiVersion: v1
kind: Service
metadata:
name: myshop
namespace: test
spec:
selector:
project: www
app: myshop1.0
ports:
- name: myshop
port: 80
targetPort: 8080 //暴露端口
2.kubectl create -f service.yaml
图
3.访问测试
注意 到这一步已经可以在本地测试网站是否部署成功
http://masterip:(自定义端口)/
五、对外发布应用
Ingress其实就是从 kuberenets 集群外部访问集群的一个入口，将外部的请求转发到集群内不同的 Service 上，其实就相当于 nginx、haproxy 等负载均衡代理服务器，会想到直接使用 nginx 就实现了，但是只使用 nginx 这种方式有很大缺陷，每次有新服务加入的时候怎么改 Nginx 配置？不可能去手动更改或者滚动更新前端的 Nginx 的Pod 。
如果再加上一个服务发现的工具的话其实就可以了，Ingress 实际上就是这样实现的，只是服务发现的功能自己实现了，不需要使用第三方的服务了，然后再加上一个域名规则定义，路由信息的刷新需要一个靠 Ingress controller 来提供。
Ingress controller 可以理解为一个监听器，通过不断地与 kube-apiserver 打交道，实时的感知后端 service、pod 的变化，当得到这些变化信息后，Ingress controller 再结合 Ingress 的配置，更新反向代理负载均衡器，达到服务发现的作用
