kubernetes简单入门

kubernetes简单入门

1.kubernetes是什么?

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。

2.kubernetes组件

2.1.控制平面组件（Control Plane Components)

2.1.1.kube-apiserver

API 服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 API 服务器是 Kubernetes 控制平面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

2.1.2.kube-scheduler

kube-scheduler 是控制平面的组件， 负责监视新创建的、未指定运行节点（node）的 Pods， 并选择节点来让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

2.1.3.kube-controller-manager

kube-controller-manager 是控制平面的组件， 负责运行控制器进程。

从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

这些控制器包括：

  • 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
  • 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
  • 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）
  • 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌
2.1.4.cloud-controller-manager

cloud-controller-manager 是指嵌入特定云的控制逻辑之 控制平面组件。 cloud-controller-manager 允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

下面的控制器都包含对云平台驱动的依赖：

  • 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
  • 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
  • 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器
2.1.5.etcd

etcd 是兼顾一致性与高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

你的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。

如果想要更深入的了解 etcd，请参考 etcd 文档。

2.2.Node 组件

2.2.1.kubelet

kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs， 确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

2.2.2.kube-proxy

kube-proxy 是集群中每个节点（node）所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

3.kubernetes的资源对象

  • 1.ReplicationController
  • 2.ReplicationSet
  • 3.Deployment
  • 4.Ingress
  • 5.Secret
1.ReplicationController

Replication Controller（RC）是一种核心资源对象，用于确保指定数量的Pod副本正在运行。它允许用户定义一个Pod模板，并创建多个相同的Pod副本，以便在集群中部署和管理应用程序容器。

具体来说，Replication Controller 可以确保满足以下条件：
1.运行指定数量的 Pod 副本：用户可以通过 RC 对象指定需要创建和维护的Pod副本数。

2.重启崩溃的 Pod：当某个 Pod 崩溃或被删除时，RC会自动创建一个新的 Pod 副本来代替它。

3.控制 Pod 的生命周期：用户可以使用 RC 来进行滚动更新、扩容/缩容等操作，而无需手动管理每个 Pod 的状态。
Replication Controller已经不被推荐使用，而是使用ReplicationSet或者Deployment进行代替

2.ReplicationSet

ReplicaSet（RS）是一种资源对象，用于确保指定数量的 Pod 副本正在运行。类似于 Replication Controller（RC），但 RS 具有更多高级的功能。

1.与 RC 不同的是，RS 可以使用 Label Selector 来选择要管理的 Pod 子集，从而允许用户根据其需要更精细地控制 Pod 的创建和删除。例如，用户可以定义一个 Label Selector 来选择特定类型的 Pod，并在满足一些特定条件时自动扩展或缩小该 Pod 集合。

2.此外，RS 还支持滚动升级，即在更新 Pod 模板时逐步替换现有 Pod 副本，以实现应用程序的无缝升级，这在 RC 中是不支持的。

3.总之，ReplicaSet 是 Kubernetes 中一种关键的资源对象，用于管理 Pod 的副本集。它提供了比 RC 更高级的功能，如 Label Selector、滚动升级等，使得管理和部署应用程序变得更加灵活和可靠。

3.Deployment

1.Deployment 是一种资源对象，用于管理 Pod 副本集的创建、更新和删除等操作。Deployment 通常建立在 ReplicaSet（RS）之上，并通过动态地创建、更新和删除 RS 对象来实现应用程序的无缝升级和回滚。

2.Deployment 允许用户指定一个 Pod 模板，并定义需要创建和维护的 Pod 副本数。然后，当需要更新应用程序时，用户可以修改 Pod 模板，并通过 Deployment 对象进行滚动升级，以逐步替换现有 Pod 副本。如果更新失败或出现问题，Deployment 还支持回滚操作，以自动恢复到先前的稳定状态。

