7. 丈母娘嫌我不懂K8s的Service概念，让我去面壁

2020-10-21 403

文章目录

怎么跟你说 Service的出现，就是解决ip不固定的问题，怎么解决呢？听小刘慢慢道来

当Pod宕机后重新生成时，其IP等状态信息可能会变动，Service会根据Pod的Label对这些状态信息进行监控和变更，保证上游服务不受Pod的变动而影响。

一、Service 简介

1.1 Service 概念

Kubernetes Service定义了这样一种抽象： Service是一种可以访问 Pod逻辑分组的策略， Service通常是通过 Label Selector访问 Pod组。

Service能够提供负载均衡的能力，但是在使用上有以下限制：只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

s 1.2 Service 类型

Service在 K8s中有以下四种类型：

① ClusterIp

默认类型，自动分配一个仅 Cluster内部可以访问的虚拟 IP ② NodePort

在 ClusterIP基础上为 Service在每台机器上绑定一个端口，这样就可以通过 : NodePort来访问该服务。 ③ LoadBalancer

在 NodePort的基础上，借助 Cloud Provider创建一个外部负载均衡器，并将请求转发到 NodePort ④ ExternalName

把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 Kubernetes 1.7或更高版本的 kube-dns才支持。

1.3 Service 基础导论

客户端访问节点时通过 iptables实现的
iptables规则是通过 kube-proxy写入的
apiserver通过监控 kube-proxy去进行对服务和端点的监控
kube-proxy通过 pod的标签（ lables）去判断这个断点信息是否写入到 Endpoints里

二、代理

2.1 VIP 和 Service 代理

在 Kubernetes集群中，每个 Node运行一个 kube-proxy进程。 kube-proxy负责为 Service实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName的形式。在 Kubernetes v1.0版本，代理完全在 userspace。在 Kubernetes v1.1版本，新增了 iptables代理，但并不是默认的运行模式。从 Kubernetes v1.2起，默认就是 iptables代理。在 Kubernetes v1.8.0-beta.0中，添加了 ipvs代理。

在 Kubernetes 1.14版本开始默认使用 ipvs代理。

在 Kubernetes v1.0版本， Service是 4 层（ TCP/ UDP over IP）概念。在 Kubernetes v1.1版本，新增了 Ingress API（ beta版），用来表示 7 层（ HTTP）服务

为何不使用 round-robin DNS？

DNS会在很多的客户端里进行缓存，很多服务在访问 DNS进行域名解析完成、得到地址后不会对 DNS的解析进行清除缓存的操作，所以一旦有他的地址信息后，不管访问几次还是原来的地址信息，导致负载均衡无效

2.2 代理模式分类

① userspace 代理模式 ② iptables 代理模式

③ ipvs 代理模式

ipvs代理模式中 kube-proxy会监视 Kubernetes Service对象和 Endpoints，调用 netlink接口以相应地创建 ipvs规则并定期与 Kubernetes Service对象和 Endpoints对象同步 ipvs规则，以确保 ipvs状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod。

与 iptables类似， ipvs于 netfilter的 hook功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外， ipvs为负载均衡算法提供了更多选项，例如：

rr：轮询调度
lc：最小连接数
dh：目标哈希
sh：源哈希
sed：最短期望延迟
nq：不排队调度

三、Service 使用

3.1 ClusterIp

ClusterIP主要在每个 node节点使用 iptables，将发向 ClusterIP对应端口的数据，转发到 kube-proxy中。然后 kube-proxy自己内部实现有负载均衡的方法，并可以查询到这个 service下对应 pod的地址和端口，进而把数据转发给对应的 pod的地址和端口。为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver：用户通过 kubectl命令向 apiserver发送创建 service的命令， apiserver接收到请求后将数据存储到 etcd中
kube-proxy： Kubernetes的每个节点中都有一个叫做 kube-porxy的进程，这个进程负责感知 service、 pod的变化，并将变化的信息写入本地的 iptables规则中
iptables：使用 NAT等技术将 virtualIP的流量转至 endpoint中

