Kubernetes Engine Usage Guide

• 1: Access Cluster
• 2: Authentication and Authorization
• 3: Using type LoadBalancer service
• 4: Usage Considerations
• 5: Version information

1 - Access Cluster

kubectl Installation and Usage

After creating a Kubernetes Engine service, you can use the Kubernetes command-line tool kubectl to execute commands against your Kubernetes cluster. With kubectl, you can deploy applications, inspect and manage cluster resources, and view logs. You can find how to install and use kubectl in the official Kubernetes documentation.

To access a Kubernetes cluster with kubectl, you need a kubeconfig file that contains the Kubernetes server address and authentication information.

Kubernetes Engine supports authentication via admin certificate kubeconfig and user authentication key kubeconfig.

Admin certificate kubeconfig

This kubeconfig uses the admin certificate as the authentication method when accessing the Kubernetes API.

Download admin kubeconfig

Kubernetes Engine > Cluster List > Cluster Details > Admin kubeconfig download Click the button to download the kubeconfig file.

Use admin kubeconfig

User authentication key kubeconfig

This kubeconfig uses the user’s Open API authentication key as the credential when accessing the Kubernetes API.

User kubeconfig download

Kubernetes Engine > Cluster List > Cluster Details > User kubeconfig Download Click the button to download the kubeconfig file.

Add authentication key token to the user kubeconfig file

Below is an example of a user kubeconfig file. To use the kubeconfig file, you must add the authentication key token (AUTHKEY_TOKEN) information to the token field inside the file.

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t...
    server: https://my-cluster-a1c3e.ske.xxx.samsungsdscloud.com:6443
  name: my-cluster-a1c3e
contexts:
- context:
    cluster: my-cluster-a1c3e
    user: jane.doe
  name: jane.doe@my-cluster-a1c3e
current-context: jane.doe@my-cluster-a1c3e
kind: Config
preferences: {}
users:
- name: jane.doe
  user:
    token: <AUTHKEY_TOKEN> #### Writing required

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0t...
    server: https://my-cluster-a1c3e.ske.xxx.samsungsdscloud.com:6443
  name: my-cluster-a1c3e
contexts:
- context:
    cluster: my-cluster-a1c3e
    user: jane.doe
  name: jane.doe@my-cluster-a1c3e
current-context: jane.doe@my-cluster-a1c3e
kind: Config
preferences: {}
users:
- name: jane.doe
  user:
    token: <AUTHKEY_TOKEN> #### Writing required

AUTHKEY_TOKEN can be generated by concatenating the ACCESS_KEY and SECRET_KEY of the authentication key with a colon (:) and then Base64 encoding it. The following is an example of creating an AUTHKEY_TOKEN in a Linux environment.

$ ACCESS_KEY=5df418813aed051548a72f4a814cf09e
$ SECRET_KEY=6ba7b810-9dad-11d1-80b4-00c04fd430c8
$ AUTHKEY_TOKEN=$(echo -n "$ACCESS_KEY:$SECRET_KEY" | base64 -w0)
$ echo $AUTHKEY_TOKEN
NWRmNDE4ODEzYWVkMDUxNTQ4YTcyZjRhODE0Y2YwOWU6NmJhN2I4MTAtOWRhZC0xMWQxLTgwYjQtMDBjMDRmZDQzMGM4r

$ ACCESS_KEY=5df418813aed051548a72f4a814cf09e
$ SECRET_KEY=6ba7b810-9dad-11d1-80b4-00c04fd430c8
$ AUTHKEY_TOKEN=$(echo -n "$ACCESS_KEY:$SECRET_KEY" | base64 -w0)
$ echo $AUTHKEY_TOKEN
NWRmNDE4ODEzYWVkMDUxNTQ4YTcyZjRhODE0Y2YwOWU6NmJhN2I4MTAtOWRhZC0xMWQxLTgwYjQtMDBjMDRmZDQzMGM4r

User kubeconfig execution example

You can view an example of executing the user kubeconfig.

