pixel
Select Page

NETWAYS Blog

NWS-ID for your Managed Kubernetes!

by | Mar 29, 2023 | , ,

First Cloud, now Kubernetes – the integration of NWS-ID with our portfolio continues! As a next step, we will merge your Managed Kubernetes clusters with NWS-ID. Credit goes to Justin for extending our cluster stack with OpenID-Connect (OIDC), the base for NWS-ID!

How can you use your Kubernetes Cluster with NWS-ID?

All you need is kubelogin, a plugin for kubectl, and a customized kubeconfig, which can be downloaded in the NWS Customer Interface. But: this applies to newly started clusters only. Older installations need some action from you! Let’s go and see, what other scenarios there are!

If you have a cluster running with a Kubernetes v1.23 or greater, just enable NWS-ID in the Customer Interface. This will restart the kube-apiserver with some new parameters which will authenticate your requests against NWS-ID using OpenID-Connect.

For clusters in version v1.22 or less you need to update your cluster at least to v1.23 and enable NWS-ID in the Customer Interface. After your cluster is ready for NWS-ID you need to pimp your kubectl for OpenID-Connect.

kubectl and kubelogin

kubelogin is a plugin for kubectl, which enables authentication via OIDC. It is easily installed with brew, krew, choco or Github Releases as described in the official documentation. After the installation, just download your kubeconfig for NWS-ID from the Customer Interface and start using kubectl as usual!

If you have multiple Managed Kubernetes clusters it is easy to switch the context with kubectl config use-context MyCluster.

Permissions and Roles

If you’re not an admin in your organization, they must authorize your NWS-ID. This happens as usual in the user group management in the Customer Interface. As admin you can grant two different roles to your colleagues. Choose between admin and reader which will be mapped the to corresponding Kubernetes cluster role.

If you need some more detailed help, just have a look into our docs for User and Groups and Permissons.

What are the advantages of integrating our Managed Kubernetes with NWS-ID?

Combining these two services makes your daily work easier, because now you can:

  1. use a single login for the NWS Customer Interface, the Cloud Interface and your Kubernetes clusters
  2. effortless switch between your Managed Kubernetes clusters with a single kubeconfig
  3. use two-factor authentication for your Kubernetes clusters
  4. authorise your colleagues to access your clusters in the NWS-ID group management

What happens to the existing certificate authentication?

The authentication with the X509 client certificate is still available for everybody with the appropriate permissions in your organization.

 

Thanks again to Justin for expanding our Kubernetes stack! If you have any questions along the way, please feel free to contact us – we’re always there to help answer any open questions.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Cloud Services and NWS-ID – It’s a match!

by | Jan 26, 2023 | , ,

We’re starting the new year with a new integration for you! As announced last year, the integration of further products with NWS-ID will continue in 2023! From now on the NWS Cloud Services are integrated with NWS-ID.

What are the advantages of integrating our Cloud Services with NWS-ID?

Combining these two services makes your daily work easier, because now you can:

  1. use a single login for both interfaces (Customer Interface and Cloud Interface)
  2. effortless switch between OpenStack projects, in the Customer Interface, in the Cloud Interface (Horizon) and on the OpenStack CLI
  3. use two-factor authentication for your Cloud Services
  4. authorise your colleagues to access your OpenStack projects in the NWS-ID group management

How can you use the Cloud Interface with NWS-ID?

Select NWS-ID at cloud.netways.de, log in and you’re done – simple as that! If you’re not an admin in your organization, they must authorize your NWS-ID. This happens as usual in the user group management in the customer interface.

How do I use the OpenStack-CLI with NWS ID?

As usual, you need an OpenStack Environment File. You can find a version adapted for NWS-ID under Get Started in your OpenStack project in the Customer Interface or in our NWS Docs.
If you’re a member of several OpenStack projects, you can easily switch between them. Simply source the OpenStack Environment File again to get a selection.
Don’t have the official OpenStack CLI client yet? No problem – you can get help in the NWS Docs!

What happens to the existing login?

