Źródło obrazu przy tworzeniu Poda. Docker Hub

Aby utworzyć nowy zasób w Kubernetes, konieczny jest plik YAML zawierający jego definicję. Przykładowy plik YAML definiujący prosty Pod, może wyglądać tak:

Gdy tworzysz nowy Pod, obraz aplikacji, który ma być uruchomiony, jest określony przez atrybut spec.containers[].image w manifeście Pod. Jest to część konfiguracji, która zawiera informacje o kontenerze, w tym obrazie, który ma być użyty do uruchomienia kontenera. Aby wybrać odpowiedni obraz aplikacji, należy podać pełną ścieżkę do obrazu w rejestrze kontenerów, na przykład:

apiVersion: v1
kind: Pod
metadata:
      name: my-pod
spec:
      containers:
      - name: mycontainer
        image: username/repository:tag

W powyższym przykładzie username/repository:tag to nazwa obrazu w rejestrze kontenerów. Może to być obraz z oficjalnego repozytorium, repozytorium prywatnego lub innego rejestr kontenerów, który jest dostępny dla twojego klastra Kubernetes. Podczas tworzenia Pod możesz więc określić, skąd ma zostać pobrany obraz aplikacji, a Kubernetes będzie używał tych informacji do pobrania i uruchomienia odpowiedniego kontenera z tym obrazem.

Przykładowe obrazy aplikacji

Obrazy używane do tworzenia Podów mogą być pobierane z różnych źródeł, takich jak publiczne i prywatne rejestry obrazów. Oto kilka przykładów popularnych obrazów oraz przykładowe sposoby ich definicji w plikach YAML:

WordPress - nazwa obrazu: wordpress, pobierany z: Publiczny rejestr Docker Hub, definicja w pliku YAML:

apiVersion: v1
kind: Pod
metadata:
      name: wordpress-pod
spec:
      containers:
      - name: wordpress
        image: wordpress
        ports:
      - containerPort: 80

Nginx - nazwa obrazu: nginx, pobierany z: Publiczny rejestr Docker Hub, definicja w pliku YAML:

apiVersion: v1
kind: Pod
metadata:
      name: nginx-pod
spec:
      containers:
      - name: nginx
        image: nginx
        ports:
      - containerPort: 80

Apache HTTP Server - nazwa obrazu: httpd, pobierany z: Publiczny rejestr Docker Hub, definicja w pliku YAML:

apiVersion: v1
kind: Pod
metadata:
      name: apache-pod
spec:
      containers:
      - name: apache
        image: httpd
        ports:
      - containerPort: 80

Prometheus - nazwa obrazu: prom/prometheus, pobierany z: Publiczny rejestr Docker Hub, definicja w pliku YAML:

apiVersion: v1
kind: Pod
metadata:
      name: prometheus-pod
spec:
      containers:
      - name: prometheus
        image: prom/prometheus
        ports:
      - containerPort: 9090

Grafana - nazwa obrazu: grafana/grafana, pobierany z: Publiczny rejestr Docker Hub, definicja w pliku YAML:

apiVersion: v1
kind: Pod
metadata:
      name: grafana-pod
spec:
      containers:
      - name: grafana
        image: grafana/grafana
        ports:
      - containerPort: 3000

Memcached - nazwa obrazu: memcached, pobierany z: Publiczny rejestr Docker Hub, definicja w pliku YAML:

apiVersion: v1
kind: Pod
metadata:
      name: memcached-pod
spec:
      containers:
      - name: memcached
        image: memcached
        ports:
      - containerPort: 11211

W każdym z tych przypadków, a także w przypadku innych obrazów, należy pamiętać o odpowiednim dostępie do obrazu (jeśli jest prywatny), takim jak użycie tajnych kluczy uwierzytelniających lub certyfikatów w przypadku repozytoriów prywatnych (Sprawdź: Chroniony dostęp do obrazów Kubernetes w repozytoriach prywatnych).

Oficjalne repozytorium Docker Hub

Istnieje wiele obrazów, które ze względu na swoją popularność, są dostępne i automatycznie wyszukiwane w oficjalnym repozytorium Docker Hub. Na przykład, gdy podajesz nazwę obrazu w formacie image: nginx, Kubernetes automatycznie użyje obrazu z oficjalnego repozytorium dla Nginx. W takim przypadku nie musisz podawać pełnej ścieżki do obrazu w rejestrze kontenerów, ponieważ Kubernetes domyślnie przeszuka znane mu repozytoria w celu odnalezienia pasującego obrazu. Gdy go znajdzie, pobierze go i użyje do uruchomienia kontenera. Używanie nazw obrazów bez pełnej ścieżki jest wygodne, szczególnie gdy dotyczy popularnych obrazów, takich jak te z oficjalnego repozytorium Docker Hub np. nginx.

Table of Contents