mirror of
https://github.com/pgsty/minio.git
synced 2026-08-10 00:03:29 +03:00
Feng Ruohang
e071bb77e4
helm/minio becomes helm/silo: chart name silo, version 6.0.0 -> 7.0.0, the MinIO wordmark icon replaced with the project's own, image.repository and mcImage.repository pointing at pgsty/silo, and the container command changed to silo. User-visible titles, comments and documentation links are rebranded. The MINIO_* environment variables and every existing values key are kept - the first Silo chart is a rename, not a values-schema migration. The hard problem is that a chart rename normally rewrites Kubernetes resource identity, and a StatefulSet's selector and volumeClaimTemplate are immutable. An existing release upgraded carelessly would either fail or orphan its PVCs. Two things address that: - Templates no longer derive the container name from .Chart.Name. It comes from a helper, so nameOverride can pin it, which means an existing release can be upgraded with nameOverride=minio, fullnameOverride=<existing-fullname> and serviceAccount.name=minio-sa and render byte-stable identity while switching chart and image. - helm-migration-guard and verify-helm-migration.sh make that a gate rather than a documented hope. The script lints the chart, renders it in distributed and standalone modes plus the optional templates, then renders the legacy chart from a pinned commit and the new chart with those three overrides and compares resource identity. The guard additionally rejects any rendered container still pulling pgsty/minio or invoking /usr/bin/minio. It runs through a pinned alpine/helm image when helm is not installed locally, so the gate does not depend on the developer's machine. Currently green over 7 compared resources. Rollback is asymmetric and the README says so: the old chart with the new image survives via the entrypoint argv shim, but the new chart with an old MinIO image does not, because `silo server` is not a command that binary knows. Only `helm rollback` is supported, never an image-only downgrade. Not addressed here: the default image tag is pgsty/silo:RELEASE.2026-08-04T00-00-00Z, which does not exist yet. The chart must not be published until the first Silo image is pushed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
44 lines
2.6 KiB
Plaintext
44 lines
2.6 KiB
Plaintext
{{- if eq .Values.service.type "ClusterIP" "NodePort" }}
|
|
Silo can be accessed via port {{ .Values.service.port }} on the following DNS name from within your cluster:
|
|
{{ template "silo.fullname" . }}.{{ .Release.Namespace }}.{{ .Values.clusterDomain }}
|
|
|
|
To access Silo from localhost, run the below commands:
|
|
|
|
1. export POD_NAME=$(kubectl get pods --namespace {{ .Release.Namespace }} -l "release={{ .Release.Name }}" -o jsonpath="{.items[0].metadata.name}")
|
|
|
|
2. kubectl port-forward $POD_NAME 9000 --namespace {{ .Release.Namespace }}
|
|
|
|
Read more about port forwarding here: http://kubernetes.io/docs/user-guide/kubectl/kubectl_port-forward/
|
|
|
|
You can now access Silo server on http://localhost:9000. Follow the below steps to connect to Silo server with mc client:
|
|
|
|
1. Download the Silo mc client - https://silo.pgsty.com/reference/minio-mc/#quickstart
|
|
|
|
2. export MC_HOST_{{ template "silo.fullname" . }}_local=http://$(kubectl get secret --namespace {{ .Release.Namespace }} {{ template "silo.secretName" . }} -o jsonpath="{.data.rootUser}" | base64 --decode):$(kubectl get secret --namespace {{ .Release.Namespace }} {{ template "silo.secretName" . }} -o jsonpath="{.data.rootPassword}" | base64 --decode)@localhost:{{ .Values.service.port }}
|
|
|
|
3. mc ls {{ template "silo.fullname" . }}_local
|
|
|
|
{{- end }}
|
|
{{- if eq .Values.service.type "LoadBalancer" }}
|
|
Silo can be accessed via port {{ .Values.service.port }} on an external IP address. Get the service external IP address by:
|
|
kubectl get svc --namespace {{ .Release.Namespace }} -l app={{ template "silo.fullname" . }}
|
|
|
|
Note that the public IP may take a couple of minutes to be available.
|
|
|
|
You can now access Silo server on http://<External-IP>:9000. Follow the below steps to connect to Silo server with mc client:
|
|
|
|
1. Download the Silo mc client - https://silo.pgsty.com/reference/minio-mc/#quickstart
|
|
|
|
2. export MC_HOST_{{ template "silo.fullname" . }}_local=http://$(kubectl get secret {{ template "silo.secretName" . }} --namespace {{ .Release.Namespace }} -o jsonpath="{.data.rootUser}" | base64 --decode):$(kubectl get secret {{ template "silo.secretName" . }} -o jsonpath="{.data.rootPassword}" | base64 --decode)@<External-IP>:{{ .Values.service.port }}
|
|
|
|
3. mc ls {{ template "silo.fullname" . }}
|
|
|
|
Alternately, use a browser, an S3 SDK, or a MinIO-compatible SDK to access Silo - https://silo.pgsty.com/reference/minio-server/minio-server/
|
|
{{- end }}
|
|
|
|
{{ if and (.Values.networkPolicy.enabled) (not .Values.networkPolicy.allowExternal) }}
|
|
Note: Since NetworkPolicy is enabled, only pods with label
|
|
{{ template "silo.fullname" . }}-client=true"
|
|
will be able to connect to this Silo cluster.
|
|
{{- end }}
|