The existing login can still be used, e.g. in your scripts or tools like Terraform. The password can be changed as usual on cloud.netways.de or via the OpenStack CLI.

What’s coming next?

For a more effortless access, we will gradually integrate our portfolio with NWS-ID. We are already playing with kubelogin and we are looking for a simple Vault SSH integration to extend the reach of your NWS-ID to your OpenStack Cloud Servers.
The same procedure as last year still applies. Please give us a little time to implement the integrations and we will of course come back to you as soon as possible! If you have any questions along the way, please feel free to contact us – we’re always there to help answer any open questions.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Let me introduce: NWS-ID

by | Dec 1, 2022 | ,

We’re really excite to share an enhancement with you that puts your NWS Customer Interface experience to a whole new level! NWS-ID – our new core for managing your personal identity and access to nws.netways.de! Even if identity management sounds a bit dull to some, NWS-ID enables us to bring some new features to you. But  what are these new features, you wonder? Okay, let’s get right into it and answer some questions, you might have. First:

What is NWS-ID?

NWS-ID is the future home for your personal user profile and a much desired integration to the current customer interface. Here, you can update your password, configure 2FA and edit your profile data, although we rarely save any of it. The introduction of personal accounts allows us to provide new features to the NWS Customer Interface and the associated products – including a user and group management.

User and Group Management

The first and probably biggest thing is the integration of NWS-ID with our Customer Interface at nws.netways.de, which enables us to release user and group management – a feature many customers requested and that we’re now thrilled to provide. It basically allows you to give your team access to your account and products. The role-based approach allows you to easily create user groups with appropriate permissions and invite your colleagues with their own personal NWS-ID. Thanks to fine-grained authorization settings, you decide who can access and manage your projects or even the whole organisation!

Managing multiple organisations at NWS?

No problem with NWS-ID! It’s never been easier. If you are in charge of managing several organisations at NWS you will love NWS-ID. Your user can be associated with multiple organisations and it’s easy to switch between them with a single click! You no longer have to log in again or use multiple browsers.

When will NWS-ID be available?

We will release NWS-ID in two weeks, on December 14th. All existing accounts will be migrated automatically – if you are a current NWS customer, you will receive an e-mail to renew your password on that day. That’s it! From then on, your NWS-ID is active and the user and group management is available! Don’t forget to enable two-factor authentication! It does not only sound easy, it is easy! We can’t wait for you to use and implement NWS-ID into your everyday life and to see and hear, what benefits it brings to you.

What does the future hold?

With NWS-ID as the new core for our identity management, not only you benefit from this enhancement, but also our products, which you’ll be able to access more effortlessly. Our portfolio will be gradually integrated, which simplifies the access to products and projects for your whole team. SSO is the buzzword here. Give us a little time to implement the integrations and we will of course come back to you as soon as possible!

I hope you are looking forward to the new home for your user profile! I am sure that NWS-ID complements our portfolio well and is the base for simple and good authentication and authorisation. If you have any questions along the way, please feel free to contact us – we’re always there to help answer any open questions.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Storage Wars – Using Ceph since Firefly | OSDC 2019

by | Apr 21, 2020 | , , , ,

This entry is part 5 of 6 in the series OSDC 2019 | Recap

YouTube player

 

Achim Ledermüller ist Lead Senior Systems Engineer bei NETWAYS und kennt sich aus in Sachen Storage. 2019 hat er seinen Talk “Storage Wars – Using Ceph since Firefly” auf der Open Source Data Center Conference (OSDC) in Berlin gehalten. Wer den Talk verpasst hat, bekommt nun die Möglichkeit, Achims Vortrag noch einmal zu sehen und zu lesen (siehe weiter unten).

Die OSDC wird 2020 erstmalig unter neuem Namen stackconf veranstaltet. Mit den Veränderungen in der modernen IT hat sich in den vergangenen Jahren zunehmend auch der Fokus der Konferenz verlagert: Von einem hauptsächlich auf statische Infrastrukturen zielenden Ansatz zu einem breiteren Spektrum, das agile Methoden, Continuous Integration, Container-, Hybrid- und Cloud-Lösungen umfasst. Dieser Entwicklung soll mit der Namensänderung der Konferenz Rechnung getragen und das Themenfeld für weitere Innovationen geöffnet werden.

