k8s部署好怎么访问

要访问部署在Kubernetes (K8s) 上的应用，可以使用以下几种方法：ClusterIP、NodePort、LoadBalancer、Ingress。推荐使用Ingress，因为它提供了灵活且全面的访问控制。Ingress可以通过一个单一的入口点管理多个服务的路由规则，并支持基于域名、路径的流量分发。它还支持TLS终端，让访问更加安全。

一、ClusterIP

ClusterIP是K8s中最基本的服务类型，它在集群内部创建一个虚拟IP地址，供其他Pod访问。这种方式仅适用于集群内部通信，不对外暴露服务。ClusterIP的优势在于它能够简单地实现服务发现和负载均衡。在定义Service时，若不指定类型，默认即为ClusterIP。对于集群内部的组件之间通信，这是最佳选择。ClusterIP配置示例：

apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 type: ClusterIP

这种配置创建了一个名为my-service的服务，其他Pod可以通过my-service这个名称进行访问。

二、NodePort

NodePort将服务暴露在每个节点的相同端口上，可以从集群外部访问该服务。NodePort是将服务通过特定端口暴露在每个节点上的方式。这种方法较简单，但不太灵活，适合开发测试环境。它要求服务在集群外的访问必须知道节点的IP地址和端口号。NodePort配置示例：

apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 nodePort: 30007 type: NodePort

这种配置将服务my-service暴露在每个节点的30007端口，可以通过<NodeIP>:30007进行访问。

三、LoadBalancer

LoadBalancer类型的服务将自动创建一个外部负载均衡器，以便在所有节点上均匀分配流量。LoadBalancer是最方便的外部访问方式，适用于生产环境。这种服务类型通常依赖于云提供商的负载均衡器服务，例如AWS的ELB或GCP的GLB。LoadBalancer配置示例：

apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 type: LoadBalancer

这种配置会在云提供商上创建一个负载均衡器，并将流量分发到相应的节点和端口。

四、Ingress

Ingress是K8s中最灵活和强大的服务暴露方式，它提供了基于域名和路径的HTTP和HTTPS路由。Ingress控制器可以配置复杂的路由规则和TLS证书，使得外部访问更加安全和灵活。使用Ingress需要首先部署一个Ingress Controller，比如Nginx Ingress Controller或Traefik。Ingress配置示例：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80

这种配置将my-service服务通过域名myapp.example.com暴露，并通过Ingress Controller处理流量。

五、配置TLS

为了保证数据传输的安全性，可以在Ingress中配置TLS。通过使用TLS证书，Ingress可以提供HTTPS访问。TLS配置示例：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: tls: - hosts: - myapp.example.com secretName: my-tls-secret rules: - host: myapp.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-service port: number: 80

这段配置中，my-tls-secret是包含TLS证书和私钥的Kubernetes Secret。

六、使用域名和路径

在Ingress中可以根据不同的域名和路径将流量分发到不同的服务。这种方式适用于需要在同一入口下管理多个服务的场景。多路径和域名配置示例：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-ingress spec: rules: - host: app1.example.com http: paths: - path: / pathType: Prefix backend: service: name: app1-service port: number: 80 - host: app2.example.com http: paths: - path: /api pathType: Prefix backend: service: name: app2-service port: number: 80

这种配置可以通过不同的域名和路径将流量路由到不同的服务。

七、Ingress控制器的部署

部署Ingress控制器是使用Ingress的前提。常见的Ingress控制器包括Nginx、Traefik和HAProxy等。选择合适的Ingress控制器，能够为应用提供更好的性能和功能。Nginx Ingress Controller部署示例：

apiVersion: v1 kind: Namespace metadata: name: ingress-nginx --- apiVersion: v1 kind: ServiceAccount metadata: name: nginx-ingress-serviceaccount namespace: ingress-nginx --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-ingress-controller namespace: ingress-nginx spec: replicas: 1 selector: matchLabels: app: nginx-ingress template: metadata: labels: app: nginx-ingress spec: serviceAccountName: nginx-ingress-serviceaccount containers: - name: nginx-ingress-controller image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1 args: - /nginx-ingress-controller - --configmap=$(POD_NAMESPACE)/nginx-configuration - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services - --udp-services-configmap=$(POD_NAMESPACE)/udp-services env: - name: POD_NAME valueFrom: fieldRef: fieldPath: metadata.name - name: POD_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace ports: - name: http containerPort: 80 - name: https containerPort: 443

