Kubernetes

1.k8s中的资源

1.1检查网络环境

kubectl -n kube-flannel get pods

kubectl -n kube-flannel get pods -o wide、

1.2资源管理介绍

1.在k8s中，所有的内容都抽象为资源，用户需要通过管理资源来管理k8s（ kubectl api-resources 查看k8s中所有的资源）

2.k8s的本质就是一个集群系统，用户可以在集群中部署各种服务

3.所谓的部署服务，其实就是在kubernetes集群中运行一个个容器，并将指定的程序跑在容器中

4.kubernetes的最小管理单元式pod而不是容器，只能将容器放在pod中

5.kubernetes一般不会直接管理pod而是通过控制器来管理pod

6.pod中服务的访问是通过kubernetes提供的service（微服务暴露端口）资源来实现

7.pod中程序的数据需要持久化是由kubernetes提供的各种存储来实现的

1.3资源管理方式

1.命令式（操作完就没了，不能审计与跟踪）

kubectl run nginx-pod   --image=nginx:latest --port=80

2.文件式(不能做更新，只能建立)

kubectl cerate -f nginx-pod.yaml

3.声明式

kubectl apply -f nginx-pod.yaml

4.create与apply的区别

kubectl run testpod --image nginx --dry-run=client -o yaml > test.yml 
kubectl create -f test.yml //运行yml文件（yml文件更改后不可更改）
kubectl apply -f test.yml // yml运行后可以更改
kubectl delete pods testpod --force//删除pods

1.3.1基本命令

 kubectl create deployment zee --image myapp:v1 --replicas 2// 用控制器创建可指定pod的数量

 kubectl explain deployment// 查看资源帮助

 kubectl edit deployments.apps zee//编辑控制器配置

 kubectl patch deployments.apps zee -p '{"spec":{"replicas":2}}'//利用补丁更改控制器配置

 kubectl delete deployments.apps zee//删除pod

 kubectl run wyz --image nginx
 kubectl expose pod wyz --port 80 --target-port 80//对内暴露，使pod可在本机被访问
 kubectl get service
 curl 10.109.202.74

 kubectl edit service zee//将spec下的ClusterIP（对内，服务类型）改为NodePort

 kubectl describe pods//查看详细信息

 kubectl logs pods/zee//查看某一个pods的日志

 kubectl run -it  testpod --image busyboxplus//运行交互pod
 # ctrl + pq 退出不停止pod
 kubectl attach pods/testpod -it //再次进入pod

 kubectl cp /etc/passwd wyz:/
 kubectl exec pods/wyz -c wyz -it -- bin/sh（-c：指定容器）

1.3.2高级指令

1.利用命令生成yaml

kubectl create deployment zee --image buxybox --dry-run=client -o yaml > dep-zee.yml //创建控制器pod
kubectl apply -f dep-zee.yml 

2.删除pod

kubectl delete -f dep-zee.yml

3.查看标签，更改标签

标签功能，设定两个pod，更改一个标签后，控制器识别到少了一个zee标签的pod，于是它会再启动一个pod，将标签改回来后，控制器识别到多了一个pod，于是它会删除一个pod（控制器控制pod数量 ）

kubectl get pods --show-labels

kubectl get label pods zee-5f46cc654-8xc4h（name） app=xxx --overwrite

2.pod（k8s中最小控制单元）

pod是可以创建和管理k8s计算的最小可部署单元

多个容器间共享ipc network

kubectl get pods//查看当前pods
​
kubectl get pods    --all-namespace//查看所有pods
​
kubectl get pods    -o  wide//可以看到pods名称等
​
kubectl get pods    -o  yaml//以yaml的形式查看

生成yml文件进行资源管理 kubectl run testpod1 --image nginx --dry-run=client -o yaml > testpod1.yml

命令式对配置（只能建立） kubectl create -f testpod1.yml

生命式对象配置（除了建立以外还可以做更新）kubectl apply -f testpod1.yml

2.1利用控制器管理pod

高可用性和高可靠性：1.自动故障恢复；2.健康检查和自愈

可扩展性：1.轻松扩缩容；2.水平自动扩缩容（HPA，无法单独运行）

版本管理和更新：1.滚动更新；2.回滚

声明式配置：1.简洁的配置方式；2.期望状态管理