Aufgrund der Bedenken rund am das Coronavirus (COVID-19) wurde die Entscheidung getroffen, die stackconf 2020 als Online-Konferenz stattfinden zu lassen. Das Online-Event findet nun vom 16. bis 18. Juni 2020 statt. Live dabei sein lohnt sich! Jetzt Ticket sichern unter: stackconf.eu/ticket/

Storage Wars – Using Ceph since Firefly

Wenn es um Storage geht, ist die Erwartungshaltung klar definiert. Storage muss immer verfügbar, skalierbar, redundant, katastrophensicher, schnell und vor allem billig sein. Mit dem Unified Storage Ceph kann man zumindest die meisten Erwartungen ohne Abstriche erfüllen. Durch das Prinzip, wie Ceph Daten zerlegt, speichert und repliziert, ist die Verfügbarkeit, Skalierbarkeit und Redundanz gewährleistet und auch eine katastrophensichere Spiegelung eines Clusters ist ohne Probleme möglich.

Neben den angebotenen Features ist aber auch ein reibungsloser unterbrechungsfreier Betrieb wichtig. Während des fast siebenjährigen Betriebs unseres Clusters änderten sich fast alle Komponenten. Betriebsysteme, Kernel und Init-Systeme wurden ausgewechselt. Alte Netzwerkkarten wurden durch 10GE- und 40GE-Schnittstellen abgelöst und vervierzigfachten ihren Durchsatz. Layer 2 wird wegen Routing on the Host immer unwichtiger, Festplatten sind plötzlich dank moderner SSDs und NVMe nicht mehr das Bottleneck und natürlich gab es auch immer wieder neue Versionen von Ceph selbst. Zwischen all diesen Neuerungen in den letzten Jahren ist natürlich genügend Platz für kleine und große Katastrophen. Umso wichtiger ist es, dass man von Anfang an ein paar grundlegende Dinge richtig macht:

Limitiere IO-intensive Jobs

Im normalen Betrieb laufen verschiedene Aufgaben im Hintergrund, um einen gesunden Zustand des Clusters zu garantieren. Scrubbing Jobs prüfen die Integrität aller gespeicherten Daten einmal pro Woche, Platten- und andere Hardwarefehler veranlassen Ceph, die Anzahl der Replika automatisch wieder herzustellen und auch das Löschen von Snaphosts bringt die Festplatten zum Glühen. Für jedes dieser kleinen Probleme bietet Ceph Konfigurationsmöglichkeiten, um größere Auswirkungen auf Latenzen und Durchsatz der Clients zu verhindern.

Neben dem Datenmanagement durch Ceph selbst wird das Cluster natürlich auch von vielen Clients beansprucht. In unserem Fall wollen virtuelle Maschinen aus OpenStack und OpenNebula an ihre Daten, verschiedenste WebClients wie GitLab, Nextcloud, Glance und andere senden Swift- und S3-Anfragen und ein zentrales NFS-Storage will natürlich auch Tag und Nacht bedient werden. Auch hier kann eine Begrenzung der Requests durch libvirtd, rate-limiting oder andere Mechanismen sinnvoll sein.

Kenne deine Anforderungen

Die Anforderungen der Clients an die Latenz und den Durchsatz des Storage-Systems können sehr unterschiedlich sein. Features wie Replikation und Verfügbarkeit werden mit erhöhten Latenzen erkauft. Große Festplatten mit Spindeln drücken die Kosten, allerdings sind auch nur noch wenige Benutzer und Anwendungen mit wenigen IOPs, höheren Latenzen und dem geringen Durchsatz zufrieden. Was für Archivdaten kein Problem ist, sorgt bei Datenbanken oft für unglückliche Benutzer. Schnellere Festplatten und eine geringe Latenz im Netzwerk verbessern die Situation erheblich, erhöhen aber auch die Kosten. Zudem ändern sich die Bedürfnisse der Clients auch im Laufe der Zeit. Dank Crush kann Ceph den unterschiedlichen Ansprüchen gerecht werden. Ein schneller SSD-Pool kann ohne Probleme parallel zu einem Datengrab auf langsamen großen Spindeln betrieben werden und auch eine Umschichtung der Daten ist jederzeit flexibel möglich.

