<li>Zrozumieć, jak obiekty Label i LabelSelector są powiązane z Serwisem</li>
<li>Udostępnić aplikację na zewnątrz klastra Kubernetes korzystając z Serwisu</li>
</ul>
</div>
<divclass="col-md-8">
<h3>Kubernetes Services - przegląd</h3>
<p><ahref="/docs/concepts/workloads/pods/pod-overview/">Pody</a> Kubernetes są nietrwałe. Pody mają swój <ahref="/docs/concepts/workloads/pods/pod-lifecycle/">cykl życia</a>. Jeśli węzeł roboczy ulegnie awarii, tracone są wszystkie pody działające na węźle. <ahref="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> będzie próbował automatycznie doprowadzić klaster z powrotem do pożądanego stanu tworząc nowe pody i w ten sposób zapewnić działanie aplikacji. Innym przykładem może być system na back-endzie przetwarzania obrazów posiadający 3 repliki. Każda z tych replik jest wymienna - system front-endu nie powinien musieć pilnować replik back-endu ani tego, czy któryś z podów przestał działać i został odtworzony na nowo. Nie należy jednak zapominać o tym, że każdy Pod w klastrze Kubernetes ma swój unikatowy adres IP, nawet pody w obrębie tego samego węzła, zatem powinna istnieć metoda automatycznego uzgadniania zmian pomiędzy podami, aby aplikacja mogła dalej funkcjonować.</p>
<p>Serwis w Kubernetes jest abstrakcyjnym obiektem, która definiuje logiczny zbiór podów oraz politykę dostępu do nich. Serwisy pozwalają na swobodne łączenie zależnych podów. Serwis jest zdefiniowany w YAMLu <ahref="/docs/concepts/configuration/overview/#general-configuration-tips">(zalecane)</a> lub w JSONie - tak, jak wszystkie obiekty Kubernetes. Zbiór podów, które obsługuje Serwis, jest zazwyczaj określany przez <i>LabelSelector</i> (poniżej opisane jest, w jakich przypadkach możesz potrzebować zdefiniować Serwis bez specyfikowania <code>selektora</code>).</p>
<p>Mimo, że każdy pod ma swój unikatowy adres IP, te adresy nie są dostępne poza klastrem, o ile nie zostaną wystawione za pomocą Serwisu. Serwis umożliwia aplikacji przyjmować ruch przychodzący. Serwisy mogą być wystawiane na zewnątrz na kilka różnych sposobów, poprzez określenie <code>typu</code> w ServiceSpec:</p>
<ul>
<li><i>ClusterIP</i> (domyślnie) - Wystawia serwis poprzez wewnętrzny adres IP w klastrze. W ten sposób serwis jest dostępny tylko wewnątrz klastra.</li>
<li><i>NodePort</i> - Wystawia serwis na tym samym porcie na każdym z wybranych węzłów klastra przy pomocy NAT. W ten sposób serwis jest dostępny z zewnątrz klastra poprzez <code><NodeIP>:<NodePort></code>. Nadzbiór ClusterIP.</li>
<li><i>LoadBalancer</i> - Tworzy zewnętrzny load balancer u bieżącego dostawcy usług chmurowych (o ile jest taka możliwość) i przypisuje serwisowi stały, zewnętrzny adres IP. Nadzbiór NodePort.</li>
<li><i>ExternalName</i> - Wystawia Service przy pomocy wybranej nazwy (wyspecyfikowanej jako <code>externalName</code>) poprzez zwracanie wartości rekordu CNAME przypisanego w usłudze DNS. W tym przypadku nie jest wykorzystywany proces przekierowania ruchu metodą proxy. Ten typ wymaga wersji v1.7 lub wyższej usługi <code>kube-dns</code>.</li>
</ul>
<p>Więcej informacji na temat różnych typów serwisów znajduje się w samouczku <ahref="/docs/tutorials/services/source-ip/">Używanie adresu źródłowego (Source IP)</a>. Warto też zapoznać się z <ahref="/docs/concepts/services-networking/connect-applications-service">Łączeniem Aplikacji z Serwisami</a>.</p>
<p>W pewnych przypadkach w serwisie nie specyfikuje się <code>selector</code>. Serwis, który został stworzony bez pola <code>selector</code>, nie utworzy odpowiedniego obiektu Endpoints. W ten sposób użytkownik ma możliwość ręcznego przyporządkowania serwisu do konkretnych endpoints. Inny przypadek, kiedy nie używa się selektora, ma miejsce, kiedy stosujemy <code>type: ExternalName</code>.</p>
</div>
<divclass="col-md-4">
<divclass="content__box content__box_lined">
<h3>Podsumowanie</h3>
<ul>
<li>Otwarcie Poda na ruch z zewnątrz</li>
<li>Rozkładanie ruchu pomiędzy poszczególne Pody</li>
<li>Używanie etykiet</li>
</ul>
</div>
<divclass="content__box content__box_fill">
<p><i>Serwis Kubernetes to warstwa abstrakcji, która definiuje logiczny zbiór Podów i umożliwia kierowanie ruchu przychodzącego do Podów, jego równoważenie oraz service discovery.</i></p>
<p>Serwis kieruje przychodzący ruch do grupy Podów. Serwisy są obiektami abstrakcyjnymi, dzięki którym pody mogą się psuć i być zastępowane przez Kubernetes nowymi bez ujemnego wpływu na działanie twoich aplikacji. Detekcją nowych podów i kierowaniem ruchu pomiędzy zależnymi podami (takimi, jak składowe front-end i back-end w aplikacji) zajmują się Serwisy Kubernetes.</p>
<p>Serwis znajduje zestaw odpowiednich Podów przy pomocy <ahref="/docs/concepts/overview/working-with-objects/labels">etykiet i selektorów</a>, podstawowych jednostek grupujących, które umożliwiają operacje logiczne na obiektach Kubernetes. Etykiety to pary klucz/wartość przypisane do obiektów. Mogą być używane na różne sposoby:</p>
<ul>
<li>Dzielić obiekty na deweloperskie, testowe i produkcyjne</li>
<p>Obiekty mogą być oznaczane etykietami w momencie tworzenia lub później. Etykiety mogą być zmienianie w dowolnej chwili. Udostępnijmy teraz naszą aplikację przy użyciu Serwisu i oznaczmy ją odpowiednimi etykietami.</p>
