Managing Virtual Services with kubectl

Required IAM Policy for Virtual Services 🔗

To use a virtual service, an administrator must grant you the required type of access in a policy (IAM). Whether you're using the Console, the REST API with an SDK, the CLI, Kubernetes kubectl, or other tool, the correct permissions are required.

Allow group MeshAdmins to manage mesh-virtual-services in compartment sales-app

Creating a Virtual Service 🔗

To create a virtual service, use the kubectl apply command. For example:

kubectl apply -f virtual-service.yaml

Create resources in different namespaces by specifying the metadata:namespace field in the YAML configuration file. By default, if namespace isn't provided, the command uses the current namespace. When specifying the mesh in the spec section of the YAML configuration file, you use either the mesh ID or the mesh reference.

Where:

• <name>: The name of the virtual service. The name must be unique within the same service mesh and can't be changed after creation (immutable). The name must start with a letter or underscore, followed by letters, numbers, hyphens, or underscores. Length can be 1–255 characters. Avoid entering confidential information.
• <compartmentId>: The OCID of the compartment to which the virtual service belongs.
• <meshId>: The OCID of the service mesh in which this virtual service is created.
• <description>: (Optional) The description of the virtual service. Avoid entering confidential information.
• <defaultRoutingPolicy>: The default routing policy across virtual deployments within a virtual service. If no virtual service route tables are present, the virtual service applies the default routing policy. Options are DENY or UNIFORM. The default routing policy is DENY.

  The routing options are as follows:

  • Uniform: Distributes traffic uniformly across virtual deployments.
  • Deny: The default option. Disables routing. Sends no traffic to the virtual deployments.

  For more information, see Routing Traffic in a Virtual Service.

• <hosts>The DNS host names of the virtual service used by its callers. Supports wild card host names in prefix form. Specify up to 10 DNS host names. The following are examples of valid host names: www.example.com, *.example.com, *.com, www.example.com:9080, *.example.com:9080. Can be omitted if the virtual service only has TCP virtual deployments.
  Warning
  
  Don't use the following service mesh reserved ports in this resource: 15000, 15003, 15006, and 9901.

  For services with HTTP based virtual deployments, the host name must match the HTTP host header used to communicate with the service. If a mismatch occurs, the applications connecting to this service receives 404 errors. The HTTP host header is of the form example.com for standard ports 80 and 443. For a nonstandard port such as 9080, the host header is of the form example.com:9080.

  For services with virtual deployments based on TLS_PASSTHROUGH, the host name must match the server name indication (SNI) used to communicate with the service. If a mismatch occurs, the applications connecting to this service receives TLS handshake errors. The service allows wild cards in the prefix form but doesn't allow a blanket wild card: *.

  SNI is similar to HTTP host headers but for TLS. However, port information isn't required for SNI. For example, if you're running a Kubernetes service on SNI example.com and on a nonstandard port 9080, you must define example.com as a host on the virtual service.

  Important
  
  Hosts entries aren't required for egress-only services. Egress-only services are microservices that don't receive any calls from other services.
• <mtls>The mTLS authentication mode to use when receiving requests from other virtual services or ingress gateways within the mesh. Set mTLS <mode> to DISABLED, PERMISSIVE, or STRICT as described in the following list. Additionally, specify <maximumValidity> to determine the number of days the mTLS certificate is valid for. Specify a value between 45 and 90. The default value is 45 days.
  • <mode>:
    • DISABLED: Accept raw TCP traffic. No minimum virtual services or ingress gateways within this mesh can use any mTLS authentication mode.
    • PERMISSIVE: Accept both mTLS and raw TCP traffic. Virtual services and ingress gateways within this mesh are either PERMISSIVE or STRICT modes.
    • STRICT: Accept mTLS traffic. All virtual services and ingress within this mesh must use STRICT mode.

    For more information on using mTLS on Service Mesh, see Using mTLS with Service Mesh.

Updating a Virtual Service 🔗

To update a virtual service with kubectl:

1. Change the existing YAML configuration file for the virtual service as needed.
2. Save the file.

3. Run the apply command again:

   Copy

   kubectl apply -f virtual-service.yaml

Moving a Virtual Service 🔗

To move a virtual service to a different compartment:

1. Update the compartment OCID to the value of the target compartment in the existing YAML configuration file for the virtual service.
2. Save the file.

3. Run the apply command again:

   Copy

   kubectl apply -f virtual-service.yaml

Get a List of Virtual Services 🔗

To get a list of virtual services in the namespace, use the following command:

kubectl get virtualservices -n <namespace>

Getting Virtual Service Details 🔗

To view the details of a specific virtual service in the namespace, use the following command:

kubectl describe virtualservice <name> -n <namespace>

Delete a Virtual Service 🔗

To delete of a specific virtual service in the namespace, use the following command:

kubectl delete virtualservice <name> -n <namespace>