Kubernetes(k8s第四部分之servers)

1,为什么不使用round-robin DNS?

因为DNS有缓存,不会清理,无法负载均衡

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:不排队调度。

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中。

Headless Service

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

通过这种去绑定。

kubectl get pod -n kube-system

kubectl get pod -n kube-system -o wide

kubectl get pod

kubectl get pod -o wide

NodePort

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

mastervim myapp-service.yaml

apiVersion: v1

kind: Service

metadate:

name: myapp

namespace: default

spec:

type: NodePort

selector:

app: myapp

release: stable

ports:

name: http

port: 80

targetPort: 80

查询流程

iptables -t nat -nvl

KUBE-NODEPORTS

LoadBalancer

loadBalancer和nodePort其实是一种方式。区别在于loadBalancer比nodePort多了一步,就是可以调用cloud provider去创建LB来向节点导流。

LAAS流量服务,特别贵,云服务器搭建的k8s

ExternalName

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

kind:Service

apiVersion: v1

metadata:

name : my-service-1

namespace: default

spec:

type: ExternalName

externalName: my.database.example.com

当查询主机my-service.defalut.cluster.local(SVC_NAME.NAMESPACE。svc.cluster.local)

时,集群的DNS服务将返回一个值my.database.example.com的CNAME记录。访问这个服务的工作方式和其他的相同,唯一不同的是重定向发生在DNS层,而且不会进行代理或转发。

资料信息

ingress

Ingress HTTP代理访问

vim ingress.http.yaml

kubectl apply -f ingress.http.yaml

kubectl get svc

curl 10.102.54.180

kubectl apply -f ingress1.ymal

进入容器的命令

kubectl exec 容器名称 -n 名称 -it -- /bin/bash

根据不同的域名实现不同的虚拟主机

创建证书,以及cert存储方式

openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj

"/CN-nginxsvc/0=nginxsvc"

kubectl create secret tls tls-secret --key tls,key --cert tls.crt

deployment.service.IngressYaml文件

APIVersion:extensions/v1betal

kind: Ingress

metadata:

name: nginx-test

spec:

tls:

secretName: tls-secret

rules:

http:

paths: /

backend:

serviceName: nginx-svc

servicePort: 80

Nginx进行BasicAuth

相关推荐
骄马之死6 小时前
SpringMVC + SpringBoot 核心知识点总结
java·spring boot·后端
ggaofeng7 小时前
glusterfs如何在k8s中使用
云原生·容器·kubernetes·glusterfs
暮云星影7 小时前
个人总结 搭建Docker监控
docker·容器·grafana·prometheus
郑洁文8 小时前
基于Spring Boot的流浪动物救助网站
java·spring boot·后端·毕设·流浪动物救助
螺丝钉code8 小时前
JAVA项目 Claude code CLAUDE.md 到底应该怎么写
java·人工智能·claude code
IT策士9 小时前
第49篇 k8s之服务网格入门:Istio 简介
容器·kubernetes·istio
摇滚侠9 小时前
Maven 入门+高深 单一架构案例 54-59
java·架构·maven·intellij-idea
VidDown10 小时前
Webhook 调试器:让第三方回调“原形毕露”
java·开发语言·javascript·编辑器·postman
折哥的程序人生 · 物流技术专研10 小时前
Java 23 种设计模式:从踩坑到精通 | 原型模式 —— 克隆对象,深拷贝与浅拷贝的坑你踩过吗?
java·设计模式·架构·原型模式·单一职责原则
装不满的克莱因瓶10 小时前
基于 OpenResty 扩展开发实现动态服务注册与发现能力
java·开发语言·架构·openresty