kubectl apply does not allow more than 63 chars on metadata.labels values
Asked Answered
G

3

6

I'm trying to create a LoadBalancer in my OKE cluster(Oracle Cloud Container Engine for Kubernetes). I'm doing a kubectl apply -f on the file, but it gives me this error.

The Service "servicename" is invalid: metadata.labels: Invalid value: "ocid1.vcn.oc1.iad.xx...xx": must be no more than 63 characters.

Here's the yaml file

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa...xxxxx"
spec:
  type: LoadBalancer
  ports:
  - port: 8100
  selector:
    app: nginx

I see the issue is because the value for service.beta.kubernetes.io/oci-load-balancer-subnet1: is more than 63 chars. But I can't change the value of the OCID. Is there a fix for this?

Gizela answered 1/4, 2020 at 12:2 Comment(3)
Your error message refers to metadata.labels, did you by any chance put the OCID under labels and not annotations?Brannon
no, @Brannon It is as shown in the question. Not sure why it shows metadata.labelsGizela
I can apply your service.yaml to a fresh OKE v1.15.7 cluster with an OCID of length 93 without any issues. Which kubectl and OKE version are you on? Might be worth opening a Service Request. Or check if you have another service defined in that file, as the error message doesn't match the service you have.Brannon
H
1

As far as i know there is no solution for that. The names of object in Kubernetes (and your annotation will create an object with the given name) should be DNS RFC complaint which is < 63 chars in the hostname part.

sources :

Hogan answered 1/4, 2020 at 14:8 Comment(0)
S
0

metadata.labels structure has that < 63 values length limit but metadata.annotations struct does not have it. Note that k8s uses metadata.annotation to store the full JSON with last applied configuration at key(kubectl.kubernetes.io/last-applied-configuration) and that almost always exceeds that limit of 63 bytes.

I had this issue when putting OCID values on label values, but NOT when using the annotation values, as you quote.

For example, this will NOT work:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa...xxxxx"
spec:
   ...

But this is expected to work:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    service.beta.kubernetes.io/oci-load-balancer-internal: "true"
    service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1..aaaaaa...xxxxx"
spec:
   ...

So, If you having this problem I do suggest to double check if you are really using the correct structure, as you quote.

https://docs.oracle.com/en-us/iaas/Content/ContEng/Tasks/contengcreatingloadbalancer.htm#Creating2

Sorcim answered 12/12, 2021 at 13:58 Comment(0)
N
0

Try as below inside annotations:

   apiVersion: v1
   metadata:
     name: ingress-nginx
     namespace: ingress-nginx
     labels:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx
     annotations:
       service.beta.kubernetes.io/oci-load-balancer-internal: "true"
       service.beta.kubernetes.io/oci-load-balancer-subnet1: "ocid1.subnet.oc1.iad.xxxxxxxxxxxxxxxxx"
   spec:
     type: LoadBalancer
     selector:
       app.kubernetes.io/name: ingress-nginx
       app.kubernetes.io/part-of: ingress-nginx
     ports:
       - name: http
         port: 80
         targetPort: http
       - name: https
         port: 443
         targetPort: https
Nadia answered 6/1, 2023 at 8:33 Comment(1)
As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.Benedicto

© 2022 - 2025 — McMap. All rights reserved.