服务发现和负载均衡：1.自动注册和发现；2.流量分发

多环境一致性：一致的部署方式

kubectl expose deployment zee --port 80 --target-port 80//进行暴露

kubectl delect services zee//如果在暴露时端口被占用，删除占用的服务，删除后重新暴露

kubectl describe service zee//显示资源的详细信息

pod的扩容和缩容

kubectl scale deployment zee --replicas 4//扩容，设置副本数量为4，缩容，更改副本数量（做四个负载均衡）

控制器自动负载均衡，前提是将pod暴露

2.2pod更新及回滚

网络插件有问题

kubectl delete -f kub-fannel.yaml//删除

kubectl apply -f kub-fannel.yaml//重新添加

1.kubectl create deployment zee --image myapp:v1 --replicas 2//创建两个控制器

2.暴露zee的端口

3.kubectl set image deployments/zee myapp=myapp:v2//更新版本为v2

4.kubectl rollout history deployment zee//查看版本更新

5.kubectl rollout undo deployment zee --to-revision 1//版本回滚

2.3利用yaml文件部署应用

清晰的表达期望，重复的利用，灵活和可扩展

kubectl api-resources//查看所有api版本

spec：详细定义对象

command：启动容器时要执行的命令

2.3.1运行多个pod

spec:
  containers:
  - image: nginx
    name: zee-container
  - image: buxybox:latest
    name: zee-container
    command: ["/bin/sh","-c","sleep 100000"]
​

2.3.2端口映射

spec:
  containers:
  - image: nginx
    name: zee-container
    ports:
      - name: webport
        containerPort: 80
        hostPort: 80
        protocol: TCP
​

如果没有进行端口暴露，则只能通过pod的ip来访问，如果暴露则可以通过主机的ip进行访问

2.3.3设定环境变量

spec:
  containers:
  - image: nginx
    name: zee-container
    command: ["/bin/sh","-c","echo $NAME;sleep 100000"]
    env:
      - name: "NAME"
        value: "wyingzee"

2.3.4资源限制

spec:
  containers:
  - image: nginx
    name: wenserver1
    resources:
      limits:
        cpu: 1
        memory: 200mi
      requests:
        cpu: 500m
        memory: 100mi
​

limits的值要大于requests，++如果将limits的值设置的与request的值一样大，那么此时的优先级最大++

2.3.5容器的启动管理

spec:
  restartpolicy: Always
  containers:
  - image: nginx
    name: wenserver1
    command: ["/bin/sh", "-c","echo hello zee"]

Always：pod一旦终止运行不论是怎样终止的，kubernetes都会重启它（不管正不正确都不能终止）

Never：退出后就执行完了

OnFailure： 容器正常就不管，非正常就重启（必须正确终止）

2.3.6共享宿主机网络

spec:
  hostNetwork: true
  containers:
  - image: nginx
    name: wenserver1
    command: ["/bin/sh", "-c","sleep 10000"]
​

2.4pod的生命周期

2.4.1init容器

pod可以包含多个容器，init容器的运行是一个接一个，init容器不支持readiness就绪探针

如果pod的init容器运行失败，那么kubernetes会不断重启该pod，知道init容器运行成功为止，但如果pod的restartpolicy的值是never，那么他就不会重新启动

2.4.1.1nit容器的功能

做主容器运行之前要做的事，如判断，运行一些指令让环境中有一些什么东西

Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。

Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。

由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动

2.4.1.2init容器示例

spec:
  containers:
  - image: nginx
    name: wyingzee
  initContainers:
  - image: busyboxplus:latest
    name: initnode
    command: ["sh","-c","until test -e /testfile;do echo wating for myservice; sleep 2 done"]
​

先运行init容器，运行成功后再运行上面的

2.4.2探针

主要功能：kubernetes对容器执行定期诊断

Execation：在容器内执行指定命令

2.4.2.1存活探针

spec:
  containers:
  - image: nginx
    name: wyingzee
    livenessProbe://探针类型
      tcpSocket://tcp的方式检测
        port: 8080
      initalDelaySecond: 3//容器运行了多少秒后开始检测
      periodSeconds: 1//每隔一秒检测一次
      timoutSecounds: 1
​

livenessProbe:指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。

2.4.2.2就绪探针

