base on # RKE2  RKE2, also known as RKE Government, is Rancher's next-generation Kubernetes distribution. It is a fully [conformant Kubernetes distribution](https://landscape.cncf.io/?selected=rke-government) that focuses on security and compliance within the U.S. Federal Government sector. To meet these goals, RKE2 does the following: - Provides [defaults and configuration options](https://docs.rke2.io/security/hardening_guide/) that allow clusters to pass the [CIS Kubernetes Benchmark](https://docs.rke2.io/security/cis_self_assessment123/) with minimal operator intervention - Enables [FIPS 140-2 compliance](https://docs.rke2.io/security/fips_support/) - Supports SELinux policy and [Multi-Category Security (MCS)](https://selinuxproject.org/page/NB_MLS) label enforcement - Regularly scans components for CVEs using [trivy](https://github.com/aquasecurity/trivy) in our build pipeline For more information and detailed installation and operation instructions, [please visit our docs](https://docs.rke2.io/). ## Quick Start Here's the ***extremely*** quick start: ```sh curl -sfL https://get.rke2.io | sh - systemctl enable rke2-server.service systemctl start rke2-server.service # Wait a bit export KUBECONFIG=/etc/rancher/rke2/rke2.yaml PATH=$PATH:/var/lib/rancher/rke2/bin kubectl get nodes ``` For a bit more, [check out our full quick start guide](https://docs.rke2.io/install/quickstart/). ## Installation A full breakdown of installation methods and information can be found [here](https://docs.rke2.io/install/methods/). ## Configuration File The primary way to configure RKE2 is through its [config file](https://docs.rke2.io/install/configuration#configuration-file). Command line arguments and environment variables are also available, but RKE2 is installed as a systemd service and thus these are not as easy to leverage. By default, RKE2 will launch with the values present in the YAML file located at `/etc/rancher/rke2/config.yaml`. An example of a basic `server` config file is below: ```yaml # /etc/rancher/rke2/config.yaml write-kubeconfig-mode: "0644" tls-san: - "foo.local" node-label: - "foo=bar" - "something=amazing" ``` In general, cli arguments map to their respective yaml key, with repeatable cli args being represented as yaml lists. So, an identical configuration using solely cli arguments is shown below to demonstrate this: ```bash rke2 server \ --write-kubeconfig-mode "0644" \ --tls-san "foo.local" \ --node-label "foo=bar" \ --node-label "something=amazing" ``` It is also possible to use both a configuration file and cli arguments. In these situations, values will be loaded from both sources, but cli arguments will take precedence. For repeatable arguments such as `--node-label`, the cli arguments will overwrite all values in the list. Finally, the location of the config file can be changed either through the cli argument `--config FILE, -c FILE`, or the environment variable `$RKE2_CONFIG_FILE`. ## FAQ - [How is this different from RKE1 or K3s?](https://docs.rke2.io/#how-is-this-different-from-rke-or-k3s) - [Why two names?](https://docs.rke2.io/#why-two-names) ## Security Security issues in RKE2 can be reported by sending an email to [[email protected]](mailto:[email protected]). Please do not open security issues here. ", Assign "at most 3 tags" to the expected json: {"id":"7424","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"