3.此外，Deployment 还支持暂停/恢复操作，允许用户在更新过程中暂停所有 Pod 的创建和删除，以便进行一些必要的检查和修复。

4.Service

具体来说，Service 可以帮助用户实现以下功能：

1.发现和路由：通过 Service 对象，用户可以为一组 Pod 创建一个稳定的 IP 和端口，并使用该 IP 和端口将请求路由到集群中的任何一个 Pod 上。

2.负载均衡：当多个 Pod 共享同一个 Service 时，Kubernetes 会自动为这些 Pod 进行负载均衡，从而分摊请求流量并提高系统的可靠性和性能。

3.健康检查：Service 还支持对后端 Pod 的健康状态进行检查，并在发现故障时自动调整路由策略，从而保证应用程序的可用性和稳定性。

5.Secret

Secret 是一种资源对象，用于存储敏感数据，例如密码、API 密钥、证书等。它提供了一种安全地将这些敏感数据传递给容器的方法，同时也可以确保这些数据在传输和存储过程中得到加密和保护。

具体来说，Secret 可以用于以下场景：

1.存储密码和机密数据：例如数据库密码、SSH 密钥等。

2.存储 TLS 证书：例如 HTTPS 网站所需的证书和私钥。

3.存储 API 认证密钥：例如 OAuth 鉴权所需的令牌信息等。

在使用 Secret 时，用户需要先创建一个 Secret 对象，并将需要存储的数据放到其中。然后，可以通过 Pod 的环境变量、卷挂载等方式，将这些数据传递给容器。Kubernetes 会自动将 Secret 数据转换为 Base64 编码格式，并在传输和存储过程中对其进行加密和保护。

6.Ingress

Ingress 是一种资源对象，用于管理对集群中 Service 的 HTTP/HTTPS 访问，并允许用户使用类似于 Nginx 的路由规则将流量路由到不同的服务或后端 Pod 上。

具体来说，Ingress 可以实现以下功能：

1.路由：使用 Ingress 规则，将入站请求路由到指定的 Service 或后端 Pod 上。

2.HTTPS 支持：通过定义 TLS 证书和私钥，Ingress 可以实现终止和解密传入的 HTTPS 连接，并在转发请求时重新加密。

3.负载均衡：当多个 Pod 共享同一个 Ingress 时，Kubernetes 会自动为这些 Pod 进行负载均衡，从而分摊请求流量并提高系统的可靠性和性能。

4.应用程序层通信：可以使用 Ingress 控制器实现应用程序层的通信，例如 WebSocket、HTTP/2 等。

注意，Ingress本身并不提供负载均衡功能，只是简单的将各个匹配规则的流量转发到各个Service，虽然Ingress会有负载均衡算法，但是这些负载均衡算法是告诉Service的，实际的负载均衡是Service来做的

7.Flannel(Kubernetes网络组件)

Flannel是Kubernetes中一种常用的网络插件，用于为集群中的Pod提供网络互联。它使用了一种名为VXLAN（Virtual Extensible LAN）的技术来创建覆盖整个Kubernetes集群的虚拟网络。

具体来说，Flannel使用以下方式工作：

1.初始化：当Flannel代理节点启动时，它会为每个节点分配一个唯一的、未使用的子网(CIDR)地址段，通过etcd存储这些地址段信息，并将其称为“网络配置”。

2.分配IP地址：当需要为一个新的Pod分配IP地址时，Flannel会从网络配置中选择一个可用的子网，然后在该子网中为该Pod分配一个IP地址。Flannel会确保所选子网中的任何其他Pod都不会使用相同的IP地址。

3.创建网络隧道：为了将不同节点上的Pod连接起来，Flannel会创建一组网络隧道。具体来说，它会在每个节点上创建一个虚拟网络接口vxlan0，并将其绑定到一个物理网络接口（如eth0）。然后，Flannel会使用VXLAN技术，在不同节点之间创建一个覆盖整个Kubernetes集群的虚拟网络。
4.数据传输：当两个Pod需要进行通信时，它们会像单个计算机内部的进程一样通信。数据包被发送到本地的虚拟网络接口vxlan0，并通过创建的隧道传输到目标节点上的vxlan0接口。然后，数据包被路由到目标Pod。