spec:
  containers:
  - image: nginx
    name: wyingzee
    readinessProbe://探针类型
      httpGet:# HTTPGetAction:对指定的端口和路径上的容器的IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
        path: /test.html
        prot: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 1
​

readinessProbe:指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Succes（没有准备好就不暴露出来，准备好就暴露出来）

3.控制器

3.1什么是控制器

控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod 的副本数目

Pod控制器是管理pod的中间层，使用Pod控制器之后，只需要告诉Pod控制器，想要多少个什么样的Pod就可以了，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod资源在运行中出现故障，它会基于指定策略重新编排Pod

当建立控制器后，会把期望值写入etcd，k8s中的apiserver检索etcd中我们保存的期望状态，并对比pod的当前状态，如果出现差异代码自驱动立即恢复

3.2控制器常用类型

ReplicaSet ：ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行 （无版本更新的能力）

Deployment： 一个 Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力 （无状态，每次启动都是随机的）

DaemonSet： DaemonSet 确保全指定节点上运行一个 Pod 的副本

StatefulSet： StatefulSet 是用来管理有状态应用的工作负载 API 对象。（每次启动都是固定的）

Job： 执行批处理任务，仅执行一次任务，保证任务的一个或多个Pod成功结束

CronJob： Cron Job 创建基于时间调度的 Jobs。

HPA全称Horizontal Pod Autoscaler ： 根据资源利用率自动调整service中Pod数量，实现Pod水平自动缩放（自动扩容和缩容，没有监控不能做）

3.3replicaset控制器（通过标签控制pod的数量，无法控制版本）

ReplicaSet和Replication Controller的唯一区别是选择器的支持，ReplicaSet支持新的基于集合的选择器需求

ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行

虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments 用作协调 Pod 创建、删除和更新的机制

3.3.1replicaset示例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  labels:
    app: replicaset
  name: replicaset
spec:
  replicas: 2
  selector:
    matchLabels:
      app: replicaset
  template:
    metadata:
      labels:
        app: replicaset
    spec:
      containers:
      - image: nginx
        name: nginx
​

3.4deployment 控制器（可以控制版本）

先控制replicaset，通过replicaset来控制pod

Deployment 为 Pod 和 ReplicaSet 提供了一个申明式的定义方法

在Deployment中ReplicaSet相当于一个版本

用来创建Pod和ReplicaSet

滚动更新和回滚

扩容和缩容

暂停与恢复

3.4.1depolyment示例

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: zee
  name: zee
spec:
  replicas: 4
  selector:
    matchLabels:
      app: zee
  template:
    metadata:
      labels:
        app: zee
    spec:
      containers:
      - image: myapp:v2
        name: myapp
​

3.4.2版本迭代

进入yml文件将v2改为v1，然后再次声明

想要被访问需要将端口暴露

kubectl expose deployment zee-dp --port 80 --target-port 80 --dry-run=client -o yaml >> zee.yml #将service追加在zee.yml后面

kubectl get svc zee #查看zee服务的信息

3.4.3版本回滚

将zee.yml中的v1改为v2

RollingUpdateStrategy: 25% max unavailable, 25% max surge//更新策略

3.4.4滚动更新策略

spec:
  minReadySeconds: 5        #最小就绪时间，指定pod每隔多久更新一次
  replicas: 4
  strategy:                 #指定更新策略
    rollingUpdate:
      maxSurge: 1           #比定义pod数量多几个，最多比这四个多一个，在更新的时候一个一个来做
      maxUnavailable: 0     #比定义pod个数少几个，必须保证这四个能用

3.4.5暂停及恢复

在生产中我们需要等所有的更新都完成后再上线

kubectl rollout pause deployment zee #将更新暂停

    spec:
      containers:
      - image: nginx
        name: nginx
      resources:
        limits:
          cpu: 0.5
          memory: 100mi
        resquests:
          cpu: 0.5
          memory: 100mi
#做资源限制，此时资源限制没有生效，因为更新被暂停了

kubectl rollout resume deployment zee #恢复更新

查看所有的是否都更新完

kubectl rollout history deployment zee

3.5daemonset控制器

DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时， 也会为他们新增一个 Pod ，当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod（有污点tains，不建立，pod可以设置对污点的容忍）

3.5.1daemonset示例（不能对pod的数量进行指定）

apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: zee-dm
  name: zee-dm
spec:
  selector:
    matchLabels:
      app: zee-dm
  template:
    metadata:
      labels:
        app: zee-dm
    spec:
      tolerations:              #对于污点节点的容忍
      - effect: NoSchedule
        operator: Exists  #对污点强容忍
      containers:
      - image: nginx
        name: nginx
​
​

将zee.yml复制为zee-dm.yml

做完容忍度后，pod就会再master节点上创建

3.6job控制器

Job，主要用于负责批量处理(一次要处理指定数量任务)短暂的一次性(每个任务仅运行一次就结束)任务

3.6.1job示例

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  completions: 6        #一共完成任务数为6      
  parallelism: 2        #每次并行完成2个
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]   计算Π的后2000位
      restartPolicy: Never                      #关闭后不自动重启
  backoffLimit: 4                               #运行失败后尝试4重新运行
​
[root@k8s2 pod]# kubectl apply -f job.yml

关于重启策略设置的说明：

• 如果指定为OnFailure，则job会在pod出现故障时重启容器

  而不是创建pod，failed次数不变

• 如果指定为Never，则job会在pod出现故障时创建新的pod

  并且故障pod不会消失，也不会重启，failed次数加1

• 如果指定为Always的话，就意味着一直重启，意味着job任务会重复去执行了

3.7cronjob控制器

• ron Job 创建基于时间调度的 Jobs。

• CronJob控制器以Job控制器资源为其管控对象，并借助它管理pod资源对象，

• CronJob可以以类似于Linux操作系统的周期性任务作业计划的方式控制其运行时间点及重复运行的方式。

• CronJob可以在特定的时间点(反复的)去运行job任务。

3.7.1cronjob示例

apiVersion: batch/v1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "* * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers: #是一个列表所以要加“-”
          - name: hello
            image: busybox
            imagePullPolicy: IfNotPresent #本地有就用本地的，没有就拉取
            command: [" - /bin/sh -c date; echo Hello from the Kubernetes cluster"]
          restartPolicy: OnFailure #失败后对容器进行重启不记录在失败次数内
​
[root@k8s2 pod]# kubectl apply -f cronjob.yml

4.微服务

4.1什么是微服务

当pod的标签与微服务的标签一致时pod的业务就可以通过微服务发布出去

用控制器来完成集群的工作负载，那么应用如何暴漏出去？需要通过微服务暴漏出去后才能被访问

• Service是一组提供相同服务的Pod对外开放的接口。

• 借助Service，应用可以实现服务发现和负载均衡。

• service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）

4.2微服务的类型（四层）

ClusterIP： 默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问

NodePort ：将Service通过指定的Node上的端口暴露给外部，访问任意一个NodeIP:nodePort都将路由到ClusterIP（在微服务中加入type）

LoadBalancer：在NodePort的基础上,借助cloud provider创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort，此模式只能在云服务器上使用

ExternalName ：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过 spec.externlName 设定

4.3ipvs

• Service 是由 kube-proxy 组件，加上 iptables 来共同实现的

• kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的 iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源

• IPVS模式的service，可以使K8s集群支持更多量级的Pod

iptables会大量消耗资源，设置为ipvs会大大节省资源，并且使调度更加精准

4.3.1ipvs模式配置方式（service的工作模式优化）

kubectl -n kube-system edit cm kube-proxy #找到mode

kubectl -n kube-system get pod | awk '/proxy/{system("kubectl -n kube-system delete pods "$1)}'#将原有的pod删除，使它生成新的pod（刷新）

将pod删除后，策略也会消失

4.4clusterip

clusterip模式只能在集群内访问，并对集群内的pod提供健康检测和自动发现功能（通过标签实现）

1.先创建一个pod

kubectl run testpod --image nginx

2.为pod建立一个微服务，将pod发布

kubectl expose pod testpod --port 80 --target-port 80 --dry-run=client -o yaml > testpod.yml

apiVersion: v1
kind: Service
metadata:
  labels:
    run: testpod
  name: testpod
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: testpod
  type: ClusterIp
​

3.新建一个pod，将pod的标签改为上一个服务的标签，它会自动发现并将pod加入到策略中

kubectl label pod testpod1 run=testpod --overwrite #新建一个pod