创建 myapp-deploy.yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
      release: stabel
  template:
    metadata:
      labels:
        app: myapp
        release: stabel
        env: test
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v2
        imagePullPolicy: IfNotPresent
        ports:
        - name: http
          containerPort: 80

创建 Service信息：

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

执行命令：


[root@master service]
deployment.apps/myapp-deploy created
[root@master service]
NAME                            READY   STATUS    RESTARTS   AGE     IP            NODE      NOMINATED NODE   READINESS GATES
myapp-deploy-6cc7c66999-5n2dj   1/1     Running   0          16s     10.244.1.26   worker1   <none>           <none>
myapp-deploy-6cc7c66999-dfgqb   1/1     Running   0          16s     10.244.1.27   worker1   <none>           <none>
myapp-deploy-6cc7c66999-wz6zk   1/1     Running   0          16s     10.244.2.30   worker2   <none>           <none>

[root@master service]
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>

[root@master service]
service/myapp created
[root@master service]
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
myapp        ClusterIP   10.104.96.7      <none>        80/TCP    8s

[root@master service]
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.104.96.7:80 rr
  -> 10.244.1.26:80               Masq    1      0          0
  -> 10.244.1.27:80               Masq    1      0          1
  -> 10.244.2.30:80               Masq    1      0          1

[root@master service]
myapp-deploy-6cc7c66999-5n2dj
[root@master service]
myapp-deploy-6cc7c66999-wz6zk
[root@master service]
myapp-deploy-6cc7c66999-dfgqb
[root@master service]
myapp-deploy-6cc7c66999-5n2dj

3.2 Handless Service

有时不需要或不想要负载均衡，以及单独的 Service IP。遇到这种情况，可以通过指定 spec.clusterIP的值为 None来创建 Headless Service 。这类 Service并不会分配 Cluster IP， kube-proxy不会处理它们，而且平台也不会为它们进行负载均衡和路由。

[root@master service]

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
  namespace: default
spec:
  selector:
    app: myapp
  clusterIP: "None"
  ports:
  - port: 80
	targetPort: 80

[root@master service]

3.3 NodePort

NodePort的原理在于在 Node上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy进一步到给对应的 pod。

创建 Service信息：

apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: NodePort
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

执行命令：


[root@master service]
service/myapp configured
[root@master service]
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
myapp        NodePort    10.104.96.7      <none>        80:30333/TCP   46m

[root@master service]
tcp6       0      0 :::30333                :::*                    LISTEN      3459/kube-proxy

C:\Users\MrHu>curl 192.168.182.100:30333/hostname.html
myapp-deploy-6cc7c66999-5n2dj

3.4 LoadBalancer

LoadBalancer和 NodePort其实是同一种方式。区别在于 LoadBalancer比 NodePort多了一步，就是可以调用 Cloud provider去创建 LB来向节点导流。

3.5 ExternalName

这种类型的 Service通过返回 CNAME和它的值，可以将服务映射到 externalName字段的内容( 例： hub.hc.com )。 ExternalName Service是 Service的特例，它没有 selector，也没有定义任何的端口和 Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。

kind: Service
apiVersion: v1
metadata:
  name: my-service-1
  namespace: default
spec:
  type: ExternalName
  externalName: hub.hc.com

当查询主机 my-service.defalut.svc.cluster.local时，集群的 DNS服务将返回一个值 hub.hc.com的 CNAME记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS层，而且不会进行代理或转发。

四、Ingress

4.1 Ingress 简介

Service只支持4层负载均衡，而Ingress有7层功能

Nginx可以通过虚拟主机域名区分不同的服务，而每个服务通过 upstream进行定义不同的负载均衡池，再加上 location进行负载均衡的反向代理，在日常使用中只需要修改 nginx.conf即可实现，但是在 K8S中又该如何实现这种方式调度呢？

K8S引入了 ingress自动进行服务的调度， ingress包含两大组件： ingress controller和 ingress。