4.kubernetes的安装与部署(基于Centos7.9)

1.部署master节点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#安装master节点
yum install -y etcd#键值对数据库
yum install -y kubernetes-master

#配置apiserver配置文件
#-------/etc/kubernetes/apiserver
KUBE_API_ADDRESS="--insecure-bind-address=0.0.0.0"

# The port on the local server to listen on.
KUBE_API_PORT="--port=8080"

# Port minions listen on
KUBELET_PORT="--kubelet-port=10250"

# Comma separated list of nodes in the etcd cluster
KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379"

# Address range to use for services
KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"

# default admission control policies
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"

# Add your own!
KUBE_API_ARGS=""

#配置/etc/kubernetes/config配置文件
KUBE_LOGTOSTDERR="--logtostderr=true"

# journal message level, 0 is debug
KUBE_LOG_LEVEL="--v=0"

# Should this cluster be allowed to run privileged docker containers
KUBE_ALLOW_PRIV="--allow-privileged=false"

# How the controller-manager, scheduler, and proxy find the apiserver
KUBE_MASTER="--master=http://192.168.245.131:8080"

systemctl start kube-apiserver.service
systemctl start kube-controller-manager.service
systemctl start kube-scheduler.service
2.部署node节点
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
yum install -y kubernetes-node
#编辑配置文件 /etc/kubernetes/kubelet
# kubernetes kubelet (minion) config

# The address for the info server to serve on (set to 0.0.0.0 or "" for all interfaces)
KUBELET_ADDRESS="--address=0.0.0.0"

# The port for the info server to serve on
# KUBELET_PORT="--port=10250"

# You may leave this blank to use the actual hostname
KUBELET_HOSTNAME="--hostname-override=k8s-node1"

# location of the api-server
KUBELET_API_SERVER="--api-servers=http://192.168.245.131:8080"

# pod infrastructure container
KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=registry.access.redhat.com/rhel7/pod-infrastructure:latest"

# Add your own!
KUBELET_ARGS=""
#/etc/kubernetes/config
###
# kubernetes system config
#
# The following values are used to configure various aspects of all
# kubernetes services, including
#
#   kube-apiserver.service
#   kube-controller-manager.service
#   kube-scheduler.service
#   kubelet.service
#   kube-proxy.service
# logging to stderr means we get it in the systemd journal
KUBE_LOGTOSTDERR="--logtostderr=true"

# journal message level, 0 is debug
KUBE_LOG_LEVEL="--v=0"

# Should this cluster be allowed to run privileged docker containers
KUBE_ALLOW_PRIV="--allow-privileged=false"

# How the controller-manager, scheduler, and proxy find the apiserver
KUBE_MASTER="--master=http://192.168.245.131:8080"

在配置kubernetes时一定要关闭swap,不然会导致服务访问缓慢

3.kubernetes的网络插件flunnel

flunnel是kubernetes的节点网络插件,主要借助TUN/TAP原理用于不同的节点之间进行通信,flannel中网络地址的分配是由etcd来维护的

4.kubernetes的资源对象

  • pod
  • ReplicationController
  • ReplicaSet
  • Deployment
  • StatefulSet
  • Service
  • Ingress
4.1.pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元,一个pod包含一个或多个容器(其中至少包含一个基础容器pause),其他一个或者多个业务容器和基础容器共享存储和网络,并且Pod 中的内容总是并置（colocated）的并且一同调度，在共享的上下文中运行。

如何创建一个pod?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: web
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      imagePullPolicy:  IfNotPresent
      ports:
        - containerPort: 80
    - names: ubuntu
      PullPolicy:  IfNotPresent
      command: ["bin/bash"]
      ports:
        - containerPort: 81
