Service
Does ZopNight manage Service?
Services of type ClusterIP are free routing records, but every LoadBalancer Service provisions a cloud load balancer with its own hourly bill. ZopNight stores the type as instance type, marks LoadBalancers without an ingress hostname pending, keeps that hostname as a join key to the cloud LB resource, and advises on exposure via RC-1721 and RC-1722.
Rules that fire on Service
A Service gives a set of pods a stable virtual IP and DNS name. Two of its types are free routing records; the third quietly provisions a cloud load balancer with an hourly bill of its own, which is why the type field is stored as the resource’s instance type.
Three types, one of them billable
ClusterIP routes inside the cluster and costs nothing. NodePort opens a static port on every node. LoadBalancer asks the cloud for a real load balancer. A LoadBalancer Service that has not yet received an ingress hostname is marked pending, the state that distinguishes a provisioning failure from a working frontend. Discovery also captures ports, the cluster IP, and any manually assigned externalIPs, each surfaced for the rules that read them.
The hostname that joins cluster config to the LB invoice
For working LoadBalancer Services, the load balancer’s ingress hostname is recorded because it doubles as a join key: it matches the DNS name on the cloud provider’s own load-balancer resource. That equality is how an orphaned load balancer (one with no healthy targets, fronting an abandoned cluster) gets connected back to the Service that created it and priced instead of merely noticed.
Exposure advisories with a dev/test mute
Two security advisories watch the type field. Service Type LoadBalancer (RC-1721 / RC-1821 / RC-1921, low severity) and Service Type NodePort (RC-1722 family, medium) both advise consolidating behind ClusterIP plus an Ingress controller, which centralizes TLS and access control and, for LoadBalancers, collapses N hourly bills into 1. Both rules read environment hints from the Service’s labels, since the discoverer never populates cloud tags for Services, and stay quiet for dev/test-labelled Services unless a production tag contradicts the name.
kubectl get services -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,TYPE:.spec.type,CLUSTER-IP:.spec.clusterIP,EXTERNAL:.status.loadBalancer.ingress[0].hostnameCounting the LoadBalancers is the audit
Most clusters need far fewer external entry points than they have. Listing Services by type and counting the LoadBalancer rows against the Ingresses that could replace them is a 10-minute review that regularly retires several always-on cloud load balancers.