ingress：修改 Nginx配置操作被抽象成了 ingress对象，
ingress controller： ingress controller通过与 kubernetes API交互，动态的去感知进集群中 Ingress规则变化，然后读取它，然后读取它，按照它自己的模板生成一段 nginx配置，再写到 nginx Pod中，最后 reload以下，工作流程如下图：

Ingress 的安装

① 下载 Ingress镜像：

[root@master ingress]
REPOSITORY                                                       TAG                 IMAGE ID            CREATED             SIZE

quay.io/kubernetes-ingress-controller/nginx-ingress-controller   0.25.0              02149b6f439f        13 months ago       508MB

② 拷贝配置文件 mandatory.yaml、 service-nodeport.yaml，位置参考 https://github.com/kubernetes/ingress-nginx/tree/nginx-0.25.0/deploy/static。

③ 部署 ingress-controller对外提供服务：


[root@master ingress]

[root@master ingress]
NAME                                        READY   STATUS    RESTARTS   AGE
nginx-ingress-controller-7995bd9c47-kldqr   1/1     Running   0          13h

④ 给 ingress-controller建立一个 servcie，接收集群外部流量


[root@master ingress]

[root@master ingress]
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.106.6.160   <none>        80:31347/TCP,443:32445/TCP   13h

4.2 Ingress HTTP 代理访问

创建 deployment和 svc

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-dm
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: nginx
    spec:
      containers:
        - name: nginx
          image: wangyanglinux/myapp:v1
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx

[root@master ingress]

[root@master ingress]
NAME                        READY   STATUS    RESTARTS   AGE
nginx-dm-7d967c7ff5-kvz6f   1/1     Running   0          5m20s
nginx-dm-7d967c7ff5-wk4jv   1/1     Running   0          5m21s

[root@master ingress]
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
nginx-svc    ClusterIP   10.100.57.201   <none>        80/TCP    16m

创建 ingress:

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-test
spec:
  rules:
    - host: www1.hc.com
      http:
        paths:
        - path: /
          backend:
            serviceName: nginx-svc
            servicePort: 80

[root@master ingress]

[root@master ingress]
NAME         HOSTS         ADDRESS   PORTS   AGE
nginx-test   www1.hc.com             80      23s

[root@master ingress]
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.106.6.160   <none>        80:31347/TCP,443:32445/TCP   13h

在 Window系统中配置 hosts后进行访问：

C:\Users\MrHu>curl www1.hc.com:31347/hostname.html
nginx-dm-7d967c7ff5-wk4jv

4.3 Ingress HTTPS 代理访问

创建证书，以及 cert存储方式：

[root@master cert]

[root@master cert]
secret/tls-secret created

[root@master cert]
NAME                  TYPE                                  DATA   AGE
default-token-cjdrb   kubernetes.io/service-account-token   3      6d14h
tls-secret            kubernetes.io/tls

创建 deployment和 svc:

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-https
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: nginx2
    spec:
      containers:
        - name: nginx
          image: wangyanglinux/myapp:v2
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc-2
spec:
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    name: nginx2

[root@master ingress]

创建 ingress：

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-https
spec:
  tls:
    - hosts:
      - www2.hc.com
      secretName: tls-secret
  rules:
    - host: www2.hc.com
      http:
        paths:
        - path: /
          backend:
            serviceName: nginx-svc-2
            servicePort: 80

[root@master ingress]

[root@master ingress]
NAME          TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
nginx-svc-2   ClusterIP   10.106.108.145   <none>        80/TCP    10m

[root@master ingress]
NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)                      AGE
ingress-nginx   NodePort   10.106.6.160   <none>        80:31347/TCP,443:32445/TCP   14h

在 Window系统中配置 hosts后进行访问：

4.4 进行 BasicAuth

[root@master ingress]

[root@master ingress]

[root@master ingress]

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress-with-auth
  annotations:
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
    nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - foo'
spec:
  rules:
  - host: auth.hc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc-2
          servicePort: 80

[root@master ingress]

