Website settings and status

Administrators use a namespaced Kubernetes Website resource to manage a site. Its API version is cms.tlspu.com/v1alpha1. The operator maintains site workloads, services, ingress and storage claims from these settings. Start with the installation procedure for a complete manifest and ordered setup steps.

1. Custom Resource

Choose a short metadata.name beginning with a letter. Generated resource names must fit Kubernetes Service naming limits, including their suffixes. Names containing dots map to hyphens; avoid two names that produce the same base.

Setting under `spec`	Meaning and default
`domain`	Required primary public hostname.
`description`	Optional display name for automatic Ipseity client setup.
`aliases`	Additional public hostnames. A dot-less alias such as `www` expands beneath the primary domain; an unrelated dotted hostname is absolute.
`cms.enabled`	Set `false` for a frontend-only site; omit CMS hostname/authentication in that case.
`cms.hostname`	Separate CMS hostname, defaulting to `cms.<domain>` when enabled.
`cms.authentication.secretRef.name`	Same-namespace Secret containing OAuth2/OIDC settings. An explicit reference takes precedence over automatic Ipseity setup.
`storage.published.size`	Published storage request, default `5Gi`.
`storage.published.storageClassName`	RWX storage class; omission uses the cluster default.
`storage.private.size`	Private editable storage request, default `2Gi`.
`storage.private.storageClassName`	RWX storage class; omission uses the cluster default.
`publishing.retainReleases`	Number of historical releases to retain after cleanup grace, default `0`.
`frontend.replicas`	Public frontend replicas, default `2` when omitted; explicit `0` scales public serving to zero.
`ingress.className`	Ingress controller class for public and CMS routing.
`ingress.tls`	Include TLS configuration on both Ingresses, default `true`.
`ingress.issuer`	Optional namespaced cert-manager Issuer name.
`ingress.cluster_issuer`	Optional cluster-scoped cert-manager ClusterIssuer name; choose this or `issuer`.

For aliases beneath your primary domain, use www for www.example.com rather than the dotted spelling. Use individual hostnames and avoid duplicates. The CMS hostname must differ from every public hostname; cms.example.com and example.com are valid separate origins.

Register DNS records with your DNS provider. Supply TLS certificate Secrets or configure cert-manager and a working issuer. The CMS requires HTTPS for production sign-in and secure cookies, including when TLS terminates outside the Ingress.

Authentication Secret

Follow authentication for the complete Secret keys and examples. Supply a client ID, the appropriate provider endpoints, a random session key of at least 32 bytes and any required client secret. Configure allowedRoles to restrict editing access and publishRoles for an additional publish/rollback gate. Empty role gates admit any otherwise authenticated user.

With automatic Ipseity setup, review the provider selection and initial administrator before creating the Website. Websites in a namespace share its Ipseity realm. Without automatic identity, request a CMS with an explicit authentication Secret. For frontend-only sites, supply published content through your own process.

Retention and replicas

Keep one CMS replica with Recreate updates. Scale public frontend replicas with frontend.replicas. Set publishing.retainReleases to at least 1 if publishers need rollback history. Retention keeps the active release plus the configured number of other releases after a short safety grace period. Arrange storage backups separately for editable-source recovery.

2. Resource naming

For a Website named example, look for these resources in its namespace:

Resource	Name
Frontend Deployment, Service and ServiceAccount	`example-frontend`
Public Ingress / TLS Secret	`example-public` / `example-public-tls`
CMS Deployment, Service, ServiceAccount and Ingress	`example-cms`
CMS TLS Secret	`example-cms-tls`
CMS status Role and RoleBinding	`example-cms-status`
Published / private PVC	`example-published` / `example-private`

Changing the domain preserves existing resource and volume names. Deleting a Website retains its PVCs; deleting a PVC separately can delete the backing volume according to its reclaim policy. Explicit authentication Secrets remain user-owned. Review Ipseity retention for automatically provisioned identities.

3. Container images

Set the controller image and its --frontend-image and --cms-image arguments to compatible versions. The controller reconciles the two workload images onto existing sites as well as new ones. Use immutable image digests or release tags, and follow the upgrade procedure before changing a shared controller. The CMS image includes the browser editor.

4. Ports and endpoints

Component	Default port	Purpose
Frontend	8080	Public website.
Frontend	8081	Internal health, readiness and metrics.
CMS	8080	Sign-in, authenticated editor and API.
CMS	8081	Internal health, readiness and metrics.
Controller	8080	Internal health, readiness and metrics.

Keep administrative endpoints within the trusted network. Use monitoring to inspect /healthz, /readyz and /metrics. Each HTTP listener identifies itself with Server: Viking <Component> <version>, including redirects and errors. Preserve that header through ingress and reverse proxies.

5. Website status

Inspect status with kubectl get website NAME -n NAMESPACE -o yaml. status.observedGeneration identifies the processed specification generation; status.currentRelease records the six-digit published release number.

Condition	Meaning when true
`StorageReady`	Both PVCs are Bound.
`FrontendReady`	The frontend Deployment reports available replicas.
`CMSReady`	The enabled CMS is available, or intentionally unconfigured.
`Published`	Published storage is Bound, frontend is available and a valid current-release ID is recorded.
`Ready`	Storage, frontend, required CMS and publication checks pass.

A new site normally needs its first publication before overall readiness. Open the CMS and create a homepage before waiting for public readiness. Status updates can follow publication asynchronously; verify the public site too. Conditions describe component checks. Test DNS, certificates and representative pages when handing a site over. Use troubleshooting for condition reasons, authentication failures or stale content.