When access is blocked by access control or a firewall

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
Unable to connect to the server: dial tcp 123.123.123.123:6443: i/o timeout

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
Unable to connect to the server: dial tcp 123.123.123.123:6443: i/o timeout

When authentication fails because the AUTHKEY_TOKEN does not match

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
error: You must be logged in to the server (Unauthorized)

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
error: You must be logged in to the server (Unauthorized)

AUTHKEY_TOKEN when authentication succeeds

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
...
kube-node-lease    Active 10d
kube-public        Active 10d
kube-system        Active 10d

$ kubectl --kubeconfig=user-kubeconfig.yaml get namespaces
...
kube-node-lease    Active 10d
kube-public        Active 10d
kube-system        Active 10d

AUTHKEY_TOKEN Authentication succeeded but lacks permission

$ kubectl --kubeconfig=user-kubeconfig.yaml get nodes
Error from server (Forbidden): nodes is forbidden: User "jane.doe" cannot list resource "nodes" in API group "" at the cluster scope

$ kubectl --kubeconfig=user-kubeconfig.yaml get nodes
Error from server (Forbidden): nodes is forbidden: User "jane.doe" cannot list resource "nodes" in API group "" at the cluster scope

2 - Authentication and Authorization

Kubernetes Engine applies Kubernetes authentication and RBAC authorization features. It explains how Kubernetes authentication and authorization functions integrate with Kubernetes Engine and IAM.

Kubernetes authentication and authorization

Describes Kubernetes authentication and RBAC authorization features.

Authentication

The Kubernetes API server obtains the information required for authenticating a user (User) or a service account (ServiceAccount) from certificates or authentication tokens, and then carries out the authentication process.

Authorization

The Kubernetes API server uses the user information obtained through the authentication process to verify, via RBAC-related objects, whether the user has permission for the requested operation. RBAC-related objects come in four types as follows.

Roll

Kubernetes defines several cluster roles by default. Some of those cluster roles do not include the prefix (system:). These are cluster roles intended for user use. This includes a superuser role (cluster-admin) applied to the entire cluster using a ClusterRoleBinding, and roles (admin, edit, view) applied to a specific namespace using a RoleBinding.

If necessary, you can define additional roles (or cluster roles) beyond the default cluster role, as shown below.

# A role that grants permission to view pods in the "default" namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# A role that grants permission to view pods in the "default" namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# Cluster role that grants permission to view nodes
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

# Cluster role that grants permission to view nodes
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

Role Binding

To manage access to the Kubernetes Engine using Samsung Cloud Platform IAM, you need to understand the relationship between Kubernetes role bindings and IAM. The subjects of a role binding (or cluster role binding) may include individual users (User) or groups (Group).

• User corresponds to the Samsung Cloud Platform username, and Group corresponds to the IAM user group name, respectively.

For RoleBinding/ClusterRoleBinding, subjects.kind can be set to one of the following.

• User: Samsung Cloud Platform is connected to individual users.
• Group: Connected to the Samsung Cloud Platform IAM user group.

The subjects.name of a role binding/cluster role binding can be specified as follows. If the user is a User: individual Samsung Cloud Platform username (e.g., jane.doe) For a group: Samsung Cloud Platform IAM user group name (e.g., ReadPodsGroup)

In this way, the IAM user group is linked to the group defined in the RoleBinding (or ClusterRoleBinding) of the Kubernetes Engine cluster. It is also granted permission to perform the API actions included in the Role (or ClusterRole) associated with the group.

Example) role binding read-pods #1

The example of writing User (individual Samsung Cloud Platform user) in a role binding is as follows.

# This role binding allows the user "jane.doe" to view pods in the "default" namespace.
# The namespace must have a role named "pod-reader".
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
roleRef:
  # The "roleRef" specifies the link to a Role or ClusterRole.
  kind: Role       # Must be Role or ClusterRole.
  name: pod-reader # Must match the name of the Role or ClusterRole you want to bind to.
  apiGroup: rbac.authorization.k8s.io