[root@master ingress]
NAME                HOSTS         ADDRESS   PORTS     AGE
ingress-with-auth   auth.hc.com             80        15s
nginx-https         www2.hc.com             80, 443   23m

在 Window系统中配置 hosts后进行访问：

4.5 Nginx进行重写

Nginx重写字段：创建 ingress：

[root@master ingress]
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-re
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: http://www1.hc.com:31347/hostname.html
spec:
  rules:
  - host: re.hc.com
    http:
      paths:
      - path: /
        backend:
          serviceName: nginx-svc
          servicePort: 80

[root@master ingress]

在 Window系统中配置 hosts后进行访问 re.hc.com:31347：

你只管学习，我来负责记笔记😲 关注公众号！ ,更多笔记，等你来拿，谢谢

微信关注我们

原文链接：https://my.oschina.net/u/4199331/blog/4683701

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

ArchLinux 2020 安装总结

ArchLinux 2020 安装总结 2020-4-1 今年我开始全面使用 ArchLinux 系统，这个系统比较小巧，安装过程自己控制的内容更多，减少很多不必要的麻烦，也更符合我自己的使用习惯。我最喜欢它的原因有三条： ArchLinux 的源很完善，使用起来很方便，能解决很多偏门的难题（相对于 centos )，比如我的 Apple MAC mini 的无线网卡、蓝牙驱动问题，都能在 ArchLinux 中得到解决。 ArchLinux 拥有专用的中文源——ArchLinuxcn，对中国人来说就是福利，很多我们习惯的软件都能在此找到，比如搜狗拼音输入法。 ArchLinux 的 wiki 很完善，而且有中文翻译，很多问题都可以在那儿找到答案。我不仅在 MAC mini 上安装，把我的 Thinkpad 笔记本、DIY 的台式机都安装了 ArchLinux 系统，都很好用。我的 MAC mini 上次没有安装好无线网卡驱动、蓝牙驱动，自己没弄好，把网卡也弄乱了，所以这次重装了 MAC mini 上的 ArchLinux 系统，这次用的是 ArchLinux 2020-02...

2020-10-21

587

链表链表是数据结构里一个很基础但是又很爱考的线性结构，链表的操作相对来说比较简单，但是非常适合考察面试者写代码的能力，以及对 corner case 的处理，还有指针的应用很容易引起 NPE (null pointer exception)。综合以上原因，链表在面试中很重要。提到链表就不得不提数组，它和数组可以说是数据结构的基础，那么它们最主要的区别在于：数组在物理内存上必须是连续的链表在物理内存上不需要连续，通过指针连接所以数组最好的性质就是可以随机访问 random access，有了 index，可以 O(1) 的时间访问到元素。而链表因为不连续，所以无法 O(1) 的时间定位任意一个元素的位置，那么就只能从头开始遍历。这就造成了它们之间增删改查上效率的不同。除此之外，链表本身的结构与数组也是完全不同的。 LinkedList 是由 ListNode 来实现的： class ListNode { int value; ListNode next; } 结构上长这样：这是单向链表，那还有的链表是双向链表，也就是还有一个 previous pointer 指向当前 ...

2020-10-22

532

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。

7. 丈母娘嫌我不懂K8s的Service概念，让我去面壁

文章目录

一、Service 简介

1.1 Service 概念

s 1.2 Service 类型

1.3 Service 基础导论

二、代理

2.1 VIP 和 Service 代理

2.2 代理模式分类

三、Service 使用

3.1 ClusterIp

3.2 Handless Service

3.3 NodePort

3.4 LoadBalancer

3.5 ExternalName

四、Ingress

4.1 Ingress 简介

4.2 Ingress HTTP 代理访问

4.3 Ingress HTTPS 代理访问

4.4 进行 BasicAuth

4.5 Nginx进行重写

ArchLinux 2020 安装总结

有关链表的小技巧，我都给你总结好了

相关文章

发表评论

资源下载

优质分享App

Nacos

Spring

Rocky Linux

欢迎您来访！