1
kubectl apply -f config.yaml #创建一个pod
4.2.ReplicationController

ReplicationController 是一组pod的控制器,确保在任何时候都有特定数量的 Pod 副本处于运行状态。 换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。

ReplicationController 如何工作?

当 Pod 数量过多时，ReplicationController 会终止多余的 Pod。当 Pod 数量太少时，ReplicationController 将会启动新的 Pod。 与手动创建的 Pod 不同，由 ReplicationController 创建的 Pod 在失败、被删除或被终止时会被自动替换。 例如，在中断性维护（如内核升级）之后，你的 Pod 会在节点上重新创建。 因此，即使你的应用程序只需要一个 Pod，你也应该使用 ReplicationController 创建 Pod。 ReplicationController 类似于进程管理器，但是 ReplicationController 不是监控单个节点上的单个进程，而是监控跨多个节点的多个 Pod。

在讨论中，ReplicationController 通常缩写为 “rc”，并作为 kubectl 命令的快捷方式。

一个简单的示例是创建一个 ReplicationController 对象来可靠地无限期地运行 Pod 的一个实例。 更复杂的用例是运行一个多副本服务（如 web 服务器）的若干相同副本。

如何创建一个rc?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:	#标签选择器RC只会去管理和维护标签相对应的pod
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx #标签一定要和selector相对应
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80
4.3.ReplicaSet

ReplicaSet 是ReplicationController的升级版,其目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。

和ReplicationController的区别

ReplicaSet支持集合的selector

如何创建一个ReplicaSet
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 按你的实际情况修改副本数
  replicas: 3
  selector:
    matchLabels: #匹配标签
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
4.4.Deployment

Deployment为 Pod 和 ReplicaSet 提供声明式的更新能力,Deployment在创建时会创建ReplicaSet,Deployment通过控制ReplicaSet,通过ReplicaSet管理实际的pod,使用Deployment而不直接使用ReplicaSet或者ReplicationController的原因是Deployment提供资源的滚动更新和回滚.

如何创建一个Deployment?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80
4.5.StatefulSet

StatefulSet 是用来管理有状态应用的工作负载 API 对象,StatefulSet 用来管理某 Pod 集合的部署和扩缩， 并为这些 Pod 提供持久存储和持久标识符。

和 Deployment 类似， StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是， StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的， 但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。

如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。 尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符使得将现有卷与替换已失败 Pod 的新 Pod 相匹配变得更加容易。

StatefulSet 对于需要满足以下一个或多个需求的应用程序很有价值：

  • 稳定的、唯一的网络标识符。
  • 稳定的、持久的存储。
  • 有序的、优雅的部署和扩缩。
  • 有序的、自动的滚动更新。

得益于StatefulSet的这些特点,因此StatefulSet一般用于管理有状态的服务(如数据库)

如何创建一个StatefulSet?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # 必须匹配 .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # 默认值是 1
  minReadySeconds: 10 # 默认值是 0
  template:
    metadata:
      labels:
        app: nginx # 必须匹配 .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts: #挂载容器卷
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: #
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi
4.6.service

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。

使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。(4层的SLB)

创建和销毁 Kubernetes Pod 以匹配集群的期望状态。 Pod 是非永久性资源。 如果你使用 Deployment 来运行你的应用程序，则它可以动态创建和销毁 Pod。

每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同,因此如果直接将pod直接在网络上公开时不可靠的,因为如果公开的pod后面出现故障,新创建的pod的ip地址和之前的pod有所不同,因此我们需要一个组件将一组pod稳定的在网络上公开,因此就有了service,service会将一组pod映射到kubernetes内部的一个虚拟ip地址上(这个虚拟ip地址只有pod内部可以访问),然后将虚拟ip地址映射出去即可以实现服务的稳定。