subjects:
# You can specify one or more "target (subject)".
- kind: User
  name: jane.doe
  apiGroup: rbac.authorization.k8s.io

# This role binding allows the user "jane.doe" to view pods in the "default" namespace.
# The namespace must have a role named "pod-reader".
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
roleRef:
  # The "roleRef" specifies the link to a Role or ClusterRole.
  kind: Role       # Must be Role or ClusterRole.
  name: pod-reader # Must match the name of the Role or ClusterRole you want to bind to.
  apiGroup: rbac.authorization.k8s.io
subjects:
# You can specify one or more "target (subject)".
- kind: User
  name: jane.doe
  apiGroup: rbac.authorization.k8s.io

When a role binding like the above is created in the cluster, a user whose username is jane.doe is granted permission to perform the API actions defined in the pod-reader role.

Example) role binding read-pods #2

The example of creating a group (IAM user group) in role binding is as follows.

# This role binding allows users in the "ReadPodsGroup" group to view pods in the "default" namespace.
# The namespace must have a role called "pod-reader".
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
# You can specify one or more "target (subject)".
- kind: Group
  name: ReadPodsGroup
  apiGroup: rbac.authorization.k8s.io

# This role binding allows users in the "ReadPodsGroup" group to view pods in the "default" namespace.
# The namespace must have a role called "pod-reader".
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
# You can specify one or more "target (subject)".
- kind: Group
  name: ReadPodsGroup
  apiGroup: rbac.authorization.k8s.io

If a role binding like the above is created in the cluster, users in the IAM user group ReadPodsGroup are granted permission to perform the API actions defined in the role pod-reader.

Example) ClusterRoleBinding read-nodes

# This cluster role binding allows users in the "ReadNodesGroup" group to view nodes.
# A cluster role named "node-reader" must exist.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ReadNodesGroup
  apiGroup: rbac.authorization.k8s.io

# This cluster role binding allows users in the "ReadNodesGroup" group to view nodes.
# A cluster role named "node-reader" must exist.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: ReadNodesGroup
  apiGroup: rbac.authorization.k8s.io

When a cluster role binding like the above is created in the cluster, users belonging to the IAM user group ReadNodesGroup are granted permission to perform the API actions defined in the cluster role node-reader.

Predefined roles and role bindings for Samsung Cloud Platform

In the Kubernetes Engine of Samsung Cloud Platform, the cluster role bindings scp-cluster-admin, scp-view, scp-namespace-view, and the cluster role scp-namespace-view are predefined. The table below shows the predefined roles and role bindings for Samsung Cloud Platform and the relationships of Samsung Cloud Platform users. Here, the cluster roles cluster-admin and view are predefined within the Kubernetes cluster. For more details, see role.

• According to the cluster role binding scp-cluster-admin, the Kubernetes Engine service creator is granted cluster admin privileges.
• Users or groups registered in the cluster role binding scp-view are granted cluster viewer permissions. It is bound to the predefined Kubernetes cluster role view, and does not grant access to cluster‑scoped resources (e.g., namespaces, nodes, ingress classes, etc.) or to secrets within a namespace. For more details, see role.
• According to the cluster role binding scp-namespace-view, all users authenticated to the cluster are granted permission to view namespaces.

The details of the predefined roles and role bindings for Samsung Cloud Platform are as follows.

ClusterRoleBinding scp-cluster-admin

Cluster role binding scp-cluster-admin is linked to the cluster role cluster-admin, and is bound to the Samsung Cloud Platform user (Kubernetes Engine cluster creator) according to the subjects field.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
  name: scp-cluster-admin
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User               
  name: jane.doe # cluster creator username
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
  name: scp-cluster-admin
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User               
  name: jane.doe # cluster creator username
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding scp-view

ClusterRoleBinding scp-view is bound to the ClusterRole view, and you can add Samsung Cloud Platform users or IAM user groups to the subjects field.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-view
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-view
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: rbac.authorization.k8s.io