这种配置将部署一个Nginx Ingress Controller，并在ingress-nginx命名空间中运行。

八、常见问题排查

在使用K8s服务暴露应用时，可能会遇到一些问题。通过日志检查、配置验证和网络诊断可以有效解决大部分问题。常见问题包括：

服务未被正确暴露：检查Service和Ingress的配置，确保端口和选择器正确。
流量未到达Pod：使用kubectl describe命令查看服务和Pod的事件日志。
证书问题：确保TLS证书和私钥正确配置，并在对应的Secret中。

通过以上几种方法和步骤，可以有效地访问部署在K8s上的应用，确保服务的稳定和高效运行。

相关问答FAQs：

K8s部署好怎么访问？

Kubernetes（K8s）作为现代云原生应用的容器编排平台，广泛应用于各种企业和项目中。部署完成后，访问K8s集群中的应用至关重要。本文将详细探讨K8s部署后的访问方式，包括服务类型、Ingress、kubectl命令等多个方面，帮助您全面了解如何访问K8s中的服务。

1. K8s服务类型有哪些？如何选择合适的服务类型进行访问？

Kubernetes提供了多种服务类型，每种类型的访问方式和场景均有所不同。主要的服务类型包括ClusterIP、NodePort、LoadBalancer和ExternalName。

ClusterIP：默认服务类型。该类型的服务只能在集群内部访问，无法从外部网络直接访问。适用于集群内部的微服务通信。若希望通过其他服务进行访问，可以结合使用其他服务类型。
NodePort：在每个节点的指定端口上开放服务。通过Node的IP和指定端口即可从外部访问。NodePort适合小型应用或开发环境，但不推荐用于生产环境，因其存在安全风险和负载不均衡问题。
LoadBalancer：为服务配置外部负载均衡器，允许从外部访问K8s服务。适合生产环境中需要高可用性和负载均衡的应用。LoadBalancer通常与云服务提供商结合使用，如AWS、GCP或Azure。
ExternalName：将服务映射到外部服务的DNS名称。适用于需要访问集群外部的资源，但不适合直接访问K8s服务。

选择合适的服务类型需根据实际需求，考虑到访问安全、可用性和网络配置等因素。

2. 如何使用Ingress进行访问？

Ingress是K8s中用于管理外部访问服务的API对象。它可以提供基于HTTP和HTTPS的路由功能，使用户能够通过单个IP地址访问多个服务。使用Ingress可以简化访问管理，并提供SSL终止等高级功能。

配置Ingress：首先，需要在集群中安装Ingress控制器（如NGINX Ingress Controller）。这可以通过Helm或YAML清单进行安装。
创建Ingress资源：定义Ingress资源，指定路由规则。以下是一个示例Ingress配置：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-service
                port:
                  number: 80

访问服务：完成Ingress配置后，可以通过域名（如example.com）访问K8s服务。注意需要在DNS中配置相应的域名解析。

使用Ingress的优势在于支持复杂的路由规则，方便进行流量管理和安全策略配置。同时，Ingress也支持TLS配置，保障数据传输的安全性。

3. 如何通过kubectl命令访问服务？

使用kubectl命令行工具，您可以便捷地访问K8s集群中的服务。kubectl提供了多种方式来获取和操作服务。

查看服务列表：使用以下命令查看当前集群中所有的服务及其类型：

kubectl get services --all-namespaces

获取特定服务的详细信息：想了解特定服务的详情，可以执行：

kubectl describe service my-service -n my-namespace

使用Port Forwarding：若希望临时访问某个服务，可以使用kubectl的Port Forward功能，将本地端口转发到K8s服务的端口：

kubectl port-forward service/my-service 8080:80 -n my-namespace

通过上述命令，您可以在本地浏览器中访问http://localhost:8080，以便访问K8s中的服务。

在K8s中，kubectl是一个强大的工具，可以帮助用户管理和访问集群资源。熟练掌握kubectl的使用，将提升您的开发效率。

结论

访问K8s部署后的服务有多种方式，包括使用不同类型的服务、Ingress路由以及kubectl命令等。每种方式都有其独特的优势和适用场景，选择合适的方式能够有效提升应用的可访问性和安全性。

关于 GitLab 的更多内容，可以查看官网文档：
官网地址： https://gitlab.cn
文档地址： https://docs.gitlab.cn
论坛地址： https://forum.gitlab.cn

原创文章，作者：xiaoxiao，如若转载，请注明出处：https://devops.gitlab.cn/archives/60277