k8s部署 JAVAWEB 理论+实战全过程(图文)

简述

之前通过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 的配置，更新反向代理负载均衡器，达到服务发现的作用

本文地址：https://blog.csdn.net/qq_46595591/article/details/107567965