Plane im Voraus

Neben eines Datenverlusts ist ein volles Cluster wohl eines der schlimmeren Szenarios. Um eine Beschädigung der Daten zu verhindern, werden bei 95% Füllstand keine weiteren Daten mehr angenommen. In den meisten Fällen macht dies den Storage unbenutzbar. Zu diesem Zeitpunkt hat man eigentlich nur zwei Möglichkeiten: Man kann versuchen, nicht mehr benötigte Daten zu entfernen, z.B. in Form von alten, nicht mehr benötigten Snapshots, oder man vergrößert den Cluster rechtzeitig. Hierbei sollte man bedenken, dass die Beschaffung und der Einbau der Hardware schnell mal 7 bis 14 Tage in Anspruch nehmen kann. Genügend Zeit zum Handeln sichert man sich durch verschiedene Thresholds, so dass der Cluster z.B. ab einem Füllstand von 80% warnt.

Ceph kann die klaren Erwartungen an ein modernes Storage-System in den meisten Fällen erfüllen. Die gegebene Flexibilität und die ständige Weiterentwicklung sichert eine einfache Anpassung an neue Anforderungen und ein sich ständig änderndes Umfeld. Somit ist mit etwas Planung, Monitoring und Liebe ❤ ein reibungsloser und stressfreies Betreiben über viele Jahre möglich.

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Out-of-Memory: Marathon 1.6+ und Heap Size

by | Jan 15, 2020 |

Auch wenn in Sachen Container Orchestrierung Kubernetes klar gegen Marathon und Mesos gewonnen hat bietet das Duo seit Jahren eine zuverlässig Plattform. Durch die stetige Weiterentwicklung und die Umstellung auf Systemd ändert sich leider auch immer wieder die Konfigurationen der Dienste.

Für einen stabilen Betrieb von Marathon sollte die maximale Heap-Size der Java Virtual Machine (JVM) eine angemessene Größe haben. Zu wenig Memory äußert sich z.B. durch erhöhte Antwortzeiten oder durch die Aktivierung des OOM-Killer. Wo in vergangenen Versionen und Konfigurationen noch die /etc/defaults/marathon zum Setzen der Javaoption verwendet wurde, kann man hier seit Marathon 1.6 vergeblich sein Glück suchen. Aus meiner Sicht ist ein Verzicht auf /etc/defaults/marathon und eine saubere Definition in einer systemd Unit-Datei natürlich zu begrüßen. Die Umgebungsvariablen lassen sich auch dort einfach definieren, aber wie genau muss das für Marathon aussehen?

# systemctl edit marathon.service
[Service]
Environment=JAVA_OPTS=-Xmx2g

Mit systemclt edit kann man eine bestehende Unit-Datei einfach erweitern und der Parameter Environment setzt die Umgebungsvariable.  Alternativ könnte man auch Environmentfile=/etc/defaults/marathon verwenden um das gewohnte Verhalten wieder herzustellen.

Nach dem Speichern braucht es einen Daemon-Reload, damit die neue Unit-Datei eingelesen wird.

# systemctl daemon-reload
# systemctl restart marathon.service

Eigentlich bleibt also alles beim Alten, man muss nur die zusätzlichen Parameter in die JAVA_OPTS setzen und den Service neu starten ?.

 

Achim Ledermüller
Achim Ledermüller
Senior Manager Cloud
Der Exil Regensburger kam 2012 zu NETWAYS, nachdem er dort sein Wirtschaftsinformatik Studium beendet hatte. In der Managed Services Abteilung ist er für den Betrieb und die Weiterentwicklung unserer Cloud-Plattform verantwortlich.
Read more from Achim and meet the Team

Trainings

Web Services

Events