4.service创建后集群DNS提供解析

kubectl -n kube-system get svc #查看微服务的dns

dig testpod.default.svc.cluster.local@10.96.0.10（svc.cluster.local固定格式）

在集群内部可通过域名访问

4.4.1clusterIP中特殊的模式headless（无头服务）

客户端直接访问pod，而不是通过访问svc访问pod，暴露pod本身的ip且不会加入到ipvsadm的策略中

spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: timinglee
  type: ClusterIP
  clusterIP: None

4.5nodeport

通过ipvs暴漏端口从而使外部主机通过master节点的对外ip:<port>来访问pod业务

会在pod暴露一个端口，在访问的时候就访问这个端口

spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: timinglee
  type: ClusterIP
  clusterIP: NodePort
​

nodeport默认端口

nodeport默认端口是30000-32767，超出会报错，如果想要超出这个范围，则需要修改配置

vim /etc/kubernetes/manifests/kube-apiserver.yaml
​
- --service-node-port-range=30000-40000 #修改参数后集群会自动重启

spec:
  ports:
​
  - port: 80
    protocol: TCP
    targetPort: 80
    nodePort: 33333 #指定端口
      selector:
    app: timinglee
      type: NodePort

4.6loadbalancer

云平台会为我们分配vip并实现访问，如果是裸金属主机那么需要metallb来实现ip的分配

spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: timinglee
  type: LoadBalancer

配置完后，无法生成对外的ip，于是我们需要搭建matelLbn来分配对外的ip

4.7matelLb

为loadbalancer分配对外的ip

4.7.1下载matelLb

1.设置ipvs模式 [root@k8s-master ~]# kubectl edit cm -n kube-system kube-proxy apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration mode: "ipvs" ipvs: strictARP: true

[root@k8s-master ~]# kubectl -n kube-system get pods | awk '/kube-proxy/{system("kubectl -n kube-system delete pods "$1)}'

2.下载部署文件 [root@k8s2 metallb]# wget https://raw.githubusercontent.com/metallb/metallb/v0.13.12/config/manifests/metallb-native.yaml

3.修改文件中镜像地址,与harbor仓库路径保持一致 [root@k8s-master ~]# vim metallb-native.yaml ... image: metallb/controller:v0.14.8 image: metallb/speaker:v0.14.8

4.上传镜像到harbor [root@k8s-master ~]# docker pull quay.io/metallb/controller:v0.14.8 [root@k8s-master ~]# docker pull quay.io/metallb/speaker:v0.14.8

[root@k8s-master ~]# docker tag quay.io/metallb/speaker:v0.14.8 reg.timinglee.org/metallb/speaker:v0.14.8 [root@k8s-master ~]# docker tag quay.io/metallb/controller:v0.14.8 reg.timinglee.org/metallb/controller:v0.14.8

[root@k8s-master ~]# docker push reg.timinglee.org/metallb/speaker:v0.14.8 [root@k8s-master ~]# docker push reg.timinglee.org/metallb/controller:v0.14.8

4.7.2部署服务

kubectl apply -f metallb-native.yaml
kubectl get namespaces 
NAME              STATUS   AGE
metallb-system    Active   6s
[root@k8s-master metalLbn]# vim configmap.yml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool                      #地址池名称
  namespace: metallb-system
spec:
  addresses:
  - 172.25.254.50-172.25.254.99         #修改为自己本地地址段
​
---                                     #两个不同的kind中间必须加分割
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system
spec:
  ipAddressPools:
  - first-pool                          #使用地址池 
​
 kubectl apply -f configmap.yml
 [root@k8s-master metalLbn]# kubectl -n metallb-system get configmaps
 

此时就有对外的ip了

[root@k8s-master ~]# kubectl get service
NAME         TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
kubernetes   ClusterIP      10.96.0.1       <none>          443/TCP        5d19h
testpod      LoadBalancer   10.96.214.227   172.25.254.50   80:31039/TCP   2s
​

4.8externalname

++将外部的业务迁移到k8s时所用到++

功能：在集群内指定一个svc把这个svc和外部的一个资源地址绑定

• 开启services后，不会被分配IP，而是用dns解析CNAME固定域名来解决ip变化问题

• 一般应用于外部业务和pod沟通或外部业务迁移到pod内时