service的暴露类型有以下几种

  • clusterIP

    通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType。

  • NodePort

    通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。

  • LoadBalancer

    使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上

  • ExternalName

    通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理

service的endpoint依赖于标签选择器(selector),在创建的时候也可以不定义selector,可以稍后创建endpoint对象实现将多个pod加入到service,一般只有在以下集中情况下才会 定义没有selector的service

  • 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
  • 希望服务指向另一个 名字空间（Namespace） 中或其它集群中的服务。
  • 你正在将工作负载迁移到 Kubernetes。 在评估该方法时，你仅在 Kubernetes 中运行一部分后端。

有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 "None" 来创建 Headless Service。

你可以使用无头 Service 与其他服务发现机制进行接口，而不必与 Kubernetes 的实现捆绑在一起。

对这无头 Service 并不会分配 Cluster IP，kube-proxy 不会处理它们， 而且平台也不会为它们进行负载均衡和路由。 DNS 如何实现自动配置，依赖于 Service 是否定义了选择算符。

service原生提供服务的自动发现,即只要匹配了service的标签选择器,service就会自动将该服务加入到endpoint

如何创建一个service？
1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP 		#指定映射的协议
      port: 80 				#指定clusterip的端口
      targetPort: 9376 		#指定需要映射的pod的端口
如何创建endpoint
1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Endpoints
metadata:
  							# 这里的 name 要与 Service 的名字相同
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

endpoint的端点 IPs 必须不可以 是：本地回路（IPv4 的 127.0.0.0/8, IPv6 的 ::1/128）或 本地链接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64)。

端点 IP 地址不能是其他 Kubernetes 服务的集群 IP，因为 kube-proxy 不支持将虚拟 IP 作为目标

4.7.ingress

Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。


graph LR;
  client([client])-. Ingress-managed <br> load balancer .->ingress[Ingress];
  ingress-->|routing rule|service[Service];
  subgraph cluster
  ingress;
  service-->pod1[Pod];
  service-->pod2[Pod];
  end
  classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000;
  classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff;
  classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5;
  class ingress,service,pod1,pod2 k8s;
  class client plain;
  class cluster cluster;

Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。 Ingress 控制器 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。

Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 类型的 Service。

与service相比,service内部是通过ip+port实现4层SLB,而ingress是一个反向代理负载均衡器,他通过访问的域名和访问的url路径实现7层SLB。

如何创建一个ingress
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress-wildcard-host
spec:
  rules:
  - host: "foo.bar.com"
    http:
      paths:
      - pathType: Prefix
        path: "/bar"
        backend:
          service:
            name: service1
            port:
              number: 80
  - host: "*.foo.com"
    http:
      paths:
      - pathType: Prefix
        path: "/foo"
        backend:
          service:
            name: service2
            port:
              number: 80

5.kubernetes的基本使用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#kubernetes常用命令
kubectl get nodes 															#查看所有节点
kubectl get pod																#查看所有pod
kubectl describe pod ${podname}												#查看指定pod的详细信息
kubectl delete pod ${podname} --force --grace-period=0
kubectl create -f ${yaml}													#创建资源
kubectl apply -f ${yaml}
																			#--force指定强制删除
																			#--grace-period指定资源回收周期
kubectl expose deployment deployment-1 --port=80 --type=NodeType			#使用命令创建一个service
kubectl run mydemo --image=docker.io/nginx:alpine --replicas=2 --record		#使用命令创建一个deployment
kubectl rollout history deployment mystaticweb								#查看历史版本
kubectl rollout undo deployment deployment-1 --to-revision=5				#回滚到指定历史版本
kubectl set image deployment deployment-1 nginx=ubuntu/nginx:latest			#更新deployment的指定容器镜像版本

结尾

参考kubernetes官方文档

linux运维
#软件使用
kubernetes简单入门
https://dreamaccount.github.io/2022/07/12/kubernetes简单入门/
作者
404NotFound
发布于
2022年7月12日
许可协议