ClusterRole and ClusterRoleBinding scp-namespace-view

The cluster role scp-namespace-view defines view permissions for namespaces. The cluster role binding scp-namespace-view is bound to the cluster role scp-namespace-view, granting namespace read permissions to all authenticated users in the cluster.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scp-namespace-view
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-namespace-view
roleRef:
  kind: ClusterRole
  name: scp-namespace-view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: scp-namespace-view
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: scp-namespace-view
roleRef:
  kind: ClusterRole
  name: scp-namespace-view
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

IAM user group RBAC use case

This chapter explains examples of granting permissions for each major user scenario. The IAM user groups, ClusterRoleBinding/RoleBinding, and ClusterRole names presented here are just examples to aid understanding. Administrators should define and apply appropriate names and permissions as needed.

Cluster Administrator

To create a cluster administrator, follow these steps.

1. Create an IAM user group named ClusterAdminGroup.
2. Create a cluster role binding with the following contents in the target cluster.
   Sample Code Download

   Copy Code

   Color mode

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: cluster-admin-group
   roleRef:
     kind: ClusterRole
     name: cluster-admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: ClusterAdminGroup
     apiGroup: rbac.authorization.k8s.io

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: cluster-admin-group
   roleRef:
     kind: ClusterRole
     name: cluster-admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: ClusterAdminGroup
     apiGroup: rbac.authorization.k8s.io

• It is linked with cluster-admin of the base cluster, granting administrator privileges for that cluster.

Cluster Editor

To create a cluster editor, follow these steps.

1. Create an IAM user group named ClusterEditGroup.
2. Create a ClusterRoleBinding with the following specifications in the target cluster.
   Sample Code Download

   Copy Code

   Color mode

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: cluster-edit-group
   roleRef:
     kind: ClusterRole
     name: edit
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: ClusterEditGroup
     apiGroup: rbac.authorization.k8s.io

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: cluster-edit-group
   roleRef:
     kind: ClusterRole
     name: edit
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: ClusterEditGroup
     apiGroup: rbac.authorization.k8s.io

• It is linked with the edit role of the base cluster, granting editor permissions for that cluster.

Cluster Viewer

To create a cluster viewer, follow these steps.

1. Create an IAM user group named ClusterViewGroup.
2. Create a ClusterRoleBinding with the following specifications in the target cluster.
   Sample Code Download

   Copy Code

   Color mode

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: cluster-view-group
   roleRef:
     kind: ClusterRole
     name: view
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: ClusterViewGroup
     apiGroup: rbac.authorization.k8s.io

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: cluster-view-group
   roleRef:
     kind: ClusterRole
     name: view
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: ClusterViewGroup
     apiGroup: rbac.authorization.k8s.io

• It is associated with the view role of the default cluster, granting viewer permissions for that cluster.

Namespace Administrator

To create a namespace manager, follow these steps.

1. Create an IAM user group named NamespaceAdminGroup.
2. Create a RoleBinding with the following contents in the target cluster.
   Sample Code Download

   Copy Code

   Color mode

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: namespace-admin-group
     namespace: <namespace_name>
   roleRef:
     kind: ClusterRole
     name: admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: NamespaceAdminGroup
     apiGroup: rbac.authorization.k8s.io

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: namespace-admin-group
     namespace: <namespace_name>
   roleRef:
     kind: ClusterRole
     name: admin
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: NamespaceAdminGroup
     apiGroup: rbac.authorization.k8s.io

• It is linked with the admin role of the default cluster, granting administrator privileges for the namespace.

Namespace Editor

To create a namespace editor, follow these steps.

1. Create an IAM user group named NamespaceEditGroup.
2. Create a RoleBinding with the following specifications in the target cluster.
   Sample Code Download

   Copy Code

   Color mode

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: namespace-edit-group
     namespace: <namespace_name>
   roleRef:
     kind: ClusterRole
     name: edit
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: NamespaceEditGroup
     apiGroup: rbac.authorization.k8s.io

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: namespace-edit-group
     namespace: <namespace_name>
   roleRef:
     kind: ClusterRole
     name: edit
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: NamespaceEditGroup
     apiGroup: rbac.authorization.k8s.io

