Update service guide wording
Signed-off-by: Sherlock113 <sherlockxu@yunify.com>
|
|
@ -1,89 +1,96 @@
|
|||
---
|
||||
title: "Services"
|
||||
keywords: 'kubesphere, kubernetes, docker, jobs'
|
||||
keywords: 'KubeSphere, Kubernetes, services, workloads'
|
||||
description: 'Create a Kubernetes Service'
|
||||
|
||||
|
||||
weight: 2060
|
||||
weight: 2262
|
||||
---
|
||||
|
||||
## What is the Service
|
||||
|
||||
An abstract way to expose an application running on a set of Pods as a network service.
|
||||
A Service is an abstract way to expose an application running on a set of Pods as a network service. Namely, a Service groups endpoints of these Pods into a single resource, which can be accessed through different ways.
|
||||
|
||||
With Kubernetes, you don't need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
|
||||
|
||||
## Service Type
|
||||
For more information, see the [official documentation of Kubernetes](https://kubernetes.io/docs/concepts/services-networking/service/).
|
||||
|
||||
- **VirtualIP**:It is based on the unique IP generated by the cluster. The service inside the cluster can be accessed through this IP, and the service outside the cluster can be accessed through NodePort and LoadBalancer. This type is suitable for most services.
|
||||
- **Headless**:The cluster does not generate an IP for the service, and the service is directly accessed through the back-end Pod IP of the service within the cluster. This type is suitable for back-end heterogeneous services, such as services that need to distinguish between master and slave.
|
||||
## Access Type
|
||||
|
||||
- **Virtual IP**: It is based on the unique IP generated by the cluster. A Service can be accessed through this IP inside the cluster. Alternatively, a Service can also be accessed through NodePort and LoadBalancer outside the cluster. This type is suitable for most Services.
|
||||
- **Headless**: The cluster does not generate an IP address for the Service, and the Service is directly accessed through the backend Pod IP of the Service within the cluster. This type is suitable for backend heterogeneous Services, such as Services that need to distinguish between master and slave.
|
||||
|
||||
{{< notice tip>}}
|
||||
|
||||
In KubeSphere, stateful and stateless services are created with a virtual IP by default. If you want to create a Headless service, use **YAML** to configure it directly.
|
||||
In KubeSphere, stateful and stateless Services are created with a virtual IP by default. If you want to create a Headless Service, use **YAML** to configure it directly.
|
||||
|
||||
{{</ notice>}}
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- You need to create a workspace, project and `project-regular` account. Please refer to the [Getting Started with Multi-tenant Management](../../../quick-start/create-workspace-and-project) if not yet.
|
||||
- You need to sign in with `project-admin` account and invite `project-regular` to enter the corresponding project if not yet. Please refer to [Invite Member](../../../quick-start/create-workspace-and-project#task-3-create-a-project).
|
||||
- You need to create a workspace, a project and an account (`project-regular`). Please refer to [Create Workspace, Project, Account and Role](../../../quick-start/create-workspace-and-project) if they are not ready yet.
|
||||
- You need to sign in with the `project-admin` account and invite `project-regular` to the corresponding project. Please refer to [these steps to invite a member](../../../quick-start/create-workspace-and-project#task-3-create-a-project).
|
||||
|
||||
## How to create a Service
|
||||
## Service Type
|
||||
|
||||

|
||||
|
||||
As shown in the image, KubeSphere provides three basic methods to create a service: **Stateless Service**, **Stateful Service**, and **External Service**. Besides, you can also customize a service through **Specify Workloads** and **Edit by YAML** under **Custom Creation**.
|
||||
As shown in the image, KubeSphere provides three basic methods to create a Service: **Stateless Service**, **Stateful Service**, and **External Service**. Besides, you can also customize a Service through **Specify Workloads** and **Edit by YAML** under **Custom Creation**.
|
||||
|
||||
There are some ways to create a service
|
||||
**Stateless Service**
|
||||
|
||||
- **Stateless Service**
|
||||
Stateless Services are the most commonly used Services in container Services. They define the Pod template to control the Pod status, including rolling updates and rollbacks. A **Deployment** workload is also created when you create a stateless Service. For more information about stateless Services, see [Deployments](../../application-workloads/deployments).
|
||||
|
||||
A **Deployment** workload is also created when you create a stateless service. For more information about stateless services, see [Deployment](../../application-workloads/deployments)
|
||||
**Stateful Service**
|
||||
|
||||
- **Stateful Service**
|
||||
Stateful Services are used to manage stateful applications, ensuring ordered and graceful deployment and scaling. They also provide stable persistent storage and network identifiers. A **StatefulSet** workload is also created when you create a stateful Service. For more information about stateful Services, see [StatefulSets](../../application-workloads/statefulsets).
|
||||
|
||||
A **StatefulSet** workload is also created when you create a stateful service. For more information about stateful services, see [Statefulset](../../application-workloads/statefulsets)
|
||||
**External Service**
|
||||
|
||||
- **External Service**
|
||||
Different from stateless and stateful Services, an ExternalName Service maps a Service to a DNS name instead of a selector. You need to specify these Services in the **ExternalName** field, indicated by `externalName` in the YAML file.
|
||||
|
||||
Different from stateless and stateful services, an ExternalName service maps a service to a DNS name instead of a selector. You need to specify these services in the `externalName` field.
|
||||
**Specify Workloads**
|
||||
|
||||
- **Specify Workloads**
|
||||
Create a Service with existing Pods.
|
||||
|
||||
Create a service with existing Pods.
|
||||
**Edit by YAML**
|
||||
|
||||
- **Edit by YAML**
|
||||
|
||||
Create a service directly with YAML. You can upload and download YAML configuration files to and from the console.
|
||||
Create a Service directly with YAML. You can upload and download YAML configuration files to and from the console.
|
||||
|
||||
{{< notice tip>}}
|
||||
|
||||
The value of `annotations:kubesphere.io/serviceType` keywords is one of them **statelessservice** , **statefulservice** , **externalservice** and **None**.
|
||||
The value of `annotations:kubesphere.io/serviceType` keywords can be defined as: `statelessservice`, `statefulservice`, `externalservice` and `None`.
|
||||
|
||||
{{</ notice>}}
|
||||
|
||||
## Create a **Stateless Service**
|
||||
## Create a Stateless Service
|
||||
|
||||
Into **Application Workload**, click **Services**
|
||||
### Step 1: Open Dashboard
|
||||
|
||||
### Step 1: click **Create**, and choose **Stateless Service**
|
||||
1. Go to **Services** under **Application Workloads** of a project and click **Create**.
|
||||
|
||||

|
||||

|
||||
|
||||

|
||||
2. Click **Stateless Service**.
|
||||
|
||||
### Step 2: Input Base data
|
||||

|
||||
|
||||

|
||||
{{< notice note >}}
|
||||
|
||||
The steps of creating a stateful Service and a stateless Service are basically the same. This example only presents the process of creating a stateless Service for demonstration purpose.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
### Step 2: Input Basic Information
|
||||
|
||||
1. In the dialogue that appears, you can see the filed **Version** prepopulated with `v1`. You need to define a name for the Service, such as `demo-service`. When you finish, click **Next** to continue.
|
||||
|
||||

|
||||
|
||||
- **Name**: The name of the Service and Deployment, which is also the unique identifier.
|
||||
- **Alias**: The alias name of the service, making resources easier to identify.
|
||||
- **Alias**: The alias name of the Service, making resources easier to identify.
|
||||
- **Version**: It can only contain lowercase letters and numbers. The maximum length of characters is set to 16.
|
||||
|
||||
{{< notice tip >}}
|
||||
|
||||
The value of **Name** is used in both configurations, one for `Deployment` and the other for `Service`.
|
||||
The value of **Name** is used in both configurations, one for Deployment and the other for Service. You can see the manifest file of the Deployment and the Service by enabling **Edit Mode** in the top right corner. Below is an example file for your reference.
|
||||
|
||||
{{</ notice>}}
|
||||
|
||||
|
|
@ -118,44 +125,70 @@ spec:
|
|||
app: xxx
|
||||
```
|
||||
|
||||
### Step 3: Input Container Image
|
||||
### Step 3: Set Image
|
||||
|
||||

|
||||
To add a container image for the Service, see [Set Image](../deployments/#step-3-set-image) for details.
|
||||
|
||||
To add a container for the service, please refer to [Pod Containers](../deployments) for details.
|
||||

|
||||
|
||||
### Step 4: Input Volume
|
||||
{{< notice tip >}}
|
||||
|
||||

|
||||
For more information about explanations of dashboard properties, see [Container Image Settings](../container-image-settings/) directly.
|
||||
|
||||
Refer to [Pod Volumes](../deployments) for details.
|
||||
{{</ notice >}}
|
||||
|
||||
### Step 5: input Advanced Settings
|
||||
### Step 4: Mount Volumes
|
||||
|
||||

|
||||
To mount a volume for the Service, see [Mount Volumes](../deployments/#step-4-mount-volumes) for details.
|
||||
|
||||
Refer to [Deployment Advanced Settings](../deployments) for details.
|
||||

|
||||
|
||||
## Check Service Detail
|
||||
### Step 5: Configure Advanced Settings
|
||||
|
||||
### Service Operations
|
||||
You can set a policy for node scheduling and add metadata which is the same as explained in [Deployments](../deployments/#step-5-configure-advanced-settings). For a Service, you can see two additional options available.
|
||||
|
||||

|
||||

|
||||
|
||||
After the stateless service is created, you can click the three dots on the right to further edit it, such as its metadata (excluding **Name**), YAML, port, and Internet access.
|
||||
#### Internet Access
|
||||
|
||||
- **Edit**: Edit the base data.
|
||||
- **Edit YAML**: Edit the YAML config.
|
||||
- **Edit Service**: Edit the service config.
|
||||
- **Edit Internet Access**: Edit the service internet access.
|
||||
- **Delete**: When deleting a service, the associated resources will be displayed. If you check them, they will be deleted together with the service
|
||||
You can expose a Service externally through two methods, NodePort and LoadBalancer.
|
||||
|
||||
### Service Detail
|
||||
- **NodePort**: A Service is exposed on each node's IP address at a static port.
|
||||
|
||||
- **LoadBalancer**: Clients send requests to the IP address of a load balancer.
|
||||
|
||||
{{< notice note >}}
|
||||
|
||||
This value is specified by `.spec.type`. If you select **LoadBalancer**, you need to add annotations for it at the same time.
|
||||
|
||||
{{</ notice >}}
|
||||
|
||||
#### Enable Sticky Session
|
||||
|
||||
You may want to route all traffic sent from a single client session to the same instance of an app which runs across multiple replicas. This makes better use of caches as it reduces latency. This behavior of load balancing is called Sticky Sessions.
|
||||
|
||||
You can set the maximum session sticky time in this field, specified by `.spec.sessionAffinityConfig.clientIP.timeoutSeconds` in the manifest file, which defaults to 10800.
|
||||
|
||||
## Check Service Details
|
||||
|
||||
### Detail Page
|
||||
|
||||
1. After a Service is created, you can click the three dots on the right to further edit it, such as its metadata (excluding **Name**), YAML, port, and Internet access.
|
||||
|
||||

|
||||
|
||||
- **Edit**: View and edit the basic data.
|
||||
- **Edit YAML**: View, upload, download, or update the YAML file.
|
||||
- **Edit Service**: View the access type and set selectors and ports.
|
||||
- **Edit Internet Access**: Edit the service Internet access method.
|
||||
- **Delete**: When you delete a Service, associated resources will be displayed. If you check them, they will be deleted together with the Service.
|
||||
|
||||
2. Click the name of the Service and you can go to its detail page.
|
||||
|
||||

|
||||
|
||||
- Click **More** to expand the drop-down menu which is the same as the one in the service list.
|
||||
- The pod list provides the pod's detail information(conditions, phase, node, pod ip, monitoring).
|
||||
- You can view the container info by clicking the pod item.
|
||||
- Click the container log icon to view the output logs of the container.
|
||||
- You can view the pod detail page by clicking the pod name.
|
||||
- Click **More** to expand the drop-down menu which is the same as the one in the Service list.
|
||||
- The Pod list provides detailed information of the Pod (status, node, Pod IP and resource usage).
|
||||
- You can view the container information by clicking a Pod item.
|
||||
- Click the container log icon to view output logs of the container.
|
||||
- You can view the Pod detail page by clicking the Pod name.
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 264 KiB |
|
Before Width: | Height: | Size: 295 KiB |
|
After Width: | Height: | Size: 289 KiB |
|
Before Width: | Height: | Size: 370 KiB |
|
After Width: | Height: | Size: 308 KiB |
|
Before Width: | Height: | Size: 372 KiB |
|
After Width: | Height: | Size: 311 KiB |
|
Before Width: | Height: | Size: 396 KiB |
|
After Width: | Height: | Size: 378 KiB |
|
Before Width: | Height: | Size: 454 KiB |
|
After Width: | Height: | Size: 260 KiB |
|
Before Width: | Height: | Size: 350 KiB |
|
After Width: | Height: | Size: 333 KiB |
|
Before Width: | Height: | Size: 385 KiB |