• 在应用向集群迁移过程中，externalname在过度阶段就可以起作用了。

• 集群外的资源迁移到集群时，在迁移的过程中ip可能会变化，但是域名+dns解析能完美解决此问题

[root@k8s-master ~]# vim zee.yaml
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: zee-service
  name: zee-service
spec:
  selector:
    app: zee
  type: ExternalName
  externalName: www.zee.org
​
​
[root@k8s-master ~]# kubectl apply -f zee.yaml
​
[root@k8s-master ~]# kubectl get services  zee-service
NAME                TYPE           CLUSTER-IP   EXTERNAL-IP         PORT(S)   AGE
zee-service   ExternalName   <none>       www.zee.org   <none>    2m58s

4.9ingress-nginx

4.9.1ingress主要功能

主要功能：ingress借助services来访问pod

• 一种全局的、为了代理不同后端 Service 而设置的负载均衡服务,支持7层

• Ingress由两部分组成：Ingress controller和Ingress服务

• Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。

• 业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维护了对应的 Ingress Controller。

4.9.2部署ingress

创建两个deployment，然后将他们以yml的形式暴露出去

将镜像上传到harper仓库

如果镜像有问题则需要再各个节点删除镜像

[root@k8s-master app]# docker load -i ingress-nginx-1.11.2.tag.gz Loaded image: reg.timinglee.org/ingress-nginx/controller:v1.11.2 Loaded image: reg.timinglee.org/ingress-nginx/kube-webhook-certgen:v1.4.3

[root@k8s-master app]# docker tag reg.timinglee.org/ingress-nginx/controller:v1.11.2 reg.wyz.org/ingress-nginx/controller:v1.11.2 [root@k8s-master app]# docker tag reg.timinglee.org/ingress-nginx/kube-webhook-certgen:v1.4.3 reg.wyz.org/ingress-nginx/kube-webhook-certgen:v1.4.3

[root@k8s-master app]# docker push reg.wyz.org/ingress-nginx/controller:v1.11.2

[root@k8s-master app]# docker push reg.wyz.org/ingress-nginx/kube-webhook-certgen:v1.4.3

kubectl apply -f deploy.yaml #安装

[root@k8s-master app] kubectl get namespaces 
NAME              STATUS   AGE
ingress-nginx     Active   30s#安装后会会建立一个域
​

安装失败

kubectl delete -f deploy.yaml #删除

修改文件，让它去我们的库下载

修改文件中的image

查看运行情况

[root@k8s-master app]# kubectl -n ingress-nginx get pods

现在就可以用了

4.9.3ingress示例

创建ingress发布svc

kubectl create ingress testpod --rule '*/=testpod:80' --dry-run=client -o yaml > ingress.yml #创建ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: testpod
spec:
  ingressClassName: nginx
  rules:
  - host:
    http:
      paths:
      - backend:
          service:
            name: testpod
            port:
              number: 80
        path: /
        pathType: Prefix

kubectl -n ingress-nginx edit svc ingress-nginx-controller #修改微服务为loadbalancer

kubectl -n ingress-nginx get all #查看

kubectl get ingress
NAME      CLASS   HOSTS   ADDRESS   PORTS   AGE
testpod   nginx   *                 80      75s

此时访问它的外部IP就可以访问到pod

4.9.4ingress的高级用法

4.9.4.1基于路径访问

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
  name: testpod
spec:
  ingressClassName: nginx
  rules:
  - host:
    http:
      paths:
      - backend:
          service:
            name: myappv1
            port:
              number: 80
        path: /v1
        pathType: Prefix
      - backend:
          service:
            name: myappv2
            port:
              number: 80
        path: /v2
        pathType: Prefix
        
# 动静分离

kubectl describe ingress testpod # 查看

4.9.4.2基于域名的访问

在测试主机解析

vim /etc/hosts

建立基于域名的yml文件

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress2
spec:
  ingressClassName: nginx
  rules:
  - host: myappv1.timinglee.org
    http:
      paths:
      - backend:
          service:
            name: myapp-v1
            port:
              number: 80
        path: /
        pathType: Prefix
  - host: myappv2.timinglee.org
    http:
      paths:
      - backend:
          service:
            name: myapp-v2
            port:
              number: 80
        path: /
        pathType: Prefix