• It is linked with the default cluster role edit, granting editor permissions for the namespace.

Namespace Viewer

To create a namespace viewer, follow these steps.

1. Create an IAM user group named NamespaceViewGroup.
2. Create a RoleBinding with the following contents in the target cluster.
   Sample Code Download

   Copy Code

   Color mode

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: namespace-view-group
     namespace: <namespace_name>
   roleRef:
     kind: ClusterRole
     name: view
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: NamespaceViewGroup
     apiGroup: rbac.authorization.k8s.io

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: namespace-view-group
     namespace: <namespace_name>
   roleRef:
     kind: ClusterRole
     name: view
     apiGroup: rbac.authorization.k8s.io
   subjects:
   - kind: Group
     name: NamespaceViewGroup
     apiGroup: rbac.authorization.k8s.io

• It is associated with the default cluster role view, granting viewer permissions for the namespace.

3 - Using type LoadBalancer service

Service Configuration Method

By creating and applying a Service manifest file (example: my-lb-svc.yaml ), you can set up a Service of type LoadBalancer.

To create and apply a type LoadBalancer Service, follow the steps below.

1. Create the Service manifest file my-lb-svc.yaml .

   • Tab 0

   Sample Code Download

   Copy Code

   Color mode

   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
   spec:
     selector:
       app.kubernetes.io/name: MyApp
     ports:
       - protocol: TCP
         port: 80
         targetPort: 9376
         appProtocol: tcp # Refer to the LB service protocol type setting section
     type: LoadBalancer

   apiVersion: v1
   kind: Service
   metadata:
     name: my-service
   spec:
     selector:
       app.kubernetes.io/name: MyApp
     ports:
       - protocol: TCP
         port: 80
         targetPort: 9376
         appProtocol: tcp # Refer to the LB service protocol type setting section
     type: LoadBalancer

2. Deploy the Service manifest using the kubectl apply command.

   • Tab 0

   Sample Code Download

   Copy Code

   Color mode

   kubectl apply -f my-lb-svc.yaml

   kubectl apply -f my-lb-svc.yaml

3. kubectl get service command is used to verify the Load Balancer configuration.
   • Tab 0

   Sample Code Download

   Copy Code

   Color mode

   # kubectl get service my-lb-svc
   NAMESPACE     NAME         TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)         AGE
   default       my-lb-svc    LoadBalancer   172.20.49.206    123.123.123.123   80:32068/TCP    3m

   # kubectl get service my-lb-svc
   NAMESPACE     NAME         TYPE           CLUSTER-IP       EXTERNAL-IP       PORT(S)         AGE
   default       my-lb-svc    LoadBalancer   172.20.49.206    123.123.123.123   80:32068/TCP    3m

Protocol type

You can create a Service manifest and use it. The following is a simple example.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    ...
  ports:
    - port: 80
      targetPort: 9376
      protocol: TCP    # required (choose one of TCP, UDP)
      appProtocol: tcp # optional (leave blank or select one of tcp, http, https)
  type: LoadBalancer   # type LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    ...
  ports:
    - port: 80
      targetPort: 9376
      protocol: TCP    # required (choose one of TCP, UDP)
      appProtocol: tcp # optional (leave blank or select one of tcp, http, https)
  type: LoadBalancer   # type LoadBalancer

The list of protocols (protocol and appProtocol) supported by the Load Balancer Service type in Kubernetes Engine, along with the corresponding settings applied to the Load Balancer service, is as follows.

• According to the k8s Service manifest spec, you can specify multiple ports for a single service.

L4 Service Manifest Writing Example

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

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

L7 Service Manifest Example

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-layer-type: "L7" # required
    service.beta.kubernetes.io/scp-load-balancer-client-cert-id: "24da35de187b450eb0cf09fb6fa146de" # required
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - appProtocol: http # required
      protocol: TCP
      port: 80
      targetPort: 9376
    - appProtocol: https # required
      protocol: TCP
      port: 443
      targetPort: 9898
  type: LoadBalancer
  

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-layer-type: "L7" # required
    service.beta.kubernetes.io/scp-load-balancer-client-cert-id: "24da35de187b450eb0cf09fb6fa146de" # required
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - appProtocol: http # required
      protocol: TCP
      port: 80
      targetPort: 9376
    - appProtocol: https # required
      protocol: TCP
      port: 443
      targetPort: 9898
  type: LoadBalancer
  

Annotation detailed settings

You can add annotations to the service manifest to configure detailed features.

apiVersion: v1
kind: Service
metatdata:
  name: my-lb-svc
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-public-ip-enabled: "true"
    service.beta.kubernetes.io/scp-load-balancer-health-check-interval: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-timeout: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-count: "3"
    service.beta.kubernetes.io/scp-load-balancer-session-duration-time: "300"
  spec:
  type: LoadBalancer
  ...
  

apiVersion: v1
kind: Service
metatdata:
  name: my-lb-svc
  annotations:
    service.beta.kubernetes.io/scp-load-balancer-public-ip-enabled: "true"
    service.beta.kubernetes.io/scp-load-balancer-health-check-interval: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-timeout: "5"
    service.beta.kubernetes.io/scp-load-balancer-health-check-count: "3"
    service.beta.kubernetes.io/scp-load-balancer-session-duration-time: "300"
  spec:
  type: LoadBalancer
  ...
  

Below is a description of all annotations available for a type LoadBalancer service.

Constraints

The constraints to consider when using Kubernetes annotations are as follows.

4 - Usage Considerations

Managed Port Constraints

The following ports are used for SKE management and cannot be used for service access. Additionally, if they are blocked by the OS firewall or similar, node functions or some features may not operate correctly.

kube-reserved resource constraints

kube-reserved is a feature that reserves resources for system daemons that do not run as pods on a node.

• System daemons that do not run as pods include kubelet, container runtime, etc.

Kubernetes Engine reserves CPU and memory based on the following criteria.

• Example: For a Virtual Server with 16 vCPU cores and 32 GB memory, kube-reserved is calculated as follows.

  • CPU: (1 core × 0.06) + (1 core × 0.01) + (2 core × 0.005) + (12 core × 0.0025) = 0.11 core
  • Memory: (4 GB × 0.25) + (4 GB × 0.2) + (8 GB × 0.1) + (16 GB × 0.06) = 3.56 GB

• Example: The resources reserved based on CPU size are as follows.

• Example: The resources reserved based on memory size are as follows.

5 - Version information

Kubernetes version and support period

Kubernetes version lifecycle

The Kubernetes open-source software (OSS) community releases minor versions three times a year, with a release cycle of approximately 15 weeks. A released minor version goes through a support period of about 14 months (12 months for standard patches, 2 months for maintenance) before reaching EOL (End of Life).

Samsung Cloud Platform Kubernetes Engine (SKE) version release plan

SKE validates and supplies the stable patch versions among released OSS minor versions. Therefore, the release timing of the version provided by SKE differs from that of the corresponding OSS version.

Also, for previously released versions, considering factors such as the open‑source EOL timing, technical support will be terminated sequentially from the older versions (End of Tech support, EoTS).

The release schedule and end-of-life schedule for OSS and SKE are as follows.

Feature restrictions when technical support ends (EoTS)

If the Kubernetes version provided by SKE reaches end-of-technical-support (EoTS) status, the features supported in that version may be limited.

• Create new cluster → Creation not allowed
• Existing cluster upgrade → upgrade possible (upgrade is possible even if the newer version is EoTS)
• Create node pool from existing cluster → possible

OS and GPU drivers

The OS and GPU driver version information available for each K8s server type is as follows.

The OS versions and supported GPU server models for each